Fail2Ban: già vietato?

Ho Fail2Ban in esecuzione sul mio server Centos. (Config sotto)

Nel mio var / log / messaggi ho notato qualcosa di veramente strano:

Jun 19 12:09:32 localhost fail2ban.actions: INFO   [postfix] 114.43.245.205 already banned

Ho configurato Fail2Ban per aggiungere l'IP vietato a iptables.

Il mio jail.conf:

[postfix]

enabled  = true
filter   = postfix
action   = iptables
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/maillog
bantime  = 43200
maxretry = 2

Il mio postfix.conf:

[INCLUDES]

before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 550 5.1.1
            reject: RCPT from (.*)\[<HOST>\]: 450 4.7.1
            reject: RCPT from (.*)\[<HOST>\]: 554 5.7.1
            reject: RCPT from (.*)\[<HOST>\]: (.*)@yahoo.com.tw
ignoreregex =

La mia domanda è: come può qualcuno che è già stato bloccato iptablesconnettersi ancora al server?

Il carcere recidivo raccomandato nell'altra risposta qui non ha risolto il problema per me. Alla fine ho risolto questo, tuttavia, ecco il mio metodo nel caso in cui aiuti gli altri.

Fail2ban blocca solo su TCP per impostazione predefinita. Almeno con la mia configurazione, ho notato che appariva il messaggio "già vietato" quando i bot sono tornati per provare invece la porta bloccata su UDP.

Per risolvere questo problema, dire a Fail2ban di bloccare la porta su tutti i protocolli anziché solo TCP. Dovrai apportare questa modifica in /etc/fail2ban/jail.conf e nella sezione [Init] di ogni azione che stai usando su /etc/fail2ban/action.d/ .

Cambia questo:

# Default protocol
protocol = tcp

Per:

# Default protocol
protocol = all

Successivamente, ho disabilitato le richieste di eco ICMP in modo che gli IP bloccati non potessero colpire il server:

1. nano /etc/sysctl.conf

2. Aggiungi queste due righe:

   net.ipv4.icmp_echo_ignore_all = 1  
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   

3. Esci e salva il file.
4. Esegui sysctl -p per rendere effettiva la modifica.

Dopodiché, esegui ricar2ban-client ricaricare e non dovresti più vedere questi messaggi "già vietati" a meno che non sei spammato da un IP che ottiene un paio di tentativi di accesso prima che il blocco abbia effetto.

Inoltre, è importante bloccare tutte le porte per tutti i trasgressori anziché la porta a cui stavano tentando di accedere utilizzando l'azione iptables-allports in ciascuna jail. Altrimenti, possono attivare un'altra prigione e finire come "già vietato" nei registri.

Se guardi l'output di iptables-save, vedrai che le fail2bancatene sono impostate in modo che valutino i pacchetti in base alle regole definite dai filtri, ad esempio:

:fail2ban-ssh - [0:0]
-A INPUT -p tcp -A INPUT -p tcp -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A fail2ban-ssh -j RETURN

Il traffico continua a raggiungere il server prima che vengano applicate le altre regole di routing e il traffico viene rifiutato. fail2bancontinua a vedere questo traffico iniziale ed è per questo che vedi i messaggi "già vietati". Inoltre, esiste un filtro speciale per i recidivi ( /etc/fail2ban/filter.d/recidive.conf):

# Fail2Ban filter for repeat bans
#
# This filter monitors the fail2ban log file, and enables you to add long
# time bans for ip addresses that get banned by fail2ban multiple times.
#
# Reasons to use this: block very persistent attackers for a longer time,
# stop receiving email notifications about the same attacker over and
# over again.
#
# This jail is only useful if you set the 'findtime' and 'bantime' parameters
# in jail.conf to a higher value than the other jails. Also, this jail has its
# drawbacks, namely in that it works only with iptables, or if you use a
# different blocking mechanism for this jail versus others (e.g. hostsdeny
# for most jails, and shorewall for this one).

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = fail2ban\.server\.actions

