Estou configurando um servidor LAMP e preciso evitar SSH / FTP / etc. tentativas de logon de força bruta sejam bem-sucedidas. Eu já vi muitas recomendações para denyhosts e fail2ban, mas poucas comparações das duas. Também li que uma regra do IPTables pode preencher a mesma função.
Por que eu escolheria um desses métodos em detrimento de outro? Como as pessoas na falha do servidor lidam com esse problema?
Respostas:
IIRC, DenyHosts só prestará atenção ao seu serviço SSH. Se você também precisa proteger outros serviços, o Fail2ban é definitivamente uma escolha melhor. É configurável para assistir a praticamente qualquer serviço, se você desejar ajustar sua configuração, mas isso não deve ser necessário, pois as versões mais recentes do Fail2ban incluem conjuntos de regras que são adequados para muitos daemons populares de servidor. O uso do fail2ban em um simples limite de taxa do iptables 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 atacar seu servidor. Eu usei o fail2ban com ótimos resultados em vários servidores de produção e nunca vi um desses servidores violado por um ataque de força bruta desde que comecei a usá-lo.
Não os deixe chegar à sua máquina em primeiro lugar! Existem várias maneiras de interromper as tentativas de força bruta antes que elas cheguem ao seu host ou mesmo no nível SSH.
Dito isto, proteger o sistema operacional com algo como fail2ban é uma ótima idéia. Fail2ban é um pouco diferente de DenyHosts, embora eles joguem no mesmo espaço. Fail2ban usa iptables.
http://en.wikipedia.org/wiki/Fail2ban
Fail2ban é semelhante ao DenyHosts ... mas, diferentemente do DenyHosts que se concentra no SSH, o fail2ban pode ser configurado para monitorar qualquer serviço que grave tentativas de logon em um arquivo de log e, em vez de usar o /etc/hosts.deny, apenas para bloquear endereços / hosts IP , fail2ban pode usar Netfilter / iptables e TCP Wrappers /etc/hosts.deny.
Há várias técnicas importantes de segurança que você deve considerar para ajudar a impedir logins de força bruta:
SSH:
Inscrição:
Eu uso as regras do iptables para limitar a taxa de novas conexões a partir do mesmo endereço IP (principalmente SSH, mas funcionaria bem também para FTP). A vantagem, a meu ver, sobre o "fail2ban" e outras ferramentas desse tipo é que a rota iptables ocorre totalmente no modo kernel e não depende de nenhuma ferramenta do modo usuário para ajustar / analisar arquivos de log.
Centenas de logins ssh com falha
Se você conseguir, limitar os endereços de origem que podem acessar os protocolos em questão ajudará, obviamente, também.
Com o SSH, você realmente deve usar a autenticação de certificado e não aceitar senhas.
Outra ótima maneira de proteger o SSH (usei isso por uma década ou mais) é usar as bibliotecas recentes no iptables nativamente (dependendo da sua distribuição).
Basicamente, ele pode ser usado como porta batendo, embutida no iptables. Isso vai lhe poupar muitas dores de cabeça. Contanto que você possa conectar-se ao tcp (o telnet é uma maneira. Eu também usei clientes ssh e apontei-os para a porta. Qualquer coisa que faça uma conexão tcp com um número de porta especificado. Estou olhando para você Putty!) 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ê telnetar do host para o servidor na porta 4103. Em seguida, você pode usar um telnet para a porta 4102 ou 4104 para fechar a abertura. O motivo dos 4102 e 4104 é impedir que uma varredura TCP simples abra 22. Somente uma conexão TCP (telnet) à porta 4103 permitirá a entrada.
Desfrutar!
Ah, e eu sou a favor do Fail2Ban. Mais flexibilidade e eu gosto que a proibição ocorra no iptables em vez do tcpwrappers.
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
Outra diferença entre Fail2ban e Denyhosts é que os Denyhosts podem compartilhar a lista de bloqueios com outros usuários do Denyhosts. Com o Fail2ban, você só pode bloquear IPs que seu servidor já viu antes - com Denyhosts, uma tentativa de força bruta pode nunca chegar ao seu servidor, se alguém o viu, e a lista de bloqueios é baixada no seu servidor antes do invasor chega ao seu computador.
Outra diferença é que o Fail2ban usa o iptables, enquanto o Denyhosts usa o tcpwrappers. Outros já mencionaram essa diferença antes, mas há algumas notas secundárias que vale a pena mencionar.
O iptables é limitado em quantos endereços IP você pode bloquear com eficiência. Essa é provavelmente uma das razões pelas quais o Fail2ban não possui um mecanismo para compartilhar listas de bloqueios.
Outro efeito é que, quando o iptables é substituído por nftables, o Fail2ban provavelmente parará de funcionar ou precisa ser reescrito. Denyhosts provavelmente continuará funcionando.
Portanto, ambos têm vantagens e desvantagens. Eu gosto de ambos; por mim mesmo, estou usando Denyhosts porque geralmente só quero proteger o SSH e gosto de compartilhar a lista de bloqueios.
Uma coisa a observar sobre o Fail2Ban é que ele parece usar cerca de 10 MB a mais de memória que o DenyHosts. Portanto, se você estiver em um VPS de 128 MB, convém examinar 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 com menos memória.
denyhosts é para ssh. fail2ban é mais abrangente (HTTP, FTP, etc.). Ambos usam iptables nos bastidores.
Em vez de mexer com iptables tediosas ou com a configuração fail2ban, por que não fazer com que a comunidade aberta faça todo o trabalho por você e usar o CSF / LFD? Eu recomendo acima de todas as outras opções mencionadas. Veja http://configserver.com/cp/csf.html para saber o que ele pode fazer pelos seus servidores. O CSF não requer um painel de controle, ele oferece uma interface do usuário simples, para aqueles que não querem fazê-lo por shell. E há muitos scripts perl não residentes confiáveis e estáveis.
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 e que o servidor rejeita. Alguns usuários apresentam muitas chaves em todos os logins e são bloqueados regularmente, apesar de seus logins terem sido bem-sucedidos após a passagem de algumas chaves.
Como resultado do exposto, atualmente estou pensando em me afastar do fail2ban. Pelo menos nesse aspecto, denyhosts é melhor. No entanto, aparentemente não é mais uma boa opção e não é mais suportado em versões mais recentes do debian (alguma discussão em https://www.chrissearle.org/2015/06/06/16/replacing-denyhosts-with-fail2ban-for- debian / )
Eu não tenho uma boa solução aqui.
Na verdade, acho que o denyHost é capaz de impedir 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
portanto, se BLOCK_SERVICEdefinirmos a variável ALLcomo acima, podemos assistir ao nosso serviço ssh.
Denyhosts versão 3.0: sempre que um endereço IP aparece 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 arquivo hosts.deny enorme e estiver sujeito a muitas análises (muitas entradas do arquivo de log), o Denyhosts se tornará um porco da CPU lendo e relendo o arquivo hosts.deny para cada endereço IP que aparecer. Não é bom.
Se você ativar o suporte ao iptables, o Denyhosts criará enormes e lentas listas de endereços IP bloqueados. Denyhosts não usa ipset ou nftables para criar mapas IP eficientes.