Archivi tag: rules

Ubuntu: analisi e debug di un’interfaccia di rete malfunzionante

Di recente, analizzando i log di uno dei server che gestisco, mi sono accorto che una delle sue interfacce di rete continuava a generare tutta una serie di eventi del tipo:

root@linux-box:~$ dmesg | grep eth0
[  184.348573] 8139too 00:40:f4:44:68:8e: eth0: link up
[  190.271409] 8139too 00:40:f4:44:68:8e: eth0: link up
[  196.374125] 8139too 00:40:f4:44:68:8e: eth0: link up
[  201.823936] 8139too 00:40:f4:44:68:8e: eth0: link up
[  208.089862] 8139too 00:40:f4:44:68:8e: eth0: link up
[  212.200536] 8139too 00:40:f4:44:68:8e: eth0: link up
[  216.950829] 8139too 00:40:f4:44:68:8e: eth0: link up
[  221.071493] 8139too 00:40:f4:44:68:8e: eth0: link up
[  226.731134] 8139too 00:40:f4:44:68:8e: eth0: link up
[  230.778527] 8139too 00:40:f4:44:68:8e: eth0: link up
[  234.126353] 8139too 00:40:f4:44:68:8e: eth0: link up
[  238.936576] 8139too 00:40:f4:44:68:8e: eth0: link up
[  244.859427] 8139too 00:40:f4:44:68:8e: eth0: link up
[  250.845563] 8139too 00:40:f4:44:68:8e: eth0: link up
[  256.831661] 8139too 00:40:f4:44:68:8e: eth0: link up
[  262.458027] 8139too 00:40:f4:44:68:8e: eth0: link up
[  266.428794] 8139too 00:40:f4:44:68:8e: eth0: link up
[  271.305659] 8139too 00:40:f4:44:68:8e: eth0: link up
[  277.091885] 8139too 00:40:f4:44:68:8e: eth0: link up
[  282.768241] 8139too 00:40:f4:44:68:8e: eth0: link up
[  287.102103] 8139too 00:40:f4:44:68:8e: eth0: link up
[  290.866316] 8139too 00:40:f4:44:68:8e: eth0: link up
[  294.267496] 8139too 00:40:f4:44:68:8e: eth0: link up

ubuntu

In più, essa risultava completamente “sorda”, nel senso che anche sniffando il traffico mediante tcpdump, non vi era evidenza di frame/pacchetti di alcun genere, nonostante fosse collegata ad un segmento di rete piuttosto popolato.

Alla luce di ciò, le cause del suddetto malfunzionamento sarebbero potute essere 2:

1) guasto hardware;
2) aggiornamento che ha compromesso i driver del kernel che si interfacciano con la scheda (leggasi moduli), rendendola inutilizzabile.

Prima di procedere con l’analisi, però, è opportuno capire come avviene il riconoscimento dell’interfaccia di rete da parte del sistema operativo durante la fase di boot.

Chipset e moduli del kernel

Durante l’accesione (boot) della macchina, il sistema operativo riconosce la scheda di rete “dialongando” con il chipset di cui è dotata. Per individuarlo è sufficiente lanciare il seguente comando (con relativo output):

root@linux-box:~# lspci | grep Ethernet

04:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

Nella fattispecie, il chipset utilizzato dalla scheda è Realtek.

Il modulo del kernel in grado di interfacciarsi con essa prende il nome di r8139too e deve essere caricato in fase di avvio. Per verificare che il suddetto modulo sia effettivamente up è sufficiente lanciare il comando:

root@linux-box:~$ lsmod | grep 8139

il cui output sarà simile al seguente:

8139too                32177  0
8139cp                 27360  0

Udev e nomenclatura

Se il modulo è stato correttamente caricato, la scheda di rete può essere effettivamente “riconosciuta” come tale ed il sistema operativo sarà in grado di assegnarle un nome.

Durante tale fase entra in gioco il demone udev, che “leggerà” il contenuto del file di configurazione dedicato alle interfacce di rete, ovvero /etc/udev/rules.d/70-persistent-net.rules:

root@linux-box:~$ cat /etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1e.0/0000:04:01.0 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:40:f4:44:68:8e", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"

La suddetta regola di esempio parla chiaro: appena viene identificata una scheda di rete recante come indirizzo MAC 00:40:f4:44:68:8e, come id 0x0 e come tipo 1, le dovrà essere assegnato come nome eth0.

Configurazione

A questo punto la scheda è pronta per essere configurata, secondo quanto definito all’interno del file /etc/network/interfaces:

auto eth0
iface eth0 inet static
address 192.168.11.1
netmask 255.255.255.0

Comandi di diagnostica

Se tutto è filato per il verso giusto, lanciando un semplice ifconfig, la suddetta scheda di rete sarà tra quelle disponibili:

root@linux-box:~$ ifconfig eth0
eth0      Link encap:Ethernet  IndirizzoHW 00:40:f4:44:68:8e
          indirizzo inet:192.168.1.1  Bcast:192.168.11.255  Maschera:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1989751 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3500430 errors:0 dropped:0 overruns:0 carrier:0
          collisioni:0 txqueuelen:1000
          Byte RX:339007498 (339.0 MB)  Byte TX:3756299292 (3.7 GB)
          Interrupt:16 Indirizzo base:0xe800

Inoltre, è possibile visualizzare il modulo in uso per interfacciarsi con la suddetta scheda, avvalendosi di ethtool con l’opzione -k:

root@linux-box:~$ ethtool -i eth0

il cui output sarà simile al seguente:

driver: 8139too
version: 0.9.28
firmware-version:
bus-info: 0000:04:01.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no

Per identificare, invece, alcuni dei suoi parametri di funzionamento, quali autonegoziazione, velocità, duplex, ecc., è sufficiente lanciare il comando:

root@linux-box:~# ethtool eth0

che ci darà un risultato simile al seguente:

Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

In alternativa, si possono ottenere delle informazioni più sintetiche utilizzando il più datato (e meno completo) mii-tool:

root@linux-box:~$ mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok

Identificazione della causa

A valle delle riflessioni fatte fin’ora, tutto ciò che riguarda la scheda risulta coerente e conforme con quanto ci si aspettava, per cui è stato facile intuire, andando per esclusione, che si trattava, banalmente, di un guasto hardware.

Una volta sostituita la scheda, infatti, tutto ha ripreso a funzionare correttamente.

Alla prossima.

Controllare lo stato di iptables mediante Nagios

Recentemente su uno dei miei server ho lanciato il comando:

nightfly@nightbox:~$ sudo iptables -L

e con mio enorme disappunto mi sono accorto che le regole di firewalling che il server avrebbe dovuto caricare all’avvio erano praticamente assenti (eccezion fatta per fail2ban), indi per cui ho deciso di monitorare lo stato di iptables mediante Nagios.

iptables.jpg

Lo scrip che ho utilizzato per i check potete scaricarlo da qui. Inoltre, poichè tale scrip è piuttosto bacato, ho deciso di apportare qualche piccola correzione. Di seguito la versione originale dello scrip:

#!/bin/bash

PARAM1=$1
TABLE=$2
MINRULES=$3
PARAM4=$4
LOG=/var/log/iptables/iptables.log
CHKIPTBLS=`/sbin/iptables -n -t filter -L |wc -l`

#
# Parameter Validation
##

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" == "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
                # Nagios exit code 3 = status UNKNOWN = orange

if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "         -h = Display's this Help"
        echo "         -T = Table to check"
        echo "                 Available Tables:"
        echo "                    nat"
        echo "                    mangle"
        echo "                    filter"       
        echo "         -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
                exit 3
   fi
fi

##
#    DO NOT MODIFY ANYTHING BELOW THIS
##

$CHKIPTBLS >/dev/null 2>/dev/null

if [ "$CHKIPTBLS" == 0 ]; then
    TOTRULES=$CHKIPTBLS
else
    TOTRULES=$[$CHKIPTBLS-8]
fi