# The name of the jail that this filter is used for. In jail.conf, name the
# jail using this filter 'recidive', or change this line!
_jailname = recidive

failregex = ^(%(__prefix_line)s| %(_daemon)s%(__pid_re)s?:\s+)WARNING\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$

[Init]

journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=4

# Author: Tom Hendrikx, modifications by Amir Caspi

Questo accadrà se l'indirizzo IP che stai vietando non è in realtà l'indirizzo IP del client che si connette al server. Ad esempio, se il tuo server si trova dietro un bilanciamento del carico o un proxy.

Mi ci è voluto un po 'di tempo per capirlo di recente. L'aringa rossa era che i log erano configurati per acquisire l' X-Forwarded-Forindirizzo IP, anziché l'indirizzo di origine reale, che nel mio caso era il bilanciamento del carico.

In questo caso fail2ban non è di grande aiuto, dal momento che vietare l'IP offensivo finirebbe per bloccare tutto il traffico.

Voglio contribuire con il mio problema e la mia soluzione con messaggi "già vietati". Come hai scritto, ne avevo centinaia in pochi minuti, mentre l'attaccante avrebbe dovuto essere già bandito.

Prima di iniziare, ecco il mio sistema:

• Plesk 12
• Centos 7
• Modulo Plesk installato, operativo e configurazione fail2ban per me

Quando ho installato OpenVPN sul mio rooterver avevo cambiato firewalld in iptables. Ciò potrebbe aver causato questo problema per me, ma a parte questo il mio sistema era quasi intatto e abbastanza fresco (il root server Strato ha suggerito di installare l'immagine).

Se hai questo problema, controlla /etc/fail2ban/jail.d/00-firewalld.conf per una linea simile a questa:

banaction = firewallcmd-ipset

Da quando l'ho commentato, salvato il file e riavviato fail2ban.service, tutto è andato bene con fail2ban. Niente più messaggi

Non sono un esperto, ma spero di fornirti la risposta giusta. Se questo funziona per te, per favore fatemi sapere!

La mia domanda è: come può ancora connettersi al server qualcuno che è già stato bloccato in iptables?

Si è collegato al server solo una volta, ma in quella connessione ha cercato di recapitare più e-mail a caselle di posta probabilmente inesistenti (come info@domain.com, sales@domain.com, tech@domain.com ecc.)

Hai configurato il tuo filtro postfix per vietare quei tentativi in ​​modo che l'IP venga bannato dopo X tentativi. Il client potrebbe già essere disconnesso da postfix, ma poiché postfix potrebbe non aver completato l'elaborazione della sua e-mail, fail2ban può rilevare un altro tentativo dallo stesso client quando postfix elabora la sua posta e quindi l'indirizzo del messaggio è già stato bannato. È a causa di come funziona la coda postfix.

La mia domanda è: come può ancora connettersi al server qualcuno che è già stato bloccato in iptables?

Incredibile buona domanda. Stavo cercando se le mie regole del firewall non funzionano, ma iliptables --list-rules corrispondevano esattamente a un altro server di produzione con fail2ban funzionante.

La soluzione strabiliante era quella di aggiungere la porta 8080 alle porte bloccate, poiché stavo ancora accedendo alla pagina di accesso tramite le porte di sviluppo.

Quindi la soluzione nella mia situazione è che questo problema è stato un adattamento abbastanza semplice del mio jail.local:

[JIRA-LOGIN-tcp]
  enabled = true
  port = http,https,8080
  protocol = tcp
  filter = JIRA-LOGIN-ERROR
  logpath = /var/atlassian/application-data/jira/log/atlassian-jira-security.log
  bantime = 600
  maxretry = 1

vedi /unix//a/525798/22315

probabilmente ti manca la porta 587 dalla riga "port =" e puoi controllare il file di configurazione di postfix o fare "lsof -i: 587" per scoprire direttamente se postfix è stato configurato per aprire quella porta.