Sugestes para defesa contra ataques de fora bruta para SSH

Page 1 of 4

Ncleo de Informao e Coordenao do Ponto br

English

Home

CSIRTs

Estatsticas

Cursos

Documentos

Mapa do Site

FAQ

Sugestes para defesa contra ataques de fora bruta para SSH

Autor: Nelson Murilo Verso: 1.3 -- 10/08/2007

Sumrio
Descrio do problema Caractersticas do ataque Sugestes para defesa Reduo no nmero de equipamentos com servio aberto para Internet Filtragem de origem Limitao de recursos Mover o servio para uma porta no padro Acesso somente via chaves pblicas Limitar incio de conexo (SYN) Configurar pacote knockd Assinatura para o Snort Referncias Agradecimentos Histrico de Revises

Descrio do problema
O servio SSH vem se tornando cada dia mais popular, por conta da sua facilidade de uso, clientes disponveis para qualquer sistema operacional moderno e, principalmente, pela segurana na autenticao e proteo (criptografia) do trfego. E exatamente por conta da maior segurana conseguida com o uso do SSH que muitos administradores tm negligenciado a escolha das senhas. A despeito do SSH permitir vrios mtodos de autenticao, o tradicional usurio/senha , em geral, escolhido pela convenincia na configurao e facilidade de uso por parte do usurio, todavia senhas fracas esto sujeitas a adivinhao e ataques de fora bruta, e tem sido este (descobrir senhas fracas) o objetivo dos ataques de dicionrio verificados contra servidores SSH. Considerando que a maior parte do sistemas Unix modernos vem com o servio SSH habilitado e, mais ainda, vrios equipamentos como roteadores e switches tambm tm o servio disponvel, muitas vezes um servio pode estar habilitado sem que o administrador se d conta da sua exposio.

Caractersticas do ataque
Cada dia mais so verificadas tentativas de ataques de dicionrio contra servidores SSH. Algumas bases de usurio/senha esto disponveis em stios na Internet e vrios atacantes esto montando suas prprias listas e ferramentas para perpetrar este tipo de ataque. Tm-se observado o uso no somente de dicionrios na lngua inglesa, mas tambm em outros idiomas, PORTUGUS inclusive. Um exemplo de um registro de tentativas de ataque pode ser visto abaixo: Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep Sep 21 21 21 21 21 21 21 21 21 21 21 21 12:02:06 12:02:08 12:02:09 12:02:10 12:02:11 12:02:13 12:02:14 12:02:15 12:02:17 12:02:18 12:02:19 12:02:20 srv srv srv srv srv srv srv srv srv srv srv srv sshd[48770]: sshd[48772]: sshd[48774]: sshd[48776]: sshd[48778]: sshd[48780]: sshd[48782]: sshd[48784]: sshd[48786]: sshd[48788]: sshd[48790]: sshd[48792]: Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed password password password password password password password password password password password password for for for for for for for for for for for for invalid invalid invalid invalid invalid invalid invalid invalid invalid invalid invalid invalid user user user user user user user user user user user user ricky from 192.0.2.251 port 58987 ssh2 ricky from 192.0.2.251 port 59042 ssh2 ricky from 192.0.2.251 port 59094 ssh2 ricky from 192.0.2.251 port 59131 ssh2 ricky from 192.0.2.251 port 59182 ssh2 ricky from 192.0.2.251 port 59218 ssh2 roy from 192.0.2.251 port 59268 ssh2 roy from 192.0.2.251 port 59316 ssh2 roy from 192.0.2.251 port 59358 ssh2 roy from 192.0.2.251 port 59405 ssh2 roy from 192.0.2.251 port 59452 ssh2 roy from 192.0.2.251 port 59491 ssh2

Deve-se notar, tambm, que cada tentativa de conexo faz com que o servidor SSH abra uma nova instncia para atender ao possvel acesso, fato que pode comprometer seriamente o desempenho do servidor, em funo da quantidade de tentativas e freqncia da incidncia dos ataques. Na seo Assinatura para o Snort est disponvel uma assinatura para detectar ataques gerados por uma ferramenta que tm sido bastante utilizada para desferir estes ataques.

http://www.cert.br/docs/whitepapers/defesa-forca-bruta-ssh/

30/05/2008

Sugestes para defesa contra ataques de fora bruta para SSH

Page 2 of 4

Sugestes para defesa

As sugestes para defender-se deste tipo de ataque so de vrios tipos, que vo desde simples troca de porta do servio at configuraes de novos servios e regras em firewall. As sugestes podem ser adotadas de forma isolada, mas no existe nenhum impedimento em combin-las, muito pelo contrrio, a adoo de vrias delas combinadas altamente recomendvel.

