Tutti gli articoli di nazarenolatella

CentOS 6 e contromisure agli attacchi DDoS: regole di firewalling basate sui netblock dei provider italiani

Scenario

Server Web Linux (basato su Apache) con CentOS 6 a bordo, dotato di 16 GB di RAM e 2 CPU con 4 core ciascuna. Totale assenza di firewall di frontend, ergo il filtraggio del traffico viene demandato direttamente al server in questione.

Problema

Da N giorni la suddetta macchina è vittima di attacchi di tipo DDoS, provenienti per lo più da IP stranieri (macchine zombie facenti parte di una botnet).

Soluzione

Creare delle regole netfilter ad hoc (mediante iptables), consentendo solo ed esclusivamente i netblock degli ISP italiani. Inoltre, per evitare che l’attaccante possa avvalersi di qualche proxy “aperto” made in Italy, sono stati bloccati ulteriori IP pubblici recuperati da un sito specifico. Infine, sono stati consentiti gli IP pubblici degli spider (aka crawler) utilizzati dai più importanti motori di ricerca (Google, Bing, Yahoo!), in modo tale da impedire che il sito Web hostato sul server venga penalizzato in termini di ranking.

Step 1: consentire gli IP italiani

Lo scrip bash (permit_ita.sh) che esegue tale operazione è il seguente:

#!/bin/bash

iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

wget http://www.ipdeny.com/ipblocks/data/countries/it.zone -O ip_italiani.txt

while read line
do
    iptables -I INPUT -s $line -p tcp --dport 80 -j ACCEPT
    iptables -I INPUT -s $line -p tcp --dport 443 -j ACCEPT
done < ip_italiani.txt

iptables-save

Il suo funzionamento è banale: per prima cosa vengono create 2 regole netfilter per droppare tutto il traffico HTTP/HTTPS diretto al sito Web. Successivamente viene scaricato (mediante wget) il contenuto del sito http://www.ip-deny.com/ipblocks/data/countries/it.zone, in cui è presente l’elenco dei netblock italiani. Infine, vegnono consentiti i netblock in questione.

Step 2: bloccare i proxy made in Italy

A questo punto possiamo procedere con il blocco dei proxy “open” italiani. Per fare ciò possiamo utilizzare il seguente scrip bash (block_proxy.sh):

#!/bin/bash

wget --user-agent="Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3"  http://spys.ru/free-proxy-list/IT/ -O lista_proxy.txt

grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}" lista_proxy.txt | uniq > ip_proxy.txt

while read line
do
    iptables -I INPUT -s $line -p tcp --dport 80 -j DROP
    iptables -I INPUT -s $line -p tcp --dport 443 -j DROP
done < ip_proxy.txt

iptables-save

Il sito target (ovvero quello che contiene la lista dei proxy da bloccare) è http://spys.ru/free-proxy-list/IT/, il quale effettua un filtraggio dei client che possono accedervi utilizzando lo User Agent come discriminante (quindi non è possibile scaricarne il contenuto se non si effettua uno spoofing di tale parametro tramite wget e l’opzione –user-agent).

Inoltre, poichè il contenuto del sito non è una “lista piatta” di IP pubblici, è stato necessario filtrare il tutto utilizzando un’espressione regolare in grado di individuare i 4 ottetti tipici dell’IPv4.

Step 3: consentire gli spider dei motori di ricerca

Come ultima fase, occorre consentire gli IP degli spider, utilizzando tale scrip (permit_spider.sh):

#!/bin/bash

while read line
do
    iptables -I INPUT -s $line -p tcp --dport 80 -j ACCEPT -m comment --comment "crawler"
done < ip_spider.txt

iptables-save

Il contenuto del file ip_spider.txt potete ricavarlo da qui (Google), qui (Yahoo!) e qui (Bing ed altri).

A configurazione completata, possiamo saggiare il carico sul server (intento a droppare il traffico proveniente dalla botnet) utilizzando htop.

Se la macchina regge e le risorse hardware locali non sono allo stremo potremo finalmente dire di aver vinto.

Alla prossima.

Demone nodejs per CentOS 6

Come già affermato in questo post, nodejs ha rappresentato una vera e propria rivoluzione nella programmazione Web, in quanto ha consentito ad un linguaggio nativamente client-side come javascrip, di essere riadattato ed utilizzato come linguaggio server-side.

nodejs

Il funzionamento del suddetto applicativo è abbastanza banale: si richiama il binario da CLI e gli si da in pasto il file di configurazione del “server javascrip”, ad esempio:

[root@linuxbox ~]# node server.js

Per lasciarlo attivo in background occorre utilizzare un tool apposito come screen oppure un semplice nohup:

[root@linuxbox ~]# nohup node server.js

Va da se che tale soluzione per “demonizzare” nodejs non è proprio pulitissima ed è per questa ragione che ho deciso di creare un demone ad hoc per il suddetto applicativo:

 #!/bin/bash

# chkconfig: 2345 95 20
# description: nodejs service
# processname: nodejs

. /etc/rc.d/init.d/functions

USER="node"

DAEMON="/usr/bin/node"
ROOT_DIR="/home/nodejs"

SERVER="$ROOT_DIR/server.js"

for i in {1..8}

do

        do_start()
        {
                PORT="900$i"
                LOG_FILE="$ROOT_DIR/server$i.js.log"

                result=`ps aux | grep "server.js $PORT" | grep -v grep`
                if [ -z "$result" ] ; then
                echo -n $"Starting $SERVER $i: "
                runuser -l "$USER" -c "$DAEMON $SERVER $PORT >> $LOG_FILE &" && echo_success || echo_failure
                RETVAL=$?
                echo
                [ $RETVAL -eq 0 ]
                else
                echo "$SERVER $i already started."
                RETVAL=1
                fi
        }

        do_status()
        {
                PORT="900$i"

                result=`ps aux | grep "server.js $PORT" | grep -v grep`
                if [ -n "$result" ] ; then
                echo "$SERVER $i is started."
                RETVAL=0
                else
                echo "$SERVER $i is stopped."
                RETVAL=1
                fi
        }

