|
Detectar
intrusos |
|
Comparando
com o modelo baseado em rede, onde um dispositivo fica "ouvindo"
todo o tráfego de rede, o modelo de host é baseado no uso de agentes.
De uma forma geral, todos eles possuem um pequeno programa (agente), instalado
no sistema que se quer proteger. Este agente é responsável por analisar,
o mais rapidamente possível, vários indicadores do sistema, como logs,
níveis de uso de CPU, que usuários estão conectados, etc... Com base nas
suas regras pré-programadas (sejam elas baseadas em assinatura ou perfis,
ou ambos), o agente decide gerar ou não alarmes. Caso o alarme seja gerado,
ele freqüentemente é enviado a um servidor central (chamado de "gerente")
que pode tomar outras ações adicionais (chamar o operador por pager, gerar
log, etc...). O
tipo de informações que um agente pode monitorar, o grau de sofisticação
com o qual ele monitora essas informações e que tipo de ação ele pode
tomar variam de sistema para sistema. No geral, todos eles permitem monitorar:
· Logs do sistema operacional.
No caso de Windows NT, os diversos EventLog. No caso de Unix, o log controlado
pelo syslog. Nesses logs são armazenados eventos básicos, como auditoria
de arquivos, logins bem sucedidos ou não, início e término de programas,
entre outros.
Contadores ou indicadores do sistema. Nesse caso, são monitorados aspectos
como consumo de CPU (via Performance Monitor do NT ou sar do Unix), espaço
disponível em disco e consumo de memória, entre outros. Embora sejam dados
não diretamente relacionados à segurança, uma mudança nestes parâmetros
pode indicar que algo mudou significativamente. Como exemplo, caso um
servidor esteja sendo utilizado indevidamente para tentar quebrar senhas
(com programas como L0phtcrack ou Crack, por exemplo) o consumo de CPU
poderá ser notadamente maior.
Alguns outros sistemas de detecção de intrusão via host também permitem
a monitoração de outros logs, especificados pelo usuário. Nesse caso,
podem ser monitorados os logs de programas que, por um motivo ou outro,
não usam os logs do sistema. Nessa categoria podemos incluir sistemas
de banco de dados, servidores de autenticação (como Radius/Tacacs), servidores
Web, entre outros. Nesses casos, o agente deve ser "treinado"
em o que deve ser analisado do log. Com
todas essas características, os IDS baseados em host acabam por oferecer
vantagens significativas para o implementador de IDS. A principal delas
é que a qualidade da informação coletada. Como o log a ser gerado pela
aplicação pode ser o resultado de uma longa transação, por exemplo, é
possível detectar ataques ou situações que uma análise dos pacotes individuais
não mostraria. Outra
vantagem do modelo de IDS de host é que, como o agente é especializado
para um determinado sistema operacional, ele pode inspecionar características
desse sistema não acessíveis via rede. Existem diversas vulnerabilidades
conhecidas, tanto em Unix como em NT, que só podem ser exploradas por
usuários locais. É comum que indicadores dessas vulnerabilidades (ou de
tentativas de exploração delas) não sejam percebidas por quem está "fora"
do sistema, como um IDS de rede. Por
outro lado, é importante conhecermos as limitações dos IDS de host. Em
primeiro lugar, um IDS de host é significativamente mais trabalhoso de
implementar, pois necessita agentes em todos os equipamentos a serem protegidos.
Se estamos falando de 200, 300 servidores, pode ser um impacto grande
ter que instalar e configurar agentes em todos eles. Outro
problema com IDS de host é a não existência de um agente para o sistema
operacional em questão. São poucos os produtos que possuem suporte a uma
gama variada de sistemas operacionais. A maioria tende a suportar Windows
(mesmo assim quase sempre somente NT), Solaris e talvez outro tipo de
Unix, como HP-UX, AIX ou Linux. De que adianta um IDS que não suporta
a plataforma desejada? Outro
ponto a ser observado diz respeito à qualidade da informação inicial.
Caso os logs observados pelo IDS não indiquem os eventos desejados em
um grau de detalhe adequado, o IDS não pode extrair nada dali. No caso
de um sistema que inspecione o syslog de Unix, por exemplo, não podemos
detectar possíveis incidentes com o daemon de DNS (ou de FTP) se o mesmo
não foi configurado para gerar logs no syslog (ou se o IDS não foi configurado
para coletar os logs em outro lugar). Finalmente,
outro ponto diz respeito à segurança do próprio daemon (ou serviço) do
IDS. Como o IDS roda no próprio sistema, caso um atacante consiga obter
acesso privilegiado (root/Administrator) ele pode desabilitar o agente
do IDS. Caso não exista nenhum mecanismo de checagem periódica, a intrusão
poderá não ser detectada. Ao final de nossa análise técnica sobre IDS, espero que tenha ficado claro que um sistema de detecção de intrusão pode ser um excelente acréscimo ao conjunto de mecanismos de segurança da organização. Um IDS pode indicar atividades suspeitas no ambiente, levando a equipe de segurança a identificar uma intrusão ou uma tentativa de intrusão. Ou seja, no final das contas, ainda há muito trabalho a ser feito depois de instalado os mecanismos de detecção de intrusão.
|