Archivi tag: swatch

CentOS 6: monitorare le regole di auditing in modo proattivo mediante Nagios, NRDP e swatch

In questo post ed in quest’altro ho illustrato, rispettivamente, come configurare Nagios, NRDP e swatch per la ricezione dei check passivi e dei security alert.

Adesso vedremo come fare a monitorare in modo proattivo le regole di auditing definite in precedenza mediante il tool auditd (vedi qui per ulteriori dettagli).

Nagios_logo_blackIn soldoni, la configurazione si avvale di due passaggi:

1) creazione di un file da dare in pasto a swatch, nel quale sono definite le espressioni regolari in grado di identificare in modo univoco ciascun evento di auditing;

2) definizione dei servizi di Nagios per la ricezione dei check passivi.

Ecco uno stralcio della configurazione di swatch:

#time_changes auditing rule
watchfor /time_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='time_changes auditing rule' --output\='$_ | time_changes\=1'"
#system_locale_changes auditing rule
watchfor /system_locale_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='system_locale_changes auditing rule' --output\='$_ | system_locale_changes\=1'"
#shadow_changes auditing rule
watchfor /shadow_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='shadow-file auditing rule' --output\='$_ | shadow_changes\=1'"
#passwd_changes auditing rule
watchfor /passwd_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='passwd_changes auditing rules' --output\='$_ | passwd_changes\=1'"
#group_changes auditing rule
watchfor /group_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='group_changes auditing rule' --output\='$_ | group_changes\=1'"
#sudoers_changes auditing rule
watchfor /sudoers_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='sudoers_changes auditing rule' --output\='$_ | sudoers_changes\=1'"
#selinux_changes auditing rule
watchfor /selinux_changes/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='selinux_changes auditing rule' --output\='$_ | selinux_changes\=1'"
#module_insertion auditing rule
watchfor /module_insertion/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='module_insertion auditing rule' --output\='$_ | module_insertion\=1'"
#webserver_watch_tmp auditing rule
watchfor /webserver_watch_tmp/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='webserver_watch_tmp auditing rules' --output\='$_ | webserver_watch_tmp\=1'"
#sshd_config auditing rule
watchfor /sshd_config/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='sshd_config auditing rules' --output\='$_ | sshd_config\=1'"
#httpd_config auditing rule
watchfor /httpd_config/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='httpd_config auditing rules' --output\='$_ | httpd_config\=1'"
#ntp_config auditing rule
watchfor /ntp_config/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='ntp_config auditing rules' --output\='$_ | ntp_config\=1'"
#iptables_config auditing rule
watchfor /iptables_config/
     echo
     exec "/usr/bin/php /usr/lib64/nagios/plugins/send_nrdp.php --url\=http://192.168.1.1/nrdp --token\=s3cr3t --host\=localhost --state\=1 --service\='iptables_config auditing rules' --output\='$_ | iptables_config\=1'"

Il comando da lanciare per rendere operativo il suddetto applicativo (che magari potremo inserire anche all’interno del file /etc/rc.local per l’avvio automatico dopo ogni riavvio della macchina) è il seguente:

swatch -c /etc/swatchaudit.conf -t /var/log/audit/audit.log --daemon

Di seguito, invece, riporto la configurazione dell’host di Nagios (localhost) per il quale occorre monitorare gli eventi di auditing:

define service{
        use                             local-service
        host_name                       localhost
        service_description             time_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             system_locale_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             shadow_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             group_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             sudoers_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             selinux_changes auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             module_insertion auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             webserver_watch_tmp auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             sshd_config auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             httpd_config auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             ntp_config auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       localhost
        service_description             iptables_config auditing rule
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             6
        flap_detection_enabled          0
        }

Come al solito, lanciamo un reload di Nagios per rendere operative le suddette modifiche:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

CentOS 6: configurare Nagios per la ricezione dei security alert

In questo post abbiamo visto come configurare e gestire i check passivi su Nagios. Ora vedremo come utilizzare tale configurazione per ricevere i security alert relativi agli host monitorati.

nagiosIngredienti

Ovviamente il primo ingrediente è l‘NMS (Nagios), integrato ad NRDP Server. Sulle macchine monitorate è installato NRDP Client, il quale dovrà interagire con un log analyzer in tempo reale (swatch).

