Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Do que se trata o artigo:

Neste artigo serão expostos os conceitos da ferramenta Snort, seu histórico e definições de IDS. Também serão mostradas suas funcionalidades, exemplos práticos e, por fim, recomendações de boas práticas de segurança no uso em produção.


Em que situação o tema é útil:

O tema é útil para facilitar a compreensão do funcionamento do Snort, bem como sua utilização em ambientes corporativos. As boas práticas de segurança descritas no final do artigo fortalecem a implementação do Snort, reduzindo falsos positivos e otimizando o desempenho da ferramenta.

Resumo DevMan:

A palavra “segurança”, na era atual da informática, tornou-se um requisito mínimo em ambientes corporativos. Muitas organizações dependem da segurança para expor suas negociações, transações e/ou parcerias via Internet, para manter a proteção da informação e não perder a credibilidade com o cliente. Neste contexto, os Sistemas de Detecção de Intrusão, ou IDS, podem detectar ataques contra serviços disponíveis na rede privada e Internet e até evitar que o atacante possa efetuar algum dano à rede corporativa. Assim, abordaremos neste artigo o Snort, uma ótima ferramenta IDS.

Dentro do cenário empresarial, a informação é um componente valioso e imprescindível que muitas vezes determina quem lidera o mercado. Assim, empresas de todos os setores trabalham em cima deste valor tentando aprimorá-lo, enriquecê-lo e torná-lo privado, na medida do possível, especialmente por ser um elemento construído com o mérito de todos os ativos da empresa.

Quando falamos em informação empresarial dentro de um contexto contemporâneo, nos referimos à velocidade com que a informação é tratada, graças à tecnologia atual que permite o acesso de todos os ativos em tempo real. A denominada Era Digital (ver Nota DevMan 1) transformou a maneira com que as organizações tratam a informação. As máquinas, por sua vez, complementam e dinamizam toda rotina do ser humano, acelerando e enriquecendo os ativos da empresa.

A Internet é um dos principais responsáveis pela evolução da Era Digital, nos proporcionando novos meios para trocar informações, permitindo a comunicação em tempo real e de forma mais econômica, por utilizar um meio de comunicação já estruturado. Alguns exemplos de novas formas de comunicação são: conexão entre diversas filiais, parceiros e fornecedores (e-business); comércio eletrônico (e-commerce), serviços públicos fornecidos pelo governo (e-governance); etc. Com todas estas possibilidades, surgem também novos métodos de expor nossa informação e, consequentemente, são criadas novas formas de se obter a informação de forma inescrupulosa.

Ante todos estes pontos inicialmente mencionados, a seguinte questão é levantada: Qual é o real valor da informação nesta Era Digital, onde os computadores são imprescindíveis em um ambiente corporativo? A informação “é essencial para os negócios de uma organização e consequentemente necessita ser adequadamente protegida” [NBR 27002, 2005]. Diante de todos os pontos levantados e desta afirmação acima, percebe-se sua importância.

“As organizações, seus sistemas de informação e redes de computadores são expostos a diversos tipos de ameaças à segurança da informação, incluindo fraudes eletrônicas, espionagem, sabotagem, vandalismo, incêndio e inundação” [NBR 27002, 2005]. É notório que o risco envolve todos os segmentos da organização, cada um com um nível diferenciado. Este nível é a probabilidade de um incidente de segurança ocorrer em um determinado segmento, multiplicado pelo valor da informação no mesmo. Quando um incidente de segurança ocorre, seja ele acidental ou intencional, pode acarretar na perda de valores da organização. O prejuízo pode ser incalculável, principalmente se o ativo principal da organização for perdido: a informação. A informação digital também está susceptível aos incidentes de segurança e deve ser protegida com o mesmo rigor.

Na área da segurança digital existem diversos aplicativos e sistemas que protegem os níveis de rede da organização. O IDS é um dos sistemas que possui esta função. Sua proteção abrange do nível de enlace ao nível de aplicação da pilha TCP/IP, podendo alertar sobre anomalias na rede e até prevenir certos tipos de ataque.

Neste contexto, o Snort é uma ferramenta com funções de IDS via rede que, em comparação com os concorrentes de código-aberto, possui uma grande popularidade. O motivo é o seu método de funcionamento, que não demanda grande poder de processamento.

Com base nisso, neste artigo será abordada a estrutura de funcionamento do Snort, demonstrando a função de cada segmento que compõe a ferramenta. Também será abordado um exemplo prático com detalhes, bem como boas práticas de segurança.

Nota DevMan 1. Era Digital

Também chamada de Era da Informação, esta é a era caracterizada pela habilidade de o indivíduo trocar informações livremente, além de ter acesso instantâneo à informação. Algo que poderia ser difícil ou até impossível de ser realizado no passado.

Histórico

Lançada em 1998 por Martin Roesch, a ferramenta Snort (gratuita e de código-livre) foi uma das primeiras em seu segmento a realizar análise de tráfego em tempo real e registro dos pacotes de forma leve, utilizando recursos mínimos de processamento. À medida que o Snort foi amadurecendo, foi se tornando o padrão em IDS.

Mais tarde, em 2001, Martin Roesch fundou a Sourcefire com o intuito de atender a toda a demanda oferecida pela versão comercial do Snort. Pelo fato de as ameaças encontradas requererem uma resposta dinâmica, a Sourcefire reforça a segurança com o Time de Pesquisa de Vulnerabilidades Sourcefire (Vulnerability Research Team – VRT), que é uma equipe formada por especialistas em segurança que proativamente descobrem vulnerabilidades, malwares, atividades hackers e outras atividades maliciosas na rede. Em consequência, são criadas regras para o Snort identificar os pacotes suspeitos.

Snort

O Snort é uma ferramenta de código aberto que atua como IDS via rede (também chamado de NIDS – Network Intrusion Detection System), combinando inspeções em protocolos e assinaturas e, ainda, podendo identificar o ataque através do comportamento anormal do tráfego da rede. A forma de detecção dos ataques é baseada em regras (também chamadas de assinaturas), podendo ser adquiridas em [1]. O registro para obtê-las é obrigatório.

