Hping3 non funziona?

Question

Hping3 non funziona?

#1 da (1 voti)
#2 da (-3 voti)

-2

Stavo cercando di eseguire un attacco di tipo SYN flood e stavo usando hping3. Ecco come appare il comando:

 sudo hping3 -S -a 192.168.100.88 --flood -p 80 192.168.100.15

Dove 192.168.100.88 è un indirizzo IP non esistente. Il server attaccato dovrebbe rispondere e creare connessioni semiaperte.

Come risultato ho questo:

    elvin@elvin-VPCZ21X9R:~$ sudo hping3 -S -a 192.168.100.88 --flood -p 80 192.168.100.15
HPING 192.168.100.15 (wlp2s0 192.168.100.15): S set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
--- 192.168.100.15 hping statistic ---
22082825 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

Che cos'è: 100% packet lost ? Cosa significa?

Poi ho aperto Wireshark e non ho visto traffico che sembrava un diluvio.

Avevo eseguito l'alluvione SYN? O non funzionava?

Ho anche effettuato il ping dell'indirizzo IP durante l'invio dei pacchetti utilizzando questo comando

ping 192.168.100.15

È giusto controllare con questo comando lo stato del server apache2?

tcp ping flooding

posta Elvin 02.05.2018 - 11:48

fonte

2 risposte

Leggi altre domande sui tag tcp ping flooding

Quale software posso utilizzare per modificare e riprodurre i pacchetti? [chiuso] Come lasciare una backdoor in un'applicazione Laravel?

score 1 · Answer 1

Prima di tutto, se si falsifica un indirizzo IP sorgente, non si otterranno risposte dalla destinazione come i pacchetti SYN / ACK vanno all'indirizzo falso.

Oltre a ciò, se wireshark non mostra il traffico in uscita appropriato, supponendo che l'hai usato correttamente, ci sono alcuni possibili motivi:

lo stack IP potrebbe filtrare i pacchetti con spoofing
il tuo filtro di pacchetti locale potrebbe rilasciare pacchetti con un SRC che non è il tuo vero indirizzo.

Inoltre, un ping sul computer di destinazione non è ciò che fornirà risultati accurati sullo stato dello stack TCP del target (e un server Web non ha nulla a che fare con questo).

Vedi, quando sincronizzi le alluvioni, il tuo obiettivo è di avere tante connessioni semiaperte che lo stack TCP del sistema operativo non consente di creare nuove connessioni.

Solo su connessioni complete mirate al programma che gestisce le connessioni (in questo caso sembra un apache) esaurisce memoria, handle di file o cpu.

Solo in quest'ultimo caso puoi sperare che la memoria o l'esaurimento della CPU mantengano il sistema operativo dal rispondere ai ping, e anche in modo non affidabile. Inoltre, Apache non gira di processi come pazzi, anche su connessioni complete, il numero massimo di processi sarà probabilmente raggiunto prima che l'esaurimento delle risorse sia un problema.

Quindi, per verificare se il tuo attacco ha un impatto sulla disponibilità del server web attaccato, dovresti piuttosto curl di ping per fare una richiesta completa - se quella connessione va in timeout, il tuo attacco funziona.

score -3 · Answer 2

Penso che dovresti controllare le tue tabelle di routing del server e dell'host. Stai utilizzando l'opzione -a

-a --spoof hostname
          Use this option in order to set a fake IP source address, this option ensures that target will not gain your real address. However  replies  will  be  sent  to
          spoofed address, so you will can't see them. In order to see how it's possible to perform spoofed/idle scanning see the HPING3-HOWTO.

Ciò significa che se la macchina sorgente ha un IP come 192.168.100.1 e si modifica l'IP sorgente su 192.168.100.88, il server risponderà a 192.168.100.88, non a 192.168.100.1. Inoltre sarebbe una buona idea pappare il traffico sul lato server per vedere questo effetto.