done

do_stop()
{
        echo -n $"Stopping $SERVER:"
        killall -w node
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
}

case "$1" in
start)
        for i in {1..8}
        do
            do_start
        done
        ;;
stop)
        do_stop
        ;;
status)
        for i in {1..8}
        do
            do_status
        done
        ;;
restart)
        do_stop
        for i in {1..8}
        do
            do_start
        done
        ;;
*)

echo "Usage: $0 {start|stop|status|restart}"
        RETVAL=1
esac

exit $RETVAL

Tale demone, ad ogni avvio, esegue 8 istanze di nodejs, ciascuna delle quali è in ascolto su una porta dedicata (dalla 9001 alla 9008). Per non definire 8 funzioni do_start() e do_status() ho utilizzato un banale ciclo for e poichè la funzione do_stop() effettua un kill di tutti i processi il cui nome contiente la stringa “node” (killall -w), essa è stata estromessa dal predetto loop.

Inoltre, per ragioni di sicurezza, è stato definito un utente dedicato per l’esecuzione dell’applicativo (USER=”node”), la cui root directory è la propria home (ROOT_DIR=”/home/nodejs/), mentre il file di configurazione di nodejs è specificato all’interno della variabile SERVER (SERVER=”$ROOT_DIR/server.js”).

Infine, all’interno della funzione do_start(), ho definito il file di log per ciascuna istanza di nodejs, utilizzando la direttiva LOG_FILE=”$ROOT_DIR/server$i.js.log”.

Per completezza, di seguito riporto anche la versione senza cicli for:

#!/bin/bash

# chkconfig: 2345 95 20
# description: nodejs service
# processname: nodejs

. /etc/rc.d/init.d/functions

USER="node"

DAEMON="/usr/bin/node"
ROOT_DIR="/home/nodejs/"

SERVER="$ROOT_DIR/server.js"

PORT1="9001"
PORT2="9002"
PORT3="9003"
PORT4="9004"
PORT5="9005"
PORT6="9006"
PORT7="9007"
PORT8="9008"

LOG_FILE1="$ROOT_DIR/server1.js.log"
LOG_FILE2="$ROOT_DIR/server2.js.log"
LOG_FILE3="$ROOT_DIR/server3.js.log"
LOG_FILE4="$ROOT_DIR/server4.js.log"
LOG_FILE5="$ROOT_DIR/server5.js.log"
LOG_FILE6="$ROOT_DIR/server6.js.log"
LOG_FILE7="$ROOT_DIR/server7.js.log"
LOG_FILE8="$ROOT_DIR/server8.js.log"

do_start1()
{
        result1=`ps aux | grep "server.js $PORT1" | grep -v grep`
        if [ -z "$result1" ] ; then
        echo -n $"Starting $SERVER 1: "
        runuser -l "$USER" -c "$DAEMON $SERVER $PORT1 >> $LOG_FILE1 &" && echo_success || echo_failure
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
        else
        echo "$SERVER 1 already started."
        RETVAL=1
        fi
}

do_start2()
{
        result2=`ps aux | grep "server.js $PORT2" | grep -v grep`
        if [ -z "$result2" ] ; then
        echo -n $"Starting $SERVER 2: "
        runuser -l "$USER" -c "$DAEMON $SERVER $PORT2 >> $LOG_FILE2 &" && echo_success || echo_failure
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
        else
        echo "$SERVER 2 already started."
        RETVAL=1
        fi
}

do_start3()
{
        result3=`ps aux | grep "server.js $PORT3" | grep -v grep`
        if [ -z "$result3" ] ; then
        echo -n $"Starting $SERVER 3: "
        runuser -l "$USER" -c "$DAEMON $SERVER $PORT3 >> $LOG_FILE3 &" && echo_success || echo_failure
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
        else
        echo "$SERVER 3 already started."
        RETVAL=1
        fi
}

do_start4()
{
        result4=`ps aux | grep "server.js $PORT4" | grep -v grep`
        if [ -z "$result4" ] ; then
        echo -n $"Starting $SERVER 4: "
        runuser -l "$USER" -c "$DAEMON $SERVER $PORT4 >> $LOG_FILE4 &" && echo_success || echo_failure
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
        else
        echo "$SERVER 4 already started."
        RETVAL=1
        fi
}

do_start5()
{
        result5=`ps aux | grep "server.js $PORT5" | grep -v grep`
        if [ -z "$result5" ] ; then
        echo -n $"Starting $SERVER 5: "
        runuser -l "$USER" -c "$DAEMON $SERVER $PORT5 >> $LOG_FILE5 &" && echo_success || echo_failure
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
        else
        echo "$SERVER 5 already started."
        RETVAL=1
        fi
}

do_start6()
{
        result6=`ps aux | grep "server.js $PORT6" | grep -v grep`
        if [ -z "$result6" ] ; then
        echo -n $"Starting $SERVER 6: "
        runuser -l "$USER" -c "$DAEMON $SERVER $PORT6 >> $LOG_FILE6 &" && echo_success || echo_failure
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
        else
        echo "$SERVER 6 already started."
        RETVAL=1
        fi
}

do_start7()
{
        result7=`ps aux | grep "server.js $PORT7" | grep -v grep`
        if [ -z "$result7" ] ; then
        echo -n $"Starting $SERVER 7: "
        runuser -l "$USER" -c "$DAEMON $SERVER $PORT7 >> $LOG_FILE7 &" && echo_success || echo_failure
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
        else
        echo "$SERVER 7 already started."
        RETVAL=1
        fi
}

do_start8()
{
        result8=`ps aux | grep "server.js $PORT8" | grep -v grep`
        if [ -z "$result8" ] ; then
        echo -n $"Starting $SERVER 8: "
        runuser -l "$USER" -c "$DAEMON $SERVER $PORT8 >> $LOG_FILE8 &" && echo_success || echo_failure
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
        else
        echo "$SERVER 8 already started."
        RETVAL=1
        fi
}

