Cadastro Newsletter

Rodando o Snort: Preliminares

O principal objetivo deste artigo é apresentar de forma bem clara os requisitos mínimos para utilização do Snort em um ambiente simples, com apenas um sensor, utilizando as ferramentas auxiliares mais conhecidas. Não serão apresentados detalhamentos, mas direcionamentos, com intuito de eliminar a “nuvem” que aparece ao tentar o primeiro contato com esse NIDS – Network Intrusion Detection System.

A versão atualizada deste documento assim como outros artigos e dicas poderão ser encontrados no site da comunidade Snort no Brasil: http://snort.org.br.

O Caminho das Pedras

Serão listadas abaixo as etapas que envolvem as decisões mais importantes para implantação correta do Snort, mas sem muito detalhamento – isso poderá ser exposto em futuros artigos. A ordem da realização das etapas poderá mudar ligeiramente, dependendo do ambiente e da disponibilidade dos recursos. Essas etapas, quando bem executadas, tornam o aprendizado e o primeiro contato com o Snort mais fáceis.

Sistema operacional

Essa é uma etapa importante. O Snort pode rodar em plataformas específicas de hardware, como é o caso dos appliances da Sourcefire [1] – entretanto, usuários iniciantes utilizarão para aprendizado ou testes no ambiente de trabalho máquinas Intel, na maioria das vezes. Logo, deve-se escolher um sistema operacional com o qual o usuário tenha o mínimo de conhecimento. O autor sugere a utilização de Linux devido ao grande número de referências e documentação específica para este SO na Internet.

Neste ponto, também se define qual tipo de pacote de instalação será utilizado. No caso do Linux, recomenda-se a instalação do pacote padrão da distribuição, ou seja, caso o usuário utilize CentOS recomenda-se a instalação do pacote RPM referente ao software Snort dessa distribuição.

Armazenamento de Eventos

O Snort oferece várias maneiras de armazenar os logs dos dados de eventos gerados pelo IDS: em arquivo texto ou binário e nos banco de dados SQL listados abaixo:

• PostgreSQL;
• MySQL;
• UnixODBC;
• MS SQL Server;
• Oracle.

A opção de arquivo binário é sugerida para cenários mais avançados, onde o Snort necessita de maior desempenho ao armazenar e processar os eventos. Para ler mais detalhes sobre essa solução, Alejandro Flores escreveu um ótimo artigo sobre o tema: “Implementando o Barnyard com Snort”. O artigo está disponível na seção de documentos do site [2].

Recomenda-se a escolha de qualquer base SQL, assim como no caso da escolha de SO, de acordo com o nível de conhecimento do usuário e a disponibilidade da utilização. Essa configuração é feita através do parâmetro output database do arquivo de configuração.

Implementação e Localização do Sensor

O sensor é tratado como uma interface ou ponto de entrada de dados capturados. Todo evento detectado pelo Snort é associado a um sensor, que basicamente é encarado pelo SO como uma interface em “modo promíscuo” conectada a um dispositivo de rede. Nesse modo, a placa de rede repassa ao SO todo o tráfego recebido, incluindo dados não direcionados ao endereço da placa de rede onde se localiza o sensor.

Dessa forma, a localização dos sensores é um dos principais pontos a serem definidos na arquitetura do sistema de detecção. A melhor localização é encontrada ao se responder a pergunta: O que se deseja monitorar? A resposta para essa questão pode ser bem ampla como a própria pergunta: tudo. No entanto, quanto maior o tráfego na rede e a quantidade de servidores, aplicações e usuários, maior será o consumo de recursos do IDS: processamento, espaço em disco e memória etc., sem contar o custo de administração e tuning.

Assim, quanto mais específico, melhor, ou seja, mais fácil será configurar o ambiente para obter os resultados esperados. O NIDS pode ter um fim específico, desde o monitoramento de invasões e atividades maliciosas ao auxílio na depuração de problemas de rede.

Dentre as aplicações e motivações para implementação do NIDS, podemos destacar:

• Detecção de ataques com origem na Internet, incluindo probes ou portscans, worms e ataques direcionados (pentesting);
• Utilização indevida da Internet (downloads, covert channels, vazamento de dados);
• Geração de relatórios estatísticos (protocolos e serviços mais utilizados, incluindo tentativas de acesso ou verificação);
• Capacity Planning;
• Detecção de falhas de rede tais como interfaces com mau funcionamento, falha de arquitetura de rede (STP, roteamento etc.);
• Detecção de utilizadores de software legado ou aplicações que serão desativadas;
• Engenharia reversa de protocolos de comunicação;
• Auxílio na aplicação e gerenciamento de regras de Firewall;
• Identificação passiva de ativos de tecnologia.

