Snort - IDS, Configurações e Assinaturas

1. Em que consiste um IDS:

A detecção de intrusão tem as suas raízes nos sistemas de auditoria financeira às Mainframes. Os acessos tinham que ser cuidadosamente controlados, dessa forma foram criados mecanismos de segurança capazes de permitir aos administradores analisar logs em busca de anomalias que indicassem mau uso ou alterações aos ficheiros não autorizados. Este é o principio de detecção de intrusões, ou IDS (Intrusion Detection Systems).

A ideia por detrás deste tipo de sistema é simples, um agente monitoriza actividade dos ficheiros num host ou no tráfego da rede e reporta as situações anómalas que possam ocorrer ao administrador.

O mercado encontra-se dividido em duas vertentes: host-based e network-based.

1.1 Host-Based IDS

Adicionam uma camada alvo de segurança a uma aplicação particularmente vulnerável ou a sistemas essenciais. Um agente monitoriza por exemplo um servidor de base de dados, audita e mantém um trilho, logs do sistema de situações anómalas, permissões, etc. O agente pode ainda empregar o checksum regularmente dos principais ficheiros do sistema e regularmente verificar se estes foram alterados, permitindo desta forma parar um ataque se detectado. Apesar da função primária do sistema ser de enviar logs e alertas.

1.1.1 Vantagens:

· Pode detectar tanto externamente como internamente misuse, algo que as redes e as firewalls não conseguem.

· Quebras de segurança são mais prováveis internamente que um hacker fora da empresa.

· Hosts –Agents são uma ferramenta poderosa para endereçar uma autorização e aceder a itens e que tornam a segurança tão complexa.

1.1.2 Desvantagens:

· Os agentes instalam-se directamente no host a ser monitorizado, consumindo dessa forma recursos, tendo que ser compativel com o OS do host.

· Pedir quais as exigencias do agente em termos de memória e de CPU, pois variam de vendedor para vendedor.

1.2 Network – based IDS

Este localiza-se na LAN, ou num segmento, e monitoriza o trafego da rede pacote a pacote em tempo real (se possível), por forma a verificar se um qq ataque coincide com as assinaturas já predeterminadas, padrões de ataque já conhecidos.

Exemplo, o TearDrop Denial of Service envia pacotes fragmentados duma maneira que crash o sistema alvo. O agente reconhece este padrão e toma-o em consideração.

O Vendedor fornecerá a base de dados das assinaturas dos ataques, bem como os administradores podem personalizar determinadas assinaturas. O IDS alerta o administrador e nalguns casos pode tomar acção de terminar a ligação. Também guarda os ataques para posterior analise. Poderá ainda ser ligado a outros sistemas, por exemplo FireWall por forma a garantir que estes não apresentam brechas.

1.2.1 Vantagens:

· acompanhamento Real time do alarme. Valioso para ataques DoS.

· Colecção. Os administradores poderão analisar não apenas o que poderia saír danificado, como poderão indicar falhas na segurança para correcção. Muitos hacker, primeiro fazem um scan à rede para detectar vulnerabilidades

· São independentes do OS

· Requer um nó dedicado que assente no segmento a monitorizar e uma NIC configurada em modo promiscuo. Requer ainda uma ligação segura entre o monitor e a consola.

1.3 Como implementar um IDS

Será incluir na política de segurança do sistema. Uma política de segurança definirá a arquitectura básica da rede, e descreve como a rede será segura, estabelecendo uma hierarquia de acessos por parte dos utilizadores e de recursos.

