POSTED BY

POSTED ON

January 23, 2015

POSTED UNDER

How-To's

COMMENTS

Comments Off on SSH Really Secure Shell

SSH Really Secure Shell

Bom dia a todos,

No inicio de janeiro de 2015, surgiu no /. um artigo muito interessante de como a NSA já consegue desencriptar em tempo real ligações de SSH.
Quem diz a NSA, diz qualquer grupo que tenha acesso a uma pool suficientemente grande de pc’s zombie, ie botnet.

A ideia em si é aterradora se tiverem que passar dados de negócio extremamente sensíveis pela internet. Os dados são nossos e queremos manter controle de quem os vê.

Descobri então este artigo no github onde nos é ensinado a efetuar military grade hardening ás conectividades de SSH.
Este post é portanto uma tradução e mini how-to do que é explicado nesse artigo e todos os créditos são deles.

Em termos de prefácio é importante lembrar que o OpenSSH suporta 8 tipos principais de troca de chave:

  • curve25519-sha256: ECDH over Curve25519 with SHA2
  • diffie-hellman-group1-sha1: 1024 bit DH with SHA1
  • diffie-hellman-group14-sha1: 2048 bit DH with SHA1
  • diffie-hellman-group-exchange-sha1: Custom DH with SHA1
  • diffie-hellman-group-exchange-sha256: Custom DH with SHA2
  • ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
  • ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2
  • ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2

Destes 8, há que recordar 3 coisas importantes:

  • ECDH curve choice: Isto elimina automaticamente das opções 6-8 porque as NIST curves falham redondamente.
    São conhecidas por efetuar leaks de informação. Igualmente NIST é considerado como sendo prejudicial e não deverá ser confiado.
  • Tamanho de Bit do modulo de DH: Isto elimina a segunda hipótese pois a NSA consegue já quebrar estas comunicações em tempo real. Pondo de uma forma simples os 1024 bits já não nos fornecem margem de segurança suficiente.
  • Segurança da função de hash. Isto automaticamente invalida as opções 2 a 4 pois o SHA1 está broken.

Isto deixa-nos com as opções 1 e 5. A opção 1 é perfeitamente boa mas para questões de interoperabilidade a versão 5 pode e deve ser incluída.

Assim sendo, ao nível da configuração do daemon de sshd (/etc/ssh/sshd_config) temos:

KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

Do lado do cliente de ssh (/etc/ssh/ssh_config) temos:

# Github needs diffie-hellman-group-exchange-sha1 some of the time but not always.
#Host github.com
#    KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
    
Host *
    KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

Autenticação:

O OpenSSH oferece 4 tipos de algoritmos públicos de autenticação:

  • DSA with SHA1
  • ECDSA with SHA256, SHA384 or SHA512 depending on key size
  • Ed25519 with SHA512
  • RSA with SHA1

Assim sendo, efetuar ao nível do /etc/ssh/sshd_config:

Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

Nota: Com isto alem de dar hostkeys diferentes, é desabilitado a versão 1 do protocolo que está broken.

Vamos gerar as keys necessárias:

cd /etc/ssh
rm ssh_host_*key*
ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

Autenticação de cliente:

Uma das formas de autentica como sempre é a password embora seja um método falível.
Recomenda-se sempre a utilização de chaves partilhadas:

No ficheiro de configuração do daemon /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes

Do lado da configuração do cliente /etc/ssh/ssh_config:

Host *
    PasswordAuthentication no
    ChallengeResponseAuthentication no
PubkeyAuthentication yes
HostKeyAlgorithms [email protected],[email protected],ssh-rsa-cert [email protected],ssh-ed25519,ssh-rsa

Finalmente geramos as client keys necessárias:

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100

Cifras simétricas:

As cifras simétricas é o que é utilizado para encriptar os dados e nos garantir segurança na comunicação assim que a troca de chaves inicial está completa.
Existem bastantes algoritmos:

Assim sendo e tendo em conta os issues identificados com algumas das cifras temos:

No ficheiro de configuração do daemon /etc/ssh/sshd_config:

Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

Do lado da configuração do cliente /etc/ssh/ssh_config:

Host *
    Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

Códigos de autenticação de mensagem.

A encriptação fornece a confidencialidade. Os códigos a integridade do que recebemos.

Existem os seguintes opções de escolha referente a MAC’s:

No ficheiro de configuração do daemon /etc/ssh/sshd_config:

MACs [email protected],[email protected],[email protected],umac [email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected]

No ficheiro de configuração do cliente /etc/ssh/ssh_config:

Host *
    MACs [email protected],[email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected]

Nota:  Todas as alterações efetuadas ao /etc/ssh/sshd_config vão obrigar a um reload ao daemon de ssh.

O artigo é extremamente extenso e extremamente bem construido. Recomendo vivamente que leiam o mesmo com muita atenção.

Caso tenham duvidas, o meu email está como sempre disponível.

Abraço,
Nuno

 

[fb_linkedin_resume_header]