Como endurecer um servidor SSH?

Question

Quais medidas posso / devo tomar para garantir que a segurança em torno do meu servidor SSH seja absolutamente impermeável?

Este será o wiki da comunidade desde o início, então vamos ver o que as pessoas fazem para proteger seus servidores.

    

Answer 1

Faça com que os IPs do cliente do bloco sshd que não forneceram as informações de login corretas " DenyHØsts " possam executar esse trabalho de maneira bastante eficaz. Eu tenho isso instalado em todas as minhas caixas de Linux que são de alguma forma acessíveis a partir do grande fora.

Isso fará com que os ataques forçados ao SSHD não sejam efetivos, mas lembre-se (!) dessa forma, você pode acabar se bloqueando se esquecer sua senha. Isso pode ser um problema em um servidor remoto ao qual você não tem acesso.

    

Answer 2

Use pares de chaves pública / privada para autenticação em vez de senhas.

1. Gere uma chave SSH protegida por senha para cada computador que precise acessar o servidor:

   ssh-keygen

2. Permitir acesso SSH de chave pública nos computadores permitidos:

   Copie o conteúdo de ~/.ssh/id_rsa.pub de cada computador em linhas individuais de ~/.ssh/authorized_keys no servidor ou execute ssh-copy-id [server IP address] em cada computador ao qual você está concedendo acesso (você precisará digitar a senha do servidor no prompt).

3. Desativar o acesso SSH por senha:

   Abra /etc/ssh/sshd_config , encontre a linha que diz #PasswordAuthentication yes e altere para PasswordAuthentication no . Reinicie o daemon do servidor SSH para aplicar a alteração ( sudo service ssh restart ).

Agora, a única maneira possível de o SSH entrar no servidor é usar uma chave que corresponda a uma linha em ~/.ssh/authorized_keys . Usando esse método, eu não me importo com ataques de força bruta, porque mesmo se eles adivinharem minha senha, ela será rejeitada. Impulsionar brute um par de chaves pública / privada é impossível com a tecnologia de hoje.

    

Answer 3

Eu sugeriria:

• Usando fail2ban para evitar tentativas de login por força bruta.

• Desativando o login como root via SSH. Isso significa que um invasor precisa descobrir tanto o nome de usuário quanto a senha, o que torna o ataque mais difícil.

  Adicione PermitRootLogin no ao seu /etc/ssh/sshd_config .

• Limitando os usuários que podem SSH ao servidor. Por grupo ou apenas usuários específicos.

  Adicione AllowGroups group1 group2 ou AllowUsers user1 user2 para limitar quem pode SSH ao servidor.

Answer 4

Outras respostas fornecem segurança, mas há uma coisa que você pode fazer para deixar seus registros mais silenciosos e reduzir a probabilidade de ficar bloqueado em sua conta:

Mova o servidor da porta 22 para outro. Em seu gateway ou no servidor.

Isso não aumenta a segurança, mas significa que todos os scanners de internet aleatórios não sobrecarregarão seus arquivos de registro.

    

Answer 5

Ative a autenticação de dois fatores com HOTP ou TOTP . Isso está disponível a partir de 13.10 em diante.

Isso inclui o uso de autenticação de chave pública sobre autenticação de senha como em outra resposta aqui, mas também exige que o usuário prove que ele mantém seu segundo fator de dispositivo além de sua chave privada.

Resumo:

1. sudo apt-get install libpam-google-authenticator

2. Peça a cada usuário que execute o comando google-authenticator , que gera ~/.google-authenticator e os ajuda a configurar seus dispositivos de dois fatores (por exemplo, o aplicativo Google Authenticator Android).

3. Edite /etc/ssh/sshd_config e defina:

   ChallengeResponseAuthentication yes
   PasswordAuthentication no
   AuthenticationMethods publickey,keyboard-interactive
   

4. Execute sudo service ssh reload para selecionar suas alterações para /etc/ssh/sshd_config .

5. Edite /etc/pam.d/sshd e substitua a linha:

   @include common-auth
   

   com:

   auth required pam_google_authenticator.so
   

Mais detalhes sobre diferentes opções de configuração são o meu post no blog do ano passado: Melhor autenticação de dois fatores ssh no Ubuntu .

    

Answer 6

Aqui está uma coisa fácil de fazer: instalar o ufw (o "firewall descomplicado") e usá-lo para avaliar o limite de conexões de entrada.

Em um prompt de comando, digite:

$ sudo ufw limit OpenSSH 

Se o ufw não estiver instalado, faça isso e tente novamente:

$ sudo aptitude install ufw 

Muitos invasores tentam usar seu servidor SSH para senhas de força bruta. Isso permitirá somente 6 conexões a cada 30 segundos a partir do mesmo endereço IP.

    

Answer 7

Se eu quiser ter alguma segurança adicional ou precisar acessar servidores SSH em algumas redes corporativas, eu configuro um escondido serviço usando o software de anonimato Tor .

1. Instale o Tor e configure o próprio servidor SSH.
2. Verifique se o sshd apenas escuta em localhost .
3. Abra /etc/tor/torrc . Defina HiddenServiceDir /var/lib/tor/ssh e HiddenServicePort 22 127.0.0.1:22 .
4. Veja var/lib/tor/ssh/hostname . Existe um nome como d6frsudqtx123vxf.onion . Este é o endereço do serviço oculto.

5. Abra $HOME/.ssh/config e adicione algumas linhas:

   Host myhost
   HostName d6frsudqtx123vxf.onion
   ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
   