Verificar muito bem, definir, os recursos necessários (humanos, técnicos, software, hardware, necessários à implementação de um IDS. Poder-se-á optar por uma implementação ou outra ou uma mistura de ambas. Tudo depende do grau de segurança requerido para a informação, do orçamento disponível, e os recursos diponíveis para gerir o sistema.

Host based estão limitados a um servidor e custam menos que um Network based, no entanto estes últimos cobrem uma vasta área da rede.

Network monitors tem dificuldade com o transito encriptado. Se a information estiver encriptada IDS não conseguem decifrar o pacote, não prevenindo dessa forma um eventual ataque.

A encriptação não impede os agentes de host, porque os dados são decifrados antes que um agente de host os veja.

Sensores de rede poder-se-ão tornar num ponto de estrangulamento numa rede de elevado débito, degradando dessa forma a performance e frustando os utilizadores. De acordo com um white paper da ICSA, uma network based IDS poderá gerir até 65 Mbits/sec do tráfego antes que a performance do motor de analise decresça.

1.4 Manutenção

A questão dos logs, preparar o sistema, dependendo do número de agentes de monitorização, dedicar bastante espaço de armazenamento para os logs. Terá que assegurar uma elevada segurança ao armazenamento dos logs por forma a que os hackers não possam alterar, ou apagar, esses logs que evidenciam as intrusões.

Como os produtos anti-vírus, uma assinatura de um ataque identificável por um IDS conduz a que a base de dados de assinaturas do IDS esteja actualizada com a mais recente informação, tenha a certeza que está a questionar por updates com a frequência necessária. Pequenas variações podem ser o suficiente para alterar uma eficaz detecção.

1.5 Lidando com os incidentes.

Quando instalar um IDS, esteja preparado para o caso dele funcionar. Tenha preparado um plano para lidar com intrusões assim que as detectar. Criar uma equipe capaz de lidar com os incidentes é um importante primeiro passo. Esta equipe dependerá do tamanho e recursos da empresa, mas cada membro da equipa deverá ter bem definido as suas funções e responsabilidades.

Deverá ser criada uma politica incident-handling que esteja orientado para os contactos da equipe e informações desta. Procedimentos incluem Backup um determinado disco, ou determinar se é necessário contactar um especialista externo ou as forças da lei.

Neste último caso trona-se um pouco complicado tomar esta decisão, pelo que se torna necessário criar uma politica bem definida.

1.6 Será um IDS o mais certo para a sua empresa

IDS ainda é uma tecnologia em maturação, em desenvolvimento, e nem toda a comunidade está convencida da sua viabilidade. Comparado por vezes à guerra das estrelas – caro e ineficaz.

É claro que caro é um pouco relativo, pois um IDS pode não ser barato, o custo de um ataque de DoS e a má imagem que provoca podem facilmente justificar o investimento.

Quanto à eficácia um IDS não é uma solução implementa e esquece, é uma solução que exige constante actualização, uma politica de segurança rigida, um constante acompanhamento dos logs, por forma a retirar o máximo partido deste esquema.

Desta forma IDS será uma mais valia na segurança do sistema.

O principal objectivo deste documento é dar uma visão global do que é o SNORT, um IDS do tipo Host-based, fornecendo as indicações necessárias, os passos a dar para instalar e configurar o produto.

2. O que é o SNORT?

É um Sistema de Detecção de Intrusões (IDS)

Suporta inspecção tanto ao header como payload, permitindo desta forma reduzir os falsos positivos.

Capacidades de alertas/logs bastante fléxiveis

Capacidade de resposta bastante limitada

Corre na maioria dos sistemas UNIX, Windows e MacOSx (desde que o OS permita a compilação e instalação da livraria libpcap).

Free (GPL) – disponível o código fonte segundo o standard GNU general public license.

Adaptação via a sua arquitectura plug-in, permitindo desta forma criar uma funcionalidade que necessitemos.

2.1. Instalação do SNORT para Linux/Unix

1. Instalar pré-requisitos:

a. Libpcap – verificar se já se encontra instalada

b. Se não estiver instalada obter por:

ftp://ftp.ee.lbl.gov/libpcap.tar.Z ou http://www.tcpdump.org

2. Obter o package SNORT disponivel em: http://www.snort.org

Nota: para verificar se a libpcap (uma aplicação capaz de capturar pacotes da rede), se encontra instalada utilizar os comando “locate” ou “find” ou mesmo “whereis”. Se se encontrar instalada mas o sistema ainda reporta erros, verificar se as livrarias pertencentes à libpcap podem ser encontradas via as variáveis de ambiente (variável de ambiente LD_LIBRARY_PATH )

3. gunzip e untar o código fonte:

a. mv /home/myself/snort-1.8.6.tar.gz /usr/local/src

b. cd /usr/local/src

c. gunzip –c snort-1.8.6.tar.gz | tar xvf –

4. Configurar o código fonte:

a. cd snort-1.8.6

b. ./configure [mais as opções desejadas]

Nota: o SNORT permite a configuração de várias opções que activa determinadas capacidades e instala plug-ins fornecidos por outros utilizadores. Quando se utiliza o SNORT pela primeira vez é recomendável a não activação de qualquer destas opções, permitindo desta forma a instalação correcta do SNORT e a certeza de que tudo funciona correctamente.

5. make – no caso de haver o relatório de erros no fim, uma das causas mais frequentes é o facto do directório que contem as livrarias do libpcap não constar das variáveis de ambiente LD_LIBRARY_PATH.

6. make install

7. Construção das regras:

a. As regras são utilizadas pelo programa por forma a saber o que tem que procurar, ou estar atento.

b. Disponíveis em vários sites:

http://www.snort.org e em http://www.whitehats.com

Deve-se indicar ao programa, a que é que ele deve estar atento, isto é feito através de linhas de comando únicas num ficheiro. Cada linha contém o que é denominada por regra, também conhecida por assinatura. Cada regra define que acção deverá ser tomada (alerta, log, etc) quando determinado tipo de assinatura é encontrado. As default rules podem ser obtidas através de diferentes fontes e são um óptimo começo. O descarregamento de um conjunto de regras pré-definidas permitem rapidamente configurar o SNORT e colocá-lo em funcionamento até o utilizador se sentir confortável para escrever as suas próprias regras.

Para utilizar um conjunto de regras, fazer o download das mesmas e realizar algumas alterações no topo do ficheiro. As alterações típicas necessárias fazer no SNORT são as indicações da ‘home’ subnet ou IP são, que IP’s pertencem aos Servidores Web, etc.

8. Executar o SNORT:

Snort –c <ruleset>

Execução do Snort especificando o conjunto de regras que se fez o download, utilizando a opção ‘–c ‘ e o nome do ficheiro de regras.

9. Notas finais:

a. A versão final encontra-se disponível via CVS (Concurrent Version System).

b. É fácil de se manter a par das últimas versões e patches bastando para tal a execução do seguinte comando:

i. Cvs –

ii. d:pserver:anonymous@cvs.snort.sourceforge.net:/cvsroot/snort login

iii. cvs –z3 –

iv. d:pserver:anonymous@cvs.snort.sourceforge.net:/cvsroot/snort co snort

No caso de se pretender fazer a instalação utilizando RPM basta para tal fazer:

Realizar o download do ficheiro: snort-1.8.4-1snort.i386.rpm e snort-plain+flexresp-1.8.4-1snort.i386.rpm e ainda o libnet-1.0.2a-1snort.i386.rpm

Fazer:

rpm –Uvh snort*.rpm libnet*.rpm
Temos agora os binaries snort-plain+flexresp na directoria /usr/sbin
Sendo como no anterior, criada a directoria /var/log/snort.

10 .Instalação na versão para Windows

a. Instalar a Winpcap fazendo o download de: http://netgroup-serv.polito.it/winpcap

b. Fazer o download e descomprimir a versão SNORT para Windows e de seguida executar snort.exe

Quando se instala o Snort pela primeira vez, utilizar a flag ‘-W’ por forma a identificar a placa de rede em que o SNORT irá escutar.

A flag ‘-W’ irá mostrar uma lista contendo as várias interfaces de rede por forma a selecionar a que queremos. Desta forma, quando executarmos o Snort podemos faze-lo recorrendo à opção ‘–i <inteface>’ para indicar qual o interface que o Snort irá utilizar.

3. Modos de utilização

Existe três níveis básicos de operação do Snort, como:

1. Sniffer

2. Packet logger

3. NIDS – Network Intrusion Detection System

Cada um destes modos prende-se com um modo particular para análise de tráfico. O modo de operação é definido pelos switches em modo de linha de comando.

3.1 Em modo de Sniffer

Em modo de Sniffer o programa lê todos os pacotes de uma rede e faz o dump de cada pacote num modo descodificado e capaz de ser compreendido, para um dispositivo de saída.

Para activar o modo de sniffer, temos os seguintes switches:

3.1.1 –v: verbose mode

3.1.2 –d: dump packects payloads com os headers

3.1.3 –a: mostra os pacotes ARP da rede.

3.1.4 –e: display link-layer data

O modo ‘-e’ display o link-layer data que para o Ethernet é o header do pacote, no entanto o Snort suporta também os header do Token Ring e do FDDI.

Combinando todos os switches temos uma visão muito detalhada do tráfego da rede.

3.2 Em modo de Packet Logger

Neste modo o Snort regista todos os pacotes que se encontram relacionados com um ficheiro ou directório. O switch que permite activar este modo é ‘–l’, e quando activado permite registar os pacotes das directorias em vigilância bem como os endereços IP dos hosts envolvidos, colocando os pacotes em ficheiros por protocolo e número das portas.

Os pacotes podem ser registados ou logged no formato binário se for especificado o switch ‘-b’, podendo desta forma preservar os pacotes para que uma aplicação capaz de manusear ficheiros em raw TCPDump.

3.2.1 Linhas de comando:

· –l <logdir>: Despeja os pacotes no ficheiro <logdir>

· –b: Regista os pacotes no formato binário (tcpdump)

3.2.2 Exemplo:

‘snort –l /usr/var/log’

‘snort –b –l /var/log/snort’

3.3 Em modo Plain text logging

Quando os pacotes são registados utilizando a funcionalidade disponibilizada por defeito, estes são registados num formato human-readble idêntico ao formato no modo verbose. Os pacotes são registados em ficheiros e directórios baseados nos endereços IP.

3.3.1 Se for utilizado o modo ‘-h’ “homenet”, por forma a especificar os termos de registo da rede interna:

· Pacotes são registados em directórios com nomes que são os endereços IP dos hosts não pertencentes à rede interna.

· Muito útil para ver de relance quem está a “bater à porta” da nossa rede.

Inconvenientes:

· Ao gerar um ficheiro por protocolo/porta temos um problema, e se alguém fizer um port scan aos 65.536 ports?

· Temos 65.536 TCP + 65.536 UDP = 131.072 ficheiros criados, é possível numa única directoria, mas será possível analisar?

· Talvez seja boa ideia utilizar o log em modo binário.

3.3.2 O que fazer com os logs em modo binário?

Velocidade e portabilidade, são as palavras chave para se optar por esta configuração.

· Ficheiros em modo binário estão no formato de TCPDump

· Podem ser lidas pelo SNORT utilizando o switch ‘-r’:

Exemplo: snort –dvr /var/log/snort/snort.log

3.4 Em modo NIDS

Esta é a parte interessante do Snort, quando em modo NIDS é carregado com uma configuração contendo uma data de regras e directivas em run-time. Uma vez a correr neste modo, é capaz de analisar o tráfico de uma rede em real-time procurando condições que permitem gerar alertas e logs dos pacotes ofensivos.

3.4.1 Carregar um conjunto de regras, configurando os plug-ins da análise dos pacotes, permitindo monitorizar a rede por indícios hostis.

3.4.2 É o Snort ao nível mais complexo.

3.4.3 Configuração básica consiste em especificar meramente o ficheiro de configuração:

Snort –c snort.conf

3.4.4 Configuração por defeito:

·        Output para o directório: /var/log/snort

·        Alert mode: full

·        Logging mode: ASCII dump

3.4.5 Opções a nível da linha de comandos:

Existe uma variedade de opções de comandos disponíveis neste modo, que irão ser apresentados nesta secção. Os alertas podem ser desactivados ao mesmo tempo utilizando o switch “none”, no entanto o logging decorre normalmente.

3.4.5.1 Com o ‘-l’ é possível especificar uma directoria alternativa para o log

3.4.5.2 Especificar um modo de alerta alternativo:

a. ‘-A <mode>’: fast, full, none, console, (unsock)

O modo ‘unsock’ é ainda um tanto experimental, e coloca o Snort a escrever os pacotes e alertas para um socket UNIX por forma que um ouvinte externo possa receber os dados.

b. ‘-s’: alertas são descarregados no syslog

Por defeito a funcionalidade syslog e nível é LOG_AUTHPRIV e LOG_ALERT.

c. ‘-M <wrkstation>’: envia alertas SMB para uma máquina com o SO Windows a correr o WinPopup. De realçar que é necessário, explicitamente, activar este modo no script de configuração, uma vez que é um tanto ou quanto perigoso a sua utilização num sensor.

3.4.5.3 Especificar um modo de alerta alternativo

· ‘-b’: modo de log binário (tcpdump)

· ‘-N’: desactivar os logs

3.4.6 Exemplos de utilização do modo NDIS

3.4.6.1 Log para um determinado directório:

‘snort –c snort.conf –l /var/snort’

3.4.6.2 Log em modo binário para um directorio com alertas em modo fast

‘snort –c snort.conf –l /var/snort –b –A fast’

3.4.6.3 Desligar o logging mas deixar os alertas para o syslog

‘snort –c snort.conf –N –s’

4. Configuração do SNORT como um IDS

Nesta secção irá ser tratada de um modo exaustivo a configuração do SNORT e os ficheiros de configuração a utilizar por forma a integrar um sistema de detecção de intrusões numa rede. O ficheiro de configuração (snort.conf) é o principal mecanismo para configurar todo o conjunto de opções disponíveis. No ficheiro snort.conf estão incluídas variáveis, opções de saída, e regras são especificadas.

4.1 Configuration file settings

Existem algumas palavras reservadas no que respeita à configuração.

4.1.1 INCLUDE

· Faz com que um ficheiro seja incluído no ficheiro de configuração

· Os caminhos absolutos tem que ser especificados, se os ficheiros não se encontrarem no mesmo directório que o ficheiro de referencia. O Snort não segue qualquer variável de ambiente.

· Includes – são utilizados no ficheiro snort.conf por forma a incluir regras dos ficheiros ou a configuração local.

· Primáriamente utilizada na ‘master’ config

· Pode ser utilizada em qualquer ficheiro config/rule

· O formato é do género: Include <ficheiro>

· Exemplo:

Include web_exploits

Include /etc/snort/buffer_exploits

4.1.2 Adicionando livrarias aos ficheiros de configuração

Geralmente o ficheiro ‘master’ config é denominado snort.conf, e os ficheiros contendo as regras são carregadas através do mecanismo ‘include’.

4.1.3 Variáveis

Outras das palavras reservadas no Snort é ‘var’, e permitem ao utilizador especificar um valor e vê-lo propagado pelo resto do ficheiro de configuração do sistema em run-time.

· Especificando uma variável, permite modificar num único local um valor que se propaga por toda a configuração config/rule.

· Aumenta a portabilidade de um determinado conjunto de regras.

· Especificada a nível da linha de comando pelo switch ‘-S’, a variável será passada ao ficheiro de regras.

· Exemplo:

‘var HOME_NET 10.1.1.0/24’

· Existe uma variável especial que permite ao utilizador detectar automaticamente e configurar o endereçamento da rede de uma variável. Normalmente, essa variável é definida referenciando ‘$<intf>_address’, que automaticamente procura o IP e a netmask de um interface específico e retorna esse valor para a variável de referencia.

‘var HOME_NET $eth0_address’

· Se atribuir simultaneamente um valor a nível da linha de comando e a um conjunto de regras à mesma varíavel, a variável definida ao nível de comando irá sobrepor-se à mesma variável definida no conjunto de regras.

· Formato:

‘var <nome_da_variavel> <valor>’

‘var HOME_NET 192.168.5.0/24’

alert tcp any >$HOME_NET 6666 \ (msg: “IRC”;)

· As variáveis poderão ter valores por defeito definidas, o que traz vantagens e desvantagens. As vantagens é permitir o utilizador não se preocupar em definir a nível de comando a variável, Para definir o valor por defeito de uma variável basta:

$<nome_da_variavel>:-<valor_por_defeito>

‘var HOME_NET $(HOME_NET:-10.1.1.0/24)

4.1.4 Mensagens – opções das variáveis:

Pode-se definir uma mensagem a ser exibida se uma determinada variável não estiver definida.

Formato:

$(<var_name>):?<message>)

