Il blog sull'informatica

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.

Da un po' di tempo a questa parte mi capita di non ricevere le notifiche via mail da qualcuno dei miei server. Purtroppo ciò accade saltuariamente ed in modo pseudorandom, quindi per mettere bene a fuoco la problematica ho dovuto effettuare un'attenta analisi degli eventi.

Ma andiamo con ordine. Ieri, dopo aver aperto il mio client di posta elettronica, mi sono accorto che mancavano TUTTE le email di notifica del mio server casalingo (qualche giorno prima mi era successo la stessa cosa con il server di un amico commercialista). Accedo quindi alla shell via SSH e lancio il comando:

nightfly@nightbox:~$ cat /var/log/exim4/mainlog | grep mioindirizzoemail

Una delle entry riportava le seguenti informazioni:

** *@nightbox.it R=hub_user_smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<> SIZE=2430: host rm.virgilio.it [62.211.72.20]: 550 mail not accepted from blacklisted IP address [188.11.59.93]

Uhm, il mio IP pubblico, ovvero 188.11.59.93 è stato blacklistato dall'SMTP di virgilio... ma per quale motivo?

Mi collego dunque al sito www.senderbase.org e digito il mio indirizzo IP pubblico. Come risultato mi becco una bella schermata in cui c'è scritto che l'IP da me digitato è classificato come poor ed è stato inserito nella pbl di spamhaus.org. Bene, ma cosa diavolo è questa pbl? Cito testualmente:

The Spamhaus PBL is a DNSBL database of end-user IP address ranges which should not be delivering unauthenticated SMTP email to any Internet mail server except those provided for specifically by an ISP for that customer's use. The PBL helps networks enforce their Acceptable Use Policy for dynamic and non-MTA customer IP ranges.

Ok, quindi il problema è dovuto al fatto che ho inviato le email al mio MTA (out.virgilio.it) senza essermi prima autenticato. Inoltre, il controllo viene effettuato solo sugli IP pubblici che iniziano con 188.*, ovvero gli ultimi (in ordine di tempo) messi a disposizione per gli utenti di Aliceadsl.

Ne è la riprova il fatto che gli altri server che utilizzano un IP pubblico diverso da 188.* non vengono blacklistati, nonostante continuino a non usare l'autentica per connettersi all'SMTP di virgilio.

Per completezza, queste sono le blacklist su cui si basa l'SMTP citato in precedenza:

http://www.spamhaus.org
http://ipremoval.sms.symantec.com
http://cbl.abuseat.org
http://psbl.surriel.com

Ma come fare per risolvere il problema? Semplice, basta fare in modo che venga utilizzata l'autentica in fase di invio dei messaggi email (soluzione definitiva), oppure cambiare indirizzo IP pubblico, sperando che non ce ne venga assegnato nuovamente uno del blocco 188.* (soluzione temporanea).

A presto.

Aggiornamento

A quanto pare il controllo sull'autenticazione SMTP è stato esteso anche ad altri netblock, ad esempio il 79.*. Dunque vi consiglio di settare l'autentica per lo smarthost (se utilizzate exim4 come mail server locale, potete trovare informazioni utili in questo post).

La IOS C837-K9O3Y6-M sviluppata per il router Cisco 837 ha un bug, ovvero è possibile che dopo qualche reload si "dimentichi" di una o più PAT translations che riguardano porte più alte delle well-known (per intenderci, superiori alla 1023).

Nel mio caso, il problema ha iniziato a verificarsi da quando ho deciso di mettere in ascolto SSH su una porta non standard, in modo da risparmiarmi i tentativi di attacco lanciati dagli script kiddie di turno.

Inoltre, per motivi di sicurezza, ho consentito l'accesso via SSH al router solo dagli host della LAN, quindi, nel caso in cui dovessi accedere alla sua configurazione, atterro sul server e da lì mi collego al router.

Ovviamente, se la porta SSH non è forwardata non posso atterrare sul server, dunque l'unica soluzione praticabile consiste nell'andare fisicamente dal cliente e ricreare la regola per il PAT.

E qui viene il bello: poichè mi sono stancato di dover perdere almeno un'ora per andare dal cliente, riconfigurare il tutto e tornarmene a casa, ho deciso di creare il seguente script, il quale si collega al router tre volte al giorno e ricrea la regola per l'SSH.

Ecco lo script:

#!/usr/bin/expect

set password1 "<password1>"
set password2 "<password2>"

spawn ssh -l <username> <IP del router>
expect "*?assword:*"
send "$password1r"
expect ">"
send "enar"
expect "Password:"
send "$password2r"
expect "#"
send "conf tr"
expect "(config)#"
send "no ip nat inside source static tcp <ip> <porta> interface Dialer0 <porta>r"
expect "(config)#"
send "ip nat inside source static tcp <ip> <porta> interface Dialer0 <porta>r"
expect "(config)#"
send "exitr"
expect "#"
send "copy run startr"
expect "?"
send "r"
expect "#"
send "exitr"
expect eof

Come al solito, mancano i backslash prima della r perchè myblog li filtra.

Una volta che avete creato lo script, convertitelo in eseguibile lanciando il comando:

nightfly@nightbox:~$ sudo chmod +x ssh_autoforward

e salvatelo nella directory /usr/bin:

nightfly@nightbox:~$ sudo mv ssh_autoforward /usr/bin

A questo punto potete creare la regola per cron, in modo da schedulare l'esecuzione dello script alle 6, alle 12 ed alle 18:

nightfly@nightbox:~$ sudo nano /etc/crontab

00 06,12,18   * * *     root          ssh_autoforward

Riavviamo cron:

nightfly@nightbox:~$ sudo service cron restart

ed abbiamo finito.

A presto.

PS: non preoccupatevi se lo script entra in esecuzione mentre siete loggati sul server: la regola per il forward dell'SSH non verrà rimossa poichè la state già utilizzando, quindi niente perdita di connessione.