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
# 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
$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ù che sufficiente un decimo della potenza di calcolo e di banda di un PC maligno.

Audiocast.it