Existem outras maneiras de proteger as conexões SSH além do firewall e das chaves RSA?

Question

Às vezes, não tenho um IP estático e preciso administrar meu servidor da web remotamente. Estou procurando por qualquer camada adicional de proteção que eu possa adicionar para tornar a abertura 22 mais segura.

Atualmente, desativei o login por senha do root por meio do SSH. Requer a chave RSA para fazer login (a chave privada é armazenada em um smart card usb).

Existe algum risco conhecido com a minha configuração se a porta 22 foi aberta ao público? Além da porta 22, o iptables tem apenas a porta 80 e a porta 443 abertas ao público.

Estou usando um computador Windows para conectar ao Centos 6 Linux com Putty.

Há alguma declaração adicional que eu possa adicionar ao firewall ou à configuração SSH para limitar ainda mais o acesso à porta 22 apenas a meu computador específico, de modo que a porta não apareça aberta para portas de verificação de pessoas? Estou usando o iptables para o firewall atualmente.

    

Answer 1

Sua configuração existente parece muito segura. No entanto, existem outras coisas que você pode usar para restringir o acesso.

A batida de porta pode ser usada para manter a porta fechada a maior parte do tempo. Isso é implementado usando iptables . Existem daemons que podem ser usados ou as regras podem ser implementadas inteiramente em iptables , conforme descrito na documentação do Shorewall .

Se os wrappers tcp estiverem ativados. Um par de regras como as seguintes em /etc/hosts.allow irá notificá-lo sempre que uma conexão remota for feita com o deamon . A primeira regra permite que as conexões locais funcionem silenciosamente, ajuste o intervalo do endereço IP conforme apropriado. A segunda regra impede o acesso de endereços que invertem a um número de TLDs do país e envia uma mensagem por e-mail para cada conexão bem-sucedida. Pode ser barulhento, se você não usar o Port Knocking.

sshd :          10.0.0.0/8 192.168.0.0/24 

sshd :          ALL \
            EXCEPT .ar .au .br .by .cl .co .cz .do .eg .gt \
                .id .il .in .jp .ma .mx .nl .pe .pk .pl .pt \
                .ro .rs .ru .sa .sg .tr .tw .ua .vn .za \
                .ae .at .bg .gh .hr .hu .ke .kz .lt .md \
                .my .no .sk .uy .ve : \
            spawn (/bin/echo "SSH connection to %N from %n[%a] allowed" | \
                /usr/bin/mailx -s "SSH Allowed" [email protected])

As regras

fail2ban podem ser usadas para hospedar temporariamente temporariamente os hosts que estão tentando forçar seu servidor. Eu vi tentativas ocasionais quando tive ssh exposto à Internet.

    

Answer 2

Como outros já disseram, o SSH já está à altura da tarefa em termos de ser seguro o suficiente. Eu acho que é inútil mover o daemon sshd para um ponto diferente. Eu comparo isso com a configuração de um ponto de acesso da Wirels e a ocultação do SSID. É trivial para passar esses tipos de segurança através de medidas de obscuridade.

Limitar o acesso não apenas à raiz, mas apenas aos usuários principais é sempre uma boa ideia, seja com acesso SSH ou qualquer outra coisa.

Uma coisa que eu acho útil é usar algo como fail2ban . Você pode usá-lo para detectar e tomar contramedidas para retardar e impedir invasores.

• link

Answer 3

Sua instalação do SSH já é o estado da arte em termos de segurança.

Há algo que você poderia fazer, mas note que pode ser mais uma dor no pescoço para você do que uma proteção real. Você poderia alterar a porta de 22 para uma menos conhecida, a fim de receber menos ataques e testes de autenticação.

    

Answer 4

en.wikipedia.org: Systrace

Página man do OpenBsd

O OpenBsd tem esse truque, você pode iniciar o OpenSsh com permissões limitadas e registros adicionais.