var HOME_NET $(HOME_NET:?HOME_NET não definida!)

Saída:

Initializing rule chains…

ERROR test-lib(3) : HOME_NET não definida!

4.1.5 Linha de Comando Overrides

Para definir variáveis a nível de comando deve-se especificar a opção ‘-S’, de seguida especificar o nome da variável que se quer definir seguido de um sinal de igual e depois o valor:

‘snort –c snort-lib –S HOME_NET=192.168.5.0/24’

‘snort –c snort-lib –S HOME_NET=192.168.5.0/24 –S WEB_SERVER=192.168.5.44

aqui mostra como definir multiplas variáveis numa única linha de comando.

4.1.6 SNORT Data Flow

No diagrama a seguir apresentado, é demonstrado o percurso que um pacote é sujeito quando tratado pelo Snort:

Nesta imagem temos a forma como o pacote é tratado pelo Snort.

· O pacote é capturado pela Libpcap e é enviado para o descodificador (decoder). O descodificador pega no pacote e preenche uma estrutura de dados com o conteúdo do pacote, preenchendo as porções que definem o tipo de pacote.

· Os Preprocessadores pegam na estrutura criada pelo descodificador e podem dessa forma manipular o conteúdo da estrutura.

· A estrutura é então passada ao motor de detecção onde as regras são aplicadas por forma a determinar se o pacote gera um alerta, ou só é feito o log, etc.

· O estado de saída, se atingido, é onde o pacote pode ser logged ou alertar.

4.1.7 A função do Preprocessador (Preprocessors)

Permitem ao Snort analisar e manipular o tráfego de pacotes em muitos aspectos tais como: Normalização do tráfego, IP defragmentation, TCP stream reassembly, etc

Executam na ordem com que são referenciados no ficheiro de configuração ou seja se aparecer um fragmento IP, significa que deverá ser tratado pelo desfragmentador antes de ser passado ao TCP stream reassembler.

Significa isto que os preprocessadores a nível de protocolo deverão ser especificados antes dos que se situam a nível aplicacional.

Exemplo:

‘preprocessor http_normalize:80 8080’

Os preprocessors são activados e configurados via directives no ficheiro de configuração

Formato:

Preprocessor <nome>:<argumentos>

<nome>= nome do módulo do preprocessador

<arguments>= lista de argumentos do preprocessador

Exemplo do ficheiro de configuração:

Os argumentos são únicos para cada um, é ler o comentário no snort.conf acerca dos formato correcto.

‘preprocessor portscan: $HOME_NET 3 4 portscan.log’

