Avere su un server un sito che contiene uno script PHP vulnerabile e ritrovarsi migliaia di mail di spam nella coda può essere un incubo per il sistemista: non avendo altre informazioni ci si ritrova costretti a dover rovistare nei log alla ricerca di comportamenti ripetitivi o al limite ad osservare i picchi di traffico per cercare di rilevare almeno l’IP del potenziale aggressore: in questi due giorni mi sono ritrovato in una situazione del genere, in un server che ospitava decine di siti.
Questa mattina ho avuto l’illuminazione: perché non cercare un sistema che intercetti le chiamate a mail() e le logghi? E mi sono imbattuto subito in un sistema che prevede la creazione di un wrapper a sendmail. Già ero contento, ma invece di mettermi giù ad implementare la soluzione mi sono messo a leggere anche i commenti ed ho scoperto che grazie a PHP 5.3 la problematica era ulteriormente semplificata:
PHP 5.3 added two configuration directives to solve this problem.
mail.add_x_header – Adds an extra header to the e-mail showing which script made the call to mail()
mail.log – Sets up a log file for all mail() calls. Contains the originating script and To addressSee http://php.net/manual/en/mail.configuration.php for more info.
In pratica con un solo parametro da aggiungere a php.ini si possono monitorare tutte le chiamate alla funzione mail(), scoprendo da quale script PHP provengono! Per attivare questo sistema di log potete usare i seguenti comandi:
mkdir /var/log/php touch /var/log/php/mail.log chmod 777 /var/log/php/mail.log echo "mail.log = /var/log/php/mail.log" >> /etc/php.ini
Notare che:
- Si presume che non esista la directory /var/log/php
- Ho dato tutti i permessi possibili al log perché, se il processo PHP appartiene allo stesso proprietario dei file web, questo è il modo più veloce per garantire a tutti la scrittura sul log
- La modifica al file php.ini viene fatta alla fine del file, ma per un maggiore ordine andrebbe fatta nella sezione relativa a mail
- Il file potrebbe crescere a dismisura: magari, una volta che avete scoperto la fonte dello spam, eliminate questa opzione di logging oppure aggiungetelo al sistema di rotazione
- A seconda della vostra configurazione, potrebbe essere necessario un riavvio del server web
Grazie a questo sistema sono riuscito a scoprire che i soliti ignoti avevano caricato un loro form su un sito WordPress trascurato, pieno di vecchi temi e di vecchi timthumb.php: ricordatevi di aggiornare sempre WordPress, i plugin e di rimuovere i temi che non usate. Se il tema che avete in uso sfrutta timthumb.php spetta a voi verificare se è aggiornato.
ciao, l’articolo mi serve grazie mille ma solo una delucidazione:
1. Si presume che non esista la directory /var/log/php
questo significa che? devo creare la directory?
Risposta breve: sì, va creata.
Risposta lunga: Io ho scelto una mia personale convenzione, ma ognuno può decidere di loggare il file dove vuole, l’importante è ricordarselo e andare a ripulirlo di tanto in tanto (oppure metterlo in logrotate, ma finora sono stato troppo pigro per farlo).
Ciao scusami… ho esattamente il tuo stesso problema e sto impazzendo da giorni perché non riesco a capire da quale dominio parta lo spam.
Prima di provare con la tua soluzione volevo sapere che cosa fa esattamente il comando… echo “mail.log = /var/log/php/mail.log” >> /etc/php.ini (
Siccome dopo dici di eliminare questa opzione volevo sapere come fare 🙂 grazie per l’eventuale aiuto.
Ciao Davide, con
Si aggiunge semplicemente una riga di configurazione al php.ini
Tuttavia in alcuni casi potresti trovare il nome dello script nel sorgente della mail. Per analizzare la coda delle mail, potresti usare un tool come pfqueue per Postfix o qmHandle per qmail. Invece con exim basta fare exim -bp.
Se non riesci a risolvere, chiedimi pure un preventivo senza impegno.