Reduo no nmero de equipamentos com servio aberto para Internet Esta sugesto se baseia no simples fato de que quanto menos mquinas expostas, menor ser o risco. Isso torna mais fcil o monitoramento, dada a menor quantidade de equipamentos a serem vigiados. A implantao desta sugesto no evita a varredura e ataques aos equipamentos que ainda permanecerem expostos.

Filtragem de origem Vrios servidores SSH no tm a real necessidade de manter o servio exposto para qualquer origem, em geral um nmero limitado de redes/usurios deveriam acessar, remotamente, um determinado servidor, mas estes costumam ser deixados sem limites por conta da convenincia. Uma vez definidas de quais redes que o administrador efetivamente necessitaria ter acesso remoto, os filtros podem ser implementados de mais de uma maneira, pode ser um bloqueio no roteador ou firewall de borda. Outra possibilidade a seleo das origens permitidas por servio, usando recursos como tcpwrappers.

Limitao de recursos Outra sugesto interessante a de limitar a utilizao dos recursos do servio, no caso do OpenSSH isso pode ser feito atravs de clusulas como MaxStartups e MaxAuthTries, que definem, respectivamente, a quantidade de instncias no autenticadas simultneas (por padro so 10), e quantas tentativas sem sucesso so permitidas por usurio (por padro so 6).

Mover o servio para uma porta no padro De simples implementao, no caso do OpenSSH basta editar o arquivo sshd_config e substituir, na clusula Port, a porta 22 por outro valor. Note que este artifcio considerado "segurana por obscuridade", ou seja, no exatamente uma medida corretiva, apenas um paliativo, visto que os ataques, por uma questo de convenincia, tendem a buscar somente a porta padro (22/tcp). Outra questo sobre a necessidade de substituir rotinas automatizadas como cpias de segurana remotas, retreinamento do usurio e uma coisa a mais para lembrar (documentar) quando da atualizao do pacote, ou instalao de um novo servidor. Por fim preciso lembrar que alguns firewalls de empresas bloqueiam portas de servios que no so utilizadas, o que pode ser um problema para um acesso remoto emergencial, visto que um administrador pode no conseguir alcanar sua rede, por conta de um bloqueio feito na rede onde ele est no momento que foi avisado de algum problema.

Acesso somente via chaves pblicas De fcil configurao, bastando (no OpenSSH) mudar para "no" as clusulas PasswordAuthentication e UsePAM, alm de gerar o par de chaves para os usurios e equipamentos envolvidos na autenticao (clientes e servidores). Os principais inconvenientes ficam por conta da dificuldade de conexo via equipamento de terceiros e o treinamento dos usurios. Vale lembrar que este recurso pode no ser de uso simples em alguns clientes SSH e que outros sequer possuem esta funcionalidade.

Limitar incio de conexo (SYN) Algumas ferramentas de ataque, para ganhar eficincia, disparam vrias cpias de si mesmas, sendo deste modo interessante configurar no firewall alguns limitadores. Por exemplo, usando o firewall padro do FreeBSD, possvel criar uma regra com a clusula "limit" associada, para informar quantas conexes simultneas so permitidas para aquela regra, por exemplo: ipfw add allow tcp from any to 200.XX.XX.6 22 limit src-addr 1 Quando utilizado o IPFilter (FreeBSD/NetBSD/Sun/Solaris/HP-UX), um exemplo de uso seria: pass in quick proto tcp from any to 200.XX.XX.6 port = 22 keep limit 1 No caso do PF (OpenBSD), o exemplo abaixo poderia ser usado: pass in quick proto tcp from any to 200.XX.XX.6 port 22 flags S/SA \ keep state (max-src-states 1) Existe uma extenso disponvel para netfilter (chamada ipt_recent) que permite configurar um perodo de tempo no qual uma determinada conexo pode ocorrer, por exemplo a cada 120 segundos:

http://www.cert.br/docs/whitepapers/defesa-forca-bruta-ssh/

30/05/2008

Sugestes para defesa contra ataques de fora bruta para SSH

Page 3 of 4

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 120 -j DROP iptables -A INPUT -p tcp --dport ssh --tcp-flags syn,ack,rst syn -m recent --se t -j ACCEPT Essa abordagem tem um efeito colateral positivo interessante, pois permite bloquear um ataque j no momento da varredura, que normalmente precede o ataque de fora bruta do servio SSH.