Tente colocar / usr / sbin / sshd em / usr / sbin / systrace.

Cada acesso a qualquer objeto do sistema seria registrado pelo systrace, qualquer acesso a qualquer arquivo, diretório, portas de rede, memória, chamadas do sistema, etc.

Gere políticas dessa maneira:

systrace -A -d /etc/systrace/sshd.policy/ \
         -E /var/log/systrace_sshd.log /usr/sbin/sshd

Edite a política com seu editor de texto favorito:

vi /etc/systrace/sshd.policy/

Em seguida, inicie o daemon sshd com restrições:

systrace -a -d /etc/systrace/sshd.policy/ \
         -E /var/log/systrace_sshd.log /usr/sbin/sshd

Existem muitos how-tos sobre o wrapper do systrace sobre o shell, mas você deve incluir o sshd, se você estiver interessado em proteger o daemon.

    

Answer 5

O único risco no lado do servidor é uma exploração de pré-autenticação. Não houve muitos (conhecidos publicamente) na história da SSH.

    

Answer 6

Eu uso uma armadilha de tar no iptables. Muitas tentativas de login com falha e você precisa ir para a máquina física.

10 vezes em 15 minutos e você está na lista negra.
9 vezes em 10 minutos e você está na lista negra. 6 vezes em 5 minutos e você está na lista negra.

Ajustar correspondentemente!

#
# - Black List
#
-A BLACKLIST -m recent --name blacklist --set
-A BLACKLIST -j LOG --log-level 4 --log-prefix "TAR-TRAP: "
-A BLACKLIST -j DROP
#
# - SSH Tar Trap
#
-A FIREWALL -p tcp --dport ssh -m state --state NEW -j TAR-TRAP
#
-A TAR-TRAP -m recent --update --name blacklist --seconds 900 --hitcount 1 -j LOG --log-level 4 --log-prefix "BANNED: "
-A TAR-TRAP -m recent --update --name blacklist --seconds 900 --hitcount 1 -j DROP
-A TAR-TRAP -m recent --set --name strike1
-A TAR-TRAP -m recent --set --name strike2
-A TAR-TRAP -m recent --set --name strike3
-A TAR-TRAP -m recent --update --name strike1 --seconds 300 --hitcount 6 -j LOG --log-level 4 --log-prefix "IPT TAR1: "
-A TAR-TRAP -m recent --update --name strike1 --seconds 300 --hitcount 6 -j BLACKLIST
-A TAR-TRAP -m recent --update --name strike2 --seconds 600 --hitcount 9 -j LOG --log-level 4 --log-prefix "IPT TAR2: "
-A TAR-TRAP -m recent --update --name strike2 --seconds 600 --hitcount 9 -j BLACKLIST
-A TAR-TRAP -m recent --update --name strike3 --seconds 900 --hitcount 10 -j LOG --log-level 4 --log-prefix "IPT TAR3: "
-A TAR-TRAP -m recent --update --name strike3 --seconds 900 --hitcount 10 -j BLACKLIST
-A TAR-TRAP -j ACCEPT
#

    

Answer 7

Você pode criar uma regra como essa para bloquear a conexão ssh de certos endereços IP de origem. O intervalo de IPs pode ser público ou privado.

$ iptables -A INPUT -p tcp -s IP_Range --dport 22 -j ACCEPT

Como exemplo, você pode usar este para sua rede privada

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -j ACCEPT

Você também pode usar tcpwrappers para controlar o acesso ssh em seus centos. Os TCPwrappers usam uma combinação para os arquivos /etc/hosts.allow e /etc/hosts.deny. O seguinte exemplo abaixo mostra para definir o controle de acesso que permite acessar o sshd a partir de 10.0.0.0/24.

$ vim /etc/hosts.deny
sshd: ALL
$ vim /etc/hosts.allow
sshd: 10.0.0.

Você também pode fazer o daemon ssh escutar uma porta diferente de 22.