Fail2Ban no CentOS 6.5 Nunca proíbe

4

Ambiente: * CentOS 6.5 * Fail2Ban 0.8.14-1 * date produz a data correta

Comportamento: O Fail2ban é iniciado com êxito, mas não cria blocos do iptables após tentativas de login com SSH incorreto. Estou preocupado apenas com o SSH neste momento. Eu tentei reinstalar usando este guia: link

O Fail2Ban costumava funcionar - mas, por meio de atualizações do sistema, parece que parou de funcionar. Se eu correr

sudo service fail2ban restart

Eu recebo um e-mail dizendo que a prisão parou e outro e-mail dizendo que a prisão foi iniciada, então parece que o fail2ban está funcionando e funcionando.

Meu arquivo /etc/fail2ban/jail.local inclui a entrada:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
       sendmail-whois[name=SSH, [email protected], [email protected], sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

Meu endereço IP não está listado na delcação ignoreip. Estou usando bantime padrão de 600, findtime de 600 e maxretry de 3.

Quando vejo / var / log / secure, vejo muitas tentativas com falha:

Sep 30 00:17:02 nebo unix_chkpwd[3796]: password check failed for user (root)
Sep 30 00:17:02 nebo sshd[3794]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.173.26.189  user=root

iptables -L parece reportar que o fail2ban tem uma cadeia:

Chain fail2ban-SSH (2 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

Meu melhor convidado atual é que a ação do sshd em actions.d / sshd.conf está usando uma expressão regular para examinar o arquivo de log, mas não corresponde à sintaxe atual do log do CentOS para uma tentativa banida .

O tempo é insync por: Por que as falhas de bloqueio do fail2ban não são?

Ran fail2ban-regex para testar minha teoria e parece que eu posso estar no caminho certo:

[isdept@nebo action.d]$ sudo 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: 0 total

Ignoreregex: 0 total

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

Lines: 22655 lines, 0 ignored, 0 matched, 22655 missed
Missed line(s): too many to print.  Use --print-all-missed to print all 22655 lines

Não sei ao certo como modificar os padrões de regex para corrigir isso (se esse for o problema), mas fico surpreso ao descobrir que não encontrei uma correção fácil, já que o CentOS é comum. Eu ficaria feliz em fornecer qualquer informação adicional. Obrigado por qualquer dica ou ponteiros que você possa dar!

Por segurança - estou atualmente desativando o acesso público a esse host.

    
por SteadH 01.10.2014 / 16:45

4 respostas

3

Bem, eu não sou mestre de regex (ou até mesmo novato), mas consegui fazê-lo funcionar adicionando:

^.*authentication failure;.*rhost=<HOST>

para filters.d / sshd.conf. Isso fez isso e eu bani com sucesso meu primeiro hospedeiro. Se algum especialista em regex quiser entrar em contato, eu ficaria muito agradecido. Tenho certeza de que há um caso que estou perdendo nesta breve expressão que falharia em um determinado caso.

Obrigado!

    
por 09.10.2014 / 00:21
2

@SteadH Na sua postagem inicial, você tem isto:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
       sendmail-whois[name=SSH, [email protected], [email protected], sendername="Fail2Ban"]
logpath  = /var/log/secure
maxretry = 5

[ssh-iptables] : sendo o nome / referência do filtro e

filter = sshd : sendo o arquivo com o filtro regex em /filter.d (sshd.conf)

Então, sua última postagem você está editando o sshd-iptables.conf? Você fez sua verificação fail2ban-regex no sshd.conf? Qual arquivo você está usando? e qual existe ou existem ambos. Eu posso te ajudar com um padrão de regex, mas eu preciso ter certeza de que estou olhando para o padrão certo para combinar.

    
por 13.10.2014 / 21:17
1

Estou trabalhando no mesmo problema hoje, também no centos 6.5.

no meu caso, o arquivo distro é chamado filters.d / sshd.conf, e não filters.d / sshd-iptables.conf como você escreveu. Não tenho certeza porque o seu e o meu seriam diferentes. mas de qualquer forma eu acredito que o problema é idêntico.

uma entrada de exemplo do meu secure.log é esta:

Oct 11 11:11:11 myhostname sshd[12345]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=1.2.3.4

o failregex correspondente mais próximo no distro filters.d / sshd.conf é este:

^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from <HOST>( via \S+)?\s*$

isso claramente não corresponderá ao exemplo acima por causa das strings "from" e "via" e não da string "rhost=". minhas tentativas de consertar isso estão listadas abaixo.

  • primeiro mod, não corresponde:

    ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    
  • segundo mod, não combinou:

    ^%(__prefix_line)[aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    
  • terceiro mod, correspondido:

    [aA]uthentication (?:failure|error); .* rhost=<HOST> .*$
    

a subexpressão __prefix_line regex vem de filters.d / common.conf e é uma grande tentativa de tentar corresponder a todas as permutações possíveis de formatos de prefixo de entrada de log linux conhecidos, mas infelizmente precisa de alguns ajustes para a nossa situação particular do centos 6.5. Eu posso dar uma olhada nisso, mas uma primeira olhada nos regexes em comum.conf faz minha cabeça doer. a regex menos complexa sem __prefix_line pode ser suficiente.

    
por 11.10.2014 / 18:50
0

@SteadH com base na sua solução, descobri a raiz do problema. Os filtros sshd terminam com '$' (dólar) que corresponde ao fim da linha, em algumas expressões regulares (notei que sua correção não funcionou). Bem, eu apaguei os dólares e a viola! começou a funcionar! Eu acho que pode haver algum misconfig em algum lugar na coragem deste que faz com que o '$' não funcione. De qualquer forma, tente corrigir isso.

    
por 23.02.2016 / 22:09