if [ "$TOTRULES" -gt "$PARAM4" ]; then
                    echo "OK - Iptables are OK the table $TABLE has $TOTRULES rules configured"
                    # Nagios exit code 0 = status OK = green
                    exit 0
else
                    echo " CRITICAL - Iptables are CRITICAL the table $TABLE has $TOTRULES rules configured"
                    for i in `w  -h | cut -f1 -d" " | sort | uniq`
                    do

                        echo "`date '+%d/%m/%Y - %H:%M:%S'` - CRITICAL - $i is logged in and there are only $TOTRULES loaded" >> $LOG
                    done
                    # Nagios exit code 2 = status CRITICAL = red
                    exit 2               
fi

Punto primo: la seconda condizione dell’if non ha praticamente senso, in quanto la prima è sempre verificata.
E’ bastato invertire le due condizioni e trattarle separatamente:

#
# Parameter Validation
##

if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "          -h = Display's this Help"
        echo "          -T = Table to check"
        echo "          Available Tables:"
        echo "          nat"
        echo "          mangle"
        echo "          filter"
        echo "          -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
        exit 3
fi

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" ==                                                                                         "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
        # Nagios exit code 3 = status UNKNOWN = orange
fi

Punto secondo: la variabile CHKIPTBLS utilizza sempre e comunque la tabella filter, dunque il parametro -T non ha senso di esistere. Possiamo però ovviare a tale mancanza, permettendo all’utente di scegliere su quale tabella (tra filter, mangle e nat) effettuare i controlli, modificando la variabile citata in precedenza nel seguente modo:

CHKIPTBLS=`sudo /sbin/iptables -n -t "$TABLE" -L |wc -l`

Punto terzo: la condizione

if [ "$TOTRULES" -gt "$PARAM4" ]; then

controlla che il numero di regole caricate sia strettamente maggiore di quello definito mediante il parametro -r. Questo però cozza con quanto dichiarato dall’autore dello scrip, ovvero:

OK - The number of Iprules equal o more than the minimun that we setup on the -r variable

Per ovviare a tale errore, occorre sostituire la condizione riportata in precedenza con questa:

if [ "$TOTRULES" -ge "$PARAM4" ]; then

Punto quarto: nagios non ha i permessi per lanciare iptables, ergo dobbiamo effettuare delle modifiche al file /etc/sudoers, inserendo la entry:

nagios   ALL = NOPASSWD: /sbin/iptables

alla fine del file. 

In definitiva, lo scrip per controllare lo stato di iptables dovrà essere il seguente:

#!/bin/bash

PARAM1=$1
TABLE=$2
MINRULES=$3
PARAM4=$4
LOG=/var/log/check_iptables.log
CHKIPTBLS=`sudo /sbin/iptables -n -t "$TABLE" -L |wc -l`

#
# Parameter Validation
##

if [ "$PARAM1" == "-h" ]; then
        echo ""
        echo "          -h = Display's this Help"
        echo "          -T = Table to check"
        echo "          Available Tables:"
        echo "          nat"
        echo "          mangle"
        echo "          filter"
        echo "          -r = Minimun quantity of rules"
        echo ""
        # Nagios exit code 3 = status UNKNOWN = orange
        exit 3
fi

if [ "$PARAM1" != "-T" -o "$TABLE" == "" -o "$MINRULES" != "-r" -o "$PARAM4" == "" ]; then
        echo "Usage: $0 -T <table> -r <min rules>"
        echo ""
        exit 3
        # Nagios exit code 3 = status UNKNOWN = orange
fi

##
#       DO NOT MODIFY ANYTHING BELOW THIS
##

$CHKIPTBLS >/dev/null 2>/dev/null

if [ "$CHKIPTBLS" == 0 ]; then
        TOTRULES=$CHKIPTBLS
else
        TOTRULES=$[$CHKIPTBLS-8]
fi

if [ "$TOTRULES" -ge "$PARAM4" ]; then
                    echo "OK - Iptables is OK The Table $TABLE has $TOTRULES rules configured"
                    # Nagios exit code 0 = status OK = green
                    exit 0
