Como proteger o servidor ubuntu dos ataques ssh da bruteforce?

Question

Eu tenho minhas senhas seguras, mas ouvi pessoas reclamando sobre o desempenho de um servidor sendo reduzido drasticamente quando um ataque de força bruta está ocorrendo. Como posso proteger meu servidor Ubuntu 1010 de tais ataques? Existe um perfil apparmor para isso? Ou alguma outra maneira de resolver isso?

    

Answer 1

Existem soluções diferentes. O melhor é usar a autenticação RSA que usa chaves públicas / privadas para autenticar usuários.

Verifique este ótimo manual para diferentes abordagens (incluindo a autenticação RSA): link

Estou usando a terceira solução no meu servidor porque não quero torne isso complicado para meus usuários não técnicos: usando iptables para limitar o número de conexões por minuto que torna os ataques bruteforce ineficientes e ineficazes.

Aqui está a solução que estou usando:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Como mencionado aqui : isso permitirá três conexões de porta 22 de qualquer endereço IP dentro um período de 60 segundos e requer 60 segundos sem tentativas de conexão subseqüentes antes que ele continue a permitir conexões novamente. A opção --rttl também leva em consideração o TTL do datagrama ao combinar os pacotes, de modo a tentar mitigar os endereços de origem falsificados.

Conforme mencionado no guia mencionado, é melhor usar uma lista branca para separar os usuários confiáveis dessas regras:

iptables -N SSH_WHITELIST

adicione hosts confiáveis:

iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT

e depois disso, faça as regras:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

    

Answer 2

Recebo ataques ssh de força bruta nos meus servidores com uma taxa de 1 a 2 por dia. Eu instalei o denyhosts (pacote ubuntu: denyhosts). É uma ferramenta muito simples, mas eficaz para essa finalidade: essencialmente, ele periodicamente verifica seus logs para detectar ataques de força bruta e coloca IPs de onde esses ataques se originam em seu arquivo /etc/hosts.deny. Você não vai ouvir falar deles novamente e sua carga deve ser reduzida consideravelmente. É muito configurável através do seu arquivo de configuração /etc/denyhosts.conf para ajustar questões como quantas tentativas erradas constituem um ataque etc.

Devido a seu funcionamento transparente, você pode facilmente ver o que está acontecendo (notificação por e-mail: 'aha, outro ataque covarde frustrado!') e desfazer erros devido a erros de digitação incorreta de seus usuários.

É claro que tudo o que foi dito anteriormente sobre a mudança para outros métodos de autenticação é válido, mas às vezes seus requisitos não são compatíveis com os de seus usuários.

Além disso, a limitação da taxa de novas conexões no iptables pode ser uma opção melhor, negando o acesso via hosts.deny. Então, dê uma olhada no fail2ban também. Mas se você sabe que a força bruta ssh é a sua principal preocupação (procure manualmente em /var/log/auth.log para determinar isso), use esta ferramenta muito fácil e de baixo impacto.

    

Answer 3

1. Altere a porta sshd para algo não padrão
2. Use knockd para implementar um sistema de portas
3. Use as combinações iptables ' recent e hashlimit para limitar tentativas consecutivas de SSH
4. Não use senhas, mas use as chaves SSH

Answer 4

Antes de mais nada, você deve considerar não usar senhas e usar chaves. Não há necessidade de usar uma senha. Se isso funcionar para você, você pode configurar o servidor OpenSSH para não reagir aos logins de senha.

link

Usar o fail2ban também pode ser uma opção.

link

    

Answer 5

Qual a extensão do servidor exposto na rede? Talvez você possa conversar com o administrador da rede e verificar se é possível monitorar e restringir o acesso à rede ao servidor. Mesmo que os logins da conta sejam seguros, parece que o servidor pode sofrer um simples ataque DoS / DDoS.

    

Answer 6

Uma alternativa ao fail2ban é o CSF: ConfigServer Security & Firewall .

Ele vem com LFD: um Daemon de falha de login que pode detectar várias tentativas de login com falha em vários serviços e bloqueará o endereço IP ofensivo (temporária ou permanentemente).

Ele tem algumas outras opções que podem ajudar contra ataques de inundação e, possivelmente, detectar intrusões.

Desvantagens:

• Você deve usar o CSF como seu firewall para que o LFD faça seu trabalho. Portanto, se você tiver um firewall existente, precisará substituí-lo pelo CSF e passar a configuração pela porta.
• Não é empacotado para o Ubuntu. Você terá que confiar nas atualizações automáticas do configserver.com ou desativar as atualizações automáticas.
• Ouvi dizer que é bastante popular, por isso os invasores inteligentes provavelmente saberão como desabilitar a detecção de invasões antes que eles sejam detectados!