A eficiência da ferramenta se deve à equipe VRT, que atua ativamente para detectar as vulnerabilidades e criar as regras para proteger a rede. As regras são lançadas mensalmente. Na versão gratuita é possível obter as regras com um mês de atraso com relação às regras disponíveis na versão comercial.

Nas primeiras versões, o Snort possuía apenas a função de sniffer (ver Nota DevMan 2). Com os aprimoramentos, passou a gerar logs dos pacotes coletados para uma melhor compreensão e, com suas funções descentralizadas, obteve a função de IDS.

Nota DevMan 2. Sniffer

Sniffer é um analisador de pacotes que possui a característica de coletar pacotes que trafegam na interface de rede do computador para fins de depuração.

Componentes

Assim que os pacotes adentram a interface de rede, o Snort trata os pacotes de acordo com a Figura 1. Cada bloco possui uma função específica, auxiliando o Snort a realizar suas tarefas com agilidade. As definições de cada bloco são comentadas a seguir:

· Biblioteca de Captura de Pacotes: é um software a parte que insere os pacotes advindos da camada de enlace para o Snort. No Linux é o libpcap que faz esta tarefa, e no Windows é o WinPcap;

· Decodificador de Pacotes Snort: o decodificador recebe os dados, separa os quadros da camada de enlace da pilha TCP/IP, os pacotes IP, TCP e UDP, e classifica-os para uma análise posterior. Outros tipos de pacotes como IPX e AppleTalk não são reconhecidos;

· Pré-processadores: são plug-ins que operam em cima dos pacotes decodificados, desempenhando uma série de transformações, o que torna o acesso à leitura dos dados mais rápido para o Snort. Pré-processadores podem classificar, habilitar alertas ou descartar pacotes antes que sejam enviados à Engine. Ademais, podem ser habilitados ou desabilitados, a gosto do analista;

· Detecção (Engine): este é o núcleo do Snort. Ele coleta as informações do pré-processador e atua nas camadas de transporte e aplicação da pilha TCP/IP, comparando o conteúdo das informações dos pacotes com os plug-ins de Detecção. Nesses plug-ins estão as regras dos ataques conhecidos;

· Saída (plug-ins): quando um pré-processador ou regra é acionado, é gerado um alerta (ou uma resposta ao ataque) e um registro no log. O Snort suporta diversas formas de registro de log.

Figura 1. Componentes internos da ferramenta Snort.

Coletando os pacotes

A coleta dos pacotes pode ser feita de três formas:

· Modo bridge: permite que o fluxo de dados trafegue pelo Snort de forma transparente, fazendo uma espécie de “grampo” no segmento selecionado. Para tal, são necessárias três placas de rede, sendo duas para a bridge e uma para análise ou transmissão dos alertas/logs;

· Modo espelhamento: switches gerenciáveis possuem um recurso chamado de port monitoring ou port mirroring, com a função de obter todos os pacotes que passam pelas portas do equipamento e copiá-los para a porta configurada com a característica de espelhamento. A desvantagem de utilizar este recurso é a sobrecarga da CPU do switch, que acaba tornando a rede mais lenta. Em alguns casos, se a sobrecarga da CPU for alta, o port mirroring é desabilitado automaticamente, prejudicando a coleta do tráfego espelhado. Neste caso, duas placas de rede serão necessárias, sendo uma para coletar os pacotes e outra para análise ou transmissão dos alertas/logs;

· Modo TAP: neste modo um equipamento é instalado entre o switch e o servidor Snort, com a finalidade de copiar o tráfego ou até fazer a função de bridge, dependendo do modelo adquirido. São necessárias três placas de rede, duas para o TAP e uma para análise ou transmissão dos alertas/logs;

A escolha da forma de coleta depende da necessidade do administrador. Se desejar apenas levantar uma estatística ou realizar alguns testes, a forma de espelhamento é mais fácil de implementar. Caso contrário, o modo bridge ou o modo TAP são mais indicados, principalmente para aqueles que desejam utilizar o método de prevenção dos pacotes suspeitos (Intrusion Prevention System – IPS).

IDS e IPS

Há muita confusão quanto às diferenças entre IDS e IPS. O IDS age de forma passiva, apenas detectando anomalias e pacotes maliciosos, enquanto IPS age de forma ativa, atuando diretamente nas regras de firewall e/ou regras de outros serviços de segurança (TCPWrappers, por exemplo). Muitos entendem que IPS é separado do IDS, quando na verdade é uma função extra que o IDS pode proporcionar na detecção do ataque. O Snort pode atuar das duas formas.

Existem aplicativos no mercado que possuem apenas a função de IPS, porém só são funcionais se analisam os alertas de aplicativos IDS. Um exemplo é o Guardian, que age de acordo com os alertas que o Snort gera.

O IPS é vantajoso quando utilizado na borda da rede corporativa, pois ajuda a diminuir ataques de categoria zero day (ver Nota DevMan 3), vírus, worms e outros, impedindo a ação do atacante e evitando que a rede seja comprometida. Em contrapartida não é recomendável utilizá-lo na rede privada da organização, pois caso ocorra um falso positivo, a conexão entre servidores e clientes confiáveis ficará comprometida.

Nota DevMan 3. Zero day

Ameaças que ainda não foram descobertas pelos desenvolvedores e/ou pelas empresas de segurança.

Escolha do hardware

A escolha do hardware apropriado para suportar o Snort depende muito do fluxo da rede da organização. Quanto maior o fluxo de pacotes do segmento, mais potente deve ser o servidor. A seguir são analisadas algumas dicas para realizar a escolha mais adequada ao ambiente:

· CPU: os sensores de tráfego do Snort consomem bastante processamento. Portanto, quanto mais pré-processadores ativados, mais recursos da CPU serão utilizados. O indicado, neste caso, é escolher processadores que contenham mais de um núcleo;

