9 de set de 2010

SSH - aspectos técnicos


Administradores de redes devem dominar o shell e conhecer profundamente as ferramentas de acesso remoto. No Linux/Unix, temo o ssh (Secure Shell) que permite acesso remoto a máquinas rodando estes SO e permite uma gama infinita de utilização, desde manipulação de arquivos, até mesmo acesso baseado em terminal X (Ambiente Gráfico).


A grande vantagem do SSH sobre outras ferramentas de acesso remoto é a grande ênfase na segurança. Um servidor SSH bem configurado é virtualmente impenetrável e você pode acessá-lo de forma segura, mesmo que a sua rede local esteja comprometida. Ele utiliza um conjunto de técnicas de criptografia para assegurar que apenas as pessoas autorizadas tenham acesso ao servidor, que todos os dados transmitidos sejam impossíveis de decifrar e que a integridade da conexão seja mantida.
São previstas respostas para diversos tipos de ataques conhecidos. O SSH detecta casos em que o servidor tenha sido substituído por outra máquina, situações nas quais se tenta injetar dados na conexão (ou seja, tirar proveito de uma conexão aberta para incluir pacotes com comandos adicionais) e inclui até mesmo técnicas de "despiste", que tornam muito mais complicado descobrir em qual pacote encriptado foi transmitida a senha de acesso, por exemplo, dificultando a vida de quem pretende descobrir a senha usando um ataque de força bruta.
A idéia central é que, mesmo em situações onde seja fácil interceptar a transmissão (como no caso de uma rede wireless pública), seja impossível descobrir o conteúdo dos pacotes, devido à encriptação. É possível ainda, utilizar um par de chaves em vez de uma senha como forma de autenticação. Nesse caso, além de possuir a chave privada (um arquivo que pode ser salvo no HD, em um pendrive ou mesmo em um smartcard), é preciso saber a passphrase, que pode ser uma senha especialmente longa e difícil de adivinhar.
Você poderia argumentar que qualquer algoritmo de encriptação pode ser quebrado via força bruta (onde simplesmente são testadas todas as possibilidades possíveis, até encontrar a combinação correta), de forma que nenhum sistema de encriptação é inteiramente seguro. Entretanto, ataques de força bruta só são realmente viáveis contra chaves de 40 ou 64 bits; acima disso é inviável, pois a cada bit adicionado, o processo torna-se exponencialmente mais demorado.(GDH)
Um exemplo de protocolo pouco seguro é o WEP de 64 bits (que na verdade utiliza uma chave de 40 bits), usado em redes wireless pouco protegidas. Ele pode ser quebrado em pouco tempo, caso você consiga capturar um volume considerável de transmissões usando um sniffer (um programa que captura a transmissão da rede, como o Kismet). O DES, um dos algoritmos mais tradicionais, que usa chaves de 64 bits (reais), pode ser quebrado em menos de um dia, caso você tenha acesso a um cluster de 100 máquinas com processadores Xeon ou Opteron quad-core.
Uma chave de 64 bits é cerca de 16 milhões de vezes mais difícil de quebrar via força bruta do que uma de 40 bits, como as que eram utilizadas no SSL dos navegadores a até poucos anos. Uma chave de 128 bits por sua vez, é (arredondando) 18.447.000.000.000.000.000 vezes mais demorada de quebrar que uma de 64 bits, de forma que, uma chave de 64 bits pode ser quebrada caso você tenha o tempo e os recursos necessários à disposição, mas uma de 128 (sem brechas conhecidas) é impossível de quebrar com tecnologia atual.
O perigo no caso dos algoritmos de encriptação não são propriamente os ataques de força bruta (que exigem muito tempo e recursos), mas sim falhas que permitam descobrir a chave usada em menos tempo. As versões originais do WEP (o sistema de encriptação para redes wireless anterior ao WPA), por exemplo, podiam ser quebradas rapidamente devido a um conjunto de falhas no algoritmo usado, o que levou os fabricantes a atualizarem rapidamente todos os seus produtos. Outro exemplo é o sistema usado na encriptação dos DVDs, que é quebrado em poucos segundos por uma máquina atual, utilizando um algoritmo de poucas linhas.
Felizmente, este não é o caso dos algoritmos usados no SSH. Por serem abertos, qualquer falha similar que pudesse eventualmente existir já teria sido descoberta e corrigida. O SSH é usado em tantos servidores importantes que uma brecha grave poderia (literalmente) parar o mundo. Por isso, todo o código é exaustivamente auditado por uma variedade de empresas e órgãos governamentais.
O SSH utiliza chaves assimétricas para fazer a autenticação. As chaves assimétricas são um sistema muito interessante, onde temos um par de chaves em vez de uma única chave simétrica. Uma (a chave pública), permite apenas encriptar dados, enquanto a segunda (a chave privada) permite desencriptar as informações embaralhadas pela primeira. O grande segredo é que qualquer informação embaralhada usando a chave pública pode ser recuperada apenas usando a chave privada correspondente. Como o nome sugere, a chave pública pode ser distribuída livremente, pois serve apenas para gerar as mensagens encriptadas, sem permitir lê-las posteriormente.
Quando você se conecta a um servidor SSH, seu micro e o servidor trocam suas respectivas chaves públicas, permitindo que um envie informações para o outro de forma segura. Através deste canal inicial é feita a autenticação, seja utilizando login e senha, seja utilizando chave e passphrase (como veremos a seguir).
Até aqui, tudo é feito utilizando chaves de 512 bits ou mais (de acordo com a configuração). O problema é que, embora virtualmente impossível de quebrar, este nível de encriptação demanda um volume muito grande de processamento. Se todas as informações fossem transmitidas desta forma, o SSH seria muito lento.
Para solucionar este problema, depois de fazer a autenticação, o SSH passa a utilizar um algoritmo mais simples (que demanda muito menos processamento) para transmitir os dados. Por padrão é utilizado o 3DES (triple-DES), que utiliza uma combinação de três chaves DES, de 64 bits cada. As chaves são trocadas periodicamente durante a conexão, o que torna o sistema quase impossível de quebrar. Na configuração do servidor e/ou cliente, é possível especificar outro algoritmo, como o Blowfish. Isso garante uma boa relação entre segurança e desempenho.
Instalação:
A instalação do ssh no Debian é muito facilitada e neste ponto, o objetivo é conhecer a ferramenta, instalar e aprender  a usar a mesma.
Este serviço é dividido em client e server.

