trabalho sobre o snort

Prévia do material em texto

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? 
1. É um Sistema de Detecção de Intrusões (IDS) 
2. Suporta inspecção tanto ao header como payload, permitindo desta forma reduzir os 
falsos positivos. 
3. Capacidades de alertas/logs bastante fléxiveis 
4. Capacidade de resposta bastante limitada 
5. Corre na maioria dos sistemas UNIX, Windows e MacOSx (desde que o OS permita 
a compilação e instalação da livraria libpcap). 
6. Free (GPL) – disponível o código fonte segundo o standard GNU general public 
license. 
7. 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á seencontra 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 é carregadocom 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 streamreassembler. 
 
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 pacotenã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 
eo 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/Ho
st 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 
significativ
o 
 
1 = bit mais 
significativ
o 
 
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 
queentra 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 
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. 
 
#!/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. 
 
 
 
 
 
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