Além disso, preciso do Tor no meu host local. Se estiver instalado, posso inserir ssh myhost e o SSH abrirá uma conexão via Tor. O servidor SSH do outro lado abre sua porta apenas no host local. Então ninguém pode conectá-lo via "internet normal".

    

Answer 8

Existe um artigo da Administração Debian sobre este tópico. Abrange a configuração básica do servidor SSH e também as regras de firewall. Isso poderia ser de interesse também para fortalecer um servidor SSH.

Veja o artigo: Mantendo o acesso SSH seguro .

    

Answer 9

Minha abordagem para o endurecimento do SSH é ... complexa. Os itens a seguir estão em termos de como eu faço isso, desde a borda da borda da minha rede até os próprios servidores.

1. Filtragem de tráfego em nível de borda através de IDS / IPS com scanners e assinaturas de serviços conhecidos na lista de bloqueio. Consegui isso com o Snort via firewall de borda (essa é minha abordagem, um pfSense utensílio). Às vezes, eu não posso fazer isso, como com meus VPSs.

2. Filtragem de firewall / rede da (s) porta (s) SSH. Eu só permito explicitamente que determinados sistemas acessem meus servidores SSH. Isso é feito por meio de um firewall pfSense na borda da minha rede ou dos firewalls em cada servidor sendo explicitamente configurados. No entanto, há casos em que não posso fazer isso (o que quase nunca é o caso, exceto em ambientes privados de teste de caneta ou de testes de segurança em que os firewalls não ajudam a testar as coisas).

3. Em conjunto com o meu pfSense, ou um firewall de borda que insere NAT na rede interna e se separa da Internet e dos sistemas, Acesso somente VPN a servidores . Tenho que entrar em VPN em minhas redes para chegar aos servidores, porque não há portas voltadas para a Internet como tal. Isso definitivamente não funciona para todos os meus VPSs, mas em conjunto com o número 2, eu posso ter um VPS como o "gateway" através da VPN para esse servidor, e então permitir que ele seja IPs para as outras caixas. Dessa forma, eu sei exatamente o que pode ou não pode ser o SSH - minha caixa que é a VPN. (Ou, na minha rede doméstica por trás do pfSense, minha conexão VPN, e sou o único com acesso VPN).

4. Onde # 3 não é factível, fail2ban, configurado para bloquear após 4 tentativas malsucedidas e bloquear os IPs por uma hora ou mais é uma proteção decente contra as pessoas que constantemente atacam com bruteforcing - apenas bloqueia-os no firewall automaticamente com o fail2ban e o meh. Configurar o fail2ban é uma dor embora ...

5. Ofuscação de porta alterando a porta SSH. No entanto, esta NÃO é uma boa ideia fazer também sem medidas de segurança adicionais - o mantra de " Segurança através da Obscuridade "já foi refutada e disputada em muitos casos. Eu fiz isso em conjunto com IDS / IPS e filtragem de rede, mas ainda é uma coisa MUITO ruim para fazer por conta própria.

6. Autenticação de dois fatores obrigatórios, por meio das soluções de autenticação de dois fatores do Duo Security . dos meus servidores SSH tem o Duo configurado, de modo que, para entrar, os prompts do 2FA acontecem e eu tenho que confirmar cada acesso. (Este é o último recurso útil - porque mesmo que alguém tenha minha senha ou invasões, eles não podem passar pelos plug-ins do Duo PAM). Essa é uma das maiores proteções dos meus servidores SSH contra acesso não autorizado - cada login de usuário DEVE ser vinculado a um usuário configurado no Duo e, como tenho um conjunto restritivo, nenhum novo usuário pode ser registrado no sistema.

Meus dois centavos para proteger o SSH. Ou, pelo menos, meus pensamentos sobre abordagem.

    

Answer 10

Você pode querer fazer o checkout do aplicativo FreeOTP do RedHat em vez de usar o Google Authenticator. Às vezes, ao atualizar o aplicativo, eles trancam você! ; -)

Se você quiser usar outros tokens de hardware como um Yubikey ou um eToken PASS ou NG ou se tiver muitos usuários ou muitos servidores, convém usar um back-end de autenticação de dois fatores de código aberto.

Ultimamente eu escrevi um how about this .

    

Answer 11

Eu escrevi um pequeno tutorial sobre como fazer isso recentemente. Basicamente, você precisa estar usando o PKI e meu tutorial também mostra como usar a autenticação de dois fatores para ainda mais segurança. Mesmo se você não usar nenhuma dessas coisas, também há algumas dicas sobre como proteger o servidor, removendo conjuntos de codificação fracos e outros princípios básicos. link

    

Answer 12

Para um grande número de usuários / certificados, considere a integração do LDAP. Grandes organizações usam o LDAP como um repositório de credenciais de usuários e certificados armazenados em badges ou fobs, sejam os certificados usados para autenticação ou assinatura de emails. Os exemplos incluem o openLDAP, o openDJ, o Active Directory, o Oracle Universal Directory, o IBM Directory Server, o snareWorks ...

Computadores e grupos também podem ser gerenciados em LDAP, fornecendo gerenciamento central de credenciais. Dessa forma, os help desks podem ter um balcão único para lidar com grandes populações.

Aqui está um link para a integração do centOS: link

    

Answer 13

Você também pode bloquear com base no país de origem usando o banco de dados geoIP.

Basicamente, se você mora nos EUA, então não há razão para alguém na Rússia se conectar ao seu SSH para que eles sejam automaticamente bloqueados.

O script pode ser encontrado aqui: link

Você também pode adicionar comandos iptables a ele (eu fiz para minhas gotas) para remover automaticamente todo o tráfego de / para esses IPs.