Nos cenários acima, é comum se utilizar o sensor nos segmentos internos (redes específicas ou corporativas) ou nos ambientes externos (Internet, DMZ etc.). Não cabe aqui, no entanto, definir em qual segmento deverá ser implantado um sensor, mas apenas auxiliar na decisão, que dependerá de cada caso ou objetivo.

Vale lembrar que o sensor pode rodar em um único servidor ou máquina com fins específicos, sem necessidade de interface de rede em modo promíscuo. Um exemplo disso é um laboratório virtual para desenvolvimento de aplicações que se comunicam em rede.

Dependendo da aplicação, a localização do sensor pode inviabilizar a produção de eventos necessários ou ainda prejudicar o tuning ou a configuração para produzir tais eventos de maneira mais eficiente. Os cenários mais comuns utilizam port mirroring (espelhamento de portas) do switch ou hubs unindo os segmentos a serem monitorados. Além destes, existe ainda o mecanismo chamado network tap. Todos eles possuem características diferentes que influenciam diretamente no poder de vazão dos dados e, conseqüentemente, na performance da solução.

Recomenda-se a pesquisa e leitura sobre esse assunto, pois os métodos empregados fogem do propósito deste artigo. Na Internet existe muito material a respeito. Palavras-chave: network tap, port mirror, ids sensor.

Console para Visualização dos Eventos

Para o funcionamento do Snort é necessário basicamente uma biblioteca de captura de pacotes na rede, o driver da placa de rede e o próprio Snort, que é essencialmente um sniffer.

Entretanto, para armazenar os dados em uma base de dados SQL, é necessário uma API para que os eventos sejam armazenados em um banco de dados (que pode, inclusive, rodar na mesma máquina). Para visualizar os eventos, é necessário um software que apresente de forma simples os eventos persistidos na base de dados. Para configurar os parâmetros do arquivo snort.conf, pode-se utilizar outro software e assim por diante, cada software adicional com uma finalidade específica, como é o caso do Barnyard, já citado aqui.

Dos principais softwares para visualização dos eventos destacam-se o Acid, agora chamado de BASE. Ele necessita de um servidor web, pois disponibiliza as informações através de scripts escritos em PHP. Mais detalhes podem ser encontrados no site do projeto ^[3].

Existem outras consoles que podem ser baixadas do próprio site do Snort ^[4].

Mais pedras no caminho – erros durante a instalação

Após a verificação das etapas acima, o comando abaixo deve funcionar. Caso contrário, inicia-se a etapa de depuração de erros:

snort -i eth0 -T -N -u snort -g snort

Nesse caso, o Snort irá carregar o software necessário para capturar pacotes pela interface eth0 (parâmetro -i) apenas como teste (parâmetro –T) sem logar pacotes (-N) e utilizando as credenciais de usuário e grupo específicos do Snort para executar o processo snort.

Caso esteja tudo configurado corretamente, a saída abaixo será mostrada:

Running in packet logging mode 
Log directory = /var/log/snort 

        --== Initializing Snort ==--
Initializing Output Plugins! 
Verifying Preprocessor Configurations! 
Decoding LoopBack on interface eth0 

        --== Initialization Complete ==--

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.8.3.1 (Build 17)
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2008 Sourcefire Inc., et al.
           Using PCRE version: 6.6 06-Feb-2006


Snort sucessfully loaded all rules and checked all rule chains! 
Snort exiting

Se a saída apresentar algum erro ou não se parecer com o conteúdo mostrado acima, utilize o Google para encontrar a solução, colocando na caixa de busca o erro entre aspas. Exemplo:

Initializing Network Interface eth0 
ERROR: OpenPcap() FSM compilation failed: 
syntax error 
PCAP command: snort 
Fatal Error, Quitting...

Basta inserir no campo busca o texto “ERROR: OpenPcap() FSM compilation failed:” que serão apresentados vários links para fóruns e FAQs que discutem possíveis soluções. Outra opção é se cadastrar na lista de discussão do Snort-BR ^[5] para que outros usuários possam ajudá-lo.

Tuning – Arquivo de configuração Snort.conf

Enquanto essa etapa não funcionar, não há motivo para alterar ou editar o arquivo de configuração do Snort, snort.conf. Este só deve ser modificado após o Snort iniciar corretamente.

Essa etapa pode ser considerada como final no processo, apesar de ser constante, pois é aqui que são tratados os famosos eventos falsos positivos. Além disso, é nesse momento que o usuário irá fazer as seguintes etapas:

• Configuração de banco de dados (decisão apresentada acima);
• Configuração de pré-processadores;
• Configuração das variáveis (HOME_NET principalmente);
• Configuração de assinaturas;
• Configuração de módulos e plugins.

Dos pontos apresentados acima, o mais importante sem dúvida é a configuração de variáveis de ambiente, motivo pelo qual será abordado neste artigo.

