Detalhes

Categoria: Como fazer segurança

Atualização: Quinta, 12 Março 2009 21:58

Autor: vovó Vicki

Acessos: 16734

Atualmente, uma das tentativas preferidas dos crackers é forçar a barra em cima do SSH. Bastou colocar meus servidores na zona desmilitarizada para que os logs que registram as tentativas de invasão engordassem em alguns megas todos os dias por conta de sucessivos usuários inexistentes e com senha recusada jogados em cima do SSH.

Analisando o intervalo entre tentativas consecutivas, ficou claro para mim que, na maioria dos casos, tratavam-se de ataques baseados em scripts e pilotados por kiddies ou até mesmo por máquinas zumbi. Mesmo que não tivessem conseguido invadir minhas máquinas, o simples fato de ficar comendo banda e engordando logs já era o suficiente para fazer com que eu perdesse a paciência e tomasse uma providência. Além do mais, eu sabia que apenas a senha escolhida estava segurando a barra, e isto não me agradava nem um pouco.

Se você tiver registros como o mostrado abaixo, então comece a pensar na possibilidade de tomar algumas medidas (espero que este artigo sirva para guiar seu caminho). Peguei um pedacinho do meu log (em /var/log/messages) onde, por incrível que pareça, aparecem dois ataques simultâneos:

Apr 13 17:24:30 nsvicki sshd[21998]: Failed password for root from 134.106.87.87 port 37068 ssh2
Apr 13 17:24:32 nsvicki sshd[22000]: Invalid user alexandra from 69.31.86.145
Apr 13 17:24:32 nsvicki sshd[22000]: reverse mapping checking getaddrinfo for eva222.named1.com
   failed - POSSIBLE BREAKIN ATTEMPT!
Apr 13 17:24:32 nsvicki sshd[22000]: Failed password for invalid user alexandra from 69.31.86.145
   port 50560 ssh2
Apr 13 17:24:32 nsvicki sshd[22004]: Failed password for root from 134.106.87.87 port 37244 ssh2
Apr 13 17:24:35 nsvicki sshd[22010]: Failed password for root from 134.106.87.87 port 37423 ssh2
Apr 13 17:24:35 nsvicki sshd[22007]: Invalid user alexandra from 69.31.86.145
Apr 13 17:24:35 nsvicki sshd[22007]: reverse mapping checking getaddrinfo for eva222.named1.com
   failed - POSSIBLE BREAKIN ATTEMPT!
Apr 13 17:24:35 nsvicki sshd[22007]: Failed password for invalid user alexandra from 69.31.86.145
   port 50827 ssh2
Apr 13 17:24:37 nsvicki sshd[22013]: Failed password for root from 134.106.87.87 port 37610 ssh2
Apr 13 17:24:38 nsvicki sshd[22016]: Invalid user alfred from 69.31.86.145
Apr 13 17:24:38 nsvicki sshd[22016]: reverse mapping checking getaddrinfo for eva222.named1.com
   failed - POSSIBLE BREAKIN ATTEMPT!

Sobre o OpenSSH

