Acabei de receber uma instância do Ubuntu no Linode. Para proteger o SSH, eu instalei o fail2ban (usando apt-get ), mas tive um problema: fail2ban continuou proibindo o meu IP (por durações limitadas, felizmente) mesmo que eu estivesse digitando a senha correta. Por isso, removi fail2ban e instalei denyhosts . Mesmo problema, mas mais grave: parece que toda vez que eu SSH entrar, meu IP é banido. Eu removo de /etc/hosts.deny , reinicio denyhosts e faço login novamente, e meu IP é banido novamente.
A única explicação que posso pensar é que eu tenho sido SSH-ing como root (sim, sim, eu sei); talvez algo esteja definido em algum lugar que bloqueie qualquer um que tenha SSH-es como root, mesmo se eles fizerem login com sucesso? Isso parece bizarro para mim. Alguma ideia? (A lista branca do meu IP é uma correção temporária. Eu não quero poder apenas fazer logon de um IP.)
Acredito que vi alguém dizer que alguns desses aplicativos contam logins com falha como uma tentativa de força bruta. Você tem um agente ssh rodando com chaves nele? Conectar-se a esse conjunto oferecerá todas as chaves antes de voltar para a senha, e isso pode ser o motivo. Tente definir o nível de log do sshd mais alto e verifique os logs do fail2ban / denyhost.
Editar: aqui é a fonte original que me deu uma dica, com uma maneira de corrigir isso.
por favor reveja os seguintes links:
se você quiser eliminar toda a idéia do fail2ban e do denyhosts, faça o que Nathan Powell abaixo diz, mude da porta 22 para algo mais obscuro
também mais algumas ideias:
iptables: o exemplo a seguir descartará as conexões de entrada que fazem mais de duas tentativas de conexão na porta 22 em dez minutos:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW
-m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW
-m recent --update --seconds 60 --hitcount 4 -j DROP
login baseado em chave
aldrava de porta (knockd)
se você estiver sshing como root por um motivo específico, espero que você tenha as chaves configuradas. Eu recomendaria essas alterações para o arquivo sshd_config :
PermitRootLogin without-password
AllowUsers [email protected]
para bloquear qual host você pode usar ssh em seu servidor como root.
se você não precisa de ssh como root, o que é uma boa chance, você deve configurar um usuário normal para si mesmo, criar um grupo ssh ou algo assim, configurar chaves para o usuário , adicione-os ao grupo ssh e adicione AllowGroups ssh a sshd_config
, em seguida, forneça ao usuário sudo acesso executando visudo como root e adicionando a linha: user ALL=(ALL) ALL , que permitirá o acesso do usuário root, com a senha do usuário, ao executar sudo commandX
Certificar-se de que o sshd esteja bloqueado seria minha primeira prioridade, especialmente se o login root tiver que ser permitido.
mesmo sendo executado em uma porta oculta, os kiddies avançados encontrarão você com a varredura de porta.
Se você estiver aberto para voltar ao fail2ban, sempre poderá usar a diretiva ignoreip no jail.conf . Por exemplo:
ignoreip = 127.0.0.1 192.168.1.0/32
Desta forma, você não fica bloqueado com a sua digitação desleixada ;-) Isso também significa que as pessoas não podem bloqueá-lo, falsificando o seu IP (embora com qualquer tráfego TCP que não é uma grande preocupação).
Se o sshd estiver configurado para o nível de log do VERBOSE (ou superior), colocará a frase '... Failed none ...' no log do sistema sempre que um usuário efetuar login com êxito. Por padrão, o fail2ban está configurado para contar como uma falha. Eu curei o problema definindo o nível de log do sshd de volta para INFO.
Para mais detalhes, consulte a minha resposta a esta pergunta fail2ban me bane após uma série de logins * bem-sucedidos
Eu acho que se você é verde o suficiente para não ser capaz de resolver isso lendo o arquivo de configuração e examinando os logs, você deve mirar um pouco mais baixo até obter alguma experiência.
Se você estiver otimizando para impedir ataques de força bruta comuns, altere a porta em que o sshd é executado. Isso cuidará da grande maioria deles.