A configuração funciona de modo muito simples, o preprocessador directive instrui o ficheiro de configuração do Snort a procurar na lista disponível dos preprocessadores pelo nome que cumpre a directive. Se esse nome for encontrado, dá-se a iniciação da função do preprocessador por forma a tratar dos argumentos, neste ponto configura-se e é adicionado à execução da lista de preprocessadores dentro do Snort.

Notar que se um dado preprocessador é compilado mas não activado pelo Snort, não existe qualquer CPU overhead, pode ser considerado dead code.

4.1.8 Plug-Ins (Preprocessors)

Os plug-ins permitem aos autores manipularem e analisarem os pacotes do tráfego. Snort manuseia pacotes completamente descodificados para o preprocessador a um nível que este pode fazer quase tudo com o pacote antes de o enviar para o motor de detecção ou detection engine.

Existe grande número de preprocessadores disponíveis e muitos mais estão a ser neste momento escritos, no entanto fica aqui a referência a sete dos que fazem parte da instalação por defeito:

· http_decode: normaliza o tráfego web para analise de assinaturas

· PortScan: detecta portscans

· Degfrag: efectua a desfragmentação dos IP

· Stream: efectua a reassemblagem do TCP Stream

· Minfrag: analiza os pacotes por pequenos fragmentos

· SPADE: Statistical Packet Anomaly Detection Engine

· Unidecode: normaliza o trafego UNICODE HTTP

· Outros disponíveis são: ARP watch, traceroute analisys, etc

4.1.9 Saída de dados

O Snort permite uma configuração muito fléxivel no que respeita à apresentação dos resultados. Dentro do ficheiro de configuração as opções de saída podem ser activadas pela especificação duma directive de saída, seguido do nome do modulo que se quer utilizar.

4.1.9.1 Output:

· Especifica alertas e logging plug-ins a serem utilizados

· Podem ser especificados vários (‘stacked’)

· Switches em modo de linha de comandos adicionam regras especificadas no ficheiro de configuração.

‘output log_tcpdump: snort.log’

4.1.9.2 Se for especificado um plug-in de saída output, dentro do ficheiro de configuração, não é necessário especificar o correspondente switch na linha de comando para esse mecanismo de saída, no entanto é de realçar que o modo de linha de comando sobrepõe-se ao definido no ficheiro de configuração.

4.1.9.3 Configuração:

· Os plug-in de saída são configurados com directivas, tal e qual os preprocessadores.

· Os argumentos variam conforme o plug-in de saída que utilizarmos.

‘output database: log, mysql, user=snort dbname=snort host=localhost’

4.1.9.4 Plug-ins:

Por defeito acompanham o Snort na instalação os seguintes plug-ins:

· Alert_fast: Alertas rápidos em modo de texto

· Alert_full: Alertas em texto com os full headers

· Alert_smb: SMB (WinPopup)

· Alert_syslog

· Alert_Unixsock

· Log_tcpdump: logs dos pacotes em modo binário tcpdump

· Database

· XML: alertas ou logs para um ficheiro em XML

Outros módulos que se poderá encontrar incluem SNMP, CIDF (Common Intrusion Detection FrameWork) e IDMEF (Intrusion Detection Message Exchange Format)

4.1.10 Plug-ins de Detecção (detection)

Menos visíveis que outros módulos, são parte integrante das regras em vez de terem linhas na configuração dedicadas a estes. Serão discutidos mais adiante.

4.1.11 Mexendo o caldeirão

Após juntar todas as opções, é uma missão relativamente facilitada. A sequencia de desenvolvimento do ficheiro de configuração começa por especificar as variáveis, depois os pré-processadores e as directivas de saída, e depois as regras. Uma vez configurado, as opções em modo linha de comando serão pois utilizadas por forma a optimizar a configuração.

4.1.12 Uma configuração exemplo:

#var HOME_NET $eth0_ADDRESS

var HOME_NET 10.1.1.0/24

var EXTERNAL_NET any

var DNS_SERVERS 10.1.1.253/32

Preprocessor defrag

Preprocessor stream: timeout 10, ports 21 23 80, maxbytes 8192

Preprocessor http_decode: 80 8080

Preprocessor portscan: $HOME_NET 4 3 portscan.log

Preprocessor portscan_ignorehosts: $DNS_SERVERS

Output log_tcpdump: snort.log

Output alert_syslog: LOG_AUTH LOG_ALERT

Output database: log, mysql, user=fernando dbname=snort host=dbhost

Include web.rules

4.2 Regras do SNORT (RULES)

A linguagem de escrita das regras foi desenvolvida de modo a ser simples de ler, escrever e entender. São relativamente simples, no entanto, bastante flexível e parametrizável. Esta simplicidade não permite por vezes, detectar determinado tipo de ataques como por exemplo portscan, nestes casos deve-se usar um pré-processador. O sistema de regras do snort em si, é completamente stateless, os pré-processadores foram acrescentados por forma a permitir a stateful packet analysis.

· As regras são suficientes para detectar a maioria dos ataques

· Para eventos/ataques de multi-pacote são geralmente detectados com pré-processadores

· http://www.snort.org/snort_rules.html

4.2.1 O que são as regras?

Ao definir as regras estamos a dar indicação de qual o tráfego na rede vai ser hostil. Regras definem quem está envolvido (origem e destino das máquinas), até ao que é considerado hostil (por exemplo um ataque smurf ou má configuração das flags TCP). Podem ser escritas por forma a serem muito específicas, à procura de um determinado pacote de dados, ou de atributos específicos dos pacotes, inclusive especificar um determinado IP ou porta.

4.2.2 Anatomia básica

Uma regra é dividida em duas partes. A primeira, rule header, define quem está envolvido por forma ao tráfego ser considerado pelas opções das regras. A segunda, rule options, define o que deve estar envolvido. Aqui está incluída a informação do header do pacote (tais como as flags do TCP) ou o conteúdo do pacote (payload).

· Sintaxe especifica para cada parte.

· É necessário ter sempre a rule header, ao passo que as rule options não.

· As regras podem conter múltiplas linhas se for usado o “\”.

4.2.3 Rule header

O cabeçalho é a primeira porção de cada regra. Define o protocolo de rede e ‘quem’ (who) está envolvido. Para cada campo individual, existe muitas opções, com uma sintaxe definida, que poderá ser utilizada por forma a especificar valores simples, conjunto ou grupos.

Notar que o motor de detecção do Snort parte o pacote para comparação em duas partes, correspondendo a cada uma da parte da regra. A primeira compara o cabeçalho da regra com a do pacote. Se o pacote não encaixa no perfil de um dos cabeçalhos das regras o motor de detecção passa para o pacote seguinte. Se o pacote não encaixa com o perfil do cabeçalho da regra, o motor de detecção continua a testar o resto das opções da regra.

O primeiro cabeçalho da regra é o campo de acção ‘action field’. Este instrui o Snort sobre o comportamento a ter se a regra é disparada. Existem actualmente cinco tipos de valor para a acção a tomar:

Alert: cria uma entrada no ficheiro de alertas e faz o log do pacote. O ficheiro de alerta é único e contém registo de todas a detecções realizadas. A informação escrita para este ficheiro no modo por defeito consiste apenas no cabeçalho do pacote.

Log: este instrui o Snort a criar apenas um registo no log, não realizando qualquer registo do tráfego no ficheiro de alertas.

Pass: quando a regra é disparada mas tem ‘pass’ especificada na acção, o Snort irá fazer o drop do pacote, e não fará qualquer tipo de processamento do pacote. É útil para fazer a monitorização de tentativas anónimas de ftp para um servidor ftp anónimo.

Activate: estas regras quando disparadas não se limitam a alertar, mas também são utilizadas para activar outras regras (dynamic) que ficam em modo suspenso até serem activadas.

