Como proteger o servidor ubuntu de ataques bruteforce ssh?

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

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 abordagens diferentes (autenticação RSA incluída): http://www.la-samhna.de/library/brutessh.html

Estou usando a terceira solução no meu servidor porque não quero complicar para meus usuários não técnicos: usando iptablespara 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

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

Conforme declarado no guia mencionado, é melhor usar uma lista branca para separar 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 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

Recebo ataques ssh de força bruta nos meus servidores com uma taxa de 1 a 2 por dia. Eu instalei denyhosts (pacote ubuntu: denyhosts). É uma ferramenta muito simples, mas eficaz para esse propósito: essencialmente, ele varre seus logs periodicamente para detectar ataques de força bruta e coloca IPs de onde esses ataques se originam no seu arquivo /etc/hosts.deny. Você não os ouvirá novamente e sua carga deverá 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 ao seu funcionamento transparente, você pode ver facilmente o que está acontecendo (notificação por e-mail: 'aha, outro ataque covarde frustrado!') E desfazer erros devido a seus usuários digitarem suas senhas repetidamente.

Obviamente, tudo o que foi dito anteriormente sobre a mudança para outros métodos de autenticação é válido, mas às vezes seus requisitos discordam dos de seus usuários.

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

1. Altere a porta sshd para algo fora do padrão
2. Use knockdpara implementar um sistema de porta batendo
3. Use iptables ' recente hashlimitcorrespondências para limitar tentativas consecutivas de SSH
4. Não use senhas, mas use chaves SSH

Antes de tudo, 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 nos logins de senha.

https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html

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

https://help.ubuntu.com/community/Fail2ban

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 da rede ao servidor. Mesmo que os logins da conta sejam seguros, parece que o servidor pode sofrer ataques simples de DoS / DDoS.

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

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

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

Desvantagens:

• Você deve usar o CSF ​​como seu firewall para que o LFD faça seu trabalho. Portanto, se você possui um firewall existente, precisará substituí-lo pelo CSF ​​e portar sua configuração.
• Não está empacotado para o Ubuntu. Você precisará confiar nas atualizações automáticas de configserver.com ou desativar as atualizações automáticas.
• Ouvi dizer que é bastante popular, portanto, invasores inteligentes provavelmente saberão como desativar a detecção de invasões antes de serem detectados!

Você pretende permitir o serviço 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 qualquer um dos casos, uma coisa que você deve fazer é garantir que o servidor SSH não permita logins de senha para o usuário root.

1. No arquivo / etc / ssh / sshd_config, nunca permita 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", acho que significa que essa nova palavra "proibir senha" significa a mesma coisa e certamente tem um significado mais óbvio. Isso NÃO é o padrão em alguns sistemas Linux, mas provavelmente deveria ser.

Agora, sobre o seu problema. O servidor do sistema apenas alguns usuários em locais específicos? Fazem isto!

2. edite /etc/hosts.deny e insira

   TUDO TUDO

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

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

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

Essa solução existia antes da criação de tabelas IP, é (acho) 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 identificarão inimigos mais cedo do que os programas conduzidos por hosts.allow e hosts .negar. Mas este é um caminho certo, uma maneira simples de resolver muitos problemas, não apenas do SSH.

Observe o problema que você cria para si mesmo. Se você deseja abrir um servidor FTP, servidor Web ou outros enfeites, precisará permitir entradas nos hosts.

Você pode atingir o mesmo objetivo básico, mexendo no iptables e no firewall. Em certo sentido, essa é uma solução preferida porque você está bloqueando os inimigos no limite externo. O Ubuntu tem "ufw" (firewall não complicado) e "man ufw" tem muitos exemplos. Prefiro ter uma boa interface gráfica para percorrer isso, não preciso fazer isso o tempo todo. Talvez outros possam nos dizer se existe um agora.

3. Outras postagens aqui sugeridas usando 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. Exigir autenticação de chave SSH causaria um grande aborrecimento, pois as pessoas passam 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 criação de uma entrada no arquivo .ssh / config. É uma PITA)

4. Se você deve deixar o servidor aberto para SSH do grande mundo, definitivamente você deve usar uma rotina de rejeição para bloquear locais que frequentemente tentam efetuar login. Existem 2 bons programas para isso, os que usamos são denyhosts e fail2ban . Esses programas têm configurações que permitem banir os infratores pela duração que você desejar.

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

Nos dois programas, é um pouco tedioso tirar os usuários da prisão se eles esquecerem sua senha e tentarem fazer login algumas vezes. É um pouco difícil recuperar as pessoas quando cometem erros de login. Você imaginaria que haveria uma GUI de apontar e clicar em que você poderia simplesmente apontar e deixar as pessoas entrarem novamente, mas não é assim. Eu só tenho que fazer isso a cada poucos meses e esquecer o que acontece entre os horários, então escrevi instruções para mim na minha página da web http://pj.freefaculty.org/blog/?p=301