Evitando um grande número de tentativas de login malsucedidas de IPs falsificados?

Question 1

Você pode tentar usar o programa Fail2Banhttps://www.fail2ban.org/wiki/index.php/Main_Page

Isso bloqueará automaticamente o IP de origem contra tentativas de login malsucedidas.

Está funcionando muito bem e você também tem muitas opções para configurá-lo. Por exemplo, quantas tentativas antes de ser banido ou por quanto tempo será banido.

Mas você deve considerar se realmente deseja ter o SSH aberto para todo o mundo. Portanto, se sua máquina estiver conectada diretamente à Internet, recomendo usar um firewall, com tudo bloqueado por padrão. E aberto somente para ssh a partir desse IP que você precisa estar aberto.

Answer

Você pode tentar usar o programa Fail2Banhttps://www.fail2ban.org/wiki/index.php/Main_Page

Isso bloqueará automaticamente o IP de origem contra tentativas de login malsucedidas.

Está funcionando muito bem e você também tem muitas opções para configurá-lo. Por exemplo, quantas tentativas antes de ser banido ou por quanto tempo será banido.

Mas você deve considerar se realmente deseja ter o SSH aberto para todo o mundo. Portanto, se sua máquina estiver conectada diretamente à Internet, recomendo usar um firewall, com tudo bloqueado por padrão. E aberto somente para ssh a partir desse IP que você precisa estar aberto.

Question 2

Existem algumas coisas que podem eliminar o risco de segurança de ter o SSH aberto para o mundo.

Fail2ban (já mencionado) é bom. Suporta bloqueio permanente ou apenas por algum tempo no firewall.
Execute o SSH em uma porta estranha de alto nível, algo acima de 8000. Isso não impede nada, mas há uma grande redução no tráfego, já que a maioria dos script kiddies está testando a porta 22.
Certifique-se de que PermitRootLogin em sshd_config não esteja em execução com o valor Sim. Você não precisa de logins root por meio de ssh. Você pode fazer o ssh como um usuário normal e depois su. Dessa forma, são necessárias duas senhas para obter acesso de administrador (a menos que seja Ubuntu ou similar, onde um usuário comum tenha poderes de sudo).
Considere a autenticação de fator duplo. Isso pode ser feito com produtos comerciais como o Duo ou usando algo como o autenticador Google. As etapas para essa configuração viriam do fornecedor.
Envie um e-mail quando houver um login bem-sucedido. Isso permite que você saiba imediatamente se há acesso, antes que um hacker tenha a chance de destruir qualquer proteção que você tenha instalado. Para fazer isso, você precisa de uma linha de sessão adicionada a /etc/pam.d/sshd que seria semelhante a esta:

sessão necessária pam_exec.so /root/scripts/send-ssh-notice.sh

Há um exemplo de script que pode fornecer detalhes em variáveis e está disponível no github:Github hospedado sshlogin_alert.sh

(Sim, forneci um link em minha resposta e por que não? O código do Github é mantido, suporta bifurcações e tem um bom feedback. Minha resposta postada não será revisada por mim nos próximos meses ou anos. Além disso, o crédito deve ser dado o prazo e este usuário do Github fez um bom trabalho.)

Answer

Existem algumas coisas que podem eliminar o risco de segurança de ter o SSH aberto para o mundo.

Fail2ban (já mencionado) é bom. Suporta bloqueio permanente ou apenas por algum tempo no firewall.
Execute o SSH em uma porta estranha de alto nível, algo acima de 8000. Isso não impede nada, mas há uma grande redução no tráfego, já que a maioria dos script kiddies está testando a porta 22.
Certifique-se de que PermitRootLogin em sshd_config não esteja em execução com o valor Sim. Você não precisa de logins root por meio de ssh. Você pode fazer o ssh como um usuário normal e depois su. Dessa forma, são necessárias duas senhas para obter acesso de administrador (a menos que seja Ubuntu ou similar, onde um usuário comum tenha poderes de sudo).
Considere a autenticação de fator duplo. Isso pode ser feito com produtos comerciais como o Duo ou usando algo como o autenticador Google. As etapas para essa configuração viriam do fornecedor.
Envie um e-mail quando houver um login bem-sucedido. Isso permite que você saiba imediatamente se há acesso, antes que um hacker tenha a chance de destruir qualquer proteção que você tenha instalado. Para fazer isso, você precisa de uma linha de sessão adicionada a /etc/pam.d/sshd que seria semelhante a esta:

sessão necessária pam_exec.so /root/scripts/send-ssh-notice.sh

Há um exemplo de script que pode fornecer detalhes em variáveis e está disponível no github:Github hospedado sshlogin_alert.sh

(Sim, forneci um link em minha resposta e por que não? O código do Github é mantido, suporta bifurcações e tem um bom feedback. Minha resposta postada não será revisada por mim nos próximos meses ou anos. Além disso, o crédito deve ser dado o prazo e este usuário do Github fez um bom trabalho.)

Question 3

TRISTE.. TÃO TRISTE?

talvez eu precise "parar meu servidor sshd"?

:(

Talvez exista alguma maneira "SIMPLES" sem instalar software adicional?

Isso ainda não resolve o problema .. mas acho que está no caminho correto?

sudo gedit /etc/ssh/ssh_config 
sudo systemctl restart ssh.service

Aqui está a aparência do "ssh_config" ...

Include /etc/ssh/ssh_config.d/*.conf

Host *
# PermitRootLogin no
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected]
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

Há também alguma modificação no "iptable" que é possível?

Answer

TRISTE.. TÃO TRISTE?

talvez eu precise "parar meu servidor sshd"?

:(

Talvez exista alguma maneira "SIMPLES" sem instalar software adicional?

Isso ainda não resolve o problema .. mas acho que está no caminho correto?

sudo gedit /etc/ssh/ssh_config 
sudo systemctl restart ssh.service

Aqui está a aparência do "ssh_config" ...

Include /etc/ssh/ssh_config.d/*.conf

Host *
# PermitRootLogin no
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected]
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

Há também alguma modificação no "iptable" que é possível?

Evitando um grande número de tentativas de login malsucedidas de IPs falsificados?

Responder1

Responder2

Responder3

informação relacionada