Fail2Ban não banindo no CentOS 7 com o SELinux

1

Em uma pilha LEMP com o WordPress e o plugin WP fail2ban, os problemas de autenticação do WordPress são registrados em / var / log / messages perfeitamente.

$ sudo fail2ban-client version
0.9.2

Nos últimos dias recebo cerca de 25K dessas linhas, alguma tentativa de força bruta da Suécia:

Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29203]: Blocked authentication attempt for mydomain from 217.70.32.9
Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29204]: Blocked authentication attempt for mydomain from 217.70.32.9
Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29796]: Blocked authentication attempt for mydomain from 217.70.32.9
Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29203]: Blocked authentication attempt for mydomain from 217.70.32.9
Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29204]: Blocked authentication attempt for mydomain from 217.70.32.9

A cadeia wordpress.conf foi ativada e o teste regexp funciona:

$ sudo fail2ban-regex /var/log/messages /etc/fail2ban/filter.d/wordpress.conf

Failregex: 25865 total
|-  #) [# of hits] regular expression
|   1) [180] ^\s*(<[^.]+\.[^.]+>)?\s*(?:\S+ )?(?:kernel: \[ *\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?wordpress(?:\(\S+\))?[\]\)]?:?|[\[\(]?wordpress(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)?\s(?:\[ID \d+ \S+\])?\s*Authentication failure for .* from <HOST>$
|   2) [25685] ^\s*(<[^.]+\.[^.]+>)?\s*(?:\S+ )?(?:kernel: \[ *\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?wordpress(?:\(\S+\))?[\]\)]?:?|[\[\(]?wordpress(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)?\s(?:\[ID \d+ \S+\])?\s*Blocked authentication attempt for .* from <HOST>$

No entanto, nenhum é banido.

$ sudo fail2ban-client status wordpress
Status for the jail: wordpress
|- Filter
|  |- Currently failed: 0
|  |- Total failed: 0
|  '- File list:    /var/log/messages
'- Actions
   |- Currently banned: 0
   |- Total banned: 0
   '- Banned IP list:

Confirmando o firewalld sabe disso:

$ sudo ipset list

Name: fail2ban-wordpress
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 65536 timeout 3600
Size in memory: 16528
References: 1
Members:

De jail.local

bantime  = 3600
findtime  = 600
banaction = firewallcmd-ipset

# Protect agains WP Login bruteforce attemps via
# https://wordpress.org/plugins/wp-fail2ban/installation/

[wordpress]

port     = http,https
logpath  = /var/log/messages
maxretry = 3
enabled = true

Note como acima temos 5 tentativas de repetição dentro de um segundo, o que deve obviamente desencadear uma proibição.

Não vejo mensagens negativas preocupantes em /var/log/audit/audit.log em relação ao SELinux, o que impede que isso funcione, embora eu esteja longe de ser um especialista no SELinux.

O registro funciona. O regex funciona. Fail2Ban é executado. A cadeia foi ativada. Firewalld está esperando coisas. Mas nada está acontecendo.

Proibir manualmente também funciona:

$ sudo fail2ban-client set wordpress banip 217.70.32.9

$ sudo fail2ban-client status wordpress
Status for the jail: wordpress
|- Filter
|  |- Currently failed: 0
|  |- Total failed: 3
|  '- File list:    /var/log/messages
'- Actions
   |- Currently banned: 1
   |- Total banned: 1
   '- Banned IP list:   217.70.32.9

$ sudo ipset list
Name: fail2ban-wordpress
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 65536 timeout 3600
Size in memory: 16592
References: 1
Members:
217.70.32.9 timeout 3457

Isso parece confirmar que meu jail.local está sendo carregado:

$ sudo fail2ban-client status
Status
|- Number of jail:  6
'- Jail list:   1, 2, 3, 4, 5, wordpress

Eu estava usando pesquisas de back-end, mas agora estou executando o Gamin. Definindo o nível de registro do Fail2Ban para depurar, isso parece funcionar quando eu me loguei errado:

2015-08-18 22:57:52,874 fail2ban.filtergamin    [29664]: DEBUG   File changed: /var/log/messages

O verificador regex continua aumentando suas correspondências também. Mas ainda assim, eu posso fazer isso 20 vezes em 2 minutos sem ser banido ...

Onde devo procurar agora?

    
por JayMcTee 18.08.2015 / 21:37

1 resposta

1

Depois de ficar trabalhando por horas, finalmente ficou claro para mim que o timestamp em / var / log / messages estava 2 horas fora de sincronia. Isso, obviamente, tem repercussões quando se trata do fail2ban descobrir o tempo de espera.

$ timedatectl
      Local time: Tue 2015-08-18 23:50:11 CEST

Em / var / log / messages:

Aug 18 21:50:11 ip-172-1-6-5 systemd: Started Time & Date Service.

Para resolver:

$ sudo systemctl restart rsyslog.service

Agora meus logins com falha são registrados com o timestamp correto e, na verdade, eu fui banido.

    
por 19.08.2015 / 00:03