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 ao invés de uma simples senha como forma de autenticação. Nesse caso, além da chave (um arquivo salvo no HD, pendrive ou smartcard), é preciso saber a passphrase, que pode ser uma senha especialmente longa e difícil de adivinhar.
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. Porém, isso só é realmente possível para chaves de 40 ou no máximo 64 bits; acima disso é inviável, pois a cada bit adicionado, o processo torna-se exponencialmente mais demorado.
O WEP de 64 bits (que na verdade utiliza uma chave de 40 bits), usado em redes wireless pouco protegidas, pode ser quebrado em pouco tempo, caso você consiga capturar um volume considerável de transmissões usando um sniffer. O DES, um dos algoritmos mais tradicionais, que usa chaves de 64 bits (reais), pode ser quebrado em alguns dias, caso você tenha acesso a um cluster de 100 máquinas Athlon 64.
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 atrás. 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 é quando são descobertas falhas que permitam descobrir a chave usada em menos tempo. As versões originais do WEP, 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. Uma (a chave pública), permite apenas encriptar dados, enquanto a segunda (a chave privada) permite desencriptar as informações embaralhadas pela primeira.
Quando você se conecta a um servidor SSH, seu micro e o servidor trocam suas 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 impossível de quebrar, este nível de encriptação demanda uma quantidade 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.
Outra precaução importante é a proteção contra ataques do tipo “man in the middle”, onde alguém com acesso físico à rede muda o cabeamento ou configuração, de forma que outra máquina se apresente no lugar do servidor, com o objetivo de roubar senhas.
Como parte das verificações de segurança, o SSH utiliza também um sistema baseado em chaves assimétricas para verificar a identidade do servidor. O servidor tem uma chave pública, que envia ao cliente na primeira conexão. As identificações de todos os servidores conhecidos ficam armazenadas no arquivo “.ssh/known_hosts” dentro do seu diretório home. Sempre que você se conecta daí em diante, o cliente SSH envia um “desafio” ao servidor, uma frase encriptada usando a chave pública, que só pode ser descoberta usando a chave privada.
O servidor falso poderia ser configurado para gravar sua senha e responder com uma mensagem do tipo “O servidor está em manutenção, tente novamente daqui a algumas horas”. Dessa forma, ele teria não apenas acesso à sua senha, mas tempo para usá-la para acessar o servidor verdadeiro sem que você desconfie.
Como de praxe, o SSH percebe que a identificação do servidor mudou e lhe avisa do problema:
Para continuar é preciso que você edite manualmente o arquivo “.ssh/known_hosts”, dentro do home e remova a linha com a antiga identificação do servidor, deixando as demais. Da próxima vez que tentar se conectar, o SSH exibe uma mensagem mais simpática, perguntando se você quer adicionar a nova chave.
Com tantas camadas de proteção o elo mais fraco da cadeia acabam sendo as senhas de acesso, já que alguém com posse da senha, pode se logar no servidor sem dificuldades, assumindo o lugar do dono da conta.
Em servidores com muitos usuários, é quase impossível controlar a qualidade das senhas usadas. Embora você possa desativar o acesso a contas com senhas em branco através da opção “PermitEmptyPasswords no” no arquivo “/etc/ssh/sshd_config”, pouco pode ser feito com relação a usuários que utilizam senhas fáceis ou com poucos caracteres.
Existe também a possibilidade de um bot ficar testando várias possibilidades durante um longo período e, num golpe de sorte, conseguir descobrir a senha de root do servidor. O SSH impões por default um tempo de espera de dois segundos entre cada tentativa, o que torna os ataques de força bruta inefetivos, já que não é possível testar mais do que 1.800 combinações de senha por hora, mas isso não impede que um número crescente de bots fique martelando os servidos diretamente conectados e acabem descobrindo senhas de acesso em alguns deles.
Uma medida simples que pode ser usada para eliminar este último risco é utilizar o fail2ban, um pequeno daemon que monitora os arquivos de log do servidor e bloqueia os endereços IP dos atacantes utilizando regras de firewall.
Você pode instalá-lo rapidamente no Debian, Ubuntu ou derivados usando o apt-get:
Para distribuições que não incluam o pacote, você pode baixar o código fonte no:
http://sourceforge.net/projects/fail2ban
A configuração é feita através do arquivo “/etc/fail2ban/jail.conf“, onde são listados os arquivos de log que serão monitorados, o número máximo de tentativas antes de aplicar o bloqueio e o tempo que ele vigorará.
Por padrão, ele é configurado para banir por 10 minutos endereços a partir dos quais sejam feitas mais do que 5 tentativas mal-sucedidas. Além do SSH, ele monitora também os arquivos de log do apache (monitorando tentativas de acesso a pastas protegidas por senha através de arquivos .htaccess) e até mesmo tentativas de acesso ao servidor de e-mails (caso seja utilizado o postfix) ou ao servidor FTP.
O tempo de banimento é especificado (em segundos) através da opção “bantime” dentro do arquivo, como em:
O número de tentativas toleradas para cada serviço, assim como seu respectivo arquivo de log (que o fail2ban monitora, identificando as tentativas de login que não foram bem sucedidas) são especificados em uma seção separada, como em:
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
É possível também criar uma lista branca de endereços que nunca serão bloqueados, independentemente do número de tentativas, através da opção “ignoreip”. Se você administra seus servidores a partir de um link com IP fixo, é interessante colocar seu endereço na lista, para evitar acidentes. Você pode especificar vários endereços, separando-os com espaços, como em:
Depois de fazer modificações no arquivo, reinicie o serviço com o comando:
Veja também
Sobre o Autor
Deixe seu comentário