Dynamic: permanecem suspensas até serem activadas por uma regra de activação. Uma vez activadas o seu comportamento é idêntico às das regras “log”.

É possível ainda definir, parametrizar, tipos de acção, que podem ser utilizados por forma a mapear uma saída para vários destinos.

Nota: A ordem normal das regras é processada nas regras de alerta primeiro, Pass em segundo e log por fim. Se quisermos modificar o comportamento por defeito, é necessário especificar a opção ‘-o’ que permite modificar a ordem que as regras são processadas. A opção ‘-o’ foi desenvolvida para o modo “expert”.

4.2.3.1 Acção : Rule Header Action

O primeiro campo do rule header é o campo correspondente a uma acção. Este instrui o Snort ao que é suposto fazer caso a regra seja activada. Existe três valores que poderá assumir:

Alert: instrui o Snort a criar um registo no ficheiro de alertas e a fazer o log do pacote. A informação escrita neste ficheiro no modo por defeito consiste apenas na informação do cabeçalho do pacote. Para o registo de log, a mesma informação que é feita para o ficheiro de alertas, também é escrita para uma estrutura de directórios e colecção de ficheiros individuais.
Log: não é feito qualquer registo do tráfego no ficheiro de alertas apenas é criada uma entrada no log.
Pass: quando uma regra é activada com a acção ‘pass’ o Snort deixa cair, ‘drop’, o pacote e não fará qualquer outro tipo de processamento. Útil para monitorizar por exemplo tentativas anónimas de ligações ftp a servidores ftp não anónimos.
Activate: quando disparadas estas regras não só alertam como são utilizadas para activar outras regras (dinâmicas).
Dynamic: são activadas pela acção da regras ‘activate’ e quando activas comportam-se como as de ‘log’.

É possível definir tipos de acções que podem ser utilizadas para dirigir a saída da regra para vários destinos. A ordem com que as regras são processadas é a mesma descrita no ponto anterior.

4.2.3.2 Protocolo : Rule Header Protocol

O campo referente ao protocolo indica ao Snort qual o tipo de tráfego na rede a que a regra se destina ou aplica.

Suporta normalmente três tipos diferentes de tráfego: TCP, UDP e ICMP.

4.2.3.3 IP origem : Rule Header Source IP

Neste campo é especificado qual a origem do trafego. É possível especificar uma origem IP desde algo genérico como uma subnet até a um host especifico. É possível também especificar múltiplos endereços ou subnets como a origem, quando necessário, utilizando uma sintaxe especial introduzida no Snort versão 1.7. Especificar múltiplos endereços IP é feito recorrendo a uma IP List.

Os endereços são especificados na notação CIDR (Classless Inter Domain Routing), incluindo dessa forma os endereços IP bem como o numero de bits da mascara de rede.

Em situações em que a regra usa as duas direcções de tráfego (inbound/outbound) o campo de direcção deve ser ‘<->’, representando a origem como o destino do tráfego sendo emparelhado com a porta do mesmo lado do campo de direcção.

Exemplos:

24.0.0.0/8= Classe A

135.1.1.0/16= Classe B

192.168.5.0/24= Classe C

192.168.5.5/32= Endereço do Host

Keywords:

Any – corresponde a todos endereços

! – nega endereços (!192.168.5.5/24 – todos excepto o 192.168.5.5)

$HOME_NET – variável definida algures no ficheiro de regras

Para especificar uma lista de endereços IP na notação CIDR, deve-se separá-los por uma virgula ‘,’ e colocar toda a lista utilizando para tal parêntesis rectos ‘[endereçoIP/netmaks,endereçoIP/netmask]’, não deixando espaços.

4.2.3.4 Porta de origem : Rule Header Source Port

Define de que porta de origem no host de origem é que o tráfego é originado. Pode ser especificado como um número, um conjunto, ou ainda a palavra chave ‘any’ representa todos as portas possíveis.

De notar que o protocolo ICMP não utiliza portas definidas como o TCP ou o UDP. Como a regra requer sempre uma lista de portas para origem e para destino, no entanto elas deverão ser incluídas para regras destinadas ao protocolo ICMP. No entanto o Snort para este protocolo irá ignorar o valor das portas, mas tradicionalmente especifica-se sempre ‘any’.

Formatos válidos:

Portas estáticas: 110

Todas as portas: any

Range: 33000:34000

Negação: !80

Menor que ou igual a: :1023

Maior que ou igual a: 1024:

4.2.3.5 Direcção do tráfico: Rule Header Traffic Direction

O campo de direcção permite especificar o sentido da direcção do pacote. Duas opções estão disponíveis, permitindo especificar a direcção do fluxo ou que determinada direcção não interessa. As opções válidas são:

· ->, define a origem e o destino

· <>, direção do pacote não interessa (bidirecional)

Utilizando a notação ‘->’, especificamos que o pacote deverá viajar da origem para o destino. A origem é especificada à esquerda e o destino à direita. Se o pacote se encontra em transito na direcção oposta o pacote não passa no teste do cabeçalho da regra pelo que não será inspeccionado mais pelo resto da regra.

4.2.3.6 Endereço IP de destino : Rule Header Destination Address

O endereço de destino especifica para onde o tráfego hostil se dirige. É especificado da mesma forma que o formato utilizado para o endereço de origem.

4.2.3.7 Porta de destino : Rule Header Destination Port

Define a porta de destino na máquina de destino a que o pacote se destina. É utilizado o mesmo formato que no caso da porta de origem.

4.3 Opções disponíveis nas regras – rule options

As opções são uma segunda porção na definição da regra. Define ‘o quê’ da regra – que atributos do pacote devem ser inspecionados e quais os valores que devem conter para ser considerado hostil. Esta porção é somente usada se o pacote cumpre com os requisitos do cabeçalho da regra.

Se o pacote cumpre com os requisitos do cabeçalho bem como o das opções, então a regra é activada ‘triggered’. Dependendo do tipo da regra, podem ser tomadas diversas acções. A mais comum é a de uma mensagem de alerta escrita para um ficheiro de alertas e o pacote ser registado no ficheiro de log. Temos assim que as opções:

· Definem ‘o que’ está envolvido

· Indica ao Snort que pacotes devem ser inspecionados

· Designa uma assinatura de um ataque ou sonda especifica.

4.3.1 Sintaxe

As opções deverão estar limitadas pelos parentsis ‘( )’, permitindo desta forma identificar mais facilmente as duas partes da regra, não são opcionais.

O conteúdo das opções é feito por pequenas partes individuais. Constituindo primeiramente dos atributos e valores do pacote, consiste também de acções que queremos que o Snort tome (alert, log ou pass).

A sintaxe utilizada é a mesma para os atributos do pacote e acções a tomar. Geralmente consiste num atributo ou acção keyword seguido de um valor. Tudo aparece emparelhado e utiliza uma estrutura de sintaxe simples que deve ser seguida para cada item.

· As opções das regras são formadas por vários atributos individuais dos pacotes de acções a tomar.

· Combina atributos múltiplos do pacote por forma a constituir uma assinatura.

· Especifica, sintaxe simples deve ser utilizada.

Os atributos devem estar separados por ‘;’. Por uma questão de facilitar a leitura podem ser usados espaços entre as partes. Notar que mesmo o último atributo deverá estar encerrado por parêntesis ‘)’ caso contrário irá causar um erro quando o Snort processar a regra durante o arranque.

Quando se fizer alterações a regras ou ficheiro de regras, não arrancar o Snort com a opção ‘-D’, pois quando o Snort arranca em modo daemon não irá exibir mensagens de erro que encontre no arranque.

Quase tudo na opções deve existir aos pares. O primeiro item é o atributo ou o nome da acção e o segundo o valor do item.

· É necessário especificar a keyword

