Denyhosts vs fail2ban vs iptables- melhor maneira de prevenir logons de força bruta?

Question

Estou configurando um servidor LAMP e preciso evitar o SSH / FTP / etc. tentativas de logon de força bruta do êxito. Eu já vi muitas recomendações para ambos os denyhosts e fail2ban, mas poucas comparações dos dois. Eu também li que uma regra IPTables pode preencher a mesma função.

Por que eu escolheria um desses métodos em detrimento de outro? Como as pessoas no serverfault lidam com esse problema?

    

Answer 1

IIRC, o DenyHosts só assistirá ao seu serviço SSH. Se você precisar dele para proteger outros serviços também, o Fail2ban é definitivamente uma escolha melhor. É configurável observar praticamente qualquer serviço se você estiver disposto a ajustar sua configuração, mas isso não deve ser necessário, pois as versões mais novas do Fail2ban incluem conjuntos de regras que são adequados para muitos daemons de servidores populares. Usar fail2ban em um limite de taxa iptables simples tem a vantagem de bloquear completamente um invasor por um período de tempo especificado, em vez de simplesmente reduzir a rapidez com que ele pode martelar seu servidor. Eu usei o fail2ban com ótimos resultados em vários servidores de produção e nunca vi um desses servidores violados por um ataque de força bruta desde que comecei a usá-lo.

    

Answer 2

melhor maneira de prevenir logons de força bruta?

Não deixe que eles cheguem à sua máquina em primeiro lugar! Há muitas maneiras de impedir tentativas de força bruta antes que elas cheguem ao seu host, ou até mesmo no nível do SSH.

Dito isto, proteger o seu sistema operacional com algo como o fail2ban é uma ótima idéia. O Fail2ban é um pouco diferente do DenyHosts, apesar de jogar no mesmo espaço. O Fail2ban usa o iptables.

link

Fail2ban is similar to DenyHosts ... but unlike DenyHosts which focuses on SSH, fail2ban can be configured to monitor any service that writes login attempts to a log file, and instead of using /etc/hosts.deny only to block IP addresses/hosts, fail2ban can use Netfilter/iptables and TCP Wrappers /etc/hosts.deny.

Existem várias técnicas de segurança importantes que você deve considerar para ajudar a impedir logins de força bruta:

SSH:

• Não permitir que o login da raiz
• Não permitir senhas ssh (usar autenticação por chave privada)
• Não escute em todas as interfaces
• Crie uma interface de rede para SSH (por exemplo, eth1), que é diferente da interface da qual você atende as solicitações (por exemplo, eth0)
• Não use nomes de usuário comuns
• Use uma lista de permissões e permita somente usuários que precisam de acesso SSH
• Se você precisar de acesso à Internet ... Restringir o acesso a um conjunto finito de IPs. Um IP estático é ideal, no entanto, bloqueá-lo em x.x.0.0 / 16 é melhor que 0.0.0.0/0
• Se possível, encontre uma maneira de se conectar sem o acesso à Internet. Dessa forma, você pode negar todo o tráfego da Internet por SSH (por exemplo, com a AWS você pode obter uma conexão direta que contorne a Internet, chamada Direct Connect)
• Use software como o fail2ban para detectar ataques de força bruta
• Certifique-se de que o sistema operacional esteja sempre atualizado, especialmente pacotes de segurança e ssh

Aplicação:

• Certifique-se de que seu aplicativo esteja sempre atualizado, em especial pacotes de segurança
• Bloqueie as páginas 'admin' do seu aplicativo. Muitos dos conselhos acima aplicam-se também à área administrativa da sua aplicação.
• Proteger sua área de administração com senha, algo como o htpasswd para o console da web projetará as vulnerabilidades de aplicativos subjacentes e criará uma barreira extra para a entrada
• Bloquear as permissões de arquivo. "Upload de pastas" são notórios por serem pontos de entrada de todos os tipos de coisas desagradáveis.
• Considere colocar seu aplicativo atrás de uma rede privada e expor apenas seu balanceador de carga de front-end e uma caixa de salto (essa é uma configuração típica no AWS usando VPCs)

Answer 3

OUTRA MANEIRA DE PROTEGER O SSH (usei isso por uma década ou mais) é usar as bibliotecas recentes do iptables nativamente (dependendo da sua distribuição).
Basicamente, ele pode ser usado como porta batendo que é construído em iptables. Isso vai lhe poupar muitas dores de cabeça. Contanto que você possa conectar tcp (telnet é uma maneira. Eu também usei clientes ssh e apontei para eles na porta. Qualquer coisa que faça uma conexão tcp com um número de porta especificado. Eu estou olhando para você, Putty!) Do cliente iniciando a conexão ssh você pode usar isso.

Abaixo está um exemplo que terá o iptables abrir a porta 22 para o seu host quando você fizer telnet do seu host para o servidor na porta 4103. Você pode então usar um telnet para a porta 4102 ou 4104 para fechar a abertura do sed. A razão para ambos 4102 e 4104 é manter um simples escaneamento de tcp da abertura 22. Apenas um tcp connect (telnet) para a porta 4103 permitirá que você entre.

Aproveite!

