Fail2Ban
Se avete un sistema Linux in produzione, spero vivamente che questo sia protetto da firewall (ho visto decine di server di produzione esposti su internet senza alcun tipo di firewall installato). Non disdegno (anzie, l’uso è necessario e fondamentale) quello integrato di Linux (iptables), ma quando si parla di Firewall opto per una soluzione commerciale; tuttavia occorre anche dire che esistono soluzioni commerciali che spacciano per firewall qualcosa che in realtà è anche un firewall. Ricordatevi che un firewall deve fare una cosa sola: proteggervi da attacchi esterni, preferibilmente con annesso un sistema di intrusion prevention/detection. Inoltre la vostra rete deve essere pensata per isolare server/servizi che possano essere attaccati dall’esterno, in maniera tale che un eventuale “cedimento” di uno dei vostri server non porti l’attaccante ad essere direttamente in contatto con la vostra rete di lavoro (un server di posta NON dovrà MAI essere messo all’interno di una lan, ma in una rete separata detta rete dmz o demilitarized zone).
Pertanto: isolate, proteggete e tenete sempre aggiornato il vostro sistema con le ultime patch rilasciate: so che è inutile ricordarlo, ma è così.
Partendo dal presupporto di avere un sistema di mail (smtp/smtps, imap/imaps, webmail) da cui occorre fare accesso dalla rete esterna, il vostro firewall dovrà necessariamente fare passare le porte 25/587, 143/993, 80/443. Possiamo già fare una “scrematura” delle porte aperte imponendo che solo i servizi sicuri possono essere acceduti dall’esterno (25/587, 993 e 443) mentre tutte le altre porte possono essere attivate anche sulla rete interna. Purtroppo non possiamo bloccare la porta 25 in quanto è la porta con cui il vostro server riceve le mail da internet. Il vostro firewall si occuperà di bloccare le porte non aperte, ma se il servizio che offrite è basato su un servizio “bacato”, un eventuale attaccante potrà sfruttare questa falla per prendere possesso del vostro server, magari con diritti amministrativi.
Quello che possiamo fare ulteriormente è analizzare in real-time i file di log generati dai servizi suddetti, in maniera tale da bloccare immediatamente eventuali tentativi di intromissione, scan provenienti dall’esterno. Per far ciò utilizzeremo un prodotto free sotto licenza GNU GPL 2.
Fail2Ban
Questo programa effettua la scansione dei file di log del nostro server e blocca gli indirizzi IP che manifestano segni maligni, quali troppi tentativi di ricerca di password, ricerche di exploit di servizi, ….. In parole povere è un log analyzer o un log parser.
Generalmente viene utilizzato per aggiornare le regole del firewall e per bloccare gli indirizzi ip da cui proviene l’attacco per un determinato periodo di tempo, magari avvertendo l’amministratore tramite email.
Chiaramente è solo un supporto aggiuntivo alla sicurezza della nostra macchina, ma non può essere l’unico metodo di prevenzione di accessi indesiderati.
Per installare il prodotto, aggiugeremo ai nostri repository quello EPEL (Extra Packages for Enterprise Linux):
# cd /usr/src # wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm # rpm -Uvh epel-release-6-8.noarch.rpm # yum -y install fail2ban
A questo punto il nostro sistema di analisi dei log in tempo reale è attivo, ma non abbiamo ancora configurato nulla da monitorare; partiamo dalle opzioni di default del nostro servizio, creando un nuovo file invece di sovrascrivere quello di default:
/etc/fail2ban/jail.local
[DEFAULT] # Ignoriamo la nostra LAN, oltre all'indirizzo di loopback ignoreip = 127.0.0.1/8 192.168.44.0/24 # Blocco dell'IP impostato a 24 ore bantime = 86400 # Ban dell' IP se genera un maxretry nell'ultimo findtime findtime = 600 maxretry = 2 backend = gamin usedns = warn
Se abbiamo qualche altro indirizzo IP che raggiunge il nostro server (indirizzi IP legati a vpn, sistemi di monitor, intrusion detection, …) li dovremo aggiungere al blocco degli IP ignorati.
Abilitiamo ora qualche controllo, a partire dal servizio ssh; facciamo in modo che se qualcuno tenta di effettuare 3 accessi ssh non autorizzati in 3 minuti, viene bloccato; inoltre deve essere segnalata l’anomalia all’amministratore di sistema.
[ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=dave@anthesia.lan, sender=fail2ban@anthesia.lan, sendername="Fail2Ban Anthesia"] logpath = /var/log/sshd.log findtime = 180 maxretry = 3
Il filtro /etc/fail2ban/filter.d/sshd.conf utilizzato dalla precedente regola cerca accessi non autorizzati del tipo:
- – autentication failure/error
- – user not know
- – failed from port
- – login refused
- – illegal/invalid user
Se da un indirizzo IP viene attivata la regola per uno dei punti indicati nel filtro, all’indirizzo IP viene assegnato 1 punto; se l’indirizzo IP raccoglie più di 3 punti in 3 minuti, allora viene bloccato tramite iptables (action) e contemporaneamente viene inviata una mail all’indirizzo dell’amministratore.
Come fatto per l’ssh, possiamo abilitare anche i filtri per gli altri servizi (qmail, webmail, ….) in maniera da proteggere quanto più possibile il nostro server.
Vediamo di seguito come analizzare il file di log di un sistema qmail ed bloccare gli indirizzi IP da cui provengono anomalie; per anomalie intenderemo:
- tentativi di accesso con utenti inesistenti;
- tentativi di accesso con password sbagliate
- tentativi di relay sul nostro server non autorizzati
Per far ciò scriveremo i seguenti filtri:
- /etc/fail2ban/filter.d/password-fail.conf
# vi /etc/fail2ban/filter.d/password-fail.conf [Definition] failregex = password fail ([^)]*) [^@]*@[^:]*:<HOST> ignoreregex =
- /etc/fail2ban/filter.d/vpopmail.conf
# vi /etc/fail2ban/filter.d/vpopmail.conf: [Definition] failregex = vpopmail user not found .*@:<HOST> ignoreregex =
Una volta create le regole, possiamo testarne il funzionamento con il comando fail2ban-regex; al esempio, per la regola password-fail:
# fail2ban-regex /var/log/maillog /etc/fail2ban/filter.d/password-fail.conf Failregex |- Regular expressions: | [1] vchkpw-smtp: password fail ([^)]*) [^@]*@[^:]*:<HOST> | `- Number of matches: [1] 13 match(es)
Se è tutto a posto, modificheremo il file jail.conf per includere i precedenti filtri:
# vi /etc/fail2ban/jail.local # password-fail [password-fail] enabled = true filter = password-fail action = iptables[name=SMTP, port=smtp, protocol=tcp] logpath = /var/log/maillog maxretry = 3 bantime = 86400 findtime = 3600 # vpopmail [vpopmail] enabled = true port = pop3 filter = vpopmail action = iptables[name=pop3, port=pop3, protocol=tcp] sendmail-whois[name=pop3, dest=dave@anthesia.lan, sender=fail2ban@anthesia.lan, sendername="Fail2Ban Anthesia"] logpath = /var/log/maillog maxretry = 3 bantime = -1
Riavviamo fail2ban per fare in modo che i nuovi filtri siano attivi:
# service fail2ban restart
Possiamo controllare se i nostri filtri sono davvero attivi:
# fail2ban-client status password-fail Status for the jail: password-fail |- filter | |- File list: /var/log/maillog | |- Currently failed: 7 | `- Total failed: 225 `- action |- Currently banned: 109 | `- IP list: xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy zzz.zzz.zzz.zzz .... `- Total banned: 109
ATTENZIONE: Ricordiamoci sempre che Fail2Ban è un logparser, non è un sistema di intrusion prevention in quanto non può fare nulla fino a quando qualcosa viene scritto nei file di log, ed ancora più importante, esiste un filtro in grado di intercettarlo; inoltre, quando fail2ban viene riavviato, gli indirizzi IP che sono in blacklist vengono cancellati. Questo è un problema legato a iptables e non a fail2ban. Per ricaricare i ban attualmente attivi possiamo fare in questo modo:
Before changes, write existing iptables rules to file # service iptables save And after any change load the saved set of rules # service iptables restart Tune fail2ban to write IPs to /etc/fail2ban/ip.deny