· Memória RAM: a quantidade de memória RAM é analisada de acordo com o desempenho do Snort. Quando todo o espaço disponível da memória RAM é ocupado, o Snort perde desempenho e pacotes são descartados, por não conseguir analisá-los a tempo. Ao adicionar uma quantidade maior de memória RAM pode-se eliminar o problema;

· Disco Rígido: a recomendação é utilizar discos rígidos eficientes. A eficiência de um disco rígido consiste na Rotação Por Minuto (RPM) do mesmo, na transferência de dados por segundo suportada e outros detalhes como buffer de disco. Atualmente, discos com a tecnologia SAS (Serial Attached SCSI) são os mais indicados, em se tratando de servidores. Discos SATA (Serial ATA) de 3 Gb/s de transferência são uma alternativa de baixo custo;

· Placa de rede: a taxa de transferência das placas de rede deve ser compatível com a taxa de transferência da rede da organização. Placas com taxa de transferência inferior a ativos da rede (switch, por exemplo) podem congestionar o tráfego, interferindo na otimização e desempenho da rede. A escolha de uma placa de rede própria para servidores é mais indicada, pois foram projetadas especialmente para aplicativos de alto desempenho que requerem um grande tráfego de dados (como o Snort), além de outros recursos como criptografia via hardware e SNMP.

Localização dos servidores IDS

A Figura 2 representa uma típica rede corporativa, somando os pontos estratégicos de cada IDS. Analisando-os, é necessário que cada um possua um comportamento diferente, se adequando a cada situação. Abaixo é explicada a situação de cada IDS:

· IDS 1: conexão entre o roteador e o firewall, ou seja, o perímetro da rede. O reforço deve ser maior neste segmento, pois esta parte é a que se expõe à rede pública. O ideal é restringir ao máximo pacotes mal formados e ataques em camada de aplicação, como Buffer Overflow (ver Nota DevMan 4), malware e outros. A restrição é realizada com o Snort operando em modo IPS;

· IDS 2: conexão entre a rede privada da organização e parceiros/fornecedores/filiais (VPN). A união entre redes privadas via Internet requer um nível de segurança maior, podendo fornecer encapsulamento, criptografia e restrição de acesso, porém pode haver comportamento indevido de algum funcionário/parceiro insatisfeito com a sua organização. Deste modo, um IDS alertando pacotes que possam comprometer a rede pode ser o suficiente;

· IDS 3 e IDS 5: conexão entre o firewall e as DMZs. Ataques específicos a certos tipos de serviço neste segmento devem ser impedidos ou evitados. Estes IDSs devem agir como IPS em certas situações (de proteção aos serviços expostos à rede) e registrar os alertas restantes. Nota-se que já existe a proteção do IDS 1, então os IDSs 3 e 5 devem ser mais restritos em relação a certos tipos de ataque;

· IDS 4: conexão entre o firewall e o switch da rede privada. Neste segmento podem estar ligados diversos servidores privados (Intranet, por exemplo). Assim, é necessário adicionar um IDS para alertar sobre possíveis ataques internos. Sendo mais cauteloso, pode-se habilitar o modo IPS nas regras que comprometam a rede, como as que detectam o ARP Spoofing (Nota DevMan 5). Apesar dos switches gerenciáveis poderem impedir este tipo de ataque, nada melhor do que garantir a segurança com uma camada a mais;

· IDS 5: conexão entre o switch e as estações de trabalho. Ataques advindos da Internet neste segmento são raros, mas existem as ameaças internas, como ataques no mesmo segmento ou propagação de malwares. A decisão por implementar um IDS neste segmento vai depender do administrador e da situação da rede corporativa.

Figura 2. Simulação de uma rede corporativa para demonstrar os locais possíveis de instalação de um IDS.

Nota DevMan 4. Buffer Overflow

É um ataque que explora o mau funcionamento da aplicação ou protocolo no momento da escrita dos dados no buffer, permitindo a execução de código malicioso na memória adjacente.

Nota DevMan 5. ARP Spoofing

Técnica que o atacante utiliza para criar mensagens falsas do protocolo ARP dentro da rede local. O protocolo ARP não é orientado a conexão, permitindo que a associação entre um endereço MAC e um endereço IP seja armazenado na tabela ARP do equipamento, independente de quem enviou o pacote ARP. Esta vulnerabilidade permite a manipulação da tabela ARP de cada equipamento, possibilitando que o atacante finja ser qualquer equipamento pertencente à rede local.

Instalação

O Snort possui suporte a diversos sistemas operacionais (Windows, Linux, Mac OS, FreeBSD etc.), mas este artigo abordará apenas a instalação no Linux, pois há um número maior de documentação referente a esta plataforma.

Antes de começar a instalação do Snort, é necessário instalar as dependências a seguir:

· Libpcap: a Biblioteca de Captura de Pacotes (Library Packet Capture), como demonstrado anteriormente, faz a captura dos pacotes que adentram na placa de rede do servidor. Ela consta nos repositórios da maioria das distribuições. O download do código-fonte pode ser realizado em [2], caso seja necessário compilar manualmente;

· PCRE (Perl-Compatible Regular Expressions): as Expressões Regulares Compatíveis com Perl (em tradução livre) facilitam a consulta nos pacotes, otimizando a aplicação. Este recurso consta nos repositórios da maioria das distribuições. O download do código-fonte pode ser realizado em [3], caso seja necessário compilar manualmente;

· Libdnet: biblioteca que provê suporte aos protocolos das camadas 2 e 3 da pilha TCP/IP. Normalmente não consta nos repositórios das distribuições, portanto, é necessário fazer o download em [4] e compilá-lo com o comando ./configure && make && make install;

· DAQ (Data Acquisition): biblioteca que substitui as chamadas diretas das funções do PCAP (ver Nota DevMan 6) e inclui uma camada de abstração que facilita a operação em diversas interfaces de hardware e software, permitindo que o Snort tenha compatibilidade a elas sem ser modificado. É necessário compilá-la, pois não consta nos repositórios das distribuições. Disponível em [3];