Ah, e eu sou a favor do Fail2Ban. Mais flexibilidade e eu gosto que a proibição aconteça no iptables ao invés de tcpwrappers.

SSH PORTKNOCKING

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP

    

Answer 4

Eu uso as regras do iptables para limitar as novas conexões a partir do mesmo endereço IP (SSH principalmente, mas também funcionaria bem para o FTP). A vantagem, como eu vejo, sobre o "fail2ban" e outras ferramentas é que a rota do iptables ocorre totalmente no modo kernel e não depende de nenhuma ferramenta do modo de usuário para processar / analisar arquivos de log.

Centenas de logins ssh com falha

Se você puder, limitar os endereços de origem que podem acessar os protcols em questão, obviamente, também ajudará.

Com o SSH, você realmente deve usar a autenticação de certificado e não aceitar senhas de qualquer maneira.

    

Answer 5

Uma coisa a notar sobre o Fail2Ban é que ele parece usar cerca de 10MB a mais de memória do que o DenyHosts. Então, se você estiver em um VPS de 128MB, talvez queira investigar isso. Além disso, o fail2ban pronto para uso é configurado apenas no SSH, o que significa que sem alterações na configuração - o DenyHosts faz a mesma coisa em menos memória.

    

Answer 6

Outra diferença entre o Fail2ban e o Denyhosts é que o Denyhosts pode compartilhar a lista de bloqueio com outros usuários do Denyhosts. Com o Fail2ban, você só pode bloquear IPs que seu servidor tenha visto antes - com o Denyhosts, uma tentativa de força bruta pode nunca chegar ao seu servidor, se alguém o viu, e a lista de bloqueio é baixada para o seu servidor antes do invasor chega ao seu computador.

Outra diferença é que o Fail2ban usa o iptables, enquanto o Denyhosts usa tcpwrappers. Outros mencionaram essa diferença antes, mas há algumas notas secundárias que vale a pena mencionar.

iptables é limitado em quantos endereços IP você pode bloquear eficientemente. Essa é provavelmente uma das razões pelas quais o Fail2ban não tem um mecanismo para compartilhar listas de bloqueio.

Outro efeito é que quando o iptables é substituído por nftables, o Fail2ban provavelmente parará de funcionar ou precisará ser reescrito. O Denyhosts provavelmente continuará trabalhando.

Portanto, ambos têm vantagens e desvantagens. Eu gosto de ambos; para mim, estou usando o Denyhosts porque normalmente só quero proteger o SSH e gosto de compartilhar a lista de bloqueios.

    

Answer 7

denyhosts é para ssh. O fail2ban é mais abrangente (HTTP, FTP, etc.). Ambos usam o iptables nos bastidores.

    

Answer 8

Em vez de mexer com tediosos iptables ou fail2ban config, por que a comunidade aberta não faz todo o trabalho para você e usa o CSF / LFD? Eu posso recomendá-lo acima de todas as outras opções mencionadas. Consulte o link para saber o que ele pode fazer pelos seus servidores. O CSF não requer um painel de controle, ele oferece uma interface de usuário simples, para aqueles que não querem fazer isso por shell. E há muitos scripts de perl não residentes confiáveis e estáveis.

    

Answer 9

O fail2ban não parece ter um mecanismo para reconhecer um login ssh bem-sucedido e redefinir sua contagem de falhas.

O filtro padrão para sshd (pelo menos na minha instalação debian), registra uma contagem de falhas para cada chave ssh que o cliente apresenta que o servidor rejeita. Alguns usuários apresentam muitas chaves em cada login e são bloqueados regularmente, apesar de seus logins terem sido bem-sucedidos depois que algumas chaves foram acessadas.

Como resultado do acima, estou pensando em me afastar do fail2ban. A este respeito, pelo menos, denyhosts é melhor. No entanto, aparentemente, ela não é mais uma boa opção e não é mais suportada em versões mais recentes do Debian (alguma discussão em link )

Eu não tenho uma boa solução aqui.

    

Answer 10

Na verdade, acho que o denyHost é capaz de evitar muitos outros serviços além do serviço sshd. Em seu arquivo de configuração - /etc/denyhosts.conf , existem algumas linhas de código mencionadas:

# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg.   sshd: 127.0.0.1  # will block sshd logins from 127.0.0.1
#
# To block all services for the offending host:  
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE  = sshd

Se definirmos a variável BLOCK_SERVICE como ALL , como acima, podemos assistir ao nosso serviço ssh.

    

Answer 11

Denyhosts versão 3.0: Toda vez que um endereço IP é exibido em um arquivo de log, o Denyhosts abre o arquivo hosts.deny e lê tudo para corresponder ao endereço. Toda vez. Nada é armazenado em cache na memória. Se você tiver um enorme arquivo hosts.deny e estiver sujeito a muitos probes (muitas entradas de arquivo de log), o Denyhosts se torna um ladrão de CPU lendo e relendo o arquivo hosts.deny para cada endereço IP que aparece. Não é bom.

Se você ativar o suporte ao iptables, o Denyhosts criará listas grandes e lentas de endereços IP bloqueados. O Denyhosts não usa ipset ou nftables para criar mapas IP eficientes.