· Não é necessário especificar sempre o valor

· A keyword e o valor dever estar separadas por ‘:’

Existe uma lista de atributos ou de keywords que podem ser utilizadas e que irá ser mostrada mais adiante. As keywords ou action keywords, indicam ao Snort que acções devem ser tomadas (em adição às acções definidas no cabeçalho da regra). Atributos do pacote dizem ao Snort para prestar atenção a um determinado atributo do pacote, como por exemplo as TCP flags ou payload. De notar que nem todos os atributos de um pacote se encontram acediveís via keyword. Para tal deve-se utilizar filtros do estilo tcpdump.

O valor que deve acompanhar cada keyword atributo/acção depende dum atributo/acção especifico. Alguns requerem valores numéricos outros texto. A sintaxe e formato dos valores varia com cada um, recomendo a visita ao site http://www.snort.org/snort_rules.html para mais informações de todas as keywords formatos e argumentos. Na secção 4.4 deste trabalho é possivel encontrar um documento escrito pelo autor do Snort, com informações acerca da escrita de regras.

4.3.2 Atributos

De seguida apresento uma tabela de algumas senão a maior parte, das opções utilizadas pelas keywords:

IP TOS	ICMP Type
IP TTL	ICMP Code
IP ID	ICMP Echo ID
IP Fragbits	ICMP Echo Seq
IP Options	Payload content
TCP Flags	Payload size
TCP Seq/Ack #	Session logging
Session/Host Tagging	Active response
Logto	Active reaction

4.3.2.1 Atributo: msg

A opção msg permite anexar uma mensagem ao tipo de actividade que aparece nos ficheiros de alertas ou de log. Obviamente, passa por caracterizar a descrição de uma forma relevante e capaz de identificar o que foi detectado quando se examina os logs. Pode-se atribuir uma qualquer descrição, mas é preciso ter em conta que deverá ser relevante para o que foi encontrado.

As mensagens são impressas para facilitar a leitura dos alertas e o log em ASCII dos pacotes. Por exemplo para a seguinte regra que tem por missão detectar o trojan BackFire, ou BackOrifice BO, ou o DeepBo teríamos algo como:

Alert udp any any-> $HOME_NET 31337 \

(msg: “Possivel trafego BackOrifice”;)

No ficheiro de alertas teriamos algo como:

[**] Possivel trafego BackOrifice [**]

30/04-18:34:26.886525 10.1.1.4:4802 -> 10.1.1.3:31337

UDP TTL:64 TOS:0x0 ID:12348 IpLen:20 DgmLen:31

Len:11

4.3.2.2 Atributo: content

O atributo da keyword content pode ser utilizado por forma a examinar o payload por uma determinada cadeia de caracteres ou valores hex. Ter em linha de conta que este tipo de analise é, em termos computacionais, bastante pesado e é provável que abrande o Snort se for usado de uma forma insensata.

· Examina o payload do pacote por um conteúdo especifico: O conteúdo pode ser texto, hex data, ou uma mistura de ambos

· Pode ser efectuado uma verificação múltipla de conteúdos por regra

· Pode ser efectuada a correspondência através da excpção ‘!’

· Modifiers estão disponíveis como outras opções da regra: offset, depth, nocase.

O payload pode ser examinado por dados de texto ou binários. Isto é útil para detectar tentativas de buffer overflow e análise a protocolos não-textuais.

Tomar em consideração que determinadas aplicações TCP, tais como telnet, os caracteres são enviados cada um e depois ecoados de volta. Se se quiser procurar pela string ‘root’ num acesso telnet, não iremos encontrar nada pois cada carácter viaja sozinho (‘r’, ’o’, ’o’, ‘t’). Não é efectuada qualquer agrupamento da stream capaz de avisar o Snort que a palavra é ‘root’. Se activar a stream pré-processador que acompanha a instalação do Snort, sendo desta forma capaz de realizar o agrupamento podendo desta forma procurar por strings em sessões telnet.

Notar ainda que a opção é case sensitive. Para tal existe a opção ‘nocase’ que permite ser insensível ao case sensitive no match do conteúdo.

De seguida apresenta-se alguns exemplos relativos ao atributo content:

Regra de match do conteúdo em plain text:

Alert tcp any any-> $HOME_NET 21 \

(content:”anonymous”; msg: “login FTP anonimo”;)

nesta regra procuramos a keyword ‘anonymous’ no tráfego ftp.

Regra de conteúdo misto:

Alert tcp any any -> $HOME_NET 143 \

(content:”|C0E8 C2FF FFFF|\bin\sh”; msg: “IMAP Buffer Overflow”;)

nesta regra temos uma mistura entre conteúdo hex e texto no campo de argumento. Notar que os dados em hex estão dentro ‘|’ por forma a indicar o parser que é dados em hex. Se for necessário escrever uma regra que inclui o pipe ‘|’, tem que se acompanhar o pipe com “\”.

Regra capaz de verificar múltiplos conteúdos:

Alert tcp any any-> $HOME_NET 21 \

(content:”anonymous”; content:”USER”; msg: “login FTP anonimo”;)

nesta regra temos uma situação em que é feito o match de dois conteúdos. Estes matches são realizados de forma separada de cada um e podem ocorrer em qualquer lugar do pacote. Se a procura necessita de ser localizada, as opções depth e offset podem ser utilizadas por forma a localizar no payload do pacote.

Regra contendo o conteúdo por excepção:

Alert tcp any any-> $HOME_NET 21 \

(content:!”anonymous”; msg: “login FTP nao-anonimo”;)

nesta regra apenas é indicada com sucesso se não corresponder a um determinado padrão. É muito útil para procurar pacotes que não correspondem a um critério especifico.

4.3.2.3 Content helpers

Existem três “helper options” para o content keyword:

· Offset

· Depth

· Nocase

Devem ser especificados após um determinado conteúdo da regra. Se existirem múltiplos content options numa única regra com helpers, estas deverão ser agrupadas com as opções dos conteúdos que estão associadas a um serviço, por forma a que o parser saiba que conteúdos estão a ser modificados.

4.3.2.3.1 Offset

Define o ponto no payload do pacote por onde começa a procurar o match do conteúdo. Notar que o conteúdo matching começa a contar no primeiro byte payload com o número 0, portanto necessito contar a partir do zero quando calculo o principio do offset.

Limita a quantidade de dados a procurar por pacote, melhorando desta forma a performance.

Exemplo:

Regra:

Alert tcp any any-> $HOME_NET 21 \

(content:”anonymous”; offset:5; msg: “login FTP anonimo”;)

pacote a interceptar será:

03/04-23:22:22.202506 10.1.1.4:2056 -> 10.1.1.1:21

TCP TTL:64 TOS:0x10 ID:16221 IpLen:20 DgmLen:56 DF

***AP*** Seq OxE41CAAFB Ack: 0x6F19F37D Win: 0x4470 TcpLen:20

55 53 45 52 20 61 6E 6F 6E 79 6D 6F 75 73 0D 0A USER anonymous …

Neste caso o Snort irá começar a analisar a partir do sexto byte pois começa a partir do zero no payload. Neste caso começaria no valor hex 61 que corresponde ao ‘a’ em ‘anonymous’.

4.3.2.3.2 Depth

Limita o número de bytes a partir do começo do offset que irá fazer a pesquisa do padrão. Se não for especificado qualquer offset, o valor depth indicará a distancia no payload desde o primeiro byte do conteúdo que irá examinar. Como limita a quantidade de dados a analisar melhora uma vez mais a performance.

Exemplo:

Regra:

Alert tcp any any-> $HOME_NET 21 \

(content:”anonymous”; depth: 13; msg: “login FTP anonimo”;)

pacote a interceptar será:

03/04-23:22:22.202506 10.1.1.4:2056 -> 10.1.1.1:21

TCP TTL:64 TOS:0x10 ID:16221 IpLen:20 DgmLen:56 DF

***AP*** Seq OxE41CAAFB Ack: 0x6F19F37D Win: 0x4470 TcpLen:20

55 53 45 52 20 61 6E 6F 6E 79 6D 6F 75 73 0D 0A USER anonymous …

neste caso o Snort irá pesquisar os 13 primeiros bytes do pacote, que corresponde à cobertura de um pacote típico.

4.3.2.3.3 Nocase

O conteúdo das regras é normalmente case sensitive. A opção nocase desactiva a pesquisa case sensitive para um determinado conteúdo. É utilizado para protocolos onde o servidor pode ser case insesitive para os comandos de entrada como muitos servidores FTP e http.

Exemplo:

Regra:

Alert tcp any any-> $HOME_NET 21 \

(content:”anonymous”; nocase; msg: “login FTP anonimo”;)

pacote a interceptar será:

03/04-23:22:22.202506 10.1.1.4:2056 -> 10.1.1.1:21

TCP TTL:64 TOS:0x10 ID:16221 IpLen:20 DgmLen:56 DF

***AP*** Seq OxE41CAAFB Ack: 0x6F19F37D Win: 0x4470 TcpLen:20

55 53 45 52 20 41 6E 4F 6E 59 6D 4F 75 53 0D 0A USER AnOnYmOuS …

4.3.2.3.4 Misturando tudo

Suponhamos a seguinte regra:

Alert tcp any any-> $HOME_NET 21 \

(flags: A+; content:”user”; depth:5; nocase; \

content: !”anonymous”; offset:5; depth:8; nocase; \

msg: “login nao-anonimo ao servidor FTP anonimo”;)

Esta regra demonstra todos os conceitos anteriormente apresentados no contexto desta secção. Esta regra incorpora múltiplos controlos de conteúdos, um controlo por excepção, offsets, depths e nocase. Quando combinados e utilizados em conjunto, podem conduzir a um poderoso padrão de matching.

Nesta regra uma atenção para a opção flags antes do matching do conteúdo. Utilizando uma simples flag TCP, posso verificar se a sessão se encontra estabelecida, permitindo desta forma reduzir a quantidade de tráfico que o Snort tem que analisar e que não tem as correspondentes flags.

4.3.2.4 Atributo: Flags

Uma das principais regras é a TCP flag. Este código é utilizado frequentemente por forma a testar por várias condições dos pacotes TCP e sessões que completam as ligações TCP, stealths portscans e IP fingerprints.

· A opção flags verifica as flags TCP por determinadas configurações.

· Lógica booleana disponível para as opções

· Utilizada para detectar actividades de scanning, fingerprinting, verificar se a ligação é estabelecida antes de efectuar a verificação do conteúdo, etc.

Argumentos dísponiveis para o atributo flags:

S = Syn	+ - Match do argumento mais alguns outros
F = Fin
R = Rst	* - Matching de um argumento especifico
A = Ack
P = Push	! – match apenas se a flag especificada não estiver activa
U = Urg
2 = 2º bit mais significativo
1 = bit mais significativo

Suponhamos a seguinte regra:

Alert tcp any any-> $HOME_NET any \

(flags: SF; msg: “SYN FIN scan”;)

Esta regra matches qualquer pacote que se destinem à nossa rede com as flags Syn e Fin activas.

A regra:

Alert tcp any any-> $HOME_NET 21 \

(flags: A+; content:”anonymous”; msg: “login FTP anonimo”;)

Esta regra matches todos os pacotes que tenham a flag Ack active bem como outra qualquer flag active.

4.4 Em conclusão

Em jeito de comentário final a esta secção, descrevi aqui alguns dos aspectos mais utilizados e que servem de base ao entendimento de como as regras funcionam e como podem ser exploradas. Em anexo apresento um documento elaborado pelo autor do Snort acerca do método de escrever regras para o Snort intitulado "Writing Snort Rules".

5. Na práctica

Básicamente em termos de conteúdos e atributos é tudo. Irei agora debruçar-me um pouco acerca da implementação prática do Snort. Pode ser utilizado das mais diversas formas e feitios, para medir o número de acessos a um servidor, para estar atento à procura de vulnerabilidades, possíveis ataques de DDoS ou de DoS (mas isto é outro trabalho) enfim, uma utilização quase ilimitada para os administradores de uma rede.

5.1 O posicionamento do sensor.

Passarei a designar a placa de rede onde o Snort se encontra instalado como “interface detecção”. Num ambiente típico o Snort opera ao examinar todos os pacotes que passam no seu “interface de detecção”. Este modo consegue-se colocando a placa de rede em modo promíscuo, por forma a que o Snort seja mais eficiente é necessário colocá-lo num local onde ele possa ver a maior parte do tráfego. Num rede ethernet, basta ligá-lo a um ponto de acesso à rede partilhada. Num rede baseada na comutação (switchs), o “interface de detecção” deverá ser ligado ao “monitor port” do comutador. O “monitor port” é uma porta do comutador que se encontra configurado por forma a receber todo o tráfico que passa no comutador (switch).

No caso de switchs mais antigos seria possível ligar o “interface de detecção” numa port denominada Port SPAN (Switch Port Analyzer), neste caso teríamos portas a 10Mbps e uma porta a 100Mbps por onde recebe todo o tráfego do switch, no entanto em situações extremas, isso levaria a uma degradação na performance do switch.

Figura referente à configuração em Port Span

Figura referente ao uso de um monitor port

Outra forma de posicionar, é num ponto onde é possível monitorizar todo o tráfico que entra e sai da rede. O exemplo típico desta implementação é o de uma empresa que se encontra ligada à Internet através de uma linha de alto débito. Colocando o sensor onde possa examinar todo o tráfego que entra e que sai, através dessa ligação, o Snort pode ser usado como uma forma de monitorizar possíveis ataques. Uma forma de conseguir esta monitorização, passa pela colocação de um concentrador (hub), entre o router fronteira e a rede interna (ou mesmo a placa externa da FireWall), permitindo desta forma ao sensor examinar todos os dados associados à placa exterior.

Outro método interessante é utilizar como uma escuta, por forma a replicar os dados da ligação.

Outra ligação em que é aconselhável o uso do Snort, é numa rede caseira, em que existe apenas uma máquina que actua como uma gateway para o resto da rede. Colocando o Snort activo na placa externa da gateway, é possível monitorizar possíveis ataques.

5.2 O Snort como ferramenta de defesa

Um dos aspectos interessantes do Snort, é o poder que fornece a um administrador para analisar os tipos de ataques que são perpetrados à sua rede. Nesse sentido o Snort tem vindo a ser utilizado em projectos de auditorias e segurança como por exemplo o projecto honeynet, ou mesmo por empresas prestadoras de auditorias informáticas como forma de identificar os tipos de ataques ou acessos indevidos e quem os faz.

De seguida apresento a topologia usada num desses projectos nomeadamente de analise aos ataques feitos a uma rede

5.2.1 Descrição da rede:

Desenho da rede e seus componentes

Existem três redes neste diagrama, a Internet, a Rede interna e a rede honeynet, todas separadas pela FireWall. A Internet é a rede untrusted, de onde os maus da fita aparecem. A honeynet é uma colecção de potes onde esperamos que venham a ser comprometidos. A rede interna, é onde iremos monitorizar o tráfego e administrar a rede honeynet. Todo o tráfego tem que passar pela FW, segmentação e controlos são cruciais. De seguida apresenta-se os scripts utilizados na configuração do Snort para a monitorização das redes.

5.2.2 Snort start-up script