Answer 7

Você pretende permitir o serviço de SSH para o mundo? Ou apenas para membros da equipe em lugares específicos? Minha resposta depende um pouco da gravidade do seu desafio.

Em ambos os casos, uma coisa que você deve fazer é garantir que o servidor SSH não permita logins de senha para o usuário root.

1. Em / etc / ssh / sshd_config, certifique-se de nunca permitir um login raiz, exceto com uma chave SSH.

Nos meus sistemas, eu tenho essa configuração

PermitRootLogin without-password

mas noto que no Ubuntu mais recente eles têm

PermitRootLogin prohibit-password

Se você ler "man sshd_config", eu acho que significa que esta nova "senha proibida" significa a mesma coisa e é certamente mais óbvia no significado. Isso NÃO é padrão em alguns sistemas Linux, mas provavelmente deveria ser.

Agora, sobre o seu problema. O seu servidor do sistema apenas alguns usuários em lugares específicos? Faça isso!

2. edite o /etc/hosts.deny e insira

   ALL: ALL

Em seguida, edite /etc/hosts.allow e liste os números IP ou um intervalo que deseja permitir o uso do SSH. A notação é um pouco confusa, porque se você quiser permitir todos os sistemas com números IP como 111.222.65.101 até 111.222.65.255, coloque uma entrada como essa em hosts.allow

ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.

Essa é uma força bruta, uma solução poderosa. Se seus usuários puderem ser enumerados por faixa de IP, faça isso!

Esta solução existia antes das tabelas IP serem criadas, é muito mais fácil de administrar, mas não é tão boa quanto uma solução de tabelas IP porque as rotinas de tabelas IP detectam os inimigos antes dos programas controlados pelos hosts. allow e hosts.deny. Mas este é um fogo seguro, uma maneira simples de fechar muitos problemas, não apenas do SSH.

Observe o problema que você criou para você mesmo. Se você deseja abrir um servidor FTP, um servidor da Web ou algo assim, será necessário permitir que as entradas nos hosts sejam permitidas.

Você pode alcançar o mesmo propósito básico mexendo com o iptables e o firewall. De certo modo, esta é uma solução preferida porque você está bloqueando inimigos no limite externo. O Ubuntu tem o "ufw" (firewall descomplicado) e o "man ufw" tem muitos exemplos. Eu prefiro ter um bom GUI para percorrer isso, eu não tenho que fazer isso o tempo todo. Talvez outros possam nos dizer se existe um agora.

3. Outros posts aqui sugeriram usar a chave pública SSH apenas para seus usuários. Isso certamente ajudará, ao preço de complexidade e frustração para seus usuários. Em nosso laboratório, existem 15 computadores. Os usuários vão entre computadores. Requerer autenticação de chave SSH causaria um grande incômodo porque as pessoas vão de um computador para o outro.

Outra fonte de frustração acontecerá quando alguns usuários acumularem chaves ssh diferentes para vários servidores. Como tenho chaves SSH para cerca de 12 projetos diferentes, agora o ssh falha porque tenho muitas chaves públicas (Exigindo "ssh -o PubkeyAuthentication = false" ou a criação de uma entrada no arquivo .ssh / config. É um PITA)

4. Se você deve deixar o servidor aberto para o SSH do mundo grande, então definitivamente você deve usar uma rotina de rejeição para bloquear locais que freqüentemente tentam se logar. Existem 2 programas bacanas para isso, os que usamos são denyhosts e fail2ban. Esses programas têm configurações que permitem proibir os infratores por um tempo que você goste.

Em nossos sistemas Centos Linux, notei que eles abandonaram o pacote denyhosts e só oferecem o fail2ban. Eu gostei denyhosts porque construiu uma lista de usuários problemáticos / intervalos de ip e, em seguida, em hosts.deny, essa lista foi anotada. Instalamos o fail2ban em vez disso e está tudo bem. Meu entendimento é que você prefere bloquear esses usuários ruins na borda externa do servidor, portanto, os bloqueadores baseados em tabelas ip, como o fail2ban, são realmente melhores. Denyhosts trabalha no nível secundário, depois que os inimigos passaram do iptables eles são rejeitados pelo daemon sshd.

Em ambos os programas, é um pouco entediante tirar os usuários da prisão se eles esquecerem suas senhas e tentar algumas vezes fazer o login. É um pouco difícil levar as pessoas de volta quando cometem erros de login. Você teria adivinhado que haveria uma GUI de apontar e clicar onde você poderia apenas apontar e deixar as pessoas de volta, mas não é assim. Eu só tenho que fazer isso a cada poucos meses e esquecer como entre os tempos, então eu escrevi instruções para mim na minha página web link