Fail2Ban: já foi banido?

Tenho o Fail2Ban em execução no meu servidor Centos. (Configuração abaixo)

No meu var / log / messages , notei algo realmente estranho:

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

Eu configurei o Fail2Ban para adicionar o IP banido ao iptables.

Meu jail.conf:

[postfix]

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

Meu 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 =

Minha pergunta é como alguém que já foi bloqueado iptablesainda pode se conectar ao servidor?

A prisão recidiva recomendada na outra resposta aqui não resolveu o problema para mim. No entanto, eu consertei isso, então aqui está o meu método, caso ajude outras pessoas.

Fail2ban bloqueia apenas o TCP por padrão. Pelo menos com a minha configuração, notei que a mensagem "já banida" estava aparecendo quando os robôs voltaram para tentar a porta bloqueada pelo UDP.

Para corrigir esse problema, diga ao Fail2ban para bloquear a porta em todos os protocolos, em vez de apenas no TCP. Você precisará fazer essa alteração no /etc/fail2ban/jail.conf e na seção [Init] de todas as ações que você estiver usando em /etc/fail2ban/action.d/ .

Mude isso:

# Default protocol
protocol = tcp

Para:

# Default protocol
protocol = all

Em seguida, desabilitei as solicitações de eco do ICMP para que os IPs bloqueados não tivessem como acessar o servidor:

1. nano /etc/sysctl.conf

2. Adicione estas duas linhas:

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

3. Saia e salve o arquivo.
4. Execute sysctl -p para que a alteração entre em vigor.

Depois disso, execute o fail2ban-client recarregar e você não deverá mais ver essas mensagens "já proibidas", a menos que seja spam por um IP que receba algumas tentativas de acesso antes que o bloqueio entre em vigor.

Além disso, é importante bloquear todas as portas para todos os infratores, e não a porta que eles estavam tentando acessar, usando a ação iptables-allports em cada uma das cadeias. Caso contrário, eles podem acionar outra cadeia e acabar como "já banidos" nos logs.

Se você observar a saída de iptables-save, verá que as fail2bancadeias estão configuradas para avaliar pacotes de acordo com as regras definidas pelos filtros, por exemplo:

: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

O tráfego ainda chega ao servidor antes que as outras regras de roteamento sejam aplicadas e o tráfego seja rejeitado. fail2banainda vê esse tráfego inicial e é por isso que você vê as mensagens "já banidas". Além disso, há um filtro especial para reincidentes ( /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

Isso acontecerá se o endereço IP que você está banindo não for realmente o endereço IP do cliente que está se conectando ao servidor. Por exemplo, se o seu servidor estiver atrás de um balanceador de carga ou proxy.

Levei um bom tempo para descobrir isso recentemente. O problema é que os logs foram configurados para capturar o X-Forwarded-Forendereço IP, em vez do endereço de origem real, que no meu caso era o balanceador de carga.

Nesse caso, o fail2ban não ajuda muito, pois a proibição do IP ofensivo acabaria bloqueando todo o tráfego.

Quero contribuir com meu próprio problema e solução com mensagens "já banidas". Como você escreveu, eu tinha centenas deles em questão de minutos, enquanto o atacante já deveria ter sido banido.

Antes de começar, aqui está o meu sistema:

• Plesk 12
• Centos 7
• Módulo Plesk instalado, operando e configurando fail2ban para mim

Quando instalei o OpenVPN no meu servidor de raiz, mudei o firewall para iptables. Isso pode ter me causado esse problema, mas, além disso, meu sistema estava praticamente intocado e bem instalado recentemente (o Strato rootserver sugeriu a instalação da imagem).

Se você tiver esse problema, consulte /etc/fail2ban/jail.d/00-firewalld.conf para obter uma linha parecida com esta:

banaction = firewallcmd-ipset

Desde o momento em que comentei isso, salvei o arquivo e reiniciei fail2ban.service, tudo estava bem com o fail2ban. Não há mais mensagens

Não sou especialista, mas espero fornecer a resposta certa. Se isso funcionar para você, entre em contato!

Minha pergunta é como alguém que já foi bloqueado no iptables ainda pode se conectar ao servidor?

Ele se conectou ao servidor apenas uma vez, mas nessa conexão tentou enviar vários emails para caixas de correio provavelmente inexistentes (como info@domain.com, sales@domain.com, tech@domain.com etc.)

Você configurou seu filtro postfix para banir essas tentativas, para que o IP seja banido após o X tentar. O cliente já pode estar desconectado do postfix, mas como o postfix pode não ter concluído o processamento de todos os seus emails, o fail2ban pode detectar outra tentativa do mesmo cliente quando o postfix processa seus emails e, portanto, você já baniu o endereço da mensagem. É por causa de como a fila de postfix funciona.

Minha pergunta é como alguém que já foi bloqueado no iptables ainda pode se conectar ao servidor?

Incrível boa pergunta. Eu estava pesquisando se minhas regras de firewall não estavam funcionando, mas iptables --list-rulescorrespondiam exatamente a outro servidor de produção com fail2ban em funcionamento.

A solução surpreendente foi adicionar a porta 8080 às portas bloqueadas, pois eu ainda estava acessando a página de login pelas portas de desenvolvimento.

Portanto, a correção na minha situação é que esse problema foi uma adaptação bastante simples da minha 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

consulte /unix//a/525798/22315

você provavelmente está perdendo a porta 587 da linha "port =" e pode verificar o arquivo de configuração do postfix ou faça "lsof -i: 587" para descobrir diretamente se o postfix foi configurado para abrir essa porta.