else
                    echo " CRITICAL - Iptables is CRITICAL The Table $TABLE has $TOTRULES rules configured"
                                        for i in `w  -h | cut -f1 -d" " | sort | uniq`
                                        do
                                                echo "`date '+%d/%m/%Y - %H:%M:%S'` - CRITICAL - $i is logged in and there are only $TOTRULES loaded" >> $LOG
                                        done
                    # Nagios exit code 2 = status CRITICAL = red
                    exit 2
fi

Se il file /var/log/check_iptables.log non esiste, dovrete crearlo mediante il comando:

nightfly@nightbox:~$ sudo touch /var/log/check_iptables.log

A questo punto possiamo rinominare lo scrip:

nightfly@nightbox:~$ mv check_iptables_status.sh check_iptables_status

rendondolo successivamente eseguibile:

nightfly@nightbox:~$ chmod +x check_iptables_status

Spostiamolo nella directory /usr/lib/nagios/plugins:

nightfly@nightbox:~$ sudo mv check_iptables_status /usr/lib/nagios/plugins

Creiamo il file iptables.cfg nella directory /etc/nagios-plugins/config:

nightfly@nightbox:/etc/nagios-plugins/config$ sudo nano iptables.cfg

il cui contenuto dovrà essere il seguente:

# 'check_iptables_status' command definition
define command{
        command_name    check_iptables_status
        command_line    /usr/lib/nagios/plugins/check_iptables_status -T '$ARG1$' -r '$ARG2$'
        }

infine aggiungiamo la seguente direttiva al file dell’host su cui vogliamo monitorare lo stato di iptables (tale file è presente nella directory /etc/nagios3/conf.d):

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       localhost
        service_description             iptables
                check_command                   check_iptables_status!filter!84
}

Dove 84 è il numero minimo di regole di firewalling attive.

Infine, riavviamo nagios:

nightfly@nightbox:~$ sudo service nagios3 restart

ed abbiamo finito.

Alla prossima.

Tuning di snort 2.9.0.5 (rules)

In questo post ho spiegato come effettuare un tuning minimale dei preprocessori di cui si avvale snort 2.9.0.5. Ora, invece, vedremo come disabilitare tutte quelle regole che potrebbero generare dei falsi positivi.

snort

Per prima cosa posizioniamoci nella directory /etc/snort/rules:

nightfly@nightbox:~$ cd /etc/snort/rules

Lanciamo un ls per visualizzare il contenuto della dir:

nightfly@nightbox:/etc/snort/rules$ ls

il cui outuput sarà simile al seguente:

attack-responses.rules  misc.rules           snmp.rules
backdoor.rules          multimedia.rules     specific-threats.rules
bad-traffic.rules       mysql.rules          spyware-put.rules
blacklist.rules         netbios.rules        sql.rules

ecc.

Come è facile intuire, esiste un file *.rules per ogni possibile minaccia, dove ciascun file contiene tutta una serie di regole che identificano i tentativi di attacco. Ad esempio, analizzando il file attack-responses.rules, noteremo delle entry del tipo:

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES directory listing"; flow:established; content:"Volume Serial Number"; classtype:bad-unknown; sid:1292; rev:9;)

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES command completed"; flow:established; content:"Command completed"; nocase; metadata:policy balanced-ips drop, policy security-ips drop, service http; reference:bugtraq,1806; classtype:bad-unknown; sid:494; rev:13;)

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES command error"; flow:established; content:"Bad command or filename"; nocase; classtype:bad-unknown; sid:495; rev:10;)

