Fail2Ban não está adicionando regras de iptables

6

O Fail2Ban não está adicionando regras de iptables para bloquear invasores. Estou rodando o CentOS 6.5 (32 bits)

Veja o que eu fiz:

  • O fail2ban foi instalado via yum usando o repositório EPEL.
  • copiei jail.conf para jail.local .
  • Eu mudei o tempo de proibição em jail.local para 3600

    bantime  = 3600
    

Para o iptables eu tenho estas regras definidas em relação ao SSH

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state ESTABLISHED 
3    fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 

Meu jail.local config para SSH:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/secure
maxretry = 5

Últimas entradas de registro:

2014-08-13 10:11:04,481 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.11
2014-08-13 10:11:04,482 fail2ban.jail   : INFO   Creating new jail 'ssh-iptables'
2014-08-13 10:11:04,514 fail2ban.jail   : INFO   Jail 'ssh-iptables' uses pyinotify
2014-08-13 10:11:04,533 fail2ban.jail   : INFO   Initiated 'pyinotify' backend
2014-08-13 10:11:04,536 fail2ban.filter : INFO   Added logfile = /var/log/secure
2014-08-13 10:11:04,537 fail2ban.filter : INFO   Set maxRetry = 5
2014-08-13 10:11:04,540 fail2ban.filter : INFO   Set findtime = 600
2014-08-13 10:11:04,540 fail2ban.actions: INFO   Set banTime = 3600
2014-08-13 10:11:04,727 fail2ban.jail   : INFO   Jail 'ssh-iptables' started

Eu inicio o fail2ban, mas depois de um tempo (cerca de uma hora) eu verifico o /var/log/secure e ainda estou recebendo ataques de força bruta:

Aug 13 10:31:35 webhost sshd[15619]: Invalid user china from 128.199.147.79
Aug 13 10:31:35 webhost sshd[15620]: input_userauth_request: invalid user china
Aug 13 10:31:36 webhost sshd[15620]: Connection closed by 128.199.147.79
Aug 13 10:35:04 webhost sshd[15661]: Invalid user klaudia from 106.187.90.33
Aug 13 10:35:04 webhost sshd[15662]: input_userauth_request: invalid user klaudia
Aug 13 10:35:05 webhost sshd[15662]: Connection closed by 106.187.90.33
Aug 13 10:41:56 webhost sshd[15772]: Invalid user cassandra from 106.187.90.33
Aug 13 10:41:56 webhost sshd[15773]: input_userauth_request: invalid user cassandra
Aug 13 10:41:57 webhost sshd[15773]: Connection closed by 106.187.90.33
Aug 13 10:44:10 webhost sshd[15807]: Invalid user knight from 106.187.90.33
Aug 13 10:44:10 webhost sshd[15808]: input_userauth_request: invalid user knight
Aug 13 10:44:12 webhost sshd[15808]: Connection closed by 106.187.90.33

Nenhuma nova regra foi adicionada ao iptables ...

Chain fail2ban-SSH (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0 

Se eu tentar e depurar o problema com fail2ban-regex :

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

Running tests

Use   failregex file : /etc/fail2ban/filter.d/sshd.conf
Use         log file : /var/log/secure

Results

Failregex: 1374 total
|-  #) [# of hits] regular expression
|   5) [1374] ^\s*(<[^.]+\.[^.]+>)?\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)?\s(?:\[ID \d+ \S+\])?\s*[iI](?:llegal|nvalid) user .* from <HOST>\s*$
'-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [4615] MONTH Day Hour:Minute:Second
'-

Lines: 4615 lines, 0 ignored, 1374 matched, 3241 missed
Missed line(s):: too many to print.  Use --print-all-missed to print all 3241 lines
</code>

The missed lines are:

Lines: 4621 lines, 0 ignored, 1376 matched, 3245 missed
|- Missed line(s):
|  Aug 10 03:46:30 webhost sshd[12340]: input_userauth_request: invalid user simulator
|  Aug 10 03:46:30 webhost sshd[12340]: Connection closed by 106.187.90.33
|  Aug 10 03:55:01 webhost sshd[12430]: input_userauth_request: invalid user simulation
|  Aug 10 03:55:02 webhost sshd[12430]: Connection closed by 106.187.90.33
|  Aug 10 04:01:33 webhost sshd[12505]: Connection closed by 128.199.147.79
|  Aug 10 04:02:46 webhost sshd[12539]: reverse mapping checking getaddrinfo for new.jerl.im [128.199.254.179] failed - POSSIBLE BREAK-IN ATTEMPT!

Eu não sei o suficiente sobre o fail2ban para saber o que há de errado com o meu filtro sshd. Eu teria pensado que a configuração padrão teria sido suficiente? Como faço para corrigir isso?

    
por Aditya K 13.08.2014 / 11:59

4 respostas

1

Verifique se você estava habilitado IPTABLES jail e filtro SSH. Verifique também os logs do f2b - o f2b está tentando banir alguém?

    
por 13.08.2014 / 12:20
0

Eu não sei o que você está usando log / var / log / secure ou /var/log/auth.log mas seja qual for o que você precisa dizer ao fail2ban de qual ele deve ler, também como mencionado se você tiver alterou a porta padrão para ssh (22) e, novamente, você precisa informar o fail2ban e abri-lo no seu firewall (iptables etc). O regex está funcionando como pretendido, ele está combinando as linhas importantes no log ou seja

Aug 13 10:31:35 webhost sshd[15619]: Invalid user china from 128.199.147.79

Os outros que foram listados como ausentes não são importantes para o fail2ban porque eles não forneceram <HOST> ou <IP> , o que o fail2ban precisa para permitir a proibição do cliente. Então o fail2ban está configurado corretamente para o ssh, então se todas as suas definições combinarem com a configuração do seu sistema, então deve ser banido, lembre-se que você tem que acionar os valores 'findtime' e 'maxretry' para serem banidos. Não se esqueça de ' $ fail2ban-client reload ' após quaisquer alterações.

    
por 13.10.2014 / 19:27
0

Da minha experiência com o SysAdmin, tente systemd para backend, e use banaction em vez de action se você estiver usando o CentOS.

Por exemplo,

no seu jail.local

[DEFAULT]

bantime = 4640000

banaction = firewalld-custom

backend = systemd

deixe-me saber se isso funciona.

    
por 27.02.2015 / 10:44
0

Quando me deparei com este problema, foi porque o comando "iptables" não estava funcionando. Eu acredito que eu poderia ter consertado isso mudando a linha

iptables = iptables <lockingopt>

para

iptables = /sbin/iptables <lockingopt>

mas, só para estar no lado seguro, e porque eu estava usando apenas o iptables-allports.conf, eu simplesmente substituí todas as ocorrências de / sbin / iptables naquele arquivo.

    
por 06.04.2017 / 03:07

Tags