Gli attacchi ad un dispositivo connesso ad internet si dividono in due categorie (10 per i nerd). Gli attacchi perpetrati da chi vuole le risorse del dispositivo e da chi vuole guardarci dentro.

I primi sono perpetrati da sistemi automatici che cercano nella massa, testando le vulnerabilità più diffuse in modo sistematico per sfruttare la vostra connessione, il vostro spazio di archiviazione o la vostra potenza di calcolo. I secondi sono messi in atto per motivi economici, politici o personali per capitalizzare dati sensibili o farvi fare una bella (?) figura.

Molto probabilmente l’unico tipo di attacco con cui vi troverete ad avere a che fare è il primo tipo. Fail2Ban è una risposta reattiva a questo tipo di attacchi. La strategia sottostante è di base questa: se un attacco è condotto da un bot proverà tutte le vulnerabilità più diffuse molto velocemente fino a trovarne una effettivamente esistente sul dispositivo target. Questo pattern è facilmente riconoscibile dall’analisi dei log, un bot difensivo (fail2ban) può riconoscere i primi tre/quattro attacchi che non vanno a buon fine per bannare l’ip sorgente prima che trovi la vulnerabilità che effettivamente c’è (reperibile al decimillesimo tentativo) per un tempo sufficientemente lungo a rendere inefficace l’attacco di forza bruta.

La configurazione di fail2ban va calibrata attentamente per trovare l’equilibrio tra gli errori che si possono generare dalla normale navigazione ed un efficace riconoscimento di questi bot.

Gli obbiettivi che ho scelto di monitorare sono, tra gli altri:

• Richieste di componenti attivi non offerti dal server. Se supporto solo PHP, e tu mi chiedi script asp, perl, cgi, python o altro … c’è qualcosa che non va.
• Richieste di proxy verso altri server. Non esiste, un webserver non è un proxy, se cerchi di sfruttare uno script o un modulo per fare qualcosa di non previsto … sei bannato.
• Autenticazioni http. Se sbagli la password piu di 3 o 4 volte … devi aspettare almeno 10 minuti per riprovare.
• Autenticazioni di webapp. Idem come sopra.
• Richieste di risorse non esistenti. Una url sbagliata capita, magari un link rotto o una pagina indicizzata tempo fà. La richiesta massiva di risorse non esistenti, magari cercando vulnerabilità nel sistema delle virtual directory è un indizio chiaro di attacco.

Alcuni link sono già finiti nel post settimanale automatico originato da delicious. Ci sono delle imperfezioni negli script quindi copiare va bene, ma cercando di capire cosa si copia ;).