E’ possibile disabilitare una qualunque entry semplicemente commentandola (ovvero inserendo un # ad inizio riga). Però, per evitare che tale entry ritorni attiva dopo l’aggiornamento delle regole mediante oinkmaster, dobbiamo operare direttamente sul file /etc/oinkmaster.conf:

nightfly@nightbox:/etc/snort/rules$ sudo nano /etc/oinkmaster.conf

aggiungendo la direttiva disablesid seguita dal sid dell’alert che ci interessa (ad esempio 1292 per ATTACK-RESPONSES directory listing):

disablesid 1292

Salviamo il file, riavviamo snort con un sudo service snort restart ed abbiamo finito.

A presto.

Aggiornare snort alla versione 2.9.0.5 su *buntu

L’installazione di snort 2.9.0.5 su *buntu non è affatto banale. Infatti, occorre installare delle specifiche librerie e degli specifici strumenti per poter compilare il codice sorgente dell’IDS in questione.

 

snort 2.0.9.5, snort.conf, oinkmaster, rules, IDS

 

Per prima cosa scarichiamo la tarball mediante CLI usando wget:

nightfly@nightbox:~$ wget -O snort-2.9.0.5.tar.gz http://www.snort.org/downloads/867

Scompattiamola e posizioniamoci nella dir appena creata:

nightfly@nightbox:~$ tar -xzvf snort-2.9.0.5.tar.gz
nightfly@nightbox:~$ cd snort-2.9.0.5/

Stoppiamo la versione obsoleta di snort presente sulla nostra macchina:

nightfly@nightbox:~$ sudo service snort stop

Installiamo adesso alcune librerie necessarie per la compilazione di snort:

nightfly@nightbox:~/snort-2.9.0.5$ sudo apt-get install libpcap0.8-dev
nightfly@nightbox:~/snort-2.9.0.5$ sudo apt-get install libpcre3 libpcre3-dev
nightfly@nightbox:~/snort-2.9.0.5$ sudo apt-get install libdumbnet-dev libdnet libdnet-dev

Creiamo quindi un link simbolico all’header dumbnet.h poichè il file configure di snort va alla ricerca del file dnet.h:

nightfly@nightbox:~/snort-2.9.0.5/$ sudo ln -s /usr/include/dumbnet.h /usr/include/dnet.h

Installiamo l’ultima libreria che ci occorre, ovvero daq-0.5, disponibile direttamente sul sito www.snort.org:

nightfly@nightbox:~/snort-2.9.0.5/$ wget -O daq-0.5.tar.gz http://www.snort.org/downloads/860

nightfly@nightbox:~/snort-2.9.0.5/$ tar -xzvf daq-0.5.tar.gz
nightfly@nightbox:~/snort-2.9.0.5/$ cd daq-0.5/

Per compilare questa libreria è necessario utilizzare l’accoppiata flex/bison. Dunque procediamo con la loro installazione:

nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ sudo apt-get install flex bison

Possiamo ora compilare la libreria daq-0.5:

nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ ./configure
nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ sudo make
nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ sudo make install
nightfly@nightbox:~/snort-2.9.0.5/daq-0.5$ cd ..

Adesso passiamo alla compilazione di snort e successivamente sostituiamo il file di configurazione delle versioni precedenti con quello della release in questione:

nightfly@nightbox:~/snort-2.9.0.5$ sudo make
nightfly@nightbox:~/snort-2.9.0.5$ sudo make install
nightfly@nightbox:~/snort-2.9.0.5$ cd etc
nightfly@nightbox:~/snort-2.9.0.5/etc$ sudo cp snort.conf /etc/snort

Posizioniamoci nella dir /etc/snort ed apriamo il file snort.conf in scrittura:

nightfly@nightbox:~/snort-2.9.0.5/etc$ cd /etc/snort
nightfly@nightbox:/etc/snort$ sudo nano snort.conf

ed effettuiamo le seguenti sostituzioni:

1) ipvar con var (poichè non abbiamo compilato snort con la flag –enable-ipv6)

2) 

var RULE_PATH ../rules
var SO_RULE_PATH ../so_rules
var PREPROC_RULE_PATH ../preproc_rules

     con

var RULE_PATH /rules
var SO_RULE_PATH /so_rules
var PREPROC_RULE_PATH /preproc_rules

3) Commentiamo le seguenti direttive:

#dynamicdetection directory /usr/local/lib/snort_dynamicrules
#include $RULE_PATH/local.rules
#inspect_gzip
#unlimited_decompress
#preprocessor normalize_ip4
#preprocessor normalize_tcp: ips ecn stream
#preprocessor normalize_icmp4
#preprocessor normalize_ip6
#preprocessor normalize_icmp6