Variáveis do Arquivo Snort.conf

No arquivo de configuração do Snort – snort.conf – existem várias variáveis que serão utilizadas, principalmente, na montagem das assinaturas. Logo, conclui-se que seu valor irá influenciar diretamente o comportamento do sensor, seja ao gerar eventos incorretos demais (falsos positivos) ou ao deixar de gerar eventos desejáveis, intrusões, ataques e outros eventos que se deseje monitorar.

A principal variável é HOME_NET, que deve ter como valor uma ou mais redes ou hosts a serem monitorados. Assim, caso essa variável seja mantida com o valor padrão (any - qualquer), qualquer IP será tratado como monitorado pelo Snort, o que irá gerar mais eventos e, conseqüentemente, mais falsos positivos e outros eventos indesejáveis.

Um evento é qualquer log gerado pelo Snort. Ele pode ser uma simples informação (uma consulta DNS) ou um ataque (pacote ICMP suspeito), ou ainda um indício de intrusão ou invasão (saída de um comando de listagem em um pacote HTTP).

Nesse contexto, faz algum sentido um ataque HTTP em direção a um servidor DNS? Pode ser que sim, caso seu sensor tenha como finalidade gravar todos os eventos para fins estatísticos; ou não, dada a quantidade de eventos e o conhecimento do analista de segurança acerca da arquitetura de firewall e servidores, só se faz necessário gerar alertas que envolvam conexões que realmente podem existir, com começo e fim.

Na prática, isso é configurado através das variáveis ou através da edição ou criação de regras de exclusão específicas (tópico um pouco mais avançado). No exemplo acima, trata-se da variável HTTP_SERVERS, que é utilizada nas assinaturas que geram alertas ou eventos de conexões ou ataques envolvendo o protocolo HTTP, geralmente implementado nas portas 80 e 443.

O ideal é testar pelo menos os valores das variáveis HOME_NET e EXTERNAL_NET, pois elas são utilizadas pela maioria das assinaturas. Com isso, verifica-se o comportamento no cenário utilizado. Uma boa prática, aplicável na maioria dos cenários, é definir um valor específico para HOME_NET e configurar o valor da variável EXTERNAL_NET para “tudo menos as redes definidas na variável HOME_NET”, ou seja, o valor ! $HOME_NET. Novamente, isso dependerá do seu cenário e deverá ser avaliado, de acordo com a necessidade.

Essas explicações servem apenas de incentivo ao leitor para utilizar de maneira eficiente as funcionalidades disponíveis no Snort. Qualquer modificação, seja em regras, pré-processadores ou variáveis, poderá influenciar no número de eventos gerados pelos sensores.

Manutenção e Atualização de Assinaturas ou Regras

Este é um dos tópicos mais polêmicos em relação ao Snort. Mesmo sendo um dos poucos NIDS que disponibilizam e permitem a total customização de regras, alguns usuários ainda não concordam com a metodologia utilizada pela empresa que mantém o Snort.

As assinaturas desenvolvidas pela equipe da empresa somente são disponibilizadas à comunidade (usuários registrados no portal do Snort) após 30 dias, pois são distribuídas sob a licença da equipe de desenvolvedores da Sourcefire – VRT (Vulnerability Research Team). Os detalhes da licença e da distribuição são apresentados em ^[6]. Esse é outro tópico que merece um artigo específico. Mais informações poderão ser encontradas nos links ^[7], ^[8] e ^[9]. O processo de atualização de assinaturas pode ser automatizado, e existem ferramentas específicas para esse fim, como o Oinkmaster ^[10].

Sobre o Autor

Alexandre Teixeira (alexandre.abreuΘgmail.com) é analista de segurança e especialista em soluções Open Source. Atualmente, trabalha em uma grande empresa do setor de telecomunicações. Possui as certificações SSCP, GCUX, RHCE, LPIC-2, SnortCP e outras. Dúvidas ou sugestões podem ser enviadas para seu email.

Links deste artigo

[1] Sourcefire: http://sourcefire.com

[2] Documentação no site do Snort: http://www.triforsec.com.br

[3] BASE: http://base.secureideas.net/

[4] Interfaces para o Snort: http://snort.org/dl/contrib/front_ends/

[5] Lista de discussão do Snort-BR: http://snort.org.br/index.php?option=com_content&task=blogcategory&id=19&Itemid=27

[6] Licença e distribuição de assinaturas: http://www.snort.org/about_snort/licenses/vrt_license.html

[7] Regras Oficiais: http://www.snort.org/vrt/

[8] White Hats: http://www.whitehats.com/ids/

[9] Emerging Threats: http://www.emergingthreats.net/

[10] Oinkmaster: http://oinkmaster.sourceforge.net/

Compartilhe

Comentários