· Barnyard: interpretador para o Snort que consegue ler a saída do tipo unified2, que é um formato binário, colhido da forma pura, sem tratamento. Permite que o Snort escreva no disco de forma eficiente e traduz a saída em vários formatos para análise posterior dos dados, em processos separados. Isto impedirá a perda de tráfego da rede. Não é obrigatório seu uso, porém pode melhorar o desempenho do Snort, principalmente se o tráfego de dados for muito grande.

Nota DevMan 6. PCAP

Abreviação de Packet Capture, utiliza a biblioteca libpcap para capturar os pacotes e pode, através do plug-in de output, converter os dados no formato PCAP para leitura. Este plug-in de output é a opção padrão do Snort.

Após as instalações das dependências, é hora de instalar o Snort. Disponível em [4], será instalada a versão em código-fonte ao invés de pacotes compilados, pois o procedimento é válido em qualquer distribuição Linux, bastando apenas instalar as dependências necessárias para compilação (de acordo com a distribuição escolhida). A versão utilizada é a 2.9.2.1. Assim, execute os seguintes comandos:


  # tar zxvf snort-2.9.2.1.tar.gz
  # cd snort-2.9.2.1
  # ./configure
  # make && make install

Um parâmetro interessante que pode ser inserido no momento da configuração da instalação do Snort (./configure) é o --prefix=</dir>. A função deste parâmetro é informar ao script de configuração o local de instalação do Snort, mas fica a critério do administrador do sistema modificar o caminho. Apesar desta opção, este parâmetro não será utilizado, sendo o Snort instalado no diretório padrão (/usr/local).

Concluída a instalação, é necessário instalar os plug-ins e as regras, contidas em [1], lançadas periodicamente pelo VRT. A versão do lançamento das regras sempre coincide com a versão do Snort. Portanto, se a versão utilizada do Snort é a 2.9.2.1, consequentemente a versão das regras a ser baixada é a 2921 (também disponível em [1]). A Listagem 1 demonstra o procedimento de instalação das regras e plug-ins.

Listagem 1. Procedimento de instalação das regras e plug-ins, disponibilizados pela VRT.


  # mkdir /etc/snort
  # tar zxvf snortrules-snapshot-2921.tar.gz –C /etc/snort
  # cd /etc/snort
  # mv etc/* .
  # rmdir etc
  # ls -l
  -rw-r--r--. 1 1210 1210    3621 Jan 12 15:17 classification.config
  -rw-r--r--. 1 1210 1210   28624 Jan 12 15:17 gen-msg.map
  -rw-r--r--. 1 1210 1210    1112 Jan 19  2010 open-test.conf
  drwxr-xr-x. 2 1210 1210    4096 Fev 22 23:51 preproc_rules
  -rw-r--r--. 1 1210 1210     666 Jan 12 15:17 reference.config
  drwxr-xr-x. 2 1210 1210    4096 Fev 22 21:17 rules
  -rw-r--r--. 1 1210 1210 2728300 Jan 12 15:19 sid-msg.map
  -rw-r--r--. 1 1210 1210   24116 Jan 12 15:17 snort.conf
  drwxr-xr-x. 4 1210 1210    4096 Fev 22 23:52 so_rules
  -rw-r--r--. 1 1210 1210    2556 Jan 12 15:17 threshold.conf
  -rw-r--r--. 1 1210 1210   53841 Jan 12 15:17 unicode.map

O conteúdo do diretório /etc/snort (também apresentado na Listagem 1) mostra diversos arquivos e subdiretórios. Cada um possui uma função que auxilia o Snort a classificar, priorizar, registrar e alertar contra diversos tipos de ameaças. O significado de cada arquivo e subdiretório está discriminado abaixo:

· classification.config: inclui informações para priorizar as regras, permitindo que os alertas sejam classificados e priorizados. É possível especificar que prioridade cada classificação possui;

· gen-msg.map: é usado para traduzir os IDs de todos os geradores de alertas no Snort, exceto os de Detecção (Engine). São necessários para o Barnyard;

· open-test.conf: arquivo de exemplo para carregar regras padrão. Serve para testar a ferramenta de uma forma rápida;

· preproc_rules: pasta que contém as regras de alertas relativas aos pré-processadores e decodificadores;

· reference.config: configurações de referências de sites de segurança. Todos os links que são adicionados neste arquivo são acrescidos aos alertas gerados, de acordo com cada regra de alerta;

· rules: pasta que contém as regras de alertas de saída;

· sid-msg.map: é usado para traduzir o ID encontrado em uma regra do Snort para uma variável. São necessários para o Barnyard;

· snort.conf: arquivo de configuração que carrega todas as regras, plug-ins, variáveis, base de detecção etc.;

· so_rules: aparentemente, as regras que constam nesta pasta não se diferem muito das regras da pasta rules. A diferença está na forma em que são lançadas, pois são regras que possuem acordos com terceiros para não serem divulgadas. Por padrão, não são carregadas;

· threshold.conf: serve para suprimir os alertas que se repetem com frequência, evitando que os arquivos de log se encham rapidamente;

· unicode.map: padrões de codificação dos logs cadastrados.

Configuração

A configuração do Snort pode ser realizada de duas formas: via parâmetros (ex.: snort -A full -i eth0 --daq-mode pcap) ou através do arquivo snort.conf. Neste arquivo é definido as regras, em quais IPs/redes o Snort deve observar, lista branca/negra, pré-processadores e outros detalhes. O arquivo original, obtido junto com as regras da equipe VRT, é totalmente intuitivo. Ele possui um roteiro de configuração que explica o que significa cada parâmetro, instruindo o administrador a configurá-lo da forma desejada.

Antes de configurar o Snort, é necessário ter em mente que ele possui três formas de funcionamento:

· Modo sniffer: apenas captura os pacotes no formato puro e mostra na tela. Seu comportamento é semelhante ao da ferramenta tcpdump. Exemplo de comando: snort -vde;

