SYN Flood

[Jonathan403]

Pessoal, estou com 2 dúvidas. Eu tava estudando sobre SYN Flood, e vi q ele consiste em tu enviar vários segmentos TCP com a flag SYN ativada. E aí o alvo vai responder com o SYN/ACK, e tu não responde mais nada. Só vai enviando um monte de SYN. Só q tipo, eu tava fazendo aqui um teste na minha máquina, e comecei a analisar com o tcpdump. E me deparei com o seguinte:
Quando eu uso o hping3 pra fazer o ataque DoS, ele ta mandando o SYN, o alvo ta respondendo com o SYN/ACK, porém o meu PC envia um RST logo após. Então minha primeira dúvida é:
Ele deveria enviar esse RST no final mesmo ?

E a segunda dúvida é, eu fiz o mesmo ataque porém agora usando um módulo do metasploit e também fiz o mesmo teste com o scapy. E analisei com o tcpdump denovo. Porém dessa vez, eu envio um monte de SYN, e o alvo não me responde com um SYN/ACK. Seria normal isso ?

Vou mandar um print aqui da analise q fiz pelo tcpdump

OBS:
- No host-alvo to executando um servidor PHP na porta 7777
- To usando Debian 10
- Isso é apenas pra conhecimento. Não vou sair por aí dando ataque DoS
- O SYN Cookies ta desativado

Rodei o hping3 assim:

# hping3 127.0.0.1 -I lo --flood -p 7777 -S

E rodei o código no scapy assim:

a = IP(dst='127.0.0.1')/TCP(sport=RandShort(), dport=7777, flags="S")
send(a, loop=1,verbose=0)

Com hping3:

 

Com scapy ou Metasploit:

[Dirceu]

Posso estar enganado, pois faz algum tempo que não mexo com isso.

A resposta RST do hping aparentemente está normal uma vez que ele não quer efetivamente estabelecer uma conexão. O hping é usado como scanner de portas e hosts.

Quanto a outra questão, vc estaria com algum firewall de pé?

[Jonathan403]

Mas tipo, o propósito do SYN Flood não é deixar o alvo esperando pelo ACK final ? E enquanto o alvo ta esperando pelo ACK, eu to mandando um monte de SYN ? E aí quando ele manda o RST, isso não iria contra a idéia do SYN Flood pois fecharia conexão ? Me corrija se eu estiver errado por favor

E com relação ao firewall, não to usando nenhum aqui. Ta desativado

[Dirceu]

Bem, eu diria que objetivo primário do hping é fingir que quer uma conexão real para forçar a resposta do servidor, sendo por isso normalmente usado como portscan.

O scapy e o metasploit tem que verificar a montagem do pacote e se o módulo tá funcionando corretamente, respectivamente.

Vamos esperar outras respostas de alguém com mais experiência.

[Fernando Mercês]

Não tenho certeza, mas talvez o RST seja enviado pelo SO, na linha do que o @Dirceu disse. Um workaround que consigo imaginar é bloquear pacotes TCP com essa flag. Já que você tá no Debian, vai ser algo como:

iptables -A OUTPUT -p tcp --tcp-flags RST -j DROP

E claro, depois vai ter que deletar essa regra, porque nada de rede nessa máquina vai funcionar mais hehe.

Abraço!

[Jonathan403]

Funcionou perfeitamente mercês, muito Obrigado!!

[Dirceu]

Depois acho que vale a pena tentar a opção --tcpexitcode do hping!

[Jonathan403]

Certo Dirceu, vou dar uma pesquisada sobre esse parametro dps! Valeu!

[Antonio Costa]

Umas sugestões ai caso queira ir além...

Nesses labs gosto de testar raw sockets e deixar algo em listening com a lib pcap, para entender a fundo o que se passa...

Seria super massa entender os internals para trabalhar com raw sockets(lembrando que tem a libnet que pode facilitar).

Fica alguma coisa para você estudar e brincar no seu lab.

https://github.com/CoolerVoid/ninja_shell

https://github.com/CoolerVoid/Hyde

 

Paper old entretanto bem massa, com as dicas que pode te ajudar a fazer um scan de portas.

https://nmap.org/nmap_doc.html

 

Esse caso queira ir além ele tem um recurso com PF_RING.

https://github.com/robertdavidgraham/masscan

 

Tool massa que os mestres MB e Fred ajudaram.

https://sourceforge.net/projects/t50/

 

[Jonathan403]

Opa, muito obrigado antonio!. Muito massa, Vou dar uma estudada nisso!