do_status1()
{
        result1=`ps aux | grep "server.js $PORT1" | grep -v grep`
        if [ -n "$result1" ] ; then
        echo "$SERVER 1 is started."
        RETVAL=0
        else
        echo "$SERVER 1 is stopped."
        RETVAL=1
        fi
}

do_status2()
{
        result2=`ps aux | grep "server.js $PORT2" | grep -v grep`
        if [ -n "$result2" ] ; then
        echo "$SERVER 2 is started."
        RETVAL=0
        else
        echo "$SERVER 2 is stopped."
        RETVAL=1
        fi
}

do_status3()
{
        result3=`ps aux | grep "server.js $PORT3" | grep -v grep`
        if [ -n "$result3" ] ; then
        echo "$SERVER 3 is started."
        RETVAL=0
        else
        echo "$SERVER 3 is stopped."
        RETVAL=1
        fi
}

do_status4()
{
        result4=`ps aux | grep "server.js $PORT4" | grep -v grep`
        if [ -n "$result4" ] ; then
        echo "$SERVER 4 is started."
        RETVAL=0
        else
        echo "$SERVER 4 is stopped."
        RETVAL=1
        fi
}

do_status5()
{
        result5=`ps aux | grep "server.js $PORT5" | grep -v grep`
        if [ -n "$result5" ] ; then
        echo "$SERVER 5 is started."
        RETVAL=0
        else
        echo "$SERVER 5 is stopped."
        RETVAL=1
        fi
}

do_status6()
{
        result6=`ps aux | grep "server.js $PORT6" | grep -v grep`
        if [ -n "$result6" ] ; then
        echo "$SERVER 6 is started."
        RETVAL=0
        else
        echo "$SERVER 6 is stopped."
        RETVAL=1
        fi
}

do_status7()
{
        result7=`ps aux | grep "server.js $PORT7" | grep -v grep`
        if [ -n "$result7" ] ; then
        echo "$SERVER 7 is started."
        RETVAL=0
        else
        echo "$SERVER 7 is stopped."
        RETVAL=1
        fi
}

do_status8()
{
        result8=`ps aux | grep "server.js $PORT8" | grep -v grep`
        if [ -n "$result8" ] ; then
        echo "$SERVER 8 is started."
        RETVAL=0
        else
        echo "$SERVER 8 is stopped."
        RETVAL=1
        fi
}

do_stop()
{
        echo -n $"Stopping $SERVER:"
        killall -w node
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ]
}

case "$1" in
start)
        do_start1
        do_start2
        do_start3
        do_start4
        do_start5
        do_start6
        do_start7
        do_start8
        ;;
stop)
        do_stop
        ;;
status)
        do_status1
        do_status2
        do_status3
        do_status4
        do_status5
        do_status6
        do_status7
        do_status8
        ;;
restart)
        do_stop
        do_start1
        do_start2
        do_start3
        do_start4
        do_start5
        do_start6
        do_start7
        do_start8
        ;;
*)

echo "Usage: $0 {start|stop|status|restart}"
        RETVAL=1
esac

exit $RETVAL

Basta dare una semplice occhiata e vi renderete subito conto del perchè abbia preferito la prima versione a quest’ultima.

Non ci rimane che rendere il demone eseguibile:

[root@linuxbox ~]# chmod +x nodejs

spostarlo nella directory /etc/init.d:

[root@linuxbox ~]# mv nodejs /etc/init.d

ed avviarlo:

[root@linuxbox ~]# service nodejs start

E’ tutto.

Configurare il protocollo SNMP su un router Cisco 2811

In questo post abbiamo visto come configurare una linux box affinchè possa ricevere le trap SNMP. Adesso vedremo come configurare il portocollo SNMP (sia polling che trap) su un router Cisco 2811.

cisco2811Configurazione generica

Per prima cosa occorre accedere alla CLI del router in modalità ena e successivamente lanciare i seguenti comandi:

Router# conf t
Router(config)# snmp-server host <IP> keypublic
Router(config)# snmp-server community keypublic RO
Router(config)# snmp-server community keyprivate RW

Mediante il primo comando stiamo definento l’host target delle trap SNMP, mentre con il secondo ed il terzo comando specifichiamo rispettivamente la community string in lettura e quella in scrittura.

Abilitazione delle trap

A questo punto possiamo definire le trap che dovranno essere inviate alla nostra linux box, ad esempio:

Router(config)# snmp-server enable traps snmp
Router(config)# snmp-server enable traps vrrp
Router(config)# snmp-server enable traps hsrp
Router(config)# snmp-server enable traps tty
Router(config)# snmp-server enable traps ethernet cfm cc
Router(config)# snmp-server enable traps ethernet cfm crosscheck
Router(config)# snmp-server enable traps memory
Router(config)# snmp-server enable traps config-copy
Router(config)# snmp-server enable traps config
Router(config)# snmp-server enable traps resource-policy
Router(config)# snmp-server enable traps pppoe
Router(config)# snmp-server enable traps cpu
Router(config)# snmp-server enable traps syslog
Router(config)# snmp-server enable traps isakmp policy add
Router(config)# snmp-server enable traps isakmp policy delete
Router(config)# snmp-server enable traps isakmp tunnel start
Router(config)# snmp-server enable traps isakmp tunnel stop
Router(config)# snmp-server enable traps ipsec cryptomap add
Router(config)# snmp-server enable traps ipsec cryptomap delete
Router(config)# snmp-server enable traps ipsec cryptomap attach
Router(config)# snmp-server enable traps ipsec cryptomap detach
Router(config)# snmp-server enable traps ipsec tunnel start
Router(config)# snmp-server enable traps ipsec tunnel stop
Router(config)# snmp-server enable traps ipsec too-many-sas

Inutile dire che la tipologia di trap da abilitare dipende strettamente dalla configurazione del router, dalle feature abilitate (VPN IPsec), dal tipo di connessione WAN (PPP), ecc.

Polling SNMP tramite Nagios

Premesso che gli OID SNMP possono variare in base alla versione di IOS installata sul nostro router (a tal proposito vi consiglio di consultare questo sito), per prima cosa occorre definire i comandi specifici (all’interno dei file /etc/nagios/object/commands.cfg) che dovranno essere utilizzati dal nostro NMS per interrogare il dispositivo target.

