Impedindo ataques de força bruta contra ssh?


49

Qual ferramenta ou técnica você usa para evitar ataques de força bruta contra sua porta ssh. Percebi nos meus logs de segurança, que tenho milhões de tentativas de efetuar login como vários usuários através do ssh.

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

Respostas:


25

Aqui está um bom post sobre Rainer Wichmann sobre esse assunto .

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

  • Senhas fortes
  • Autenticação RSA
  • Usando 'iptables' para bloquear o ataque
  • Usando o log sshd para bloquear ataques
  • Usando tcp_wrappers para bloquear ataques
  • Porto batendo

39

Eu uso o fail2ban que bloqueará um IP após várias tentativas com falha por um período de tempo configurável.

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


4
Fail2ban é excelente. Era simples para estendê-lo para monitor / var / log / maillog e obtê-lo para proibir spammers persistentes de bater o meu servidor de correio
Dave Cheney

Fail2ban pode ser combinado com uma cadeia de iptables que envia tráfego tcp para o TARPITdestino, se você estiver se sentindo desagradável (de xtables-addons).
Tobu



15

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


11
Se, é claro, seu sistema aguenta.
C. Ross

13
Segurança através da obscuridade, eficaz todas as vezes.
5289 Chris Ballance

11
Eu não me importaria de mudar tanto a porta, mas aprendi que a maioria dos firewalls (exceto os meus) tende a bloquear todas as portas que não sejam as comuns (80,22, 443, etc.). Se estou atrás desses firewalls, não consigo acessar meu servidor doméstico nessa porta fora do padrão. Para mim, isso não é possível.
27509 luto

@grieve então mude nosso firewall para deixar essa porta sair?
Rory

@ Roy Estou falando de firewalls diferentes daqueles que possuo. Por exemplo, se eu quiser ssh na minha máquina doméstica da Starbucks, o firewall deles bloqueará a porta de saída. Eu não posso mudar isso. (Acabei de usar a Starbucks como exemplo. Não tenho idéia de quais portas elas realmente bloqueiam ou não).
lamentar

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 públicos ssh que você está mantendo e se você pode restringir seus critérios gerais de conexão, pode ser uma configuração mais simples e sustentável para limitar o acesso a alguns hosts externos.

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


2
A lista de permissões é extremamente importante se você estiver fazendo algum tipo de lista negra, a menos que queira ser bloqueado.
21909 Ryaner

2
+1 para lista de permissões proativa.
5119 Chris Ballance

3
+1 por ter a melhor resposta absoluta. Essas duas coisas são as únicas medidas razoáveis ​​e são realmente muito eficazes. Sozinho vale a pena, e os dois juntos mais. Boo nas outras respostas defendendo a segurança através da obscuridade!
Dwc 23/05/09

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

Eu poderia ser mal-entendido alguma coisa, mas muitos navegadores tradicionais conectar entre 4-6 conexões de cada vez - embora os HTTP conjuntos padrão de TI em 2.
Joshua Enfield

11
Sim, isso seria um problema se você estivesse tentando limitar a porta 80. Você não está se conectando ao ssh com seu navegador da Web, e as sessões ssh são sessões de longa duração que mantêm estado, e não sessões sem estado de curta duração como http. Paralelamente sessões ssh como essa não fazem sentido. Isso não quer dizer que não haja um uso específico de ssh que isso possa quebrar, mas é raro.
sherbang

Esta solução não é tão boa se, como eu, você estiver servindo o Subversion via ssh. Uma única consulta SVN pode fazer um grande número de conexões em rápida sucessão. Se você estiver fornecendo esse serviço, poderá usar um segundo serviço sshd em outra porta ou colocar IPs conhecidos na lista de permissões. Estou pensando em usar fail2ban ou sshdfilter para capturar ataques óbvios na primeira vez, sem punir meus usuários legítimos.
arroz

bom saber esta opção também ...
ZEE

6

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

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

por exemplo,

AllowUsers user1 user2@host.example.com

Isso reduzirá o espaço de pesquisa e evitará os usuários antigos que foram deixados acidentalmente ou ativados (embora, é claro, eles 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.


3

Use algo parecido com o PF:

A tabela <ssh-brute> persiste o
bloco no log rápido do rótulo ssh_brute
transfere o $ ext_if proto tcp para ($ ext_if) o estado do módulo ssh da porta \
(max-src-conn-rate 3/10, sobrecarga global de descarga)


2

Bater à porta é uma maneira bastante sólida de manter esse tipo de coisa de fora. Um pouco complicado, às vezes irritante, mas definitivamente faz o problema desaparecer.


Eu tentei isso e os usuários acham irritante. Se é apenas uma ou duas pessoas, esta poderia ser uma boa opção, e seria quase eliminar ataques de força bruta
Brent

2

O contexto é importante, mas eu recomendaria algo assim:

  • Como você está usando o FreeBSD, considere executar o firewall PF e usar seus sólidos recursos 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 essa caixa precisar ser acessada do mundo exterior, considere usar uma regra PF rdr para não permitir o tráfego para a porta 22, mas para redirecionar alguma porta obscura para ela. Ou seja, você precisa se conectar à porta 9122 em vez de 22. É obscuro, mas mantém os aldravas afastados
  • considere mudar apenas para autenticação baseada em chave, tornando inúteis os ataques de dicionário

2

Além da sugestão de limitação de taxa de Sherbang , a duração do atraso é importante. Ao aumentar o atraso entre os grupos de três tentativas de login de 2 minutos para 20 minutos, o número de endereços IP diferentes que fizeram mais de três tentativas de login diminuiu, comparando períodos de duas semanas em uma máquina minha, de 44 tentativas para 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 ...


1

Eu simplesmente não me importo com isso. Deixe que eles se afastem no porto, eles não vão usar uma força bruta.


-1 Já ouviu falar em ataques DoS?
5119 Chris Ballance

8
Sim, porque o SSH é o único serviço suscetível a ataques de força bruta. Se você tem uma porta aberta para a Internet, ela pode ser usada para esquentar sua máquina. Você, provavelmente, colocar o servidor HTTP em portas estranhas também, e atrás da porta batendo, para "evitar ataques DoS" ...
womble

1

instale o OSSEC. não apenas monitora logins repetidos, mas também insere um bloco temporário com iptables para o ip incorreto. E no final, ele enviará um relatório informando os detalhes. ele registra tudo, o que é legal. Alguém já tentou mais de 8000 nomes de login para fazer login. Analisei os logs e consegui uma boa lista de usuários;)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.