ti-enxame.com

Como endurecer um servidor SSH?

Que 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.

128
LassePoulsen

Faça com que o sshd bloqueie os IPs do cliente que não forneceram as informações corretas de login " DenyHØsts " pode fazer esse trabalho de forma 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 de força no 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.

21
LassePoulsen

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ê terá que digitar a senha do servidor no prompt).

  3. Desabilite o acesso SSH à 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, o único caminho possível para o SSH no servidor é usar uma chave que corresponda a uma linha em ~/.ssh/authorized_keys. Usando este método, I não se preocupam com ataques de força bruta, porque mesmo se eles adivinharem minha senha, ela será rejeitada. Brute forçando um par de chaves pública/privada é impossível com a tecnologia de hoje.

108
Asa Ayers

Eu sugeriria:

  • Usando fail2ban para evitar tentativas de login de 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, dificultando o ataque.

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

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

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

72
Mark Davidson

Outras respostas fornecem segurança, mas há uma coisa que você pode fazer para deixar seus registros mais silenciosos e diminuir 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 vão sobrecarregar seus arquivos de log.

24
Douglas Leeder

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 da autenticação de chave pública sobre a autenticação de senha, como em outra resposta aqui, mas também exige que o usuário prove que ele possui 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 Google Authenticator Android app).

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

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Execute Sudo service ssh reload para pegar 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 do ano passado: Melhor dois fatores de autenticação ssh no Ubunt .

23
Robie Basak

Aqui está uma coisa fácil de fazer: instalar fw (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 fw 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á apenas 6 conexões a cada 30 segundos a partir do mesmo endereço IP.

20
mpontillo

Se eu quiser ter alguma segurança adicional ou precisar acessar servidores SSH dentro de alguma rede corporativa, eu configuro um serviço oculto usando o software de anonimização Tor .

  1. Instale o Tor e configure o próprio servidor SSH.
  2. Certifique-se de que o sshd apenas atenda em localhost.
  3. Abra /etc/tor/torrc. Defina HiddenServiceDir /var/lib/tor/ssh e HiddenServicePort 22 127.0.0.1:22.
  4. Olhe para 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, eu preciso do Tor no meu Host local. Se estiver instalado, posso inserir ssh myhost e o SSH abre 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".

12
qbi

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 endurecer um servidor SSH.

Veja o artigo: Mantendo o acesso SSH seguro .

8
Huygens

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ço conhecidos na lista de bloqueio. Consegui isso com o Snort via firewall de borda (isso é minha abordagem, um appliance pfSense). Às vezes, eu não posso fazer isso, como com meus VPSs.

  2. Filtragem de firewall/rede da (s) porta (s) SSH Eu permiti 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 configurado. 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 NAT-ing a rede interna e separando da Internet e os sistemas, Acesso somente VPN aos 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 # 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 falhadas e bloquear os IPs por uma hora ou mais é uma proteção decente contra as pessoas constantemente atacando com bruteforcing - apenas bloqueia em no firewall automaticamente com fail2ban e meh. Configurar o fail2ban é uma dor ...

  5. Ofuscação de porta alterando a porta SSH No entanto, isso NÃO é uma boa idéia para fazer sem medidas de segurança adicionais, bem - o mantra de "Segurança através da Obscuridade" já foi refutado e contestado 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ória, via soluções de autenticação de dois fatores do Duo Security . Cada um dos meus servidores SSH tem o Duo configurado sobre isso, para que, mesmo para entrar, 2FA prompts aconteçam, 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). Esta é uma das maiores proteções dos meus servidores SSH contra acessos não autorizados - 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 garantir o SSH. Ou, pelo menos, meus pensamentos sobre abordagem.

6
Thomas Ward

Você pode querer verificar o 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 backend de autenticação de dois fatores de código aberto.

Ultimamente eu escrevi um howto sobre isso .

1
cornelinux

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 selos 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: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html

0
weller1

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: https://www.axllent.org/docs/view/ssh-geoip/

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

0
Michael A Mike

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. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

0
01000101