Eccone un esempio:

# 'check_snmp_if_status' command definition
define command{
        command_name    check_snmp_if_status
        command_line    $USER1$/check_snmp -t 20 -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -r $ARG3$
        }
# 'check_snmp_cpu_load' command definition

define command{
        command_name    check_snmp_cpu_load
        command_line    $USER1$/check_snmp -t 20 -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -w $ARG3$ -c $ARG4$
        }

# 'check_snmp_used_memory' command definition

define command{
        command_name    check_snmp_used_memory
        command_line    $USER1$/check_snmp -t 20 -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -w $ARG3$ -c $ARG4$
        }

# 'check_snmp_uptime' command definition

define command{
        command_name    check_snmp_uptime
        command_line    $USER1$/check_snmp -t 20 -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -w $ARG3$ -c $ARG4$
        }

Infine, definiamo i servizi che si avvarranno dei suddetti comandi:

define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Uptime
 check_command                   check_snmp_uptime!keypublic!.1.3.6.1.6.3.10.2.1.3.0!@61:900!@0:60
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Last Minute CPU Load
 check_command                   check_snmp_cpu_load!keypublic!.1.3.6.1.4.1.9.2.1.57.0!80!90
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Last 5 Minutes CPU Load
 check_command                   check_snmp_cpu_load!keypublic!.1.3.6.1.4.1.9.2.1.58.0!80!90
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Used Memory
 check_command                   check_snmp_used_memory!keypublic!1.3.6.1.4.1.9.9.48.1.1.1.5.1!100000000!120000000
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Status Interface WAN
 check_command                   check_snmp_if_status!keypublic!.1.3.6.1.2.1.2.2.1.8.1!1
 }
define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_description             Status Interface LAN
 check_command                   check_snmp_if_status!keypublic!.1.3.6.1.2.1.2.2.1.8.2!1
 }

A questo punto sarà sufficiente ricaricare la configurazione di Nagios mediante il comando:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

MRTG e Nagios: monitoraggio del throughput di rete

MRTG (Multi Router Traffic Grapher) rappresenta lo standard “de facto” per ciò che concerne il monitoraggio del throughput della nostra rete. Il suo funzionamento è basato sul polling SNMP, grazie al quale vengono raccolte le informazioni sul traffico che coinvolge le schede di rete monitorate, per poi procedere con la creazione di un grafico “ad hoc”, contenente le predette informazioni.

mrtg_logo

Installazione e configurazione di MRTG

La macchina che svolge le operazioni di monitoraggio è una linux box con a bordo CentOS 6. Per installare MRTG è dunque sufficiente digitare il comando:

[root@linuxbox ~]# yum install mrtg

Inoltre, sarà necessario installare anche i pacchetti net-snmp e net-snmp-utils (per effettuare il polling SNMP vero e proprio):

[root@linuxbox ~]# yum install net-snmp net-snmp-utils

Ad installazione completata passiamo alla configurazione di MRTG. Per prima cosa sarà necessario lanciare il comando:

[root@linuxbox ~]# cfgmaker --global 'WorkDir: /var/www/mrtg' --output /etc/mrtg/mrtg.cfg keypublic@iptarget

Esso ci consentirà di popolare in maniera automatica il file di configurazione /etc/mrtg/mrtg.cfg, grazie al quale, successivamente, verrà creata la pagina Web (con estensione *.html) contenente i grafici generati da MRTG. Inoltre, all’interno del file di configurazione mrtg.cfg, sarà opportuno abilitare le seguenti opzioni:

Options[_]: growright, bits

le quali consentiranno la tracciatura dei grafici da sinistra verso destra, utilizzando i bit come unità di misura (anzichè i byte).

Per creare la pagina Web contenente i grafici è necessario digitare il comando:

[root@linuxbox ~]# indexmaker --output=/var/www/mrtg/index.html /etc/mrtg/mrtg.cfg

A questo punto facciamo in modo che i dati relativi al traffico vengano aggiornati ogni 5 minuti, creando un’apposita regola mediante cron (editando il file /etc/cron.d/mrtg):

*/5 * * * * root LANG=C LC_ALL=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg --lock-file /var/lock/mrtg/mrtg_l --confcache-file /var/lib/mrtg/mrtg.ok

L’ultimo step relativo alla configurazione di MRTG riguarda il settaggio delle credenziali (username/password) per l’accesso alla pagina index.html. Per fare ciò occorre creare il file mrtg.conf, all’interno della directory /etc/httpd/conf.d di Apache (il nostro server Web), il cui contenuto dovrà essere simile al seguente:

Alias /mrtg /var/www/mrtg

<Location /mrtg>
    Order deny,allow
    Allow from all
    AuthName "MRTG Access"
    AuthType Basic
    AuthUserFile /etc/mrtg/passwd
    Require valid-user
</Location>

Ora definiamo lo username e la password (che verrà salvata nel file /etc/mrtg/passwd in formato digest), utilizzando il comando:

[root@linuxbox ~]# htpasswd -c /etc/mrtg/passwd mrtguser

Infine, ricarichiamo la configurazione Apache digitando:

[root@linuxbox ~]# service httpd reload

e proviamo ad accedere ai grafici generati da MRTG, puntando a questa URL:

http://iplinuxbox/mrtg

Se la pagina è accessibile ed i grafici sono aggiornati, possiamo passare alla configurazione di Nagios.

Integrazione tra Nagios ed MRTG

Il plugin di Nagios che ci consente di integrare tale NMS con MRTG prende il nome di check_mrtgtraf. Esso può essere installato singolarmente, digitando:

[root@linuxbox ~]# yum install nagios-plugins-mrtgtraf

oppure installando tutti i plugin di Nagios:

[root@linuxbox ~]# yum install nagios-plugins-all

Ad installazione completata, possiamo definire il comando check_local_mrtgtraf (all’interno del file /etc/nagios/object/commands.cfg), il quale si avvarrà del plugin appena installato:

