Apr 192011
 

fail2ban

Come commento dell’articolo “Knockd, per garantire la sicurezza delle porte”, ho ricevuto:
“Usare knockd è una cattiva idea: una pessima idea.

“Knockd è, alla fine, una password. Un’unica password sniffable che è soggetta ad attacchi di tipo man-in-the-middle e quindi non si possono usare nemmeno one-time-password ed essere sicuri.

Coppie di chiavi Pubbliche/private  e/o one-time-password (Opie, skey e simili) sono le soluzioni reali, insieme al monitoraggio dinamico per prevenire attacchi DOS che portino all’esaurimento delle risorse CPU. (OpenBSD PF incorpora una bella soluzione, così come iptables con fail2ban/denyhosts/etc. Anche swatch può fare miracoli.) “

Ebbene, a mio parere knockd è uno strato ulteriore di sicurezza, forse sottile ma comunque può salvare da alcuni script che tentano attacchi del tipo forza bruta e quindi aggiunge un po’ di sicurezza alla vostra soluzione, in questo articolo vi mostrerò fail2ban che aggiunge un altro strato di sicurezza ai nostri servizi esposti in rete.


Fail2ban è un software per la prevenzione delle intrusioni scritto in Python. E’ in grado di girare su sistemi POSIX che hanno un interfaccia ad un sistema di controllo dei pacchetti o firewall installato localmente (per esempio, iptables o TCP Wrapper).
La funzione principale di Fail2ban è quella di bloccare gli indirizzi IP selezionati che potrebbero appartenere a dei computers che stanno tentando di violare la sicurezza del sistema. Determina i server che devono essere bloccati da un controllo dei file di log (per esempio /var/log/pwdfail, /var/log/auth.log, ecc) e proibisce l’accesso dagli IP degli host che hanno troppi tentativi di accesso indesiderato o esegue altre azioni in un arco di tempo definito dall’amministratore.

Installazione

fail2ban è disponibile su Debian, Ubuntu, Gentoo, Arch, Suse e Fedora quindi su queste distro potete usare il gestore di pacchetti standard per installarlo (con le sue dipendenze), i.g. aptitude install fail2ban, emerge net-analyzer/fail2ban.

Uso

fail2ban è composto da due programmi, il server (fail2ban-server) che monitorizza i log e usa un socket unix per parlare con il client e passargli le informazioni in tempo reale. Il server non sa nulla del file di configurazione. Così, allo start-up, il server è in uno stato di “default” in cui non ci sono “jail” (prigioni) definite.

fail2ban-client è il frontend di fail2ban. Si connette al file di socket del server ed invia comandi al fine di configurare e gestire il server. Il client può leggere i file di configurazione o può semplicemente essere utilizzato per inviare un unico comando al server utilizzando la riga di comando o la modalità interattiva (che si attiva con l’opzione -i).

Configurazione

Una configurazione tipica si presenta così:

/etc/fail2ban/
├── action.d
│   ├── dummy.conf
│   ├── hostsdeny.conf
│   ├── iptables.conf
│   ├── mail-whois.conf
│   ├── mail.conf
│   └── shorewall.conf
├── fail2ban.conf
├── fail2ban.local
├── filter.d
│   ├── apache-auth.conf
│   ├── apache-noscript.conf
│   ├── couriersmtp.conf
│   ├── postfix.conf
│   ├── proftpd.conf
│   ├── qmail.conf
│   ├── sasl.conf
│   ├── sshd.conf
│   └── vsftpd.conf
├── jail.conf
└── jail.local

Ogni file .conf può essere sovrascritto con un file chiamato .local . Il file .conf viene letto prima, poi il .local, con le impostazioni lette dopo che sovrascrivono le precedenti. Così, un file .local non deve necessariamente includere tutto ciò che è presente nel file corrispondente .conf, solo le impostazioni che si desidera configurare in maniera diversa. Le modifiche devono avvenire nel file .local e non nel .conf. Questo evita problemi durante l’aggiornamento.

Configurazione generale

