Apenas SSH do Servidor Linux Ultra Seguro

2

Estou configurando um servidor seguro para meu uso apenas para armazenar arquivos criptografados, mas ele precisa ser acessado pela Internet. O próprio servidor está em um local seguro, sem acesso físico, o que é bom, mas estou mais preocupado com o lado da Internet. Estou pensando em usar o Ubuntu sem outro software além do ssh aberto.

Como eu configuro o iptables para bloquear todas as conexões além do ssh? E como eu configuro o ssh aberto para bloquear mais de 2 tentativas fracassadas?

    
por LuminousFlux 11.04.2011 / 19:05

6 respostas

6

iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --name sshattack --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name sshattack --rcheck --seconds 60 --hitcount 4 -j LOG --log-prefix 'SSH REJECT: '
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name sshattack --rcheck --seconds 60 --hitcount 4 -j REJECT --reject-with tcp-reset

Veja, por exemplo, meu artigo sobre o assunto para obter mais detalhes (incluindo onde em seu regras de firewall para colocar isso, o que importa ).

As recomendações dos outros respondentes para permitir que apenas o ssh baseado em chave finamente endosse, porque ele torna inútil a adivinhação de senha de força bruta; mas você poderia ir ainda mais longe e permitir apenas a autenticação de dois fatores, veja meu artigo no yubikey para mais detalhes sobre isso.

    
por 11.04.2011 / 19:09
5

Para segurança Ultra, permita somente entradas SSHKEY em vez de permitir logins com senha.

    
por 11.04.2011 / 19:13
2

Para o SSH, recomendo mudar para a autenticação apenas de chaves. Desativar o acesso root ao daemon e ao período de autenticação de senha. Uma vez que a autenticação baseada em chave é a única maneira de entrar, realmente não há necessidade de "bloquear" como você sugere. Isso é realmente apenas uma maneira eficaz de diminuir a eficácia dos ataques de senha de força bruta.

O site iptables já foi respondido por @MadHatter.

    
por 11.04.2011 / 19:13
2

Se você quiser um pouco de segurança extra acima de outras medidas sutis sugeridas nestas respostas, você pode querer considerar a porta-batida. Port-knocking dá boa proteção contra atacantes que fazem varredura de faixas de números IP para servidores atacarem, o que na minha experiência é de longe o ataque mais comum na vida real.

    
por 11.04.2011 / 20:00
1

Aqui está um guia básico para proteger o Linux ssh . Isso abrange a configuração (e somente o uso) da Autenticação de chave pública, a desativação do login raiz (e a configuração do sudo) e o uso de portas não padrão.

Veja um guia iptables .

    
por 11.04.2011 / 19:16
1

Eu uso o Shorewall para configurar minhas regras do iptables, com uma política padrão para DROP everything e uma única regra para ACCEPT conexões SSH (bem, mais regras / políticas para permitir o tráfego de saída, é claro); O efeito é praticamente idêntico ao que o @MadHatter postou, mas acho que o Shorewall é muito mais fácil de configurar e usar do que as regras diretas do iptables. (Shorewall é uma camada de configuração no topo do iptables, usando uma série de arquivos de configuração mais fáceis de entender para empregar configurações de firewall complexas; não é em si um firewall.)

Em seguida, configure seu servidor SSH para permitir apenas a autenticação baseada em chave, conforme sugerido por praticamente todos - até então, isso deve lhe dizer como é uma boa idéia!

E para satisfazer sua exigência de bloquear tentativas de força bruta, recomendo enfaticamente o Fail2ban, que pode ser configurado para definir quantas tentativas com falha de bloqueio, quanto tempo para proibir o IP ofensivo e pode monitorar a si mesmo até o efeito uma proibição mais longa de invasores persistentes não dissuadidos pelo primeiro nível de resposta (veja o HOWTO no site do Fail2ban "Fail2ban monitoring Fail2ban"). Você pode até mesmo configurar notificações por e-mail sobre as respostas do Fail2ban: Eu configurei essa parte ontem à noite, e até esta manhã já havia banido um possível hacker chinês (baseado no whois do IP, de qualquer forma).

    
por 11.04.2011 / 20:25