# 'check_local_mrtgtraf' command definition
define command{
        command_name    check_local_mrtgtraf
        command_line    $USER1$/check_mrtgtraf -F $ARG1$ -a $ARG2$ -w $ARG3$ -c $ARG4$ -e $ARG5$
        }

dove -F indica il file di log (generato da MRTG) che dovrà essere consulato; -a indica la modalità di analisi del traffico (MAX o AVG); -w la soglia di warning e -c la soglia critica.

Non ci rimane che definire il servizio (relativo ad uno specifico host) che dovrà avvalersi del suddetto comando:

define service{
        use                             local-service   ; Inherit values from a template
        host_name                       Router-cisco
        service_description             WAN Bandwidth Usage
        check_command                   check_local_mrtgtraf!/var/www/mrtg/router-cisco/192.168.3.1_16.log!AVG!100000000,200000000!110000000,120000000!10
        }

Ricarichiamo la configurazione di Nagios mediante il comando:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

Creazione di una logging facility mediante logrotate ed expect

Scenario

Diversi siti Web (Apache) con N virtual host, ciascuno dei quali utilizza 2 file di log dedicati (access ed error), per il salvataggio degli accessi (nel primo caso) e degli errori generati (nel secondo caso).

Problema

Data l’enorme mole di utenza, è necessario comprimere e salvare i suddetti file di log con cadenza settimanale, spostando l’archivio appena ottenuto su di una logging facility (nella fattispecie una linux box), utilizzando il protocollo SFTP.

Soluzione

Integrare lo scrip di logrotate con alcuni scrip expect fatti in casa.

logging-facility

Logrotate

Lo scrip logrotate che si occuperà della vera e propria rotazione dei file di log (con cadenza settimanale) è il seguente:

/var/log/httpd/*log {
    rotate 1
    missingok
    notifempty
    sharedscrips
    dateext
    compress
    copytruncate
    weekly
    postrotate
        /sbin/service httpd restart > /dev/null 2>/dev/null || true
    endscrip
    lastaction
        /root/logrotation/autoputlog/apache > /var/log/autoputlog/apache.log
    endscrip
}

/var/log/httpd/virtual/*/*log {
    rotate 1
    missingok
    notifempty
    sharedscrips
    dateext
    compress
    copytruncate
    weekly
    postrotate
        /sbin/service httpd restart > /dev/null 2>/dev/null || true
    endscrip
    lastaction
         /root/logrotation/autoputlog/apachecustom > /var/log/autoputlog/apachecustom.log
    endscrip
}

Nella fattispecie, la prima parte si occupa della rotazione dei file di log relativi alla root directory canonica di Apache, ovvero /var/www/html, mentre la seconda parte si occupa dei virtual host veri e propri.

I suddetti scrip ci permettono di integrare logrotate con expect grazie alla direttiva lastaction. In particolare, essa farà in modo che, una volta completata la rotazione (con la creazione di una tarball opportuna), venga eseguito lo scrip expect apache (nel primo caso) ed apachecustom (nel secondo caso), presenti nella directory /root/logrotation/autoputlog.

L’output realtivo al processo di esecuzione degli scrip in questione verrà salvato rispettivamente all’interno del file apache.log ed apachecustom.log, presenti in /var/log/autoputlog. Inoltre, sarà necessario creare i file in questione prima che la rotazione venga testata, utilizzando i comandi :

[root@frontend ~]# mkdir -p /var/log/autoputlog

e

[root@frontend ~]# touch apache.log apachecustom.log

Infine, di seguito riporto il contenuto dello scrip expect apache:

#!/usr/bin/expect
set timeout 60
set password "vostrapassword"
spawn sftp admin@iplogfacility:array1/logs/frontend1/httpd
expect "*?assword:*"
send "$password\r"
expect "sftp"
send "put /var/log/httpd/*.gz\r"
expect "sftp"
send "exit\r"
expect eof

ed apachecustom:

#!/usr/bin/expect
set timeout -1
set password "vostrapassword"
spawn sftp admin@iplogfacility:array1/logs/frontend1/httpd
expect "*?assword:*"
send "$password\r"
expect "sftp"
send "cd vhost1\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost1/*.gz\r"
expect "sftp"
send "cd ../vhost2\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost2/*.gz\r"
expect "sftp"
send "cd ../vhost3\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost3/*.gz\r"
expect "sftp"
send "exit\r"
expect eof

Non ci rimane che lanciare forzatamente logrotate per testarne il funzionamento, utilizzando il comando:

[root@frontend ~]# logrotate -f /etc/logrotate.d/httpd

ed abbiamo finito.

A presto.

Centos 6 e snmptrapd: ricevere le trap SNMP sulla nostra linux box

Il protocollo SNMP, nativamente, ci mette a disposizione 2 modalità di funzionamento: quella classica, basata sul semplice polling, che utilizza la porta UDP 161, e quella “asincrona”, le cosiddette trap, che utilizzano la porta UDP 162.

Va da se che la seconda modalità è migliore rispetto alla prima, in quanto ci consente di ricevere un allarme quasi in tempo reale, dato che è proprio il dispositivo monitorato a generare l’evento (trap) ed a inoltrarcelo.

snmptrap

Ma vediamo ora come configurare la nostra linux box in modo da farle accettare (e loggare) le suddette trap.

Iptables

La prima cosa da fare consiste nel consentire il traffico UDP in ingresso, sulla porta 162:

iptables -I INPUT -p udp --dport 162 -j ACCEPT

Ovviamente tale regola iptables può essere ulteriormente affinata, specificando, ad esempio, l’interfaccia in ingresso (-i), l’IP sorgente (-s) e l’IP di destinazione (-d).

Configurazione di snmptrapd

Adesso occorre configurare il demone che si occupa della ricezione delle trap, ovvero snmptrapd.

Il suo file di configurazione è /etc/snmp/snmptrapd.conf, il cui contenuto dovrà essere simile al seguente:

authCommunity log,execute,net keypublic
format1 %l-%m-%y %h:%j:%k from %A: %b %P %N %W %v\n
format2 %l-%m-%y %h:%j:%k from %A: %b %P %N %W %v\n