· Modo registro de pacotes: além de capturar os pacotes, possui a função de registrar todos os pacotes que entraram na interface de rede. Exemplo de comando: snort -vde -l /var/log/snort;

· Modo detecção/prevenção de intrusos na rede: modo que detecta e/ou previne intrusos na rede. É mais complexo, pois envolve várias etapas, conforme foi descrito na Figura 1. O snort.conf facilitará a configuração do sistema. Exemplo de comando: snort -c /etc/snort/snort.conf.

O arquivo snort.conf possui várias configurações, portanto, serão comentadas aqui apenas as principais opções que podem modificar o comportamento do Snort. A equipe VRT organizou os parâmetros do snort.conf em seções para facilitar a configuração e compreensão das opções. As seções estão definidas da seguinte forma:

· Configurar as variáveis: esta seção especifica as variáveis que serão utilizadas por todo o arquivo, inclusive pelas regras. Há variáveis de portas, serviços, rede etc.;

· Configurar o decodificador: são opções que alertam o sistema contra pacotes fora do padrão. O manual possui uma lista dos códigos de cada alerta que ele classifica;

· Configurar a base de detecção: define as opções gerais da base de detecção e os plug-ins disponíveis, como método de detecção, fila de eventos a serem registrados pelo mesmo pacote ou stream, ordem dos pacotes na fila e outras opções;

· Configurar as bibliotecas dinâmicas a serem carregadas: como o próprio nome diz, esta configuração informa ao Snort o caminho correto para as bibliotecas dinâmicas a serem carregadas;

· Configurar os pré-processadores: carrega os plug-ins de cada pré-processador e suas opções;

· Configurar os plug-ins de saída: configura a forma que o Snort irá reportar os alertas. O padrão é dentro de /var/log/snort;

· Personalizar a lista de regras de pré-processadores e decodificadores: possibilita escolher quais regras devem constar no momento da análise dos pacotes. Também permite criar regras para detectar um comportamento suspeito, além de habilitar regras extras;

· Personalizar sua lista de regras de objetos compartilhados (shared objects): possibilita escolher quais regras devem constar na análise dos pacotes. Esta lista é diferente da anterior, pois a equipe VRT não pode divulgar vulnerabilidades descobertas sem autorização. Outra diferença está na criação das regras: a lista comum de regras é criada na linguagem própria do Snort, enquanto a linguagem desta lista é criada na linguagem C, para facilitar a distribuição para outras plataformas.

Os parâmetros a seguir se referem àqueles que foram modificados para os testes:

· ipvar HOME_NET 192.168.1.0/24 – rede (ou host) a ser protegida. O parâmetro any significa qualquer IP;

· var RULE_PATH rules – informa a localização do diretório das regras gerais. Neste caso, no mesmo diretório do arquivo de configuração;

· var SO_RULE_PATH so_rules – informa a localização do diretório das regras de objetos compartilhados;

· var PREPROC_RULE_PATH preproc_rules – informa a localização do diretório das regras de pré-processamento;

· var WHITE_LIST_PATH rules – informa a localização da “lista branca” do Snort. É necessário criar um arquivo chamado white_list.rules;

· var BLACK_LIST_PATH rules – informa a localização da “lista negra” do Snort. É necessário criar um arquivo chamado black_list.rules;

· config daq: nfq – determina o módulo DAQ para a coleta dos pacotes. O módulo NFQ (Netfilter Queue) possui um novo método de manipulação dos pacotes em conjunto com o iptables e vai ser utilizado nos testes;

· config daq_dir: /usr/local/lib/daq – indica o caminho para os módulos DAQ;

· include $PREPROC_RULE_PATH/preprocessor.rules – inclui as regras dos pré-processadores necessárias para o teste;

· include $PREPROC_RULE_PATH/decoder.rules – inclui as regras dos decodificadores necessárias para o teste.

Não há a necessidade de alterar os outros parâmetros, pois serão suficientes para rodar o Snort sem falhas.

O teste a seguir será baseado em bloqueio de varreduras de portas, com o Snort em modo IPS (no modo inline) através do módulo DAQ chamado NFQ. Este módulo controla os pacotes que estão na fila das regras do iptables, decidindo o destino de cada pacote analisado. Quando a varredura do aplicativo malicioso é realizada, o Snort irá detectar esses pacotes maliciosos e não permitirá a passagem destes, impedindo o atacante de obter informações.

Figura 3. Ambiente de rede para realizar testes com o Snort.

A Figura 3 demonstra um exemplo de como o Snort pode se estabelecer na rede. Neste caso, o Snort está em modo bridge (ponte), ou seja, todos os pacotes que adentram na interface de rede eth0 passam pela interface eth1 (e vice-versa) de forma transparente, agindo como um switch. A conexão de uma bridge depende do pacote bridge-utils, que utiliza o comando brctl para criar a conexão. A Listagem 2 mostra como criar uma bridge e adicionar as duas interfaces de rede.

Listagem 2. Criação da bridge e adição das duas interfaces de rede.


  brctl addbr br0
  brctl addif br0 eth0
  brctl addif br0 eth1
  ifconfig eth0 0
  ifconfig eth1 0
  ifconfig br0 up

Nota-se que as interfaces eth0 e eth1 não podem, em hipótese alguma, obter endereço de rede. Os comandos ifconfig eth0 0 e ifconfig eth1 0 certificam que estas interfaces não possam ter endereço de rede configurado.

Os pacotes devem estar em fila (queue) para a análise do módulo DAQ NFQ, sendo assim, a Listagem 3 os põe nestas condições.

Listagem 3. Regras de iptables para colocar os pacotes em fila.


  iptables -A INPUT -j QUEUE
  iptables -A OUTPUT -j QUEUE
  iptables -A FORWARD -j QUEUE
  

Depois de tudo configurado, o Snort pode ser iniciado com o comando snort -c /etc/snort/snort.com -Q, onde o parâmetro -Q informa para o Snort atuar em modo inline (para permitir o modo IPS). A Listagem 4 mostra o comando executado e sua saída.