Configurar pacote knockd O programa KNOCKD est disponvel atualmente para sistemas Linux, e atua de forma a permitir que, somente aps o usurio enviar uma seqncia previamente conhecida de pacotes, o programa ative um servio pr-determinado, SSH no nosso caso. composto de um servidor (knockd) e um cliente (knock) responsvel por enviar os pacotes da maneira como o knockd espera receber. No exemplo abaixo foi inventada uma seqncia de pacotes que indicasse, ao knockd, que ele deveria iniciar a execuo do servio SSH. O arquivo de configurao knock.conf foi configurado de maneira que, para iniciar o servio, o programa deve receber um pacote (SYN) tcp nas portas 100 e 200 e um pacote UDP na porta 300: [openSSH] sequence = 100:tcp,200:tcp,300:udp seq_timeout = 5 command = /etc/init.d/ssh start tcpflags = syn [closeSSH] sequence = 300:udp,200:tcp,100:tcp seq_timeout = 5 command = /etc/init.d/ssh stop tcpflags = syn E para finaliz-lo deve receber a seqncia inversa. Foi ento executado: # knock sitio.org.br 100:tcp 200:tcp 300:udp Para fechar o servio foi executado na ordem inversa: # knock sitio.org.br 300:udp 200:tcp 100tcp Nos logs ficou registrado: [2005-09-23 [2005-09-23 [2005-09-23 [2005-09-23 [2005-09-23 [2005-09-23 [2005-09-24 [2005-09-24 [2005-09-24 [2005-09-24 [2005-09-24 23:47] 23:47] 23:47] 23:47] 23:47] 23:47] 00:00] 00:00] 00:00] 00:00] 00:00] starting up, listening on eth0 10.0.0.1: openSSH: Stage 1 10.0.0.1: openSSH: Stage 2 10.0.0.1: openSSH: Stage 3 10.0.0.1: openSSH: OPEN SESAME openSSH: running command: /etc/init.d/ssh start 127.0.0.1: closeSSH: Stage 1 127.0.0.1: closeSSH: Stage 2 127.0.0.1: closeSSH: Stage 3 127.0.0.1: closeSSH: OPEN SESAME closeSSH: running command: /etc/init.d/ssh stop

Esta soluo tem alguns inconvenientes, uma vez que alm de tornar mais complexa a ao de login remoto, pois necessita de um passo adicional, o administrador ainda deve escolher com bastante cuidado as portas usadas na sinalizao, por conta de possveis bloqueios quando atrs de firewalls. Outro dificultador o fato de que em alguns ambientes o acesso Internet se d somente atravs de proxy, entre outras limitaes de protocolos e portas, tornando ainda mais complicado o envio de uma seqncia, de pacotes, para um equipamento remoto.

Assinatura para o Snort

Tm sido observada a utilizao, em larga escala, de uma ferramenta para realizar ataques de fora bruta de SSH, que gera trfego com caractersticas peculiares. Estas caractersticas podem ser identificadas no trfego de rede atravs de sistemas de deteco de intruso (IDS). A seguir apresentada uma assinatura para o IDS Snort que identifica ataques na porta 22 gerados por esta ferramenta: alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \ (msg:"Possible SSH brute force attempt"; \ flow:to_server,established; \ threshold:type threshold, track by_src, count 5, seconds 60; \ content:"SSH-2.0-libssh-0.1"; offset: 0; depth: 18;)

Vale ressaltar que o trfego s detectado nos casos em que a ferramenta conseguir estabelecer conexes na porta 22/tcp (SSH).

http://www.cert.br/docs/whitepapers/defesa-forca-bruta-ssh/

30/05/2008

Sugestes para defesa contra ataques de fora bruta para SSH

Page 4 of 4

Referncias
Cyber Security Tip ST04-002: Choosing and Protecting Passwords http://www.us-cert.gov/cas/tips/ST04-002.html

Agradecimentos
Klaus Steding-Jessen Cristine Hoepers

Histrico de Revises
Verso 1.0 Verso Inicial, 11/10/2005 Verso 1.1 Corrigida a regra do OpenBSD PF, includa a seo de Referncias, 17/10/2005 Verso 1.2 Includa a seo de regras para o Snort, corrigidos erros de digitao, 05/01/2006 Verso 1.3 Atualizados o link para o software KNOCKD e a seo de referncias, 10/08/2007

CERT.br Centro de Estudos, Resposta e Tratamento de Incidentes de Segurana no Brasil $Date: 2008/01/30 15:35:40 $

http://www.cert.br/docs/whitepapers/defesa-forca-bruta-ssh/

30/05/2008