La prima entry specifica la community string (keypublic) e le azioni che snmptrapd può effettuare alla ricezione delle trap, ovvero loggarle (log), eseguire un evento specifico tramite handler (execute) oppure inoltrarle ad un altro dispositivo connesso in rete (net).

Mediante le direttive format1 e format2 (utilizzare, rispettivamente, nell’ambito del protocollo SNMPv1 e v2c), specifichiamo il formato del file di log in cui verranno salvate le trap ricevute. In particolare, con:

%l-%m-%y %h:%j:%k

indichiamo il timestamp nel formato giorno-mese-anno ora:minuto:secondo.

Utilizzando invece:

from %A

siamo in grado di loggare il nome del dispositivo che ci ha inviato la trap, mentre con:

%b

ricaviamo l’indirizzo IP del suddetto dispositivo.

Infine, con:

 %P, %N, %W

abbiamo rispettivamente la community string utilizzata dalla trap, la stringa enterprise (che identifica univocamente il produttore del dispositivo) e la descrizione della trap. Ecco un esempio del contenuto del file di log popolato da snmptrapd:

23-7-2015 10:9:0 from 10.12.12.3: UDP: [10.12.12.3]:62741->[10.12.12.2] TRAP, SNMP v1, community keypublic VMWARE-CIMOM-MIB::vmwCimOm Enterprise Specific VMWARE-ENV-MIB::vmwEnvIndicationTime.0 = STRING: 2015-7-23,8:8:59.0

Occorre notare che le trap non vengono ricevute (e loggate) in formato numerico, in quanto sulla linux box sono presenti le MIB (scritte attraverso il linguaggio SMI) specifiche per i dispisitivi monitorati (in questo caso degli host VMWare). Solo a titolo informativo, le suddette MIB vanno salvate all’interno della directory /usr/share/snmp/mibs/.

 Opzioni di avvio

Una volta configurato, snmptrapd deve essere avviato utilizzando determinate opzioni, affinchè il processo di logging venga effettuato secondo le nostre necessità. Il file in cui specificare tali opzioni è /etc/sysconfig/snmptrapd, il cui contenutò dovrà essere simile al seguente:

OPTIONS="-A -m ALL -M /usr/share/snmp/mibs -Lf /var/log/snmptrapd.log -p /var/run/snmptrapd.pid"

dove l’opzione -A indica la modalità di scrittura del file di log (append); -m ALL indica la necessità di utilizzare tutte le MIB presenti sul sistema; -M serve a specificare il pathname delle MIB; -Lf indica il file di log ed infine -p punta al pathname del file *.pid (process ID) associato al demone in questione.

Rotazione del file di log

Naturalmente un file di log troppo grande risulta molto più difficile da consultare, ergo occorre definire delle regole di rotazione utilizzando lo strumento messo a disposizione dalla nostra linux box, ovvero logrotate. In particolare, il contenuto del file snmptrapd presente nella directory /etc/logrotate.d dovrà essere il seguente:

/var/log/snmptrapd.log {
    rotate 10
    missingok
    notifempty
    sharedscripts
    delaycompress
    copytruncate
    weekly
    postrotate
        /sbin/service snmtrapd restart > /dev/null 2>/dev/null || true
    endscript
}

Tra le suddette opzioni, quella più importante è certamente copytruncate, senza la quale, dopo ogni rotazione, il file di log non sarebbe in grado di registrare nuovi eventi.

Ora che è tutto configurato possiamo avviare il demone:

[root@linuxbox ~]# service snmptrapd start

e fare in modo che venga eseguito automaticamente dopo ogni boot:

[root@linuxbox ~]# chkconfig snmptrapd on

Invio tramite email delle trap di allarme

L’ultimo step consiste nel fare in modo che tutte le trap di allarme vengano inviate sulla nostra mailbox. Per fare ciò si può utilizzare swatch, il cui file di configurazione (/etc/swatch_snmp.conf) dovrà essere simile a questo:

#SNMP TRAP ALERT
watchfor  /Alert|alert/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH LINUX-BOX: SNMP TRAP ALERT

Editiamo il file /etc/rc.local in modo da avviare automaticamente swatch ad ogni boot della macchina:

swatch -c /etc/swatch_snmp.conf -t /var/log/snmptrapd.log &

Lanciamo il comando:

[root@linuxbox ~]# swatch -c /etc/swatch_snmp.conf -t /var/log/snmptrapd.log &

ed abbiamo finito.

Alla prossima.

sniffer.sh: script bash per l’individuazione dei site grabber

Scenario

Supponiamo che il vostro sito sia diventato oggetto delle attenzioni di un grabber (di cui non si conosce l’indirizzo IP pubblico), che ogni X tempo ne preleva il contenuto forzosamente.

Supponiamo, inoltre, che il suddetto grabber sia abbastanza intelligente da coprire le proprie tracce “spoofando” lo user agent in modo da apparire come un client lecito.

590x300

Nel caso in cui non si abbiano a disposizione strumenti di log analysis avanzati quali Splunk, l’unica alternativa per individuare l’IP pubblico del grabber consiste nel crearsi degli strumenti ad-hoc,  in grado di fare un conteggio del numero di hit per ciascun IP pubblico che ha contattato il nostro sito.

In soldoni si tratta di un semplice scrip bash, che riporto di seguito.

#!/bin/bash

filename1="/var/log/sniffer.log"

filename2="/var/log/sources.log"

filename3="/var/log/sources_sorted.log"

filename4="/var/log/sources_sorted_by_hits.log"

if [ -e $filename1 ];then

cat /dev/null > $filename1

fi

if [ -e $filename2 ];then

cat /dev/null > $filename2

fi

if [ -e $filename3 ];then

cat /dev/null > $filename3

fi

if [ -e $filename4 ];then

cat /dev/null > $filename4

fi

echo ""

echo -e "33[32mSniffing traffic... Press CTRL+C to stop"

echo -e "33[37m"

START=$(date +%s);

iftop -i eth0 -n -f 'port (80 or 443)' -t > $filename1