Listagem 4. Execução do Snort, incluindo sua saída.


  snort -c /etc/snort/snort.conf -Q
   
  Enabling inline operation
  Running in IDS mode
   
          --== Initializing Snort ==--
  Initializing Output Plugins!
  Initializing Preprocessors!
  Initializing Plug-ins!
  Parsing Rules file "/etc/snort/snort.conf"
  PortVar 'HTTP_PORTS' defined :  [ 80:81 311 591 593 901 1220 1414 1830 2301 2381 2809 3128 3702 4343 5250 7001 7145 7510 7777 7779 8000 8008 8014 8028 8080 8088 8118 8123 8180:8181 8243 8280 8800 8888 8899 9080 9090:9091 9443 9999 11371 55555 ]
  PortVar 'SHELLCODE_PORTS' defined :  [ 0:79 81:65535 ]
  PortVar 'ORACLE_PORTS' defined :  [ 1024:65535 ]
  PortVar 'SSH_PORTS' defined :  [ 22 ]
  PortVar 'FTP_PORTS' defined :  [ 21 2100 3535 ]
  PortVar 'SIP_PORTS' defined :  [ 5060:5061 5600 ]
  (...)
  +++++++++++++++++++++++++++++++++++++++++++++++++++
  Initializing rule chains...
  2873 Snort rules read
      2478 detection rules
      142 decoder rules
      253 preprocessor rules
  2873 Option Chains linked into 171 Chain Headers
  0 Dynamic rules
  +++++++++++++++++++++++++++++++++++++++++++++++++++
  (...)
  [ Number of patterns truncated to 20 bytes: 511 ]
  nfq DAQ configured to inline.
  The DAQ version does not support reload.
  Reload thread starting...
  Reload thread started, thread 0x7f8c45e03700 (7492)
   
          --== Initialization Complete ==--
   
     ,,_     -*> Snort! <*-
    o"  )~   Version 2.9.2.1 IPv6 GRE (Build 107) 
     ''''    By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
             Copyright (C) 1998-2012 Sourcefire, Inc., et al.
             Using libpcap version 1.1.1
             Using PCRE version: 8.12 2011-01-15
             Using ZLIB version: 1.2.5
   
             Rules Engine: SF_SNORT_DETECTION_ENGINE  Version 1.15  <Build 18>
             Preprocessor Object: SF_SDF (IPV6)  Version 1.1  <Build 1>
             Preprocessor Object: SF_SSLPP (IPV6)  Version 1.1  <Build 4>
             Preprocessor Object: SF_DNP3 (IPV6)  Version 1.1  <Build 1>
             Preprocessor Object: SF_MODBUS (IPV6)  Version 1.1  <Build 1>
             Preprocessor Object: SF_DNS (IPV6)  Version 1.1  <Build 4>
             Preprocessor Object: SF_DCERPC2 (IPV6)  Version 1.0  <Build 3>
             Preprocessor Object: SF_REPUTATION (IPV6)  Version 1.1  <Build 1>
             Preprocessor Object: SF_POP (IPV6)  Version 1.0  <Build 1>
             Preprocessor Object: SF_SIP (IPV6)  Version 1.1  <Build 1>
             Preprocessor Object: SF_GTP (IPV6)  Version 1.1  <Build 1>
             Preprocessor Object: SF_SSH (IPV6)  Version 1.1  <Build 3>
             Preprocessor Object: SF_FTPTELNET (IPV6)  Version 1.2  <Build 13>
             Preprocessor Object: SF_SMTP (IPV6)  Version 1.1  <Build 9>
             Preprocessor Object: SF_IMAP (IPV6)  Version 1.0  <Build 1>
  Commencing packet processing (pid=7492)
  Decoding Raw IP4

As informações geradas informam, passo a passo, as configurações e regras carregadas. O destaque em negrito é importante para sabermos se o Snort e o módulo DAQ NFQ estão sendo executados em modo inline.

A simulação de varredura de portas será realizada com o aplicativo chamado hping3, que possui a capacidade de gerar diversos tipos de pacotes da pilha TCP/IP personalizados. Neste caso, a técnica utilizada é a varredura de TCP com a flag SYN ativada e com o payload de zero byte, forçando a vítima a responder a requisição como se fosse uma solicitação de conexão TCP válida.

Supondo que o Snort não esteja em execução, a vítima irá responder às requisições feitas pelo hping3. Veja o comportamento deste aplicativo na Listagem 5.

Listagem 5. Comportamento do aplicativo hping3 quando o Snort não está sendo executado.


  hping3 --syn 192.168.1.102
  HPING 192.168.1.102 (eth0 192.168.1.102): S set. 40 headers + 0 data bytes
  len=46 ip=192.168.1.102 ttl=64 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=5.8 ms
  len=46 ip=192.168.1.102 ttl=64 DF id=0 sport=0 flags=RA seq=1 win=0 rtt=7.4 ms
  len=46 ip=192.168.1.102 ttl=64 DF id=0 sport=0 flags=RA seq=2 win=0 rtt=20.4 ms
  (...)

Com o Snort em execução, a saída do comando hping3 será diferente, conforme a Listagem 6.

Listagem 6. Comportamento do aplicativo hping3 quando o Snort está sendo executado.


  hping3 --syn 192.168.1.102
  HPING 192.168.1.102 (eth0 192.168.1.102): S set. 40 headers + 0 data bytes

Analisando o log de alertas do Snort em tempo real (tail -f /var/log/snort/alert), surgem os registros apresentados na Listagem 7.

Listagem 7. Log de alertas do Snort no momento do bloqueio do tráfego.

 
  [**] [129:1:1] Syn on established session [**]
  [Classification: Potentially Bad Traffic] [Priority: 2] 
  03/25-12:22:59.297441 192.168.1.103:2884 -> 192.168.1.102:0
  TCP TTL:64 TOS:0x0 ID:21260 IpLen:20 DgmLen:40
  ******S* Seq: 0x1867B5E  Ack: 0x5C027F24  Win: 0x200  TcpLen: 20
   
  [**] [129:1:1] Syn on established session [**]
  [Classification: Potentially Bad Traffic] [Priority: 2] 
  03/25-12:23:00.289089 192.168.1.103:2885 -> 192.168.1.102:0
  TCP TTL:64 TOS:0x0 ID:3267 IpLen:20 DgmLen:40
  ******S* Seq: 0x31A38B47  Ack: 0x2159E6A5  Win: 0x200  TcpLen: 20
   
  [**] [129:1:1] Syn on established session [**]
  [Classification: Potentially Bad Traffic] [Priority: 2] 
  03/25-12:23:01.289362 192.168.1.103:2886 -> 192.168.1.102:0
  TCP TTL:64 TOS:0x0 ID:29667 IpLen:20 DgmLen:40
  ******S* Seq: 0x1BC7846F  Ack: 0x5506B5A3  Win: 0x200  TcpLen: 20
   
  [**] [129:1:1] Syn on established session [**]
  [Classification: Potentially Bad Traffic] [Priority: 2] 
  03/25-12:23:02.289530 192.168.1.103:2887 -> 192.168.1.102:0
  TCP TTL:64 TOS:0x0 ID:65354 IpLen:20 DgmLen:40
  ******S* Seq: 0x2B1C05AC  Ack: 0x3DAAFC2  Win: 0x200  TcpLen: 20
  (...)

Analisando a saída do alarme, a primeira linha informa o tipo de ataque e um campo (ID) com três números, separados por dois-pontos. O primeiro ID informa qual componente do Snort gerou o alerta. Consultando o guia gen-msg.map (dentro de /etc/snort), é informado que o decodificador que gerou o alerta foi o stream5. O segundo ID é a identificação do alerta gerado de acordo com a regra criada. O terceiro ID, por fim, indica a revisão do alerta, sendo que neste exemplo não sofreu nenhuma alteração (o que é explicitado pelo número 1).

A segunda linha faz referência à classificação que o alerta recebeu e sua prioridade. Quanto menor o número, mais crítico é o alerta.

Da terceira linha em diante são apresentadas informações do pacote capturado (TTL, flag TCP, sequência, tamanho do cabeçalho, origem e destino e outras características do cabeçalho).

Concluindo o exemplo, percebe-se que o Snort conseguiu bloquear este tipo de ataque, informando nos registros de alerta qual decodificador agiu contra o ataque, dentre outras informações. Vale lembrar que os decodificadores atuam em um nível mais baixo (desde a camada de enlace até a camada de transporte da pilha TCP/IP) para detectar o ataque, porém há pré-processadores que auxiliam na busca de ataques na camada de aplicação.

Ajustes finos

O pleno funcionamento do Snort depende muito de um ajuste fino na ferramenta. A seguir, listamos algumas dicas para evitar falsos positivos (alarmes falsos), falsos negativos (alarmes que são ignorados, mas são legítimos), melhorias de desempenho e algumas dicas de segurança:

· Inclusão/exclusão de regras: dependendo do local físico onde o servidor IDS é instalado, certas regras não têm necessidade de serem inseridas. Ex.: se no segmento em que o Snort se encontra não há servidor web, não é preciso carregar regras para proteger servidores web. Isto diminuiria a carga da ferramenta Snort e eliminaria falsos positivos;

· Testes de bloqueio: a eficiência da ferramenta depende de testes no segmento em que o servidor IDS está localizado. A análise dos alertas em um determinado período vai informar ao administrador a rotina dos pacotes que adentram neste segmento. Em modo IPS, esta análise é de suma importância para bloquear os pacotes específicos. Para simular o bloqueio de pacotes pode-se utilizar o parâmetro --enable-inline-test ou inserir a linha config policy mode:inline_test no arquivo snort.conf;

· Definindo e configurando pré-processadores e decodificadores: de acordo com a análise da rotina dos pacotes que trafegam no segmento, é possível perceber que nem todos os pré-processadores e decodificadores serão necessários. O ajuste das opções dos pré-processadores e decodificadores é importante, pois cada um possui uma particularidade e fornece diversas opções de verificação. O manual de cada pré-processador/decodificador encontra-se no código-fonte do Snort, no diretório doc;

· Escolha do hardware: assunto abordado anteriormente, a escolha do hardware é importante para o desempenho da ferramenta Snort. Se o servidor não conseguir suportar a exigência da ferramenta, a análise dos pacotes pode ficar comprometida, havendo a perda de pacotes;

· Faça suas próprias regras: a ferramenta Snort permite a criação de suas próprias regras. Em seu manual é explicado com detalhes como criar um alerta personalizado, seja para uma nova descoberta de vulnerabilidade, seja para se adequar à situação da rede organizacional;

· Criptografia do tráfego de alertas: os logs armazenados, por padrão, ficam no formato PCAP. Apesar de ser ilegível utilizando um editor de texto comum, aplicativos que conseguem ler arquivos neste formato (tcpdump e Wireshark, por exemplo) podem ler os logs do Snort. Se os logs são registrados em outro servidor, estes dados devem ser criptografados, evitando interceptação. A criação de túneis criptografados é a solução para suprir a falta de segurança. VPNs (IPSec, OpenVPN, L2TP) ou aplicativos mais simples, como o stunnel (via SSH), podem criptografar os dados trafegados;

· Não execute o Snort como root: a execução de serviços com privilégios de super usuário não é recomendada. Ataques de Buffer Overflow podem usurpar a aplicação e obter os mesmos direitos de execução, podendo ter total acesso ao servidor. O recomendado é criar um novo usuário e um novo grupo com privilégios restritos. Obs.: alguns módulos DAQ só aceitam serem executados com privilégios de super usuário;

· Utilize o Barnyard: à medida que o fluxo de pacotes aumenta o Snort não consegue mais tratá-los, tornando-o mais lento e ocasionando o descarte de novos pacotes. O modo output chamado unified2 permite um número maior de pacotes por segundo a ser analisado, pois guarda estes valores em binário e não em modo texto. O Barnyard lê estes logs gerados e converte-os para o formato desejado (PCAP, syslog etc.).

Aplicativos e dicas que facilitam o gerenciamento do Snort

O gerenciamento e monitoramento da ferramenta Snort não é uma tarefa simples, mas existem ferramentas que podem facilitar o trabalho do administrador de redes. Aqui serão mencionadas as mais utilizadas apenas.

· Oinkmaster: é uma ferramenta escrita em Perl que atualiza automaticamente as regras através da base de dados da equipe VRT, substituindo as regras existentes. Esta ferramenta manterá sempre o seu Snort apto a detectar as últimas ameaças descobertas pela equipe VRT. O ponto fraco está no método de atualização, que substitui as regras anteriores pelas novas adquiridas pelo aplicativo. Uma forma de evitar isto é separar as regras modificadas/criadas em outro diretório e adicioná-las no snort.conf. Assim, é aconselhável realizar uma cópia de segurança do arquivo snort.conf para o caso de falha na execução do Snort. A ferramenta Oinkmaster está disponível em [5];

· BASE (Basic Analysis and Security Engine): esta ferramenta, em conjunto com diversas dependências (MySQL, PHP, Apache, ADODB), facilita a visualização dos alertas gerados pelo Snort, através de uma interface web. O Snort registra seus alertas no banco de dados do MySQL e o BASE realiza a consulta, informando na interface web os tipos de protocolos capturados, com detalhes de cada um. Os logs podem ser registrados no banco através da opção output database: alert, <tipo_banco>, dbname=<banco>, user=<usuário>, pass=<senha>. Observação: a ferramenta em questão é baseada no antigo ACID (Analysis Console for Intrusion Database), que está descontinuado. Disponível em [6];

· SnortAlog: semelhante ao BASE, porém mais enxuto. Tem a capacidade de ler todos os tipos de outputs disponíveis no Snort e gera gráficos em formatos JPEG, PNG e GIF. Disponível em [7];

· SnortSam: aplicativo que substitui o método tradicional de IPS do Snort, bloqueando o tráfego manipulando as regras do firewall do servidor. Sua estrutura é separada em duas partes: a primeira fornece uma nova opção de output para o Snort, chamada alert_fwsan; e a segunda é o agente instalado no servidor, que manipula o firewall do sistema (o agente funciona em Linux, Windows e até em firewall Cisco). O ponto fraco da ferramenta é a configuração das regras, porque é necessário acrescentar o parâmetro fwsam em cada regra desejada. Disponível em [8];

· Guardian: substitui o método tradicional de IPS do Snort, semelhante ao SnortSam, porém não utiliza de agentes nem output específico. O bloqueio do tráfego é realizado, também, manipulando as regras do firewall. O Guardian é mais simples de configurar, porém suas opções são limitadas. Disponível em [9];

· IDScenter: um front-end gráfico que gerencia alertas, regras e opções do Snort. Bastante intuitivo, adapta aqueles administradores que não estão acostumados com a famosa tela preta. Funciona apenas em Windows. Disponível em [10].

Conclusão

O Snort é o IDS open source mais utilizado no mundo, por sua robustez e precisão na geração de alertas de pacotes suspeitos. Sua estrutura descentralizada favorece o desempenho e escalabilidade, podendo adicionar novos recursos sem modificar seu núcleo. A equipe VRT mantém as regras atualizadas constantemente, melhorando sempre a precisão do Snort em encontrar pacotes maliciosos, e a possibilidade de criar regras personalizadas amplia a detecção de novos ataques, permitindo a colaboração para a comunidade Snort.

O gerenciamento e o monitoramento são complexos, o que é uma desvantagem da ferramenta. Porém, existem diversos aplicativos que auxiliam na administração do IDS, além de acrescentar funcionalidades extras ao Snort.

Além das opções demonstradas neste artigo, existem muitas outras que permitem ao Snort se adaptar ao ambiente desejado, exigindo do administrador um alto conhecimento sobre elas. Por isso, é sempre recomendado contar com a ajuda do manual disponível no código-fonte para utilizar as melhores opções.

Mesmo assim, a eficácia do Snort na rede organizacional depende de um estudo para saber quais são os pontos mais vulneráveis a ataques, com análises de tráfego de cada segmento em um determinado período. Esta análise é importante para determinar quais regras serão utilizadas no Snort, bem como os pré-processadores/decodificadores ideais.

Por fim, vale ressaltar que configurar o Snort é um processo árduo e demorado. Depende de diversos ajustes finos, análises de desempenho, testes, redução de falsos positivos e negativos. No entanto, quando se chega a um ponto estável, faz todo o esforço valer à pena. Afinal, uma camada de segurança a mais é sempre bem-vinda.

Links

Download das regras do Snort [1]
http://www.snort.org/snort-rules/

Site oficial do tcpdump (sniffer) [2]
http://www.tcpdump.org

Download do Snort e dependências [3]
http://www.snort.org/snort-downloads

Site oficial do Libdnet [4]
http://libdnet.sourceforge.net/

Site oficial do Oinkmaster [5]
http://oinkmaster.sourceforge.net/

Site oficial da suíte BASE [6]
http://base.secureideas.net

Site oficial do SnortAlog [7]
http://jeremy.chartier.free.fr/snortalog/

Site oficial do SnortSam [8]
http://www.snortsam.net

Site oficial do Guardian [9]
http://www.chaotic.org/guardian/

Site oficial do IDScenter [10]
http://www.engagesecurity.com/products/idscenter/

Manual do Snort
http://www.snort.org/assets/166/snort_manual.pdf

Passo-a-passo para instalar o Snort com o BASE no Fedora
http://www.rootninja.com/snort-ids-basic-analysis-security-engine-base-fedora/

Livros -Snort for Dummies por Charlie Scott, Paul Wolfe e Bert Hayes

Normas -Tecnologia da Informação – Técnicas de Segurança – Código de Prática para a gestão de segurança da informação pela ABNT NBR ISO/IEC 27002:2005