Recentemente, analisei alguns aspectos de segurança de sistemas de detecção de intrusão (IDS) baseados em observação de tráfego de rede. Observei que embora os sistemas de IDS via rede sejam bastante interessantes para detectar possíveis intrusões, estes sistemas possuem limitações que, caso não sejam endereçadas adequadamente, podem comprometer a funcionalidade dos mesmos.
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.