Tengo un servidor Ubuntu 20.04 que recibe cientos de solicitudes SMTP AUTH en mi servidor Postfix todos los días desde la misma IP. Tengo instalado fail2ban, pero, irónicamente, no logra prohibir la IP.
Mi /etc/fail2ban/jail.localarchivo es (los bits <snip> son IP personales y comerciales):
[postfix-flood-attack]
enabled = true
bantime = 1h
filter = postfix-flood-attack
action = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
logpath = /var/log/mail.log
ignoreip = <snip> 127.0.0.1/8
maxretry = 3
[postfix]
enabled = true
maxretry = 3
bantime = 1h
filter = postfix[mode=aggressive]
logpath = /var/log/mail.log
ignoreip = <snip> 127.0.0.1/8
[dovecot]
enabled = true
port = pop3,pop3s,imap,imaps
filter = dovecot
logpath = /var/log/mail.log
maxretry = 3
ignoreip = <snip> 127.0.01/8
La cárcel en cuestión es postfix-flood-attacktomada dela parte inferior de este tutorial. El /etc/fail2ban/filter.d/postfix-flood-attack.confarchivo es:
[Definition]
failregex = lost connection after AUTH from (.*)\[<HOST>\]
ignoreregex =
Mis mensajes de registro se ven así
Aug 15 13:54:45 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:46 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: warning: unknown[193.35.48.18]: SASL PLAIN authentication failed:
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:54:50 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:51 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:54:57 ikana postfix/smtps/smtpd[268729]: connect from unknown[193.35.48.18]
Aug 15 13:54:58 ikana postfix/smtps/smtpd[268729]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268729]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268729]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Aug 15 13:55:04 ikana postfix/smtps/smtpd[268734]: connect from unknown[193.35.48.18]
Aug 15 13:55:05 ikana postfix/smtps/smtpd[268734]: Anonymous TLS connection established from unknown[193.35.48.18]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: warning: unknown[193.35.48.18]: SASL PLAIN authentication failed:
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: lost connection after AUTH from unknown[193.35.48.18]
Aug 15 13:55:09 ikana postfix/smtps/smtpd[268734]: disconnect from unknown[193.35.48.18] ehlo=1 auth=0/1 commands=1/2
Según fail2ban-regex, esto debería funcionar, pero la propiedad intelectual no está prohibida. La salida del comando fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/postfix-flood-attack.confes:
Running tests
=============
Use failregex filter file : postfix-flood-attack, basedir: /etc/fail2ban
Use log file : /var/log/mail.log
Use encoding : UTF-8
Results
=======
Failregex: 5356 total
|- #) [# of hits] regular expression
| 1) [5356] lost connection after AUTH from (.*)\[<HOST>\]
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [37949] {^LN-BEG}(?:DAY )?MON Day %k:Minute:Second(?:\.Microseconds)?(?: ExYear)?
`-
Lines: 37949 lines, 0 ignored, 5356 matched, 32593 missed
[processed in 1.43 sec]
Missed line(s): too many to print. Use --print-all-missed to print all 32593 lines
Por lo tanto, encuentra una coincidencia para 5356 registros y nunca prohíbe ninguno. Generalmente hay 8 intentos dentro del tiempo de búsqueda predeterminado de 10 minutos. Un fragmento del uso de la -vopción fail2ban-regexmuestra las siguientes coincidencias con marcas de tiempo:
...
193.35.48.18 Thu Aug 15 13:50:55 2019
193.35.48.18 Thu Aug 15 13:51:02 2019
193.35.48.18 Thu Aug 15 13:51:10 2019
193.35.48.18 Thu Aug 15 13:51:15 2019
193.35.48.18 Thu Aug 15 13:54:50 2019
193.35.48.18 Thu Aug 15 13:54:57 2019
193.35.48.18 Thu Aug 15 13:55:04 2019
193.35.48.18 Thu Aug 15 13:55:09 2019
193.35.48.18 Thu Aug 15 13:58:40 2019
193.35.48.18 Thu Aug 15 13:58:48 2019
193.35.48.18 Thu Aug 15 13:58:54 2019
193.35.48.18 Thu Aug 15 13:58:59 2019
...
Respuesta1
La configuración se ve bien, pero hay un detalle importante a notar con el resultado de fail2ban-regex: decidió que las fechas son de 2019. Dado el aspecto de los registros en la pregunta, esto parecía bastante estúpido al principio. Resulta que esto es un problema conocido con fail2ban, algo a lo que se refieren comoel problema de TZ. Después de configurar su servidor para usar una zona horaria específica, debe reiniciar varios servicios o reiniciar todo el sistema para que surta efecto correctamente. Aunque no recuerdo cuánto tiempo ha pasado, supongo que nunca reinicié mi servidor desde que configuré la zona horaria en él.
Después de reiniciar el servicio syslog a través de systemctl restart syslog, fail2ban reconoció las líneas de registro en la zona horaria correcta.
Fail2ban reconoció inmediatamente los mensajes de registro en el tiempo de búsqueda configurado y prohibió la IP que ha estado plagando mi servidor durante días. Supongo que Fail2ban solicita a syslog la información de la zona horaria en lugar de usar lo que se configuró en la máquina desde que se inició el servidor fail2ban.
Espero que esto pueda ayudar a alguien más con un problema similar.
Respuesta2
La ambigüedad que hizo que fail2ban asumiera que esas fechas eran en 2019 no puede ocurrir cuando se utiliza el formato de fecha estándar. Puede evitar el problema por completo siutilizando ISO 8601- Es posible que no le quede ninguna buena razón para seguir con el formato de registro compatible con versiones anteriores en 2020.
Además, en Ubuntu, es probable que pueda omitir el formateo/análisis de la fecha por completo, indicando a fail2ban que consuma systemd journal directamente, lo que proporciona compensaciones simples desde la época sin información de zona horaria (pruebe backend = systemden el [DEFAULT]bloque en la configuración de la cárcel local).