Il file fail2ban.conf contiene le impostazioni generali per il demone fail2ban-server, come ad esempio il livello di log e la sua destinazione. È inoltre possibile specificare qual’è il percorso del socket utilizzato per la comunicazione tra il client e il server.

jails

Il più importante file è probabilmente jail.conf, che contiene la dichiarazione delle vostro jails.
I parametri più importanti sono:

PARAMETRO	DESCRIZIONE
ignoreip	Lista di IP da ignorare, IP possono essere inseriti con il netmask /24 per esempio
bantime	        Tempo in secondi per il quale non accettiamo piu connessioni dal HOST
findtime	Tempo di reset dei tentativi, dopo X secondi il contatore del retry è resettato
maxretry	Numero di tentativi massimo in un intervallo findtime
action	        Cosa fare quando si raggiunge il maxretry, normalmente si blocca la porta a quel IP
port	        Il servizio o meglio la porta che usa quel servizio che vogliamo controllare
filter	        La regola di filtro che applichiamo ai log in /etc/fail2ban/filter.d
logpath	        Naturalmente il log da monitorare e ricordiamoci di attivare il daemon per scrivere le info necessarie

Esempi:

[ssh]
 
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

Questo è l’esempio classico per ssh, verifica il log /var/log/auth.log utilizzando il filtro che si chiama sshd e se trova 6 tentativi di attacco chiude la porta 22 (azione di default)