4) Rimuoviamo le direttive:

compress_depth 65535 decompress_depth 65535

Ora occorre eliminare tutte le vecchie rules di snort ed installare quelle nuove. Per fare ciò digitiamo i seguenti comandi:

nightfly@nightbox:/etc/snort$ cd rules
nightfly@nightbox:/etc/snort/rules$ sudo rm *

Successivamente installiamo le nuove regole mediante oinkmaster, configurandolo opportunamente affinchè possa scaricare le rules della versione 2.0.9.5:

nightfly@nightbox:/etc/snort/rules$ sudo nano /etc/oinkmaster.conf

ed inseriamo la stringa:

url = http://www.snort.org/pub-bin/oinkmaster.cgi/<vostro oinkcode>/snortrules-snapshot-2905.tar.gz

Adesso possiamo procedere con l’installazione vera e propria delle regole:

nightfly@nightbox:/etc/snort/rules$ sudo oinkmaster -o /etc/snort/rules

Ad installazione completata, prima di lanciare snort, modifichiamo il file /etc/ld.so.conf aggiungendo la direttiva:

include /usr/local/lib

Infine, rendiamo effettiva tale modifica lanciando il comando:

nightfly@nightbox:/etc/snort/rules$ sudo ldconfig

A questo punto lanciamo uno snort -V il cui output dovrebbe essere:

 ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.0.5 (Build 135)
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
           Copyright (C) 1998-2011 Sourcefire, Inc., et al.
           Using libpcap version 1.0.0
           Using PCRE version: 7.8 2008-09-05

Copiamo l’eseguibile presente in /usr/local/bin/snort all’interno della dir /usr/sbin/snort:

nightfly@nightbox:/etc/snort/rules$ sudo cp /usr/sbin/snort /usr/local/bin/snort

Verifichiamo che la configurazione di snort non contenga errori digitando:

nightfly@nightbox:/etc/snort/rules$ sudo snort -T -c /etc/snort/snort.conf

Se l’output visualizzato è il seguente:

Snort successfully validated the configuration!

allora possiamo lanciare un sudo service snort start ed iniziare ad avvalerci di questo potentissimo IDS.

A presto.

Snort: disabilitare la notifica DOUBLE DECODING ATTACK

Che Snort generi una miriade di falsi positivi durante il normale utilizzo della rete è abbastanza risaputo. Ultimamente, però, ho notato la presenza, piuttosto insistente, di notifiche simili alle seguenti:

 [**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**]
 [Priority: 3]
 05/12-21:23:59.624917 192.168.*.*:1299 -> 212.52.84.153:80
 TCP TTL:128 TOS:0x0 ID:5340 IpLen:20 DgmLen:98 DF
 ***AP*** Seq: 0xC593D3E7  Ack: 0x1DDBAA89  Win: 0xFFFF  TcpLen: 20

A quanto pare il preprocessore http_inspect si altera perchè nota la presenza di un doppio meccanismo di codifica mentre si naviga sulla webmail di Libero (per la precisione mailbeta.libero.it). Il fatto che venga utilizzata questa tecnica di codifica non è un’anomalia, semplicemente moltissimi siti Web preferiscono codificare più volte le variabili in modo da garantire un livello di sicurezza più elevato.

images.jpg

 

Come procedere quindi per disabilitare l’alert in questione?

Una soluzione abbastanza rapida consiste nel modificare il file threshold.conf presente nella directory /etc/snort/:

nightfly@nightbox:/etc/snort$ sudo nano threshold.conf

Aggiungendo la stringa:

suppress gen_id 119, sig_id 2

Adesso verifico che il file threshold.conf venga effettivamente utilizzato da snort.conf:

nightfly@nightbox:/etc/snort$ sudo nano snort.conf

A tal proposito è sufficente decommentare la stringa:

# include threshold.conf

che diventerà:

include threshold.conf

Riavvio infine Snort mediante il comando:

nightfly@nightbox:/etc/snort$ sudo service snort restart

e questo piccolo tuning è stato completato.

A presto.