Antes de começar, uma observação: este texto se baseia no [url=http://www.openssh.com]OpenSSH[/url]. O OpenSSH é uma versão FREE das ferramentas de conectividade SSH bastante difundida e respeitada por usuários técnicos da Internet. Poucos se dão conta de que o telnet, rlogin e ftp transmitem as senhas através da rede sem criptografia. O OpenSSH encripta todo o tráfego (incluindo-se aí as senhas) para efectivamente eliminar interceptações, sequestro de conexões e outros ataques. Adicionalmente, o OpenSSH permite tunelamento seguro, possui vários métodos de autenticação e dá suporte a todas as versões do protocolo SSH. Para que funcione com a segurança desejada, o OpenSSH precisa estar configurado corretamente.

Configuração de programas cliente

O arquivo que configura o funcionamento de programas cliente é o ssh_config, localizado no diretório /etc/ssh. Abra este arquivo e verifique se os parâmetros citados abaixo (os principais) são:

# Site-wide defaults for various options

Host *
ForwardAgent no
ForwardX11 no
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication yes
FallBackToRsh no
UseRsh no
BatchMode no
CheckHostIP yes
StrictHostKeyChecking no
IdentityFile ~/.ssh/identity
Port 22
Cipher blowfish
EscapeChar ~

Configuração do servidor SSH

O servidor SSH também possui um arquivo de configuração próprio: é o sshd_config que está no diretório /etc/ssh. Verifique se os parâmetros citados abaixo possuem os valores indicados.

# This is ssh server systemwide configuration file.

Port 22
Protocol 2
ListenAddress 192.168.1.1
HostKey /etc/ssh/ssh_host_key
ServerKeyBits 1024
LoginGraceTime 20
MaxStartups 1
KeyRegenerationInterval 3600
PermitRootLogin no
IgnoreRhosts yes
IgnoreUserKnownHosts yes
StrictModes yes
X11Forwarding no
PrintMotd yes
SyslogFacility AUTH
LogLevel INFO
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords no
AllowUsers admin

Alguns recomendam alterar a porta padrão do SSH para alguma outra porta que não esteja sendo usada pelo sistema. O ganho de segurança é muito pequeno, se é que não é nulo porque a maioria das ferramentas hacker identificam com facilidade a mudança. Os parâmetros destacados em negrito tiveram seus valores default alterados:

• O valor default de Protocol é 2, 1. Mude-o para que apenas o protocolo 2 seja aceito (é mais seguro).
• Não permita que o usuário root faça login. Crie um usuário mais fraco para trabalhar com o SSH. Ele sempre pode usar um su para tarefas especiais.
• O LoginGraceTime ajusta o tempo que o servidor SSH espera até que um login seja completado. O valor default de 120 segundos foi drasticamente baixado para 20 segundos.
• O MaxStartups determina quantas conexões simultâneas, não autenticadas (sem login) o daemon SSH permite. O valor default de 10 foi reduzido para apenas 1.

Nenhum destes parâmetros interfere na quantidade de usuários autenticados, apenas dificulta a vida dos falsos usuários e cada um deles representa um pequeno ganho de segurança.

Usuários com acesso a shell

Verifique se os usuários que não precisam usar conexões SSH, como usuários apenas de email ou de FTP, estão com acesso a shell desabilitado. Edite o arquivo /etc/passwd e altere o final dos registros desejados para /sbin/false ou /sbin/nologin

uucp:x:56:15:uucp:/var/spool/uucp:/sbin/nologin
games:x:58:100:games:/usr/games:/sbin/nologin
gopher:x:99:2:gopher:/var/gopher:/sbin/nologin
forest:x:600:611:Forest Gump:/home/forest:/sbin/nologin

Controlando acessos através do inetd

O inetd é um servidor de serviços que trabalha com dois arquivos de configuração sobre os quais falaremos mais tarde. Quando o daemon inetd está ativo, os serviços que estiverem sendo gerenciados por ele são ativados assim que forem solicitados e são desativados assim que forem encerrados. Isto significa que estes serviços não precisam estar no ar, o que reduz a carga do sistema.

Além disso, o inetd permite filtragens de solicitações... exatamente o que estamos procurando! Mas, antes das filtragens que devem frustrar os invasores, vamos aos arquivos de configuração.

A configuração de serviços

O arquivo /etc/services possui uma lista de nomes de serviços associados a números de portas. De acordo com as recomendações da IANA, cada uma das portas bem conhecidas devem ser designadas para o TCP e o UDP, mesmo se o protocolo não der suporte a operações UDP. As portas são divididas em três grupos:

• Portas bem conhecidas, com números de 0 a 1023
• Portas registradas, de 1024 a 49151
• Portas dinâmicas e/ou privadas, de 49152 a 65535

As portas são canais de acesso ao sistema. As mais conhecidas são FTP/21, SSH/22, telnet/23, SMTP/24, HTTP/80 e mais outras tantas. A sintaxe utilizada no arquivo /etc/services é:,/P.

nome-do-serviço   porta/protocolo   [aliases ...]

Um exemplo é:

http   80/tcp   www www-http
http   80/udp   www www-http

A configuração do inetd

O arquivo de configuração /etc/inetd.conf é composto por linhas compostas por vários campos separados por TAB ou ESPAÇO. É importante que todos os campos tenham seus valores definidos:

• nome do serviço
• tipo de socket - o tipo pode ser stream, dgram, raw, rdm ou seqpacket,
• protocolo - precisa ser válido, de acordo com um dos indicados no arquivo /etc/protocols.
• wait/nowait[.max]
• user[.group] ou user[:group] - o usuário (grupo) precisa ser um usuário (grupo) do sistema.
• programa servidor - precisa ser indicado com o caminho completo.
• argumentos do programa servidor

Se quisermos que o SSH seja controlado pelo inetd, precisamos acrescentar a seguinte linha ao /etc/inetd.conf:

ssh   stream   tcp   nowait   root   /usr/sbin/tcpd   sshd -i

O parâmetro -i especifica que o sshd corre através do inetd toda vez que for acionada a porta 22 conforme declarado no arquivo /etc/services.

Sempre que o arquivo de configuração /etc/inetd.conf for alterado, o daemon sshd precisa ser avisado de que houve uma modificação. Para que a nova configuração entre em vigor, dê o comando:

# killall -HUP inetd

Se você fez estas alterações, o sshd passa a ser chamado pelo inetd e não precisa ficar "daemonizado", ou seja, não precisa ficar no ar o tempo todo. Acontece que o daemon está no ar porque foi acionado no boot. Para que isto não ocorra, podemos comentar a chamada ao sshd no /etc/rc.d/rc.inet2 (onde também é feita a chamada para o inetd) ou desabilitar o script /etc/rc.d/rc.sshd. Se você optar pela segunda alternativa, faça um

# chmod 600 /etc/rc.d/rc.sshd

Camuflando a porta 22

Como já foi comentado, podemos mudar a porta do SSH alterando o campo Port ou ListenAdderss no seu arquivo de configuração em /etc/ssh/sshd_config

...
Port 222          (ao invés de 22)
...

ou

...
ListenAddress 192.168.1.10:222
...

onde o IP 192.168.1.10 deve ser substituído pelo IP da sua máquina. Isto não é um grande lance de segurança, mas ajuda a espantar os kiddies. O problema é que as ferramentas hacker detectam com facilidade a nova porta associada ao SSH e fica tudo na mesma.

A alternativa é trocar a porta e o nome do serviço. Aí a camuflagem fica melhorzinha Escolha uma porta livre (existem quantas você quiser no arquivo /etc/services, principalmente na faixa das portas privadas) e dê um nome qualquer a ela. Por exemplo:

inferno   54321/tcp
inferno   54321/udp

Depois de "adquirir" a nova porta, copie o arquivo /usr/sbin/sshd com um nome que soe bem, que pareça um serviço "sério" para que tenha credibilidade, mas que nem de longe lembre o SSH. Digamos que seja in.primed (cuidado para não escolher um nome que já existe, senão você detona o programa original):

# cp /usr/sbin/sshd /usr/sbin/in.primed

Adicione este programa servidor no /etc/inetd.conf. Não se esqueça de colocar comentários que expliquem exatamente o que você está fazendo...

...
# Camuflagem do sshd
# O programa servidor sshd foi copiado para /usr/sbin/in.primed
# A porta 54321 recebeu o nome de inferno em /etc/services
inferno   stream   tcp   nowait   root   /usr/sbin/tcpd   in.primed -i

Para atualizar o inetd, não se esqueça de dar o comando

# killall -HUP inetd

Taí uma boa camuflagem, mas ela pode melhorar ainda mais! Para isto existem os arquivos /etc/hosts.allow e /etc/hosts.deny que são consultados pelo inetd quando se pede uma conexão...

Bloqueando acessos com hosts.allow e hosts.deny

Se os usuários da shell SSH não forem muito numerosos, então os arquivos /etc/hosts.allow e /etc/hosts.deny foram feitos sob medida. O hosts.allow guarda os serviços e os IPs liberados; o hosts.deny indica os serviços e os IPs bloqueados. Antes de ativar um serviço, o inetd confere as proibições no hosts.deny. Logo em seguida, ele confere as permissões no hosts.allow e, caso ele encontre algum dos IPs bloqueados na lista dos permitidos, ele os libera novamente. Isto significa que o hosts.allow tem prioridade. Daí, a solução é um abraço...

Temos o serviço in.primed (o sshd camuflado) disponível na porta 54321. Se quisermos que apenas o host 192.168.1.10 tenha acesso ao serviço, podemos usar o apenas hosts.deny ou o hosts.deny associado ao hosts.allow. Se você quiser usar apenas o hosts.deny, acrescente ao arquivo /etc/hosts.deny

...
in.primed: ALL EXCEPT 192.168.1.10

ou, caso você tenha vários usuários na mesma faixa de IP

...
in.primd: ALL EXCEPT 192.168.1.

Outra forma é negar o acesso a todos os IPs em hosts.deny e depois autorizar um ou mais IPs em hosts.allow. Neste caso, insira a linha indicada abaixo em hosts.deny:

...
in.primed: ALL

e, em hosts.allow

...
in.primed: 192.168.1.10

No meu caso, esta última solução funcionou como uma luva. Tenho poucos usuários do SSH, todos com IPs fixos, o que facilita a configuração. É lógico que, se eu estiver no Japão, tentando me conectar através de um IP nipônico, vou quebrar a cara. Vou ter que fazer uma ligação internacional para o meu gerente de webservices para que ele libere temporariamente determinado IP ou faixa de IP. Acontece que esta é uma possibilidade muito remota e, provavelmente, para você também. Neste caso, esta solução é aceitável.

Moral da história

Meu log está enxutinho, ou seja, os kiddies deram sossego. Mas isto não quer dizer que a solução que encontrei seja adequada para as suas necessidades. Nas minhas pesquisas sobre o assunto, esbarrei uma porção de vezes em sugestões para se usar iptables. São outras soluções para o mesmo problema em condições diferentes. Se este este for o seu caso, dê uma olhada em A Cure for the Common SSH Login Attack da Soloport Corporation, na pettingres.org em sshblack e no excelente artigo do Rainer Wichmann, Defending against brute force ssh attacks