echo ""

read -p "Press [Enter] key to continue..."

END=$(date +%s);

ELAPSED_TIME=$((END-START))

echo -e "33[32mShowing hit number provided in $ELAPSED_TIME seconds, ordered by source..."

echo -e "33[37m"

cat $filename1 | grep '<=' | awk '{ print $1 }' > $filename2

cat $filename2 | sort -u > $filename3

while read line

do
 hits=`cat $filename2 | grep $line | wc -l`

host=`host $line`

echo "hits for IP $line ($host): $hits" >> $filename4

done < $filename3

cat $filename4 | sort -k 5 -nr

exit 0

Esso si basa principalmente sul software iftop e, una volta lanciato, rimane in ascolto sulle porte di interesse (nel nostro caso la TCP/80 e la TCP/443), per poi stilare una “classifica” di IP pubblici in base al numero di hit che hanno prodotto durante il tempo di osservazione.

Come informazione aggiuntiva, per ogni IP viene ricavato anche il suo FQDN (attraverso il comando host), in modo da individuare ancora più facilmente la provenienza del grabber.

Per maggiore chiarezza, ecco un esempio di output relativo al suddetto script:

hits for IP 87.18.215.154 (154.215.18.87.in-addr.arpa domain name pointer host154-215-dynamic.18-87-r.retail.telecomitalia.it.): 18
hits for IP 84.223.145.17 (17.145.223.84.in-addr.arpa domain name pointer dynamic-adsl-84-223-145-17.clienti.tiscali.it.): 23
hits for IP 84.222.212.172 (172.212.222.84.in-addr.arpa domain name pointer dynamic-adsl-84-222-212-172.clienti.tiscali.it.): 23
hits for IP 79.18.99.217 (217.99.18.79.in-addr.arpa domain name pointer host217-99-dynamic.18-79-r.retail.telecomitalia.it.): 24
hits for IP 2.35.156.49 (49.156.35.2.in-addr.arpa domain name pointer net-2-35-156-49.cust.vodafonedsl.it.): 21
hits for IP 188.87.64.235 (235.64.87.188.in-addr.arpa domain name pointer static-235-64-87-188.ipcom.comunitel.net.): 23
hits for IP 151.45.153.218 (218.153.45.151.in-addr.arpa domain name pointer adsl-ull-218-153.45-151.net24.it.): 14

Inoltre, consultando il file /var/log/sources_sorted_by_hits.log, sarà possibile ricavare la lista degli IP/FQDN ordinati (in modo decrescente) in base al numero delle hit che hanno effettuato.

Una volta individuato l’IP che ci interessa non ci resta che bloccarlo utilizzando, ad esempio, iptables:

iptables -I INPUT -s <ip del grabber> -j DROP

ed abbiamo finito.

Alla prossima.

TCP Offload: conviene davvero abilitarlo?

Di recente, dopo svariati test effettuati in laboratorio, si è deciso di aggiornare i driver delle schede di rete installate su 2 macchine Windows Server 2003 R2 (in failover cluster) , passando dai driver Broadcom a quelli Intel (cosa molto più sensata dato che il produttore delle NIC è, per l’appunto, Intel).

intelVa detto che tale scelta è stata dettata anche dal fatto che con il software di gestione del teaming  messo a disposizione da Broadcom, l’unica modalità selezionabile era il load balancing, ovvero la possibilità di transmettere/ricevere il traffico di rete “un po’ da una scheda ed un po’ dall’altra”. Fin qui nulla di male, se non fosse per il fatto che,  in caso di fault di uno dei due switch o di una delle due schede del teaming, prima che il sistema riuscisse a riconvergere sull’unica NIC ancora funzionante, si è assistito ad un tempo di disservizio randomico, che poteva variare da qualche secondo a qualche minuto. Premesso che, a mio avviso, tale comportamento era strettamente legato alla durata della cache ARP dei sistemi coinvolti, una situazione del genere non era comunque tollerabile, soprattutto per dei sistemi di importanza critica e cruciale.

A differenza di quanto assistito per il software Broadcom, grazie al software Intel, configurando le schede in modalità switch failover, si è riusciti a ridurre notevolmente i tempi di riconvergenza, portandoli a circa un secondo (ed un solo pacchetto ICMP in request timeout). Tutto molto bello, a parte il fatto che dopo aver aggiornato i driver, il sistema ha iniziato a ricevere (ed inviare) i dati troppo lentamente.

Dopo aver analizzato innumerevoli tracciati Wireshark ed aver spulciato tutta la documentazione possibile ed immaginabile, sono arrivato alla conclusione che la causa della suddetta problematica era il TCP Offload (abilitato di default).

Cos’è il TCP Offload

Il TCP Offload è stato introdotto per ridurre l’overhead (leggasi carico aggiuntivo) dei server durante la gestione del traffico di rete (il quale è aumentato in modo esponenziale rispetto alle reti TCP/IP di un trentennio addietro). Nella fattispecie, grazie alla suddetta “feature”, il traffico viene gestito direttamente dall’hardware della NIC (senza quindi passare per la CPU). Per essere più precisi, vige la regola che per ogni byte di traffico di rete gestito dal server corrisponda un carico sulla CPU pari ad un HZ, quindi si può certamente intuire quanto il TCP offload possa portare (in alcuni casi) dei benefici a livello computazionale e prestazionale.

Solitamente tale configurazione è dunque migliorativa, salvo alcune eccezioni. Ad esempio, spesso accade che il TCP offload forgi dei segmenti TCP di dimensione superiore a 64 byte, i quali vengono incapsulati (layer 2) in frame di dimensione superiore ai 1500 byte (che rappresenta la MTU di default delle reti Ethernet e quindi quella supportata nativamente dalla stragrande maggioranza dei dispositivi di rete).

Cosa succede in questo caso? Ebbene, se gli switch non sono configurati a dovere, essi scarteranno (in modo trasparente, salvo previa connessione alla CLI se si tratta di dispositivi managed) i pacchetti con MTU > 1500 byte, riducendo drasticamente il throughput dei server.

