Il blog sull'informatica

Sempre più spesso mi capita di vedere rigettati dallo smarthost (leggere server SMTP) una miriade di messaggi generati dai sistemi di monitoring attivi sui miei server.

Per intenderci, lanciando un cat /var/log/exim4/mainlog, l'output seguente è costellato da info del tipo:

2011-12-26 23:20:01 1Rehhj-0000tY-BZ Message is frozen
2011-12-26 23:20:01 1Rex2z-0003El-5p Message is frozen
2011-12-26 23:20:01 1RfIpL-0000Pq-Dg Message is frozen
2011-12-26 23:20:01 1ReajD-0001FI-Nb Message is frozen
2011-12-26 23:20:01 1Rf4Wf-0000oG-AG Message is frozen
2011-12-26 23:20:01 1Rf8Ho-0003Ku-Pq Message is frozen
2011-12-26 23:20:01 1ReloA-0003d2-AH Message is frozen
2011-12-26 23:20:01 1ReaZS-00018P-KD Message is frozen

Ok, i messaggi caratterizzati da questi ID sono "bloccati" in coda. Cosa fare dunque? Bhè, se non sono di vitale importanza, possiamo semplicemente cestinarli grazie a questo semplice comando:

nightfly@nightbox:~$ sudo exiqgrep -z -i | xargs exim -Mrm

Potete anche impostare un job su cron per eliminarli giornalmente ed evitare la formazione delle suddette code.

A presto.

Di seguito riporto la configurazione del mio Swatch, in grado di tenere sotto controllo ciò che accade sul server Web (Apache) che attualmente ho in gestione:

ignore /nagios-plugins/

#HTTP Forbidden
watchfor  /403/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Access Forbidden

#HTTP Not Found
watchfor  /404/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Not Found

#HTTP Internal Server Error
watchfor  /500/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Internal Server Error

#HTTP OK
watchfor  /200/
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: Hit OK

Poichè sul server è presente anche nagios che ogni tanto effettua dei check sull'HTTPS, ho dovuto utilizzare la entry ignore /nagios-plugins/, evitando così di ricevere un'email ad ogni controllo.

Inoltre, sul server Web è presente l'autentica .htaccess, quindi ho messo sotto monitoraggio anche le hit andate a buon fine, in modo da poter verificare quale utente ha effettuato l'accesso alle aree riservate. Ciò è stato possibile anche grazie al fatto che sul server non vi è una grande mole di richieste. In caso contrario avrei certamente evitato una configurazione del genere, pena il rischio di beccarmi un ban sullo smarthost.

Infine, non ho ritenuto opportuno controllare gli errori HTTP 401 (Unauthorized), in quanto tale funzione è svolta egregiamente da fail2ban.

A presto.

Un sistemista degno di questo nome dedica diverse ore della sua attività lavorativa alla lettura dei log. Ovviamente, poichè tale operazione spesso viene svolta dopo un po' di tempo dalla generazione dei log stessi, è di fondamentale importanza utilizzare dei sistemi di logging proattivi, in grado cioè di "avvertire" l'amministratore del verificarsi di un qualche tipo di anomalia.

Di software del genere ne esistono a miolioni ma in questo post ho deciso di concentrarmi su swatch per via della sua facilità d'uso e della sua flessibilità.

Infatti, grazie a swatch sarà possibile monitorare i diversi file di log generati sui nostri server, alla ricerca delle entry di nostro interesse.

Per installarlo è sufficiente lanciare il comando:

nightfly@nightbox:~$ sudo apt-get install swatch

Ad installazione completata verrà creato un file di configurazione all'interno della nostra home dir, il cui nome sarà .swatchrc.

Personalmente credo che per ragioni di sicurezza swatch debba utlizzare un file di configurazione accessibile in lettura ma non in scrittura (ovvero che non possa essere modificato da utenti illegittimi), appartenente a root. Inoltre, consiglio di salvare il file in questione all'interno della directory /etc (per omogeneità).

Generiamo quindi il file di configurazione, il cui nome sarà swatch.conf:

nightfly@nightbox:~$ sudo nano /etc/swatch.conf

in cui inseriremo un'unica regola, poichè ci troviamo ancora in fase di test:

#HTTP Forbidden
watchfor  /401/
       echo
       mail addressess=vostro.indirizzo@email.it,subject=Failed Authentication

Grazie a questa entry, swatch ci avviserà via email ogniqualvolta si accorgerà che qualcuno ha provato a visualizzare una sezione riservata del sito Web presente sul nostro server (protetta mediante .htaccess).

Per fare in modo che swatch invii un'email immediatamente dopo aver individuato un determinato evento, occorre modificare il file /usr/share/perl5/Swatch/Actions.pm sostituendo:

if (! $args{'MAILER'} ) {
foreach my $mailer (qw(/usr/lib/sendmail /usr/sbin/sendmail)) {
$args{'MAILER'} = $mailer if ( -x $mailer );
}
if ($args{'MAILER'} ne '') {
$args{'MAILER'} .= ' -oi -t -odq';
}
}

con

if (! $args{'MAILER'} ) {
foreach my $mailer (qw(/usr/lib/sendmail /usr/sbin/sendmail)) {
$args{'MAILER'} = $mailer if ( -x $mailer );
}
if ($args{'MAILER'} ne '') {
$args{'MAILER'} .= ' -oi -t -odb';
}
}

Nel caso in cui decideste di non effettuare la modifica indicata in precedenza, swatch invierà le email dopo un lasso di tempo prefissato.

In alternativa, potete utilizzare i comandi bash per inviare gli alert alla vostra casella email. Per fare ciò, dovete creare una configurazione del tipo:

watchfor  /401/
exec echo 'SWATCH HOME: HTTP access forbidden: $_' | mail -iv -s "SWATCH HOME: Failed HTTP Authentication" vostro.indirizzo@email.it

Lanciamo quindi swatch con l'opzione -t (tail), ovvero in monitoraggio costante del file di log che andremo a specificare. Dovremo inoltre indicare qual è il file di configurazione a cui tale software dovrà riferirsi:

nightfly@nightbox:~$ swatch -c /etc/swatch.conf -t /var/log/apache2/ssl_access.log &

La & finale consente di lanciare il processo in background. Esiste anche l'opzione --daemon ma a quanto pare non accetta flag aggiuntive, quali -c o -t e monitorizza soltanto il file /var/log/messages.

Purtroppo swatch non consente di monitorare più file con un'unica istanza, quindi per fare ciò è necessario lanciare più istanze di tale programma, possibilmente utilizzando file di configurazione diversi a seconda del log che si intende tenere sotto osservazione.

Infine, è possibile mandare in esecuzione tale applicativo ad ogni avvio del nostro sistema operativo, semplicemente inserendo la seguente direttiva:

swatch -c /etc/swatch.conf -t /var/log/apache2/ssl_access.log

all'interno del file /etc/rc.local.

Fine del post, a presto.

Ha inizio una nuova avventura :)

Un grazie va a tutti coloro che hanno creduto in me e nelle mie capacità. Un grazie altrettanto grande e motivato va a tutti quelli che, invece, hanno dubitato delle mie potenzialità: è per merito vostro che ad ogni caduta ho imparato a rialzarmi.

Dopo le versioni 0.1 e 0.2 di autovodafone, ecco la versione 0.3 ulteriormente ottimizzata rispetto alle precedenti:

#!/bin/bash

#File di log
FILELOG=/var/log/autovodafone

data=$(date)

echo "Inserisci il destinatario:"

read destinatario

if [[ ! $destinatario =~ "+39" ]]; then

destinatario="+39$destinatario"

fi

echo "Inserisci l'oggetto del messaggio:"

read oggetto

echo "Inserisci il testo del messaggio:"

read testo

echo "$testo" > text

cat text | sed -f urlencoding.sed > encoded

enc=$(cat encoded)

curl -c cookiev.txt -F "username=vostrousername" -F "password=vostrapassword" https://www.vodafone.it/190/trilogy/jsp/login.do 2&>1
curl -b cookiev.txt --data "recipient=$destinatario&subjecttosend=$oggetto&SmilName=&TextName=$enc&ImageName=&AudioName=&nextPage=/web/servletresult.html" http://mmsviaweb.net.vodafoneomnitel.it/WebComposer/web/elaborapop.jsp | grep -o -E '"s*(.*)>(.*)"' > out

sed -n -e s/"//g -e "s/ /+/g" -e "2p" out > out1

url="http://mmsviaweb.net.vodafoneomnitel.it"

url1=$(cat out1)

url2=$(echo "$url$url1")

curl -b cookiev.txt $url2 > result

if grep -q "SendMessage=1" result;then

echo "messaggio inviato"

echo "$data: messaggio inviato" >> $FILELOG

else

echo "il messaggio non e' stato inviato"

echo "$data: il messaggio non e' stato inviato" >> $FILELOG

fi

rm out*

rm cookiev.txt

rm text

rm encoded

rm result

exit 0

In particolare, mediante il comando:

sed -n -e s/"//g -e "s/ /+/g" -e "2p" out > out1

ho ridotto il numero di file temporanei, grazie all'utilizzo ottimizzato di sed (espressioni multiple).

Per poter eseguire lo script senza i privilegi di root, dovete prima identificare il proprietario dei seguenti file:

autovodafone

urlencoding.sed

/var/log/autovodafone

e nel caso in cui ce ne fosse bisogno, potete modificare il loro owner mediante il comando:

nightfly@nightbox:~$ sudo chwon vostrouser:vostrogruppo nomefile

A questo punto l'esecuzione dello script senza privilegi di root dovrebbe filare liscia.

Bye.

Aggiornamento

Il servizio Vodafone MMS gratis da Web non esiste più (ne è la riprova il timeout che ci becca ad ogni tentativo di contattare la URL http://mmsviaweb.net.vodafoneomnitel.it). Per maggiori informazioni potete consultare questo 3d.

Non finirò mai di ribadire quanto sia importante "registrare" tutto ciò che accade sul nostro router, in modo da avere il pieno controllo su di esso. Tra i log "di vitale importanza" rientrano sicuramente quelli relativi ai comandi lanciati da shell: tale mini-guida ha come scopo principale proprio quello di illustrare la procedura per abilitare e configurare i log citati in precedenza.

Per prima cosa entriamo in modalità enable e successivamente accediamo alla modalità di configurazione del nostro router:

router>ena
router#conf t

Adesso posizioniamoci nell'archivio, ovvero dove verranno salvati i log che ci interessano:

router(config)#archive

Abilitiamo quindi il logging vero e proprio:

router(config-archive)#log config
router(config-archive-log-cfg)#logging enable

e successivamente configuriamolo, imponendogli di spedire i log al nostro logserver, avendo cura però di nascondere le eventuali password che verranno digitate in futuro (hidekyes):

router(config-archive-log-cfg)#notify syslog
router(config-archive-log-cfg)#hidekeys
router(config-archive-log-cfg)#exit
router(config-archive)#exit

Impostiamo il livello dei log da inviare al logserver (in questo caso settandolo su informational):

router(config)#logging trap informational

ed infine salviamo la configurazione:

router(config)#exit
router#copy run start

Da ora in poi il nostro logserver terrà traccia dei comandi lanciati dalla shell del router.

Bye.

PS: se non sapete come abilitare l'invio dei log su un server apposito, potete utilizzare questo post come riferimento.

PPS: il logging level da impostare sul server per poter ricevere i log dei comandi è pari 5 (o superiore).

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.

In questo post ho riportato l'esempio di uno script che si occupa dell'aggiornamento relativo alle blacklist utilizzate da squidGuard. Tale script è stato ulteriormente migliorato, in modo da riportare informazioni più dettagliate all'interno dell'email che vi verrà inviata dopo l'update.

Ecco il codice:

#!/bin/bash

logfile=/var/log/squidguardupdate.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

wget http://squidguard.mesd.k12.or.us/blacklists.tgz

tar -xvf blacklists.tgz

cd blacklists/

cp -R * /var/lib/squidguard/db

cd /home/vostrousername/cartelladelloscript

squidGuard -d -C all &> result

chown proxy:proxy -R /var/lib/squidguard/db

squid -k reconfigure

sleep 5

ps aux | grep squidGuard >> result

if grep  -q "squidGuard" result ;then

echo "Update Riuscito" >> result

else

echo "Update Non Riuscito" >> result

fi

rm blacklists.tgz

cat result | mail -iv -s "HOME: Le blacklist di squidGuard sono state aggiornate correttamente" $destinatario;

rm result

exit 0

Nella fattispecie, ho fatto in modo che successivamente all'aggiornamento delle blacklist venisse controllato lo stato di esecuzione di squidGuard, semplicemente lanciando un ps aux | grep squidGuard.

L'output di questo comando verrà inserito all'interno dell'email e se squidGuard è effettivamente presente tra i processi in esecuzione, sarà aggiunta la dicitura Update Riuscito.

Fatene buon uso.

A presto.

Ieri, mentre facevo i soliti controlli di routine, ho dato un'occhiata al log dei comandi lanciati sulla shell del mio Cisco 837 ed ho avuto una sincope appena ho letto le seguenti info:

*Dec  8 00:00:21.523: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:access-list 199 permit icmp host 10.10.10.10 host 20.20.20.20
*Dec  8 00:00:21.835: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:crypto map NiStTeSt1 10 ipsec-manual
*Dec  8 00:00:22.119: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:match address 199

*Dec  8 00:00:22.315: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:set peer 20.20.20.20

*Dec  8 00:00:22.367: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:exit
*Dec  8 00:00:22.471: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:no access-list 199
*Dec  8 00:00:22.571: %PARSER-5-CFGLOG_LOGGEDCMD: User:console  logged command:no crypto map NiStTeSt1

WTF!??? Una VPN? Sono riusciti ad ottenere l'accesso (abusivo) al mio router?

Bhè, per fortuna non era niente di grave, in quanto questi comandi vengono lanciati automaticamente ad ogni riavvio del router per verificare il corretto funzionamento del suo crypto engine.

Falso allarme... e vissero tutti felici e contenti.

A presto.

Una rete che si possa definire "sicura" deve necessariamente utilizzare un IDS per identificare i tentativi di intrusione. Inoltre, è indispensabile che venga controllato il corretto funzionamento dell'IDS, in modo da evitare tempi morti durante i quali il network risulti "sguarnito". A tal proposito ho deciso di monitorare il mio IDS (per la precisione snort), attraverso l'uso di nagios (nella fattispecie la versione 3.0).

Ma andiamo con ordine. Per prima cosa scarichiamo l'add-on di nagios denominata check_snort (non è altro che un semplice script bash). Potete trovarlo a questo indirizzo.

Successivamente scompattiamo la tarball mediante il comando:

nightfly@nightbox:~$ tar -xf check_snort.tar

e copiamo il file check_snort dentro la directory /usr/lib/nagios/plugins:

nightfly@nightbox:~$ cp check_snort /usr/lib/nagios/plugins/

Creiamo quindi un servizio specifico che si occupi di controllare lo stato di snort:

nightfly@nightbox:~$ cd /etc/nagios-plugins/config
nightfly@nightbox:/etc/nagios-plugins/config$ sudo nano snort.cfg

inserendo all'interno del file appena creato il seguente contenuto:

# 'check_snort' command definition
define command{
        command_name    check_snort
        command_line    /usr/lib/nagios/plugins/check_snort

}

A questo punto possiamo aggiungere il seguente servizio alla configurazione dell'host su cui vogliamo attivarlo:

nightfly@nightbox:~$ cd /etc/nagios3/conf.d
nightfly@nightbox:/etc/nagios3/conf.d$ sudo nano localhost_nagios2.cfg

e digitiamo:

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       localhost
        service_description             Snort
                check_command                   check_snort
}

salviamo il tutto, riavviamo nagios:

nightfly@nightbox:/etc/nagios3/conf.d$ sudo service nagios3 restart

ed abbiamo finito.

Adesso anche snort è sotto il controllo di nagios.

A presto.