Scenario

Due server Web in produzione, SO *nix e framework Drupal.

Problema

Una tonnellata di email dirette agli indirizzi di posta elettronica più disparati.

Premessa

Riassumendo, è proprio questo il problema che si è verificato nei giorni scorsi su alcuni server che gestisco. Ora, affinchè lo spam bot possa funzionare è indispensabile che sulla macchina sia installato ed in esecuzione un MTA, magari senza autenticazione. Si, lo so, non prevedere alcun meccanismo di autenticazione per le email in uscita è altamente sconsigliato, ma dipende strettamente da quello che ci devi fare. Mi spiego: su quelle macchine le uniche email che devono essere inviate sono quelle generate da alcuni strumenti di monitoring, quali logwatch, rkhunter e compagnia bella. Ergo, in realtà, l’MTA non fa altro che appoggiarsi ad uno smarthost per l’inoltro della posta elettronica, fornito dall’hosting provider (ed il cui unico filtro è rappresentato dall’indirizzo IP sorgente). In soldoni, se la richiesta proviene da un IP appartenente al pool della LAN relativa all’hosting provider, la mail viene inviata, altrimenti nisba.

Detto ciò, è bene precisare che l’MTA attivo su quelle macchine è exim e non Postfix (per una semplice ragione di dimestichezza, ovvero conosco meglio il primo rispetto al secondo).

Soluzione

La prima cosa che ho notato listando il contenuto delle directory su cui sono ospitati i siti Web è stata la presenza di file tipici di WordPress, ad esempio wp-config.php. Si, esatto, questo spam bot è stato pensato per ambienti WP, come abbia fatto ad intrufolarsi in un framework Drupal devo ancora scoprirlo. Quello che so, però, è che si comporta sempre allo stesso modo: infetta il server, prende possesso dell’MTA ed invia email a più non posso.

Dunque, come potete facilmente immaginare, per arginare il problema ho impostato determinate ACL su exim, definendole in base all’indirizzo email di destinazione. Infatti, poichè le email di monitoring sono destinate esclusivamente a me ed al webmaster, è bastato inserire la seguente direttiva nel file di configurazione dell’MTA in questione:

accept  hosts = vostro.indirizzo1@email.it : vostro.indirizzo2@email.it

Per rendere effettive tali modifiche è stato necessario riavviare exim:

[root@bqweb2 ~]# service exim restart

Non conoscendo il baco che ha consentito al malware di infiltrarsi sui server, ho deciso anche di tirar su uno scrip bash che controllasse il contenuto delle dir target ed in caso di anomalie mi inviasse un’apposita email. In questo modo ho realizzato un sistema di sicurezza proattivo.

Ecco lo scrip:

#!/bin/bash

destinatario=vostro.indirizzo@email.it

cd /var/www/

grep -HR "wp-config.php" * > botcheck;

if [ -s botcheck ];then

cat botcheck | mail -iv -s "Server Bqweb2 Infected!" $destinatario;

fi

rm botcheck;

exit 0;

Esso non fa altro che andare alla ricerca del file wp-config.php. Se lo trova mi avvisa in modo tale da poter fare pulizia della directory.

Appena avrò maggiori info sul baco che ha consentito allo spam bot di infilarsi sulle mie macchine le pubblicherò.

Alla prossima.