In definitiva, nel caso in cui riscontraste una lentezza anomala in TX/RX da parte delle vostre macchine, vi consiglio, come primo step, di disabilitare tale opzione.

Alla prossima.

Firewall Cisco ASA ed attacchi DDoS/DoS

Ultimamente mi è capitato di dover far fronte a tutta una serie di attacchi DDoS, per lo più basati sul protocollo HTTP (connessioni half-open/embryonic, in cui manca il l’ACK finale poichè l’indirizzo IP sorgente del SYN è falso o soggetto a spoofing), mitigati senza troppe difficoltà da un cluster di Firewall Cisco ASA.

ddosLa configurazione che ho utilizzato per mitigare tale tipologia di attacchi è simile alla seguente:

ASA(config)# class-map mpf-policy
ASA(config-cmap)# match access-list outside_access_in
ASA(config-cmap)# exit
ASA(config)# policy-map mpf-policy-map
ASA(config-pmap)# class mpf-policy
ASA(config-pmap-c)# set connection conn-max 11500
ASA(config-pmap-c)# set connection embryonic-conn-max 3000
ASA(config-pmap-c)# set connection per-client-embryonic-max 200
ASA(config-pmap-c)# set connection per-client-max 95
ASA(config-pmap-c)# exit
ASA(config-pmap)# exit
ASA(config)# service-policy mpf-policy-map interface outside
ASA(config)# exit

Tutto è filato liscio per un po’ di tempo, fino a quando l’attaccante non ha deciso di cambiare strategia, passando da un attacco DDoS ad uno DoS (dunque con un solo IP sorgente) e dal protocollo TCP a quello UDP (molto più adatto a questa tipologia di attacco poichè connection-less).

La VPS utilizzata come sorgente di traffico, dotata di ampia banda (si trovava in una farm tedesca) è stata in grado, in un lasso di tempo brevissimo, di far collassare i firewall. Una volta identificato il suo IP ho creato un’ACL del tipo:

ASA(config)#deny ip host <IP attaccante> any

che però si è rivelata essere un’arma a doppio taglio visto che il firewall si è visto costretto a “maneggiare” e “bloccare” una mole di traffico tale per cui la sua CPU ha raggiunto livelli di carico assurdi (la dashboard di ASDM indicava un picco di oltre il 300% a fronte di un rate di pacchetti droppati superiore ai 100k  – vedi immagine sottostante).

dropped_ratedropped_rate

Fondamentalmente ciò è dovuto al fatto che ciascun modello di ASA può gestire solo una determinata mole di traffico (sessioni concorrenti, nuove connessioni/secondo, pacchetti/secondo, ecc – per ulteriori dettagli vedi qui), limite imposto soprattutto dalle caratteristiche hardware di cui è dotato (CPU, RAM, ecc.). Inoltre, per ciascun pacchetto scartato, è necessario un certo overhead, ragion per cui la suddetta ACL ha prodotto effetti collaterali che hanno portato ad un peggioramento della situazione.

Dopo qualche minuto di smarrimento, ho deciso di modificare la mia strategia (sulla falsariga di quella dell’attaccante), consentendo sul firewall tutto il traffico in ingresso dall’IP della VPS incriminata, demandando ai server la sua gestione. Nella fattispecie, ho configurato dei blackhole (aka null route) a livello 3, mediante il seguente comando:

route add -net <IP attaccante> gw 127.0.0.1 lo

Ho scelto questa strategia per 2 motivi:

1) I server sono dotati di maggiori risorse hardware rispetto ai firewall, quindi più “propensi” a gestire una tale mole di traffico in ingresso;

2) Lavorare a livello 3 anzichè a livello 4 implica un minor overhead.

Alla fine tale strategia si è rivelata vincente e l’attaccante ha deposto le armi.

E’ tutto, alla prossima.

checksecurity.sh: script bash per monitorare gli aggiornamenti critici su CentOS 6

Poichè devo gestire un elevato numero di VM *nix, mi è indispensabile riuscire ad automatizzare quanti più task possibili, tenendo sempre a mente tale regola:

                                                                        a good sysadmin is a lazy one

Uno di questi task riguarda le notifiche per gli aggiornamenti critici di sistema, soprattutto per ciò che concerne l’aspetto della cyber security.

A tal proposito, ho realizzato uno scrip bash in grado di verificare la presenza di eventuali aggiornamenti e di inviarmi successiva notifica via email.  Starà a me, in un secondo momento, decidere quando e se installare gli aggiornamenti proposti.

I tool necessari al suo funzionamento sono 2, ovvero yum-security e mutt. Procediamo dunque con la loro installazione mediante yum:

[root@linuxbox ~]# yum install yum-plugin-security mutt -y

bashEd ecco lo scrip:

#!/bin/bash

logfile=/var/log/checksecurity.log

data=`date +%d-%m-%Y`

destinatario=vostro.indirizzo@email.it

echo "$data: Checking for security updates..." >> $logfile

yum clean all

yum list-security >> /root/checksec/tmp

security=`cat /root/chcksec/tmp | grep security | grep -v Loaded`

bugfix=`cat /root/checksec/tmp | grep bugfix`

cve=`cat /root/checksec/tmp | grep cve`

if [ -n "$security" ];then
echo "$data: security updates available" > /root/checksec/out
fi

if [ -n "$bugfix" ];then
echo "$data: bugfix updates available" >> /root/checksec/out
fi

if [ -n "$cve" ];then
echo "$data: cve updates available" >> /root/checksec/out
fi

if [ -s /root/checksec/out ];then

cat /root/checksec/tmp >> /root/checksec/out

cat /root/checksec/out >> $logfile

cat /root/checksec/out | mutt -s "GESTORE01: security, bugfix and cve system report" $destinatario

rm /root/checksec/out

else

echo "$data: Nothing to do, exiting..." | tee -a $logfile

fi

rm /root/checksec/tmp

exit 0;

Ci rimane solo rendere lo scrip eseguibile (chmod +x /root/checksec/checksecurity.sh) ed aggiungerlo a crontab.

Alla prossima.