Opensource Snort IDS Security – Defesa ativa e adaptável de Perímetro.

Num dos meus últimos posts perguntaram-me que outras ferramentas incluídas na pfSense uso para defender os meus Clientes de ataques, alem do tradicional packet filtering.

A resposta leva-nos a um opensource (!) project que nasceu em 1998 e até ao dia de hoje continua a ser um dos melhores do panorama: O Snort.
O Snort foi inicialmente desenvolvido por Martin Roesch em 1998. O Snort é correntemente desenvolvido pela  Sourcefire, fundada por Roesch,  e em 2013 foi adquirida pela Cisco.

 

Snortpig_professor2

Em 2009, o Snort conseguiu a distinção de ser um dos melhores programas opensource de toda a história.

O Snort é um network intrusion prevention system (NIPS) and network intrusion detection system (NIDS):  Deteta e previne intrusões de rede e é precisamente na parte de deteção e prevenção que nos vamos concentrar.

Embora o software possa ser usado numa multitude de sistemas operativos com integração, no caso presente iremos usar uma pfsense, tanto pela facilidade de configuração, mas sobretudo pela capacidade de defesa automática integrada que ela nos permite (e porque é o que habitualmente uso).

Ela irá comportar-se como um man in the middle na nossa rede, inspecionado o tráfego através do snort e enviando instruções à firewall para que tudo o que seja considerado ataque ou possível incidente de segurança seja bloqueado:

 

Em primeiro lugar, devemos instalar o software através do package installer disponibilizado no GUI da pfSense:

instalar

Escolher o pacote:

instalar1
O pacote depois de instalado:

instalar2

Após a instalação, o nosso serviço de snort já deverá aparecer no menu da pfSense, secção de serviços:

instalar3

No entanto, a nossa configuração estará vazia. Chegou portanto a hora de a popular:

configurar0
Em primeiro lugar deveremos escolher  os Global Settings e os Updates. Esta configuração irá nos permitir detetar eventos de segurança e reagir ao mesmos:

configurar1
Nota: Deve se registar para regras através dos links na página, e colocando o link na secção de Snort Oinkmaster Code.
Podemos ainda adicionar mais regras, ou rulesets que na prática são as assinaturas que o snort irá utilizar para detetar os issues.

É importante lembrar que até se ter as regras perfeitamente afinadas, poderão existir falsos positivos, que como o nome indica são eventos que não são problemas de segurança, mas identificados e sobre eles agidos como.
Nota: Podem fazer finetuning aos rulesets que utilizarão na secção de updates.

No fim da página dos global settings, tem duas partes extremamente importantes da vossa configuração de sort: Atualizações da listas, e o que é que ele irá fazer quando detetar um evento.
No nosso caso especifico, ele irá atualizar as regras a cada 6 horas e bloquear os atacantes durante uma hora:

configurar2
Depois da correta configuração das listas, na secção updates teremos:

configurar3
Devem sempre validar se as vossas atualizações estão em dia.
São elas que vos detetam os problemas.

Temos agora um active ruleset válido para deteções. Podemos então voltar ao ecrã inicial, do interface settings overview e configurar a nossa primeira sonda de IDS (neste caso para a interface WAN):

configurar4

No fim da página podem definir quais as supression lists (para fazer whitelist do que sabem ser falsos eventos) e as pass lists que são redes cujo endereçamento por defeito ele não irá inspecionar.

configurar5
Em seguida, na secção de categorias, podem definir o que querem vasculhar, e a profundidade a que querem ir.
Por exemplo, e como a própria GUI do snort indica, entre ver os típicos ataques do dia até ir a granularidade de validar se existe dentro de ficheiro excel, um objeto flash embebido:

configurar6

Finalmente na secção pre-processors temos pré-processadores de tráfego que procuram padrões específicos de ataque em serviços chave com opor exemplo RPC, SSH, DNS etc.

configurar7
Finalmente estamos em condição de ligar o nosso Snort e ver a deteção ocorrer:

final0
Nota: Podemos ter múltiplas instâncias de snort, desde que estejam em interfaces separadas, com rulesets (ou paranoia diferente).
Por exemplo, paranoico para wan, muito apertado para dmz, e mildly para a rede wired.

Finalizando,  e após o boot do nosso snort já o conseguimos ver em funcionamento quer através do monitor interno da pfSense, quer da consola da mesma.

Na secção de serviços dentro da pfsense:

final1
E em consola:

final2
Nota: podem ver dois processos. Um snort e outro do barnyard2 que está a recolher dados para um próximo post sobre analise de ataques.
Depois de um dia em funcionamento, o nosso snort já tinha detetado os seguintes eventos de segurança:

alerta0

Por estes eventos terem ocorrido durante a noite, e como eu só estou a bloquear durante uma hora ataques (até se verificarem novamente), altura em que vão para uma blacklist permanente (a demonstrar num próximo post como é construida), não foi possível mostrar nenhum bloqueio através da GUI:

blockedhosts
Assim chegamos ao fim de mais um post, desta vez de uma forma muito abreviada de deteção e mitigação de eventos de segurança.
O Snort não evita ataques. Só os deteta quando tem assinaturas para tal, portanto sempre muita atenção a idade e validade dos vossos rulesets.

O tráfego irá ainda sofrer latência. O snort na pratica introduz um hop de processamento na firewall, para inspecionar o tráfego. Quando mais apertada a ruleset, mais seguros estarão, mas ao mesmo tempo mais processamento e latência irão introduzir na vossa ligação, pois o trafego será batido contra todas as regras que escolherem.

Será uma questão  de optarem por uma quantidade de redes que vos pareça acertada e vos dê alguma paz de espírito.

Em breve farei mais posts relacionados com o snort, e com as interfaces utilizadas para gestão de incidentes como o Snorby, o BASE e o Sguil.

Pf lembrem-se que esta configuração é simples. Demasiado simples. Tem de ser trabalhada para as vossas necessidades.
Este post serve apenas para demonstrar e para despertar a questão da segurança.
O assunto é muito mais complexo do que é possível apresentar num post curto.

Lembrem-se ainda que nada substitui uma boa política de patch managment de fora a eliminar pontos de falha identificados nos vossos sistemas.

Até lá, boa deteção e mitigação. Se tiverem duvidas já sabem onde me encontrar.

Abraço!
Nuno