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:[email protected]:/cvsroot/snort login

iii.    cvs �z3 �

iv.    d:pserver:[email protected]:/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:

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:

(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:

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 <[email protected]>

# 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

fi

### 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.

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.

�        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