Audiocast.it ha subito un attacco DOS (Denial Of Service)

Il giorno di sabato 16 settembre 2007 questo sito ha subito un attacco DOS (Denial Of Service), probabilmente involontario, ed è stato irraggiungibile per quasi tutta la giornata.

Io sono stato fuori tutto il giorno e me ne sono accorto solo a tarda sera, ho indagato ed ho scoperto che c’era un “bot” (uno di quei programmi che scaricano le pagine per indicizzarle su un motore di ricerca) che si comportava in modo anomalo:

• scaricava diverse pagine al secondo (i bot normali come GoogleBot scaricano lentamente per non creare problemi ai siti che indicizzano)
• apriva parecchie connessioni contemporanee
• audiocast.it gira su una macchina virtuale linux con una minima quantità di RAM, per cui il web server apache è configurato per gestire lo scaricamento di poche pagine in contemporanea (ogni nuova connessione per una nuova pagina crea un nuovo processo che occupa una certa quantità di memoria)
• quello che capitava è che il web server non riusciva a servire altri clienti mentre il bot lo teneva occupato
• il bot si identificava con la stringa “VadixBot”, una breve ricerca su internet confermava che aveva creato problemi a molti altri siti
• il bot non apparteneva a nessuna società nota, i suoi indirizzi IP di provenienza appartengono al network 67.78.34.0/24 che è di un provider di connettività americano

(Quella che segue è una spiegazione piuttosto tecnica che sembrerà oscura a chi tecnico non è).
Avendo individuato la causa del problema ho pensato di bloccare l’accesso a qualunque pagina del sito da parte di questo bot, probabilmente scritto male dall’autore. Per fare questo ho inserito le seguenti righe nel file di configurazione di Apache:

  # block bad robots
  RewriteCond %{HTTP_USER_AGENT} VadixBot
  RewriteRule .* - [F,L]

Adesso il bot riceveva sempre un errore 403 (Accesso Negato) indipendentemente dalla pagina richiesta.

Il problema però non è stato risolto perchè quello che succedeva era che il bot continuava a chiedere molte pagine in contemporanea, riceveva questo messaggio di errore ma non chiudeva la connessione TCP/IP. Ho notato infatti che c’erano moltissime connessioni da vari indirizzi del bot che si trovavano nello stato FIN_WAIT2, ossia:

• il bot richiedeva più pagine in contemporanea utilizzando più connessioni TCP
• il server web apache creava un nuovo processo per ciascuna di queste connessioni e ciascun processo rispondeva rapidamente con un errore 403 (accesso negato)
• il bot, però, non chiudeva la connessione che rimaneva nello stato FIN_WAIT2
• il processo creato da apache non terminava, perchè aspettava la chiusura della connessione oppure il suo timeout (piuttosto lungo)
• poichè il massimo numero di processi possibili era occupato in questo modo, tutte le altre richieste dei veri utenti venivano messe in coda e mai servite

Per risolvere il problema sono stato costretto ad installare il software di firewall, con iptables, e mettere una regola apposita per bloccare il network di provenienza del bot. Nella catena di INPUT ho inserito la seguente regola:

$IPT -A tcp_inbound -p TCP -s 67.78.34.0/24 \ 
       --destination-port 80 -j RETURN

Ho riavviato il server per troncare le connessioni in corso e per verificare che iptables partisse correttamente al riavvio, ho verificato che adesso il bot veniva bloccato ed ho infine verificato che il web server rispondeva correttamente ed in tempi ragionevoli.

La morale di questa storia è che occorre sempre monitorare quello che avviene sul proprio server su Internet ed essere sempre pronti ad intervenire, considerando che non sono solo i siti più noti ad essere sottoposti ad attacchi DOS. D’altra parte se per buttare giù un grosso servizio come Yahoo o Google ci vuole un enorme DOS distribuito e coordinato, per buttare giù un serverino virtuale, misero di risorse, è pi&ugrave che sufficiente un decimo della potenza di calcolo e di banda di un PC maligno.