Como root, fazer a instalação com o comando: 
aptitude install openssh-client openssh-server

o arquivo de configuração fica em:

/etc/ssh/sshd.config

Sempre no primeiro acesso ao host, o ssh apresenta a mensagem como abaixo, indicando que a autenticidade do destino não pode ser verificada até que você aceite (yes) a chave RSA. A partir deste ponto, sua conexão é então criptografada e protegida pelo ssh.


The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is 0d:5c:b7:6e:7c:d3:09:2f:0a:6b:8a:99:88:e4:2d:af.
Are you sure you want to continue connecting (yes/no)?
Note que  a chave acima só precisa ser aceita na primeira vez. Após isso, o arquivo com o host ficará gravado em /home/usuario/.ssh/know_hosts e fará alerta quando eventualmente a configuração do host for alterada, como por exemplo, mudança da chave ou uma simples troca de placa de rede. Portanto, é imprescidível que ao utilizar o ssh e sempre que houver uma indicação de alteração, que se verifique os motivos para tal, impedindo assim de acessar um servidor cuja segurança esteja de fato comprometida.


Outras dicas e truques do ssh(/etc/ssh/sshd.config):
 
Altere a porta padrão do ssh. Assim sistemas de invasores automatizados terão menas chances contra seu servidor. Scanners de rede normalmente não procuram por portas altas, uma sugestão seria colocar este serviço em uma porta 2222 por exemplo:


Port 2222


Use somente o Protocol versão 2. A versão 1 é mais susceptível à problemas de segurança:
Protocol 2


Permita login via ssh somente para alguns usuários e nunca para o root. Acreditar que seu ssh nunca será explorado é o mesmo que ter segurança por obscuridade (isto nunca vai acontecer, ou, isto nunca aconteceu comigo, ainda, não tem nada para ser roubado aqui).


PermitRootLogin no
AllowUsers  fafanet
denyUsers ALL



Você pode usar o TCP WRAPPERS para colocar uma camada a mais de segurança, por exemplo liberando somente alguns hosts para fazer o acesso. Perceba que esta pode não ser uma boa solução se estes hosts usarem ip's dinãmicos.
No arquivo de configuração do tcp wrappers /etc/hosts.allow insira ou altere o serviço ssh para liberar aos ips desejados :
sshd:

A exemplo da regra acima, pode ser utilizado o seu firewall para permitir conexões somente de determinados hosts. Veja como é seu firewall e insira as regras pertinentes. Pelo iptables ficaria assim:

Liberando o acesso :
# iptables -A INPUT -p tcp -m state --state NEW --source 200.220.222.222--dport 22 -j ACCEPT
Bloqueando para os demais: 
# iptables -A INPUT -p tcp --dport 22 -j DROP 



Dicas de uso do ssh:


Indicando o usuário para o acesso:
ssh -l user hostname   ou ssh user@hostname


Indicando a porta para o acesso:

ssh -p 2222 user@hostname


O ssh também permite a execução de comandos remotamente:
ssh user@hostname "ls -C /etc"



Note que se você deseja editar o arquivo remotamente, precisará especificar a flag -t para que o ssh aloque um pseudo terminal, desta forma:

ssh -t user@hostname "vi /etc/inetd.conf


Você pode executar o comando remotamente e obter o resultado na sua máquina local como neste exemplo:

ssh user@hostname "ls /bin" | grep -i rm > arq



Referências:
man ssh
http://www.dicas-l.com.br/arquivo/dicas_avancadas_de_seguranca_para_ssh.php
http://www.guiadohardware.net/tutoriais/dominando-ssh/pagina2.html