Denial of service lan-side che influisce sulle prestazioni della CPU della destinazione

1

Perché un flood UDP sul lato LAN assume le risorse della CPU del target e lo rende lento? Ad esempio: il mouse non risponde correttamente, l'apertura di un'applicazione è lenta ...

Nota: i computer sono entrambi collegati a uno switch che si collega al router. Inoltre, il target visibile diventa lento quando si apre una pagina Web, e anche dopo la chiusura del browser le prestazioni lente rimangono allo stesso livello.

Nel caso in cui non l'avessi chiarito, le scarse prestazioni si verificano sul computer che viene allagato, non sul computer che esegue l'inondazione. Non appena il denial of service viene interrotto, l'obiettivo ritorna alle sue normali prestazioni.

    
posta John 19.12.2018 - 22:55
fonte

1 risposta

0

Why does a LAN-side UDP flood take up the target's CPU resources and make it sluggish?

Questo dipende da una serie di fattori, uno dei principali è l'azione che sta avvenendo sul sistema che riceve l'inondazione UDP. Diamo un'occhiata alle basi del processo.

Per iniziare, l'host riceve il traffico UDP. Tutto il traffico ricevuto deve essere elaborato in una certa misura. Per lo meno, è necessario determinare la porta di destinazione del traffico UDP. Ciò significa che le intestazioni Ethernet e IP vengono rimosse mentre si sposta attraverso lo stack di rete e viene distribuita per essere elaborata come segmento UDP. Potrebbero esserci anche regole firewall da elaborare.

La porta di destinazione viene controllata per vedere se c'è un'applicazione in ascolto su quella porta UDP (un servizio associato alla porta o una porta utilizzata dal traffico in uscita che potrebbe aspettarsi traffico di risposta).

Se c'è un'applicazione in ascolto sulla porta UDP, le intestazioni UDP vengono rimosse e passate all'applicazione. L'applicazione deve quindi elaborare i dati in qualsiasi modo sia configurato per farlo.

Se non c'è, l'host può rispondere in due modi: silenziosamente rilascia i dati o rifiuta i dati. Rifiutare i dati è generalmente considerato più "amichevole" e fa cose come il debug di easiers in quanto un avviso che il traffico viene respinto viene rinviato all'origine del traffico tramite ICMP. Ciò è utile quando il traffico viene accidentalmente inviato all'host o alla porta errati e può causare l'interruzione del traffico indesiderato (se l'host / applicazione di invio riconosce che il traffico non è desiderato).

Quindi, abbiamo un processo. Ora, in quel processo, la maggior parte di quanto sopra può essere fatto in hardware se la scheda di rete (e il driver, il sistema operativo, ecc.) Lo supportano. Ciò che non viene fatto nell'hardware è fatto nel software eseguendo sulla CPU.

Da dove viene l'utilizzo della CPU? In gran parte dalle seguenti quattro possibilità:

  • Elaborazione del traffico ricevuto (Ethernet - > IP - > UDP), comprese le eventuali regole del firewall
  • Controllo delle applicazioni in ascolto sulla porta UDP
  • Dati di elaborazione delle applicazioni ricevuti su una porta di ascolto
  • Generazione del traffico di ritorno (messaggi di errore ICMP)

Perché un host specifico diventa lento potrebbe essere il risultato dell'esecuzione di uno o più dei precedenti software (ad esempio CPU).

Se un host elabora il traffico (incluse le regole del firewall) e lascia traffico indesiderato (o elabora lo scarto) tutto nell'hardware, non ci dovrebbe essere alcun impatto sulla CPU come conseguenza di un flood UDP alle porte UDP a cui ha nessuna applicazione in ascolto.

Il modo in cui una determinata applicazione viene influenzata dalla ricezione di traffico indesiderato su una porta in ascolto dipende interamente dall'applicazione.

    
risposta data 20.12.2018 - 05:36
fonte

Leggi altre domande sui tag