Blindando o OpenSSH …
A pouco tempo escrevi como usar o SSH juntamente com o Screen e agora pretendo mostrar como configuro o OpenSSH (Open Secure Shell) nos Servidores que administro.
Vou demostrar como ir um pouco mais fundo na configuração do sshd_config para se prevenir de ataques de Brute_Force e como configurar algumas regras de Firewall especificas para a conexão SSH.
É possivel executar conexões remotas via VPN com trocas de chaves públicas e privadas usando criptografia de 2048 bits (OpenVPN), mas nada como ter a comodidade e simplicidade de poder fazer acesso aos seus servidores usando o SSH desde que para manter uma conexão segura siga alguns passos extras de precaução.
Eu sempre configuro meus Servidores com as seguintes caraterísticas para acesso ao SSH:
1) Não uso a porta padrão para acesso, sempre mudo para uma porta acima de 45000 (na verdade qualquer valor acima de 1024 está bom);
2) Não permito acesso ao root, permito acesso somente aos usuários que pertencem a um determinado grupo e restrinjo o acesso ao comando su a este grupo de usuários usando o PAM;
3) Só aceito conexões com protocolo versão 2;
4) Limito o número de tentativas de conexão a 3;
5) Não permito senhas em branco;
6) Habilito o uso de PAM e Log;
7) Não permito o uso de tunelamento sobre SSH;
Não permito que o X seja exportado via SSH;
9) Uso a variável “MaxStartups” para bloquear ataques de Força Bruta;
10) Uso uma variável para fazer com que os processos filhos do OpenSSH rodem com baixos privilegios;
11) Faço acesso ao SSH sempre usando passphase, por isso do Screen com SSH;
12) Mostro um Banner sempre na conexão;
Além destas configurações que são feitas no arquivo de configuração do OpenSSH eu ainda rodo um Script de Firewall para filtrar conexões SSH e impedir ataques de Brute-Force, bem como um Script que roda via Cron de 15 em 15 minutos que pesquisa nos logs tentativas de acesso forçadas e cria regras de bloqueio automaticamente para elas.
Uma outra medida muito importante, senão a mais de todas é manter o pacote do OpenSSH sempre atualizado, pois as regras acima bloqueiam ataques de força-bruta mas não falhas do programa que podem ser exploradas por exploits e etc.
Também limite ao máximo o número de pessoas que terão acesso ao SSH mas nunca compartilhe um mesmo login, sempre crie um diferente para cada administrador (dentro do grupo que é permitido o acesso ao SSH);
Abaixo você tem o Script do Iptables que utilizo para filtrar e logar as conexões ao SSH:
{
####
#### Script para Bloquear ataques de Força Bruta no OpenSSH
#### Obs:> Se a porta do SSH for outra nao esqueça de mudar a váriável
#### By Leandro Godoy
####
IPTABLES=`which iptables`
PORTA=”55555″
$IPTABLES -A INPUT -p tcp –syn –dport $PORTA -m recent –name sshattack –set
$IPTABLES -A INPUT -p tcp –dport $PORTA –syn -m recent –name sshattack –rcheck –seconds 60 –hitcount 3 -j LOG –log-prefix ‘SSH REJECT: ‘
$IPTABLES -A INPUT -p tcp –dport $PORTA –syn -m recent –name sshattack –rcheck –seconds 60 –hitcount 3 -j REJECT –reject-with tcp-reset
$IPTABLES -A FORWARD -p tcp –syn –dport $PORTA -m recent –name sshattack –set
$IPTABLES -A FORWARD -p tcp –dport $PORTA –syn -m recent –name sshattack –rcheck –seconds 60 –hitcount 3 -j LOG –log-prefix ‘SSH REJECT: ‘
$IPTABLES -A FORWARD -p tcp –dport $PORTA –syn -m recent –name sshattack –rcheck –seconds 60 –hitcount 3 -j REJECT –reject-with tcp-reset
}
Abaixo está o Script que utilizo via Cron para bloquear os ataques de Brute-force já executados e logados pelo Servidor:
}
#!/bin/bash
# Shellscript criado para bloquear os corriqueiros bruteforce probes
# feitos para a porta do ssh. Pega as ultimas 10 tentativas ilegais na porta do ssh.
# Verifica se voce já bloqueou o Ip e se voce quer adicionar na regra do iptables.
# Caso queira usar manualmente, é so mudar o valor da var $MODE pra “AUTO”…
# Traduzido: Leandro Godoy
# Abracos, Mastah
MODE=”AUTO”
#MODE=”MANUAL”
if [ -f /var/log/messages ] ; then
ips=$(cat -n /var/log/messages | tail -n 10 | grep -i SSH_REJECT | grep -i sshd | awk -F” ” {’print $11′})
attempts=1
for ip in $ips ; do
lastip=$ip
if [ "$lastip" == "$ip" ] ; then
attempts=$(expr $attempts + 1)
if [ $attempts -ge 5 ] ; then
echo “Ataque de Brute Force (SSHD) detectado e originario de $ip”
attempts=1
lastip=”"
blocked=$(iptables -L INPUT | grep -i $ip | grep -i DROP)
if [ "$blocked" ] ; then
echo “> IP ja esta bloqueado. Continuando o Scan”
echo ” “
else
if [ $MODE == "MANUAL" ] ; then
echo “> Voce quer adicionar este IP nas regras de DROP do Iptables da Chain INPUT? (y/n)”
read resp
if [ "$resp" == "y" ] ; then
iptables -A INPUT -s $ip -j DROP
echo “> IP $ip bloqueado com DROP na Chain INPUT”
echo ” “
fi
else
iptables -A INPUT -s $ip -j DROP
echo “> IP $ip bloqueado com DROP na Chain INPUT”
echo ” “
fi
fi
fi
fi
done
fi
}
No meu iDisc, dentro de Gnu/Linux, você encontra um arquivo de configuração do OpenSSH (sshd_config) todo comentado em português (por mim) e com todas as configurações citadas aqui bem como os demais arquivos de script citados aqui e muitos outros. Podem baixar a vontade e caso façam acréscimos me mandem…
Abraços
Textos do Blog Blogmind sao licenciados sobre a Creative Commons Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 2.5 Brasil License.
Parte do Trabalho de Leandro Godoy - www.opencode.com.br.
Out 10th 2006
Legal a blindagem do sshd, mas usaria o Ossec HIDS (http://www.ossec.net) para fazer o controle das tentativas de logs e resposta ativas. Parabens pelo artigo.
[]z! Sp0oKeR
Out 10th 2006
Olá SpOoKeR …
Na verdade se utilizar de um IDS baseado em Host seria melhor opção, mas eu não quis entrar neste mérito ficando restrito apenas ao SSH. Eu sempre configuro os Servidores com PortSentry (http://sourceforge.net/projects/sentrytools/), mas existe o Prelude que é até mais completo.
Abraços
Out 10th 2006
Beleza estas suas dicas, eu estava atrás de mais e mais segurança para SSH e aqui descobri mais algumas. Estou testando regra por regra, acabei de testar uma que não deu certo: foi a MaxAuthTries … Uso Conectiva 10 como servidor modo texto, OpenSSH 3.8 … parece que o SSH não reconheceu a MaxAuthTries
Out 10th 2006
Gostei muito do post, só não entendi porque fazer X11 forward não é seguro? E com relação aos arquivos de configuração sshd_config que está no iDisk, tentei baixar e o arquivo é do tipo binário, vc sabe o que aconteceu???
Valeu.
Out 10th 2006
Otimo artigo hein.
Caramba Sp0oKeR, se for quem eu to pensando…
Alias deve ser sim #linuxall na veia.
Out 11th 2006
Olá Galera …
Obrigado pelos comentários!!
Viana:
A diretiva “MaxAuthTries” não funciona em todas as versões do OpenSSH, a versão 3.8 é a mesma usada no Debian Sarge e no SLES 9 e não rola esta diretiva, mas na 4.2 que uso no SLES10 funciona perfeitamente. Me manda as tuas dicas de segurança e as configurações que implementa no SSH.
Japoneis:
Eu somente habilito o Forward do X11 no momento que vou utilizar, mas logo em seguida desabilito, pois é mais uma possível falha de segurança que pode envolver um acesso devido a um overflow de memória ou falha no algoritimo de criptografia, execução de código arbitrário dependendo do que tu tá exportanto no X … enfim acho que o SSH deve ficar restrito a acesso remoto. Se precisar de uma console gráfica é porque tá na hora de parar na frente de máquina e configurar com um X local (minimo).
Eduardo: Conhece o Spooker? Lenda viva!! Ele tá trabalhando aqui em Porto Alegre na BRConection (filial), gente boa o cara e manja muito … pena que usa RH (brincadeira ….hehehe).
Out 11th 2006
Port Knocking ?
Alguém?
Out 11th 2006
As dicas que encontrei em outros sites, basicamente estão contidas também no seu artigo. Seu artigo, foi um dos mais completos que encontrei. Só tem uma regra que encontrei e ainda não consegui fazer funcionar no meu servidor:
Habilitamos somente o usuário X por exemplo a fazer login remoto no SSH, mas o usuário X não pode virar root. Contudo o usuário Y pode virar root. Então o X vira Y que por sua vez vira root. Assim um possível invasor teria que descobrir 2 nomes de usuários e 3 senhas para ter acesso total do servidor.
A configuração para negar usuário X virar root seria feita no arquivo /etc/suauth , que se não existir, deve ser criado:
root:nome_usuario_do_ssh:DENY
No meu servidor não funcionou porque o arquivo /etc/suauth é ignorado pelo comando su. Mas alguns colegas meus conseguiram. Acho que o Conectiva usa um modo diferente de configurar o su, ou seja, não é pelo suauth.
Se descobrir como fazer funcionar o suauth , me avisa … rsrsrs
Abraço
Out 11th 2006
Olá Viana …
Cara não usa suauth para isso, utilize o PAM. É compatível com todas as distribuições e funciona que é uma beleza.
Dá uma olhada no FocaLinux que tem um passo-a-passo bem legal:
http://focalinux.cipsga.org.br/guia/avancado/ch-d-restr.htm
Abraços
Out 16th 2006
Bons tempos de #linuxmall, fui master la um tempao
PS: Artigo muito util.
Abs.
Out 16th 2006
Correção, #LinuxALL
Abs.
Nov 6th 2006
Amigo, Aqui na empresa trabalho com OpenSSH e alguns clientes conectados à ele… tive que reinstalar o servidor OpenSSH e agorao mesmo me pede senha a cada conexão.. vc pode me ajudar…
Nov 6th 2006
Junior …
Para que não peça senha a tua chave publica deve estar no arquivo $HOME/.ssh/authorized_keys do usuario que vais fazer o ssh.
Por exemplo: Tu está logado no cliente com o usuario boteco e vaifazer ssh para o usuario root do servidor cachaca. A chave pública do usuario boteco deve estar no arquivo authorized_keys do usuario root no servidor cachaça.
Verifique tambem as seguintes entradas do arquivo /etc/ssh/sshd_config:
RSAAuthentication yes
PubkeyAuthentication yes
Se precisar de mais ajuda me manda um e-mail em PVT.
Abraços
Nov 7th 2006
Leandro Godoy…
Obrigado pela ajuda amigo, ainda não consegui resolver, mas pelomenos vc me deu um direcionamento.
Abs,
Orides Júnior
Mai 11th 2007
Bom artigo, interessante!
Parabéns