#!/bin/ksh

# snort.sh

# Created by Honeynet Project <project@honeynet.org>

# March 18, 2000

# Used to rotate snort for daily for automated IDS

PATH=/bin:/usr/local/bin

PID=`cat /var/run/snort_qfe0.pid`

DIR=/opt/ids/snort

DATE=`date +%b_%d`

SNORT=/usr/local/bin/snort

USER=snort

### Kill snort

echo "\nKilling snort, PID $PID\n"

kill $PID > /dev/null 2>&1

### Create daily directory to archive log files

if [ -d $DIR/logs/$DATE ];then

else

mkdir $DIR/logs/$DATE

### launch snort

$SNORT -b -c $DIR/snort.conf -D -i qfe0 -l $DIR/logs/$DATE -s -u $USER

5.2.3 Configuração do snort.conf

##### Set variables for your own Honeynet network

var HOME_NET 172.16.1.0/24

var INTERNAL 172.16.1.0/24

var PORTS 5

var SECONDS 15

##### Preprocessors

preprocessor http_decode: 80 443 8080

preprocessor minfrag: 128

preprocessor portscan: $HOME_NET $PORTS $SECONDS /var/adm/snort/portscan

### Log all TCP connection

# Log all ASCII TCP activity to session breakout files

log tcp any any <> $INTERNAL any (session: printable;)

# Log all TCP activity to binary file

log tcp any any <> $INTERNAL any

### Log all UDP connections

# Log all ASCII UDP activity to session breakout files

log udp any any <> $INTERNAL any (session: printable;)

# Log all UDP activity to binary file

log udp any any <> $INTERNAL any

### Log all ICMP activity

# Log all ASCII ICMP activity to session breakout files

log icmp any any <> $INTERNAL any (session: printable;)

# Log all ICMP activity to binary file

log icmp any any <> $INTERNAL any

### Standard snort signatures begin here ###

5.2.4 Análise dos dados recolhidos

Depois de estar a funcionar toda a parametrização referente ao Snort e à rede, basta escrever as nossas próprias regras, que podem ser vistas em anexo, e começar a analisar os dados recolhidos quer pela FireWall quer pelo IDS. Um script perl pode ajudar a extraír os dados do Snort por forma a podermos analisar os alertas gerados. De seguida passo a apresentar o script em perl desenvolvido uma vez mais pelo próprio criador do Snort.

#!/usr/bin/perl

# Syslog analysis script orignially written by

# Angelos Karageorgiou <angelos@StockTrade.GR> and

# tweaked by Martin Roesch <roesch@clark.net>

if($ARGV[1] eq undef)

{

print "USAGE: snortlog <logname> <machinename>\n";

print "EXAMPLE: snortlog /var/log/messages sentinel\n";

print "Note: The machine name is just the hostname, not the FQDN!\n";

exit;

}

$HOST={}; # DNS table

$timeoutalarm=1; # in 5 second the DNS resolver should timeout

$machine = $ARGV[1];

$targetlen=25;

$sourcelen=35;

$protolen=12;

use Socket;

$SIG{ 'ALRM' } = "cannotresolve";

open(LOG,"< $ARGV[0]") || die "No can do";

printf("%-15s %-35s %-25s %-25s\n","DATE","WARNING", "FROM", "TO");

print "=" x 100;

print "\n";

while(<LOG>) {

chomp();

if (

( ! /$machine snort/gi )

) { next ; }

$date=substr($_,0,15);

$rest=substr($_,16,500);

@fields=split(": ", $rest);

$j=1;

$text=$fields[$j++];

if ( $text =~ /spp_http_decode/ ){

$text=$fields[$j++];

}

$fields[$j] =~ s/ \-\> /-/gi;

($source,$dest)=split('-', $fields[$j]);

($host,$port)=split(':',$source);

$skipit=0;

($shost,$sport)=split(':',$dest);

$sport =~ s/ //gi;

$name=resolv($host);

$name = $name . ":" . $port;

$sname=resolv($shost);

$sname = $sname . ":" . $sport;

if ( $text =~ /portscan/i ) {

$rest =~ s/$machine snort.*\]\://gi;

$rest =~ s/ spp_portscan\://gi;

$mystring=sprintf("%15s %s\n", $date, $rest);

push(@PSCAN,$mystring);

} else {

printf("%15s %-35s %-30s %s\n", $date, $text, $name,$sname);

}

close(LOG);

print "\n\n";

print "=" x 100;

print "\n";

print " " x 40;

print "PORTSCANS\n\n";

#printf("%-15s %-35s %-25s %-25s\n","DATE","WARNING", "FROM", "TO");

print "=" x 100;

print "\n";

foreach $sc (@PSCAN) {

print $sc;

}

sub cannotresolv

{

print "cannot resolve\n";

alarm($timeoutalarm);

return 1;

}

sub resolv #resolv and cache a host name

{

local $mname,$miaddr,$mhost;

$mhost=shift;

$miaddr = inet_aton($mhost); # or whatever address

if (! $HOSTS{$mhost} ) {

$mname='';

eval {

local $SIG{ALRM} = sub { die "alarm\n" }; # NB \n required

alarm $timeout;

$mname = gethostbyaddr($miaddr, AF_INET);

};

die if $@ && $@ ne "alarm\n"; # propagate errors

if ( $mname =~ /^$/ ) {

$mname=$mhost;

}

$HOSTS{$mhost}=$mname;

}

return $HOSTS{$mhost}

}

E com estas ferramentas disponibilizadas, já não existe desculpas para um administrador de rede não estar alerta ao que se passa na sua rede, pelo menos alertando-o para o que de mais grave se possa passar.

Ainda por cima o programa é gratuito, não é necessário pagar para se utilizar uma ferramenta com esta utilidade, no entanto já se pensa em fazer uma versão comercial podem ser consultado detalhes em: http://online.securityfocus.com/news/332

5.3 Resultados

Por forma a provar que é uma boa ferramenta e que isto não é só teoria, a seguir mostro os resultados por mim obtidos, nos testes realizados à minha rede. Para tal utilizei os programas da suite TigerSuite http://www.tigertools.net e Cerberus Internet Scanner em http://www.cerberus-infosec.co.uk/cis e após a instalação do snort versão RPM 1.8.4 utilizando as assinaturas de ataque (regras) disponíveis em http://www.snort.org/dl/signatures, foi só descomprimir e untar o ficheiro, alterar o snort.conf que acompanha as regras para identificar a minha rede ($HOME_NET) e obtive o ficheiro de alertas em anexo. A máquina agressora, facilmente se identifica como sendo o IP 192.168.1.113.

Da análise ao ficheiro pude no entanto detectar alguns falso positivos, que com uma parametrização correcta do snort.conf a par de algumas regras poderiam ser amenizadas. No entanto é de salientar que o Snort é capaz de identificar qual a vulnerabilidade que o scanner agressor está à procura.

Recomendo a leitura do documento "Building an IDS Solution using SNORT" escrito por Aidan Carty, em que descreve todos os passos desde a instalação do Linux, MySQL, Apache, um documento muito bem escrito.

Publicado originalmente em: http://paginas.fe.up.pt/~mgi98020/pgr/snort.htm

6. Sites com interesse:

· Snort: http://www.snort.org

· Whitehats.com e arachNIDS rules database: http://www.whitehats.com

· Libpcap: ftp://ftp.eecs.lbl.gov

· Libnet: http://www.packetfactory.net

· Incident.org (database plug-ins): http://www.incident.org

· Silicon Defense (boas ferramentas para o Snort): http://www.silicondefense.com

· Snort para Win32: http://www.datanerds.com/~mike

· Snorticus: http://www.snorticus.baysoft.net

Alfaia com Linux

Pesquisar este blog