[apache-multiport]
enabled   = true
port      = http,https
filter    = apache-auth
logpath   = /var/log/apache*/*error.log
maxretry  = 6

Questo esempio per Apache è molto simile, ma ha come differenza che blocca 2 porte (http ed https) e verifica più file di log.

Filtri

La directory filter.d contiene principalmente le espressioni regolari che vengono utilizzate per individuare tentativi di intrusione, fallimenti password, ecc Questo è un esempio per filter.d/sshd.conf con alcune possibili espressioni regolari per verificare le linee del file di log:

failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from s*$
            ^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from s*$
            ^%(__prefix_line)sFailed (?:password|publickey) for .* from (?: port d*)?(?: sshd*)?$
            ^%(__prefix_line)sROOT LOGIN REFUSED.* FROM s*$
            ^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from s*$
            ^%(__prefix_line)sUser .+ from  not allowed because not listed in AllowUsers$
            ^%(__prefix_line)sauthentication failure; logname=S* uid=S* euid=S* tty=S* ruser=S* rhost=(?:s+user=.*)?s*$
            ^%(__prefix_line)srefused connect from S+ ()s*$
            ^%(__prefix_line)sAddress  .* POSSIBLE BREAK-IN ATTEMPT!*s*$
            ^%(__prefix_line)sUser .+ from  not allowed because none of user's groups are listed in AllowGroupss*$

Far partire il server

Dopo aver configurato tutti i filtri ed i servizi che si desidera monitorare è possibile avviare il server con il comando:

sudo /etc/init.d/fail2ban start

Comandi utili

per vedere tutta la configurazione con eventuali warning usiamo il comando

fail2ban-client -d

Possiamo testare le espressioni regolari di un filtro

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Per vedere chi è stato bannato

iptables -L

Riferimenti:

Esempi di configurazioni
Fail2ban guida all’uso

Dal minuto 7.00 per una guida a fail2ban




Popular Posts:

flattr this!

  10 Responses to “Fail2ban,Ferma gli attacchi brute force”

  1. knockd has never been my favorite either. fail2ban has been a terrific tool. One thing to include in the individual jails that I like to include is the bantime statement. This might be useful if you wanted to ban certain intrusion attempts longer than others.

  2. “Well, in my opinion knockd it’s a layer of security, perhaps thin but still can save you from some brute force script and so it adds a bit of security to your solution”

    Nice article. And, I just had to comment about the above quote: Exactly right! Of course keeping ports closed and opening them only on demand adds security.

    Apparently there are some amateur “security experts” reading your posts who think they’re clever, but lack some basic common sense.

  3. Ciao, per mod_sec ho usato le direttive di debianizzati.org, ma mi da un problema con la action, che loro hanno impostato così:

    iptables-multiport[name=ModSec, port=”http,https”]

    – Questa sarebbe la direttiva per bloccare l’IP che attacca?
    – Di Default quale è la action?

    Appena attivo questa jail, il server non funziona più, se invece la disattivo, va tutto bene.

    – Posso levare questa action, richiamando così quella di dafult e bloccando l’ip che attacca?
    – Dove è il mio problema? Perchè IPTABLES non va?

    Mi dai una mano? Grazie

    • Ciao,

      Non ho mai usato mod_sec, ma guardando la documentazione ufficiale vedo una riga molto simile:
      http://www.fail2ban.org/wiki/index.php/HOWTO_fail2ban_with_ModSecurity2.5

      Nel jail dovresti avere:

      [modsec]
      enabled = true
      filter = modsec
      action = iptables-multiport[name=ModSec, port=”http,https”]
      # sendmail-buffered[name=ModSec, lines=5, dest=[email protected]]
      logpath = /var/log/apache2/modsec_audit.log
      bantime = 172800
      maxretry = 1

      Che errore hai nei log quando fai partire fail2ban ?

      • ciao linuxari,
        grazie anzitutto per la risposta. Mi pare (non ricordo) che risolsi quel problema, e ora non saprei dirti gli errori sul log, quale conf usaiper mod_sec, e come sta andando…so solo che fail2ban non mi convince del tutto perchè nel logo auth continuo a vedere tentativi…

        Il punto è che sono solo…terribilmente solo…e tra l’altro ho voluto 5 server virtuali…mi diverto tantissimo, ma ovviamente è anche una faticaccia…
        tentativi ne vedo parecchi, è vero, ma credo che ancora nessuno sia riuscito ad entrare…questa sarebbe anche un’altra cosa interessante da sapere…consigli?

        • Come consiglio cerca di automatizzare il più possibile (aggiornamenti, restart dei demoni con monit, etc.) e fatti mandare email o sms se qualcosa va male, questo di solito aiuta a respirare un po.

          Sul come capire se qualcuno è entrato…ci sono i programmi che fanno verifiche per rootkit noti, in generale cerca di avere dei report dai tuoi sistemi su uso di rete/cpu/disco ed indaga se noti anomalie.

          Ciao

          • Grazie per i consigli,
            hai la mia mail, perchè non mi mandi qualche script per automatizzare, e qualche nome di qualche programma.

            Considera però che io stringo tutto all’osso, relativamente a demoni e utilizzo ram. Perchè ne ho solo 512mb, e preferisco utilizzarla tutta o quasi per apache2(in modalità prefork purtroppo).

            Grazie ancora
            Saluti

  4. Un tool alternativo di brute force protection è SSHGuard. Oltre a proteggere SSH protegge anche diversi altri demoni frequenti su UNIX per e-mail, FTP etc. E’ scritto in C anziché essere uno script intepretato, quindi è più leggero in memoria, ed è tutto italiano.

    • Ciao Michele,
      Grazie per l’informazione. Ci guardo ed a breve ci scappa un’articoletto ;)

    • Ciao Federico,
      grazie per l’informazione anche da parte mia! Purtroppo sui miei server ho già installato e configurato fail2ban, altrimenti volentierissimo avrei provato un progetto italiano, che pare sia anche più completo.

      Alcune domande:

      Pacchetto su/per Ubuntu?
      lavora accoppiato a fail2ban, o si dovrebbe poi levare l’ultimo?
      Per pulizia del sistema, sono un pò restio a cambiare completamente, perchè purtroppo io sono solo e il giorno è solo di 24 ore anche per me… però magari se tu riuscissi a convincermi magari dicendomi anche come posso tenere pulito il sistema, levando tutti i file di fali2ban. magari ci faccio un pensierino… se ti va vorrei farti alcune domande, potrei contattarti?
      Saluti

 Leave a Reply

(required)

(required)


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>