Il blog sull'informatica

Questa mattina mi sono accorto che su tutte le mie macchine snort era stoppato. Provando a lanciare un service restart il risultato era sempre lo stesso: fail.

Indi per cui ho deciso di visualizzare l'output del syslog per capire cosa diavolo stava succedendo.

Per farla breve, mi sono beccato una sfilza di errori del tipo:

FATAL ERROR: /etc/snort//rules/specific-threats.rules(946) Undefined variable name: SIP_SERVERS

FATAL ERROR: /etc/snort//rules/specific-threats.rules(766) Undefined variable name: FILE_DATA_PORTS.

Ok, mi sono detto, mancano le suddette variabili nel file di configurazione, alla fine è un problema banale e di facile soluzione. Quindi, ho aperto in scrittura il file /etc/snort/snort.conf ed ho aggiunto le seguenti direttive:

portvar FILE_DATA_PORTS [$HTTP_PORTS]

subito dopo la dichiarazione della variabile $HTTP_PORTS, e

var SIP_SERVERS $HOME_NET

Dopo aver fatto ciò, ho riavviato il demone digitando

nightfly@nightbox:~$ sudo service snort restart

e tutto è tornato a funzionare alla grande.

Bye.

Gli alert generati da snort sono di indubbia utilità, in quanto da un'attenta analisi degli stessi è possibile individuare possibili tentativi di intrusione sulla nostra rete. Poichè sono un po' pigro e la lettura dei log è sicuramente una delle fasi più tediose del mio lavoro, ho pensato di creare il seguente script, in grando di inviare al mio indirizzo email gli alert in questione man mano che vengono generati.

Ecco lo script:

#!/bin/bash

logfile=/var/log/snort2sms.log

destinatario=vostro.indirizzo@email.it

ROOT_UID=0

if [ "$UID" -ne "$ROOT_UID" ];then

        ERRORE1="Errore 1: Devi essere root per eseguire lo script"
        echo $ERRORE1
        echo "$(date) $ERRORE1" >> $logfile
        exit 1

fi

cd /var/log/snort

if [ -f alert ];then

        if [ -f alert_backup ];then
                #confronto i due file e salvo le differenza all'interno di mail
                diff alert alert_backup > mail

        else

                touch alert_backup
                cp alert alert_backup
        fi

else

        ERRORE2="Errore 2: Il file alert non esiste. Sei sicuro di aver installato snort?"
        echo $ERRORE2
        echo "$(date) $ERRORE2" >> $logfile

fi

if [ -s mail  ];then

        cp alert alert_backup

        cat mail | mail -iv -s "HOME: snort alert" $destinatario;
fi

rm mail

Non vi resta che schedulare l'esecuzione dello script mediante cron e creare il file di log snort2mail.log nella directory /var/log.

Enjoy.

Premesso che i PIX 501 sono molto limitati come IDS, in quanto supportano soltanto circa 70 signature (piuttosto datate), può tornare comunque utile configurarli come Intrusion Detection System di prima linea, a cui associare dei sistemi più sofisticati, basati ad esempio su snort.

Ovviamente, affinchè l'IDS possa svolgere il suo compito è necessario abilitare il logging dei pacchetti "sospetti", reindirizzandoli su un'altra macchina (aka logserver), in modo da non causare eventuali memory leak al nostro piccolo firewall (soprattutto se la mole di traffico che deve esaminare è piuttosto elavata).

Ma veniamo alla configurazione del PIX. Per prima cosa digitiamo il comando (in modalità enable):

NightFirewall# sh run | i ip audit

il cui output sarà:

ip audit info action alarm
ip audit attack action alarm

Esso rappresenta le due tipologie di signature che possono essere gestite dal firewall, ovvero info ed attack, con le rispettive azioni di default (che in entrambi i casi è alarm).

Definiamo adesso delle nuove policy di audit digitando:

NightFirewall# conf t
NightFirewall(config)# ip audit name esterna info
NightFirewall(config)# ip audit name interna attack action drop

La prima policy è di tipo info, la seconda è di tipo attack a cui è associata l'azione drop nel caso in cui vengano individuati dei pacchetti sospetti.

Associamo le policy di audit appena create alle interfacce del nostro PIX:

NightFirewall(config)# ip audit interface outside esterna
NightFirewall(config)# ip audit interface inside interna

ed infine lanciamo un write mem per salvare la nuova configurazione:

NightFirewall(config)# write mem

Ora il nostro PIX si comporterà come un IDS.

A presto.

PS: i log generati dal firewall avranno sa seguente struttura:

Oct 22 17:57:26 nightfirewall.*.org %PIX-4-400014: IDS:2004 ICMP echo request from 172.16.*.* to 172.16.*.* on interface inside
Oct 22 17:59:16 nightfirewall.*.org %PIX-4-400014: IDS:2004 ICMP echo request from 172.16.*.* to 192.168.*.* on interface inside
Oct 22 17:59:16 nightfirewall.*.org %PIX-4-400010: IDS:2000 ICMP echo reply from 192.168.*.* to 192.168.*.* on interface outside

In questo caso l'IDS ha generato dei falsi positivi, in quanto trattasi semplicemente di alcuni ping lanciati da nagios per i suoi check.

Ho quindi proceduto a disattivare le signature coinvolte utilizzando i seguenti comandi:

NightFirewall(config)# ip audit signature 2000 disable
NightFirewall(config)# ip audit signature 2004 disable