Evitando ataques de força bruta contra o ssh?

49

Qual ferramenta ou técnica você usa para evitar ataques de força bruta contra sua porta ssh? Percebi em meus registros de segurança que tenho milhões de tentativas de fazer login como vários usuários por meio do ssh.

Isso está em uma caixa do FreeBSD, mas imagino que seria aplicável em qualquer lugar.

    
por grieve 04.05.2009 / 19:46

14 respostas

25

Aqui está uma boa postagem sobre esse assunto de Rainer Wichmann.

Explica os prós e contras dos métodos para fazer isso:

  • Senhas strongs
  • Autenticação RSA
  • Usando o 'iptables' para bloquear o ataque
  • Usando o log sshd para bloquear ataques
  • Usando o tcp_wrappers para bloquear ataques
  • Batida de porta
por 05.05.2009 / 18:53
39

Uso o fail2ban , que bloqueia um IP após várias tentativas malsucedidas por um período de tempo configurável.

Combine isso com o teste de força da senha (usando john (John the Ripper)) para garantir que os ataques de força bruta não sejam bem-sucedidos.

    
por 04.05.2009 / 19:53
24

A pequena coisa que você pode fazer é usar algo como o DenyHosts:

link

Ele usa o built-in hosts.allow / hosts.deny para bloquear os usuários de SSH.

    
por 04.05.2009 / 20:06
16
  • Alterar a porta usada (como Trent mencionado)
  • Requerer chaves de criptografia em vez de senhas. link
  • ips do atacante da Lista Negra
  • Usuários conhecidos da Whitelist para impedir a inclusão de listas negras acidentais. (como Samiuela mencionou)
por 04.05.2009 / 19:53
15

Uma das maneiras mais fáceis de evitar esses ataques é alterar a porta que o sshd escuta em

    
por 04.05.2009 / 19:48
12

Como Chris aponta, use chaves de criptografia em vez de senhas.

Adicione a isso:

  • use uma lista de permissões sempre que possível.

Quantas pessoas ou locais (com IPs públicos flutuantes) você realmente precisa acessar suas conexões ssh públicas?

Dependendo do número de hosts ssh públicos que você está mantendo e se você pode restringir seus critérios gerais de conexão, pode ser uma configuração mais simples e segura para limitar o acesso a alguns hosts externos.

Se isso funcionar para você, isso pode realmente simplificar sua sobrecarga de administração.

    
por 05.05.2009 / 09:37
11

Além das outras boas sugestões, uma coisa realmente fácil de fazer é limitar as conexões de entrada de taxa. Limite de 3 conexões por minuto por IP:

iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
    
por 23.05.2009 / 19:36
6

Use a opção "AllowUsers" em sshd_config para garantir que apenas um pequeno conjunto de usuários possa efetuar login. Todos os outros serão rejeitados, mesmo que o nome de usuário e a senha estejam corretos.

Você pode até restringir os usuários a logins de um determinado host.

por exemplo,

AllowUsers user1 [email protected]

Isso reduzirá o espaço de pesquisa e evitará os usuários antigos que foram acidentalmente deixados por perto ou habilitados (embora, obviamente, devam ser desativados de qualquer maneira, essa é uma maneira fácil de impedir que eles sejam usados para uma entrada baseada em SSH ).

Isso não impede totalmente os ataques de força bruta, mas ajuda a reduzir o risco.

    
por 21.05.2009 / 11:04
3

Use algo parecido com o PF:

tabela < ssh-brute > persistir
bloquear em log rápido do rótulo ssh_brute
passar em $ ext_if proto tcp para ($ ext_if) port ssh modular estado \
        (max-src-conn-rate 3/10, sobrecarga de limpeza global)

    
por 27.05.2009 / 21:20
2

Bater o porto é uma maneira bastante sólida de manter esse tipo de coisa. Um pouco complicado, às vezes irritante, mas definitivamente faz com que o problema desapareça.

    
por 04.05.2009 / 19:52
2

O contexto é importante, mas eu recomendo algo assim:

  • Como você está usando o FreeBSD, considere executar o firewall PF e usar seus recursos sólidos de limitação de taxa de conexão. Isso permitirá que você envie os forçadores brutos para uma lista negra se eles se conectarem com frequência
  • Se esta caixa deve ser acessada do mundo externo, considere o uso de uma regra PF rdr para não permitir o tráfego para a porta 22, mas redirecionar alguma porta obscura para ela. Ou seja, você precisa se conectar à porta 9122 em vez de 22. É obscuro, mas mantém as alças afastadas
  • considere mudar apenas para autenticação baseada em chave, tornando os ataques de dicionário inúteis
por 05.05.2009 / 17:48
2

Além da sugestão de limitação de taxa do sherbang , a A duração do atraso é importante. Aumentando o atraso entre grupos de 3 tentativas de login de 2 minutos a 20 minutos, o número de endereços IP diferentes que fizeram mais de três tentativas de login caiu, comparando dois períodos de uma semana em uma máquina minha, de 44 tentativas a 3 Nenhum desses três endereços continuou tentando por mais de 11 horas.

Muito anedótico, mas o auth.log se tornou muito mais legível para mim ...

    
por 19.04.2010 / 15:16
1

Eu simplesmente não me importo com isso. Deixe-os grudarem no porto, eles não vão forçar uma chave.

    
por 05.05.2009 / 00:36
1

instale o OSSEC. não só monitora logins repetidos, ele irá inserir um bloco temporário com o iptables para o ip ofensivo. E no final ele enviará um relatório informando os detalhes. registra tudo, o que é legal. Somone uma vez tentou mais de 8000 nomes de login para fazer login. Eu analisei os logs e obtive uma boa lista de usuários fora do negócio;)

    
por 27.05.2009 / 21:03