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.