Scenario

La topologia utilizzata nell’ambito di questa guida è abbastanza minimale e prevede un server su cui è installato Nagios ed un altro server (da monitorare) che funge da antispam. Si vuole fare in modo che i security alert generati da quest’ultimo vengano inoltrati all’NMS, il quale dovrà successivamente aggiornare lo stato dei check passivi di riferimento, inviando opportune notifiche ai sysadmin.

Configurazione di Nagios

La configurazione dell’NMS è del tutto simile a quella vista qui, ma la riporto per completezza:

define service{
        use                             local-service
        host_name                       server-antispam
        service_description             Antispam Access Denied
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       server-antispam
        service_description             Antispam Domain Not Found
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       server-antispam
        service_description             Antispam Cannot Find Your Reverse Hostname
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       server-antispam
        service_description             Antispam SPF Reject
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       server-antispam
        service_description             Antispam Relay Access Denied
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       server-antispam
        service_description             Antispam Amavis Blocked
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       server-antispam
        service_description             Antispam Spam
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

define service{
        use                             local-service
        host_name                       server-antispam
        service_description             Antispam Spammy
        check_command                   check_passive
        passive_checks_enabled          1
        active_checks_enabled           0
        max_check_attempts              1
        is_volatile                     1
        check_freshness                 1
        freshness_threshold             600
        flap_detection_enabled          0
        }

Il comando check_passive, invece, è così definito:

# 'check_passive' command definition
define command{
        command_name check_passive
        command_line $USER1$/check_dummy 0 "No Security Alert"
}

La logica di funzionamento è banale: se un security alert non viene ricevuto entro 600 secondi significa che non vi sono eventi rilevanti e, di conseguenza, lo stato del check passivo tornerà ad essere OK. Inoltre, poichè l’alert deve generare immediatamente una notifica (HARD STATE), è necessario settare il campo max_check_attempts a 1 (anzichè 4 che è il valore di default).

Come ultimo step ricarichiamo la configurazione di Nagios:

[root@NMS ~]# service nagios reload

Configurazione del server antispam

Una volta configurato l’NMS possiamo dedicarci alla configurazione del server da monitorare. In questo caso il lavoro sporco verrà svolto da swatch, il cui compito è quello di analizzare in tempo reale (tail -f) il contenuto del file di log relativo al servizio di antispam (/var/log/maillog), alla ricerca di determinati error code. Ad ogni error code corrisponderà un security alert specifico, e, una volta identificato, verrà richiamato NRDP Client per l’invio dell’evento a Nagios.

Ma bando alle ciance ed ecco la configurazione di swatch:

#SMTP Domain not found
watchfor  /Domain not found/
     echo
     exec "/usr/bin/php /usr/lib/nagios/plugins/send_nrdp.php --url\=http://IPNMS/nrdp --token\=vostrotoken --host\=server-antispam --state\=1 --service\='Antispam Domain Not Found' --output\='$_'"

#SMTP Sender address rejected
watchfor  /Access denied/
     echo
     exec "/usr/bin/php /usr/lib/nagios/plugins/send_nrdp.php --url\=http://IPNMS/nrdp --token\=vostrotoken --host\=server-antispam --state\=1 --service\='Antispam Access Denied' --output\='$_'"

#SMTP Cannot find your reverse hostname
watchfor  /cannot find your reverse hostname/
     echo
     exec "/usr/bin/php /usr/lib/nagios/plugins/send_nrdp.php --url\=http://IPNMS/nrdp --token\=vostrotoken --host\=server-antispam --state\=1 --service\='Antispam Cannot Find Your Reverse Hostname' --output\='$_'"

#SMTP SPF reject
watchfor  /openspf/
     echo
     exec "/usr/bin/php /usr/lib/nagios/plugins/send_nrdp.php --url\=http://IPNMS/nrdp --token\=vostrotoken --host\=server-antispam --state\=1 --service\='Antispam SPF Reject' --output\='$_'"

#SMTP Relay access denied/
watchfor /Relay access denied/
     echo
     exec "/usr/bin/php /usr/lib/nagios/plugins/send_nrdp.php --url\=http://IPNMS/nrdp --token\=vostrotoken --host\=server-antispam --state\=1 --service\='Antispam Relay Access Denied' --output\='$_'"

#SMTP Amavis blocked
watchfor /Blocked/
     echo
     exec "/usr/bin/php /usr/lib/nagios/plugins/send_nrdp.php --url\=http://IPNMS/nrdp --token\=vostrotoken --host\=server-antispam --state\=1 --service\='Antispam Amavis Blocked' --output\='$_'"

#SMTP Spam
watchfor /SPAM/
     echo
     exec "/usr/bin/php /usr/lib/nagios/plugins/send_nrdp.php --url\=http://IPNMS/nrdp --token\=vostrotoken --host\=server-antispam --state\=1 --service\='Antispam Spam' --output\='$_'"

watchfor /SPAMMY/
     echo
     exec "/usr/bin/php /usr/lib/nagios/plugins/send_nrdp.php --url\=http://IPNMS/nrdp --token\=vostrotoken --host\=server-antispam --state\=1 --service\='Antispam Spammy' --output\='$_'"

Nella fattispecie, NRDP Client viene richiamato mediante la direttiva exec, facendo attenzione al carattere = (utilizzato per specificare i dati da inviare a Nagios), poichè trattasi di un carattere speciale per swatch (che quindi dovrà essere munito di escape \).

A questo punto lanciamo il comando:

[root@server-antispam ~]# swatch -c /etc/swatch.conf -t /var/log/maillog --daemon

ed inseriamolo all’interno del file /etc/rc.local (per automatizzare l’esecuzione del suddetto applicativo dopo ogni riavvio).

Test

Per testare il corretto funzionamento della configurazione appena riportata, possiamo, ad esempio, generare un error code 450 (cannot find your reverse hostname).
Lanciamo dunque il comando:

[root@client ~]# telnet server-antispam.vostrodominio.com 25

ed inviamo al server antispam le seguenti direttive:

helo server-antispam.vostrodominio.com
250 server-antispam
mail from:<n.latella@ciao.it>
250 2.1.0 Ok
rcpt to:<n.latella@ciao.ot>
450 4.7.1 Client host rejected: cannot find your reverse hostname, [5.170.*.*]

A questo punto il servizio Antispam Cannot Find Your Reverse Hostname dovrebbe generare un WARNING, segnalando quanto avvenuto mediante email.

Nei prossimi post vedremo come configurare Nagios per la ricezione delle trap SNMP.

Alla prossima.

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.

Swatch e Asterisk: monitorare la chiamate in ingresso ed in uscita

In questo post ho discusso della configurazione di Asterisk per il sip provider cheapvoip (cheapnet.it). Ora vedremo come monitorare le chiamate in ingresso ed in uscita dal nostro PBX utilizzando un apposito tool, ovvero swatch.

asteriskPer prima cosa è necessario creare il file di configurazione di swatch (che chiameremo swatchvoip.conf) all’interno della directory /etc:

[root@PBX ~]# nano /etc/swatchvoip.conf

il contenuto del suddetto file dovrà essere il seguente:

#Inbound call
watchfor  /cheapvoip-inbound/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH HOME: Inbound call received

#Outbound call
watchfor  /cheapvoip-outbound/
     echo
     mail addresses=vostro.indirizzo\@email.it,subject=SWATCH HOME: Outbound call performed

Mediante la direttiva watchfor indichiamo la stringa da monitorare (che identifica univocamente le chiamate in ingresso e quelle in uscita, nella fattispecie cheapvoip-inbound e cheapvoip-outbound).

Con echo imponiamo a swatch di reindirizzare l’output su terminale (tty) e mediante mail facciamo in modo che le chiamate vegano notificate al nostro indirizzo di posta elettronica.

Infine editiamo il file /etc/rc.local, in modo da eseguire automaticamente swatch dopo un eventuale riavvio della macchina:

swatch -c /etc/swatchvoip.conf -t /var/log/asterisk/cdr-csv/Master.csv &

A questo punto non ci resta che lanciare il comando:

swatch -c /etc/swatchvoip.conf -t /var/log/asterisk/cdr-csv/Master.csv &

da console ed abbiamo finito.

A presto.

Swatch ed HTTP 404 (not found)

Premessa

Swatch monitora attivamente tutte le richieste dirette ai miei server Web, quindi qualunque tentativo di accesso ad una particolare pagina viene loggato.

Problema

Ultimamente le richieste verso una particolare URL sono aumentate a dismisura. Ecco uno stralcio degli alert generati dal suddetto tool:

201.157.16.123 - - [06/Aug/2012:01:28:55 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

201.22.125.163 - - [06/Aug/2012:00:03:58 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

77.54.223.3 - - [05/Aug/2012:22:13:00 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

95.229.250.152 - - [05/Aug/2012:20:59:13 +0200] "GET /vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../..//etc/amportal.conf%00 HTTP/1.1" 404 2089 "-" "-"

 

elastix, amportal.conf, directory traversal, input sanitiziation, php vulnerability, querystring, swatch, http 404

Trattasi palesemente di un attacco directory traversal, data la sintassi ../../../../../../../../ utilizzata nella URL, che consente all’attaccante di accedere alla directory /etc ed in particolare al file di configurazione amportal.conf

Tale attacco può essere attuato grazie ad una vulnerabilità specifica che affligge la distro Elastix, in particolare il CRM Vtiger. La vulnerabilità consiste nell’uso errato delle procedure di input sanitization, che consente l’uso dei caratteri . e / all’interno della querystring (espressi in URL encoding), in modo da eseguire la “scalata” delle directory fino ad arrivare al file di configurazione target.

Soluzione

Aggiornare il pacchetto elastix-vtigercrm alla versione 5.2.1-5.

Alla prossima.

Swatch, Apache e base rate fallacy a palla

In questo post vi ho mostrato una possibile configurazione di swatch per ciò che concerne il monitoraggio delle richieste inoltrate ad un server Web. 

apache, swatch, regex, pattern, log, HTTP error code

Ovviamente tale configurazione è molto simile a quella che attualmente gira sui miei server, ragion per cui ho avuto modo di testarla in modo massiccio. Un effetto colletarale che mi è saltato all’occhio quasi immediatamente riguardava i falsi positivi, ovvero pattern del tutto innocui che swatch mi segnalava come errori HTTP.

Mi spiego meglio. Data una entry del file di log simile alla seguente:

192.168.x.x - jumbo [30/Jul/2012:16:03:20 +0200] "GET /prova.php HTTP/1.1" 200 4036 "https://www.pincopallo.it/prova.php" "Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1"

essa mi veniva segnalata come HTTP Forbidden (errore 403) per via del 4036.

Il file di log contenente il giusto codice di errore dovrebbe avere una forma simile alla seguente:

79.55.x.x - jumbo [30/Jul/2012:21:28:53 +0200] "GET /prova.php HTTP/1.1" 403 773 "-" "Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0"

Ovvero il codice di errore è sempre preceduto e seguito da uno spazio vuoto.

Alla luce di tali considerazioni le regex da settare su swatch diventano le seguenti:

#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

Quindi, poichè i pattern da matchare devono essere contenuti all’interno dei due slash (/), è bastato aggiungere uno spazio prima e dopo del codice di errore.

Enjoy.

Apache, swatch e favicon inesistente

Premessa: i browser di ultima generazione che tantano di connettersi ad un sito (non presente nella loro cache) vanno automaticamente alla ricerca della famigerata favicon (ovvero quell’iconcina che appare a fianco della barra degli indirizzi – benedetto Web 2.0).

swatch, log, apache, favicon, http 404, not found, log monitoring

Fatto: se il sito non contiene la suddetta iconcina, il Web server (Apache nella fattispecie), genererà un bell’errore HTTP 404 (not found).

Problema: se il file di log del Web server è monitorato mediante un’apposita applicazione (leggasi swatch), che intercetta gli errori HTTP 404, il povero sistemista che legge gli alert (leggasi il sottoscritto), si ritroverà con un kg di mail praticamente inutili.

Soluzione: fare in modo che swatch ignori completamente le entry del file di log di Apache che contencono la keyword favicon.

In particolare, tali entry avranno la seguente forma:

79.5.*.* - - [29/May/2012:13:57:45 +0200] "GET /favicon.ico HTTP/1.1" 404 628 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20100101 Firefox/10.0.4"

indi per cui, nel file di configurazione di swatch basterà aggiungere la seguente direttiva (in testa):

#Favicon
ignore /favicon/

Niente di più facile.

Per rendere la modifica operativa occorre killare tutti i processi attivi di swatch (sudo killall -w swatch) e successivamente avviare nuovamente tale applicativo.

Alla prossima.

Script kiddie ed errore HTTP 404: tiriamo le somme

Non è certamente un caso che abbia configurato swatch in modo da tenere d’occhio anche gli errori HTTP 404 (Not Found). In questo modo ho potuto “registrare” in un file apposito tutti i tentativi di cracking perpetrati contro i miei server Web, individuando quali sono le URL cercate dai lamer di turno.

Ecco le 2 entry più significative:

 211.191.168.214 - - [26/Dec/2011:21:01:57 +0100] "GET /admin/Y-ivrrecording.php?php=info&ip=uname HTTP/1.1" 404 2050 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0"

173.243.121.58 - - [06/Jan/2012:19:54:16 +0100] "GET /admin/config.php HTTP/1.1" 404 2041 "-" "Python-urllib/2.4"

Nel primo caso hanno verificato la presenza di FreePBX sulla mia macchina (ovviamente con interfaccia di management in forwarding e dunque accessibile dall’esterno).

Nel secondo caso, invece, hanno controllato se sul mio server fosse presente l’interfaccia di gestione relativa a trixbox. Ho optato per trixbox (anzichè PHPMyAdmin), in quanto, dopo aver lanciano un nmap avente come target l’IP sorgente loggato, la porta TCP 443 (HTTPS) risultava in ascolto e proprio grazie ad essa era raggiungibile l’interfaccia Web di trixbox. Si trattava quindi di una testa di ponte.

Inoltre, dallo User Agent (Python-urllib/2.4) si può avere la certezza che si tratta di uno scrip (editato in Python), il cui compito è quello di scansionare range di IP alla ricerca di macchine vulnerabili.

Tra qualche mese vedrò di stilare un nuovo report.

A presto.

Swatch: configurazione per il monitoraggio dei server FTP (vsftpd)

Ecco la configurazione di swatch che sto utilizzando sui miei server per tenere d’occhio il demone vsftpd:

ignore /127.0.0.1/

#FTP File Status OK
watchfor  /150 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP File Status OK

#FTP Command Not Implemented
watchfor  /202 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Not Implemented

#FTP User Logged Out
watchfor  /221 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP User Logged Out

#FTP Directory Send OK
watchfor  /226 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Directory Send OK

#FTP User Logged In
watchfor  /230 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP User Logged In

#FTP Requested File Action Ok
watchfor  /250 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Requested File Action Ok

#FTP Service Not Avaliable
watchfor  /421 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Service Not Available

#FTP Can't Open Data Connection
watchfor  /425 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Can't Open Data Connection

#FTP Transfer Aborted
watchfor  /426 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Transfer Aborted

#FTP File Unvailable
watchfor  /450 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP File Unvailable

#FTP Command Unrecognized
watchfor  /500 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Unrecognized

#FTP Syntax Error
watchfor  /501 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Syntax Error

#FTP Command Not Implemented
watchfor  /502 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Not Implemented

#FTP Bad Sequence Of Commands
watchfor  /503 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Bad Sequence Of Commands

#FTP Login Incorrect
watchfor  /530 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Login Incorrect

#FTP Illegal File Name
watchfor  /553 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Illegal File Name

 

ftp,vsftpd,simple watchdog,status code,logging,swatch,rc.local

Come potete notare, le espressioni regolari verificano che all’interno del file /var/log/vsftpd.log siano presenti gli status code tipici del protocollo FTP.

Occorre precisare, però, che per default vsftpd non prevede il logging degli status code. Per abilitare tale funzione occorre modificare il file /etc/vsftpd.conf nel modo seguente:

xferlog_enable=YES

log_ftp_protocol=YES

xferlog_std_format=NO

A modifica completata riavviamo il demone in questione:

nightfly@nightbox:~$ sudo service vsftpd restart

ed infine inseriamo una entry nel file /etc/rc.local in modo da rendere automatica l’esecuzione di swatch per il monitoraggio di vsftpd ad ogni avvio del sistema:

swatch -c /etc/swatchftp.conf -t /var/log/vsftpd.log

Ora anche vsftpd può definirsi “sotto controllo”.

Alla prossima.

PS: per una lista (semi)completa degli status code relativi al protocollo FTP, potete consultare questo link.