[Analisi tecnica] Approfondito e facile da comprendere: Introduzione all'attacco dell'attacco e della difesa di rete

Gli attacchi DDoS (Distributed Denial of Service) sono tra quelli più potenti e difficili da difendere, poiché lo scopo principale degli attacchi DDoS è impedire a un bersaglio designato di fornire servizi normali o addirittura di scomparire da Internet.

I DDoS possono essere semplicemente suddivisi in tre categorie a seconda del modo in cui vengono avviati.

La prima categoria vince per forzaEnormi pacchetti di dati si riversano da ogni angolo di Internet, bloccando l'ingresso dell'IDC, rendendo inutili vari potenti sistemi di difesa hardware e processi di emergenza rapidi ed efficienti. Esempi tipici di questo tipo di attacco sono ICMP Flood e UDP Flood, che ora sono rari.

La seconda categoria vince per astuzia, intelligente e impercettibile, inviare un pacco ogni pochi minuti o anche solo necessitare di un pacchetto può far sì che il lussuoso server di configurazione non risponda più. Questo tipo di attacco viene principalmente lanciato sfruttando vulnerabilità in protocolli o software, come attacchi Slowloris, attacchi di collisione hash, ecc., e richiede specifiche coincidenze ambientali.

La terza categoria è una miscela delle due sopraNon solo sfrutta i difetti del protocollo e del sistema, ma offre anche una grande quantità di traffico, come l'attacco SYN Flood e l'attacco DNS Query Flood, che è il metodo di attacco più diffuso attuale.

Questo articolo descriverà uno per uno questi metodi di attacco più comuni e rappresentativi e ne presenterà le opzioni di difesa.

SYN Flood è uno degli attacchi DDoS più classici su Internet, apparso per la prima volta intorno al 1999, con Yahoo come vittima più famosa dell'epoca. Gli attacchi SYN Flood sfruttano difetti TCP triple handshake che possono rendere il server target non reattivo e difficile da tracciare a basso costo.

Il processo standard di handshake a tre vie TCP è il seguente:

• Il client invia un pacchetto TCP contenente il flag SYN, SYN è sincronizzato e il pacchetto di sincronizzazione indica la porta utilizzata dal client e il numero di serie iniziale della connessione TCP.
• Dopo aver ricevuto il pacchetto SYN dal client, il server restituirà un pacchetto SYN+ACK (cioè conferma di conferma), indicando che la richiesta del client è stata accettata e che il numero di serie TCP iniziale viene aggiunto automaticamente con 1.
• Il client invia anche un messaggio di conferma ACK al server, e il numero di serie TCP viene aggiunto anch'esso da 1.
  

Dopo questi tre passaggi, viene stabilita la connessione TCP. Per garantire una trasmissione affidabile, il protocollo TCP ha impostato alcuni meccanismi di gestione delle eccezioni durante le tre strette di mano. Nel terzo passo, se il server non riceve il pacchetto finale di conferma ACK dal client, il server rimarrà nello stato SYN_RECV, aggiungerà l'indirizzo IP del client alla lista d'attesa e riinvierà il pacchetto SYN+ACK nel secondo passaggio. I repost vengono solitamente eseguiti 3-5 volte, e la lista d'attesa viene interrogata una volta a intervalli di circa 30 secondi per riprovare tutti i clienti. D'altra parte, dopo che il server invia il pacchetto SYN+ACK, pre-alloca le risorse per memorizzare le informazioni per la connessione TCP imminente, che vengono mantenute in attesa del ritentativo. Ancora più importante, se le risorse del server sono limitate, lo stato SYN_RECV che può essere mantenuto non accetterà più nuovi pacchetti SYN dopo aver superato il limite, cioè nuove connessioni TCP saranno rifiutate.

SYN Flood utilizza le impostazioni del protocollo TCP sopra indicate per raggiungere lo scopo dell'attacco. Gli attaccanti mascherano un gran numero di indirizzi IP per inviare pacchetti SYN al server e, poiché gli indirizzi IP falsi sono quasi impossibili da esistere, quasi nessun dispositivo restituirà alcuna risposta al server. Di conseguenza, il server mantiene una lunga lista d'attesa e continua a riprovare a inviare pacchetti SYN+ACK, che consuma molte risorse e non può essere rilasciata. Ancora più importante, la coda SYN_RECV del server attaccato è piena di pacchetti dannosi, nuove richieste SYN non vengono più accettate e gli utenti legittimi non possono completare tre strette di mano per stabilire connessioni TCP. In altre parole, il server è stato negato dal servizio da SYN Flood.

Se sei interessato a SYN Flood, puoi dare un'occhiata al http://www.icylife.net/yunshu/show.php?id=367, che ho scritto nel 2006, e che successivamente ho apportato diverse modifiche, corretto bug, ridotto l'aggressività ed è stato usato esclusivamente per i test.

Essendo il servizio più basilare e fondamentale di Internet, il DNS è naturalmente uno dei bersagli importanti degli attacchi DDoS. Far cadere un servizio DNS può indirettamente far crollare l'intera attività di un'azienda o un servizio di rete in una regione. Qualche tempo fa, il popolare gruppo hacker anonymous ha anche annunciato che avrebbe attaccato 13 server DNS su Internet globale, ma alla fine non ci è riuscito.

Gli attacchi UDP sono il metodo più semplice per avviare traffico massiccio, e la falsificazione di IP a fonte casuale è difficile da tracciare. Tuttavia, il filtraggio è più semplice perché la maggior parte degli IP non fornisce servizi UDP, quindi puoi semplicemente scartare il traffico UDP. Pertanto, gli attacchi puramente UDP sono oggi relativamente rari e sono sostituiti da attacchi DNS Query Flood portati dal protocollo UDP. In parole povere, gli attacchi DDoS lanciati su più alto è il protocollo, più difficile è difendersi perché più alto è il protocollo, più è legato al business e più complesso è il sistema di difesa.

Il DNS Query Flood si verifica quando un attaccante manipola un gran numero di macchine sockpuppet per lanciare un gran numero di richieste di query di nome di dominio al target. Per prevenire il filtraggio basato su ACL, è necessario migliorare la casualità dei pacchetti. Una pratica comune è falsificare casualmente l'indirizzo IP sorgente, falsificare casualmente la porta sorgente e altri parametri al livello UDP. Al livello del protocollo DNS, l'ID della query viene forgiato casualmente insieme al nome di dominio da risolvere. Oltre a prevenire il filtraggio, la risoluzione casuale dei nomi di dominio falsificati può anche ridurre la probabilità di colpire la cache DNS e consumare quante più risorse CPU possibile del server DNS.

Per quanto riguarda il codice per DNS Query Flood, ho scritto un codice a luglio 2011 per testare le prestazioni del server, e il link è http://www.icylife.net/yunshu/show.php?id=832. Allo stesso modo, questo codice è artificialmente meno aggressivo ed è solo a scopo di test.

Il SYN Flood e il DNS Query Flood descritti sopra possono essere efficacemente difesi a questo punto, e il vero problema per i grandi produttori e le aziende Internet sono gli attacchi HTTP Flood. HTTP Flood è un attacco a un servizio web su un protocollo di settimo livello. Il suo grande danno si manifesta principalmente in tre aspetti: iniziazione comoda, filtraggio difficile e impatto di vasta portata.

Sia SYN Flood che DNS Query Flood richiedono agli attaccanti di controllare un gran numero di bot con privilegi root. Ci vuole tempo e fatica per raccogliere un gran numero di privilegi root e, durante l'attacco, la macchina burattina è lenta a rifornire a causa della rapida perdita di risorse da parte dell'attaccante dovuta al traffico anomalo scoperto dall'amministratore, causando una significativa riduzione dell'intensità dell'attacco e non può essere sostenuta a lungo. Gli attacchi HTTP Flood sono diversi: gli attaccanti non devono controllare un gran numero di bot, ma invece usano scanner di porte per trovare proxy HTTP anonimi o proxy SOCKS su Internet, attraverso i quali l'attaccante avvia richieste HTTP al bersaglio dell'attacco. I proxy anonimi sono una risorsa relativamente ricca e non è difficile ottenerli in pochi giorni, quindi gli attacchi sono facili da avviare e possono durare a lungo.

D'altra parte, gli attacchi flood HTTP vengono lanciati al livello HTTP, che imita vigorosamente il comportamento delle richieste di pagina web degli utenti normali, strettamente correlato al business del sito web, rendendo difficile per i fornitori di sicurezza fornire una soluzione comune che non influisca sull'esperienza utente. Regole che funzionano bene in un solo posto, cambiare scenario può portare a un gran numero di omicidi colposi.

Infine, gli attacchi HTTP flood possono causare gravi reazioni a catena, non solo causando una risposta lenta dal front-end web attaccato, ma anche attaccando indirettamente il back-end Java e altri servizi logici di business e database back-end, aumentando la loro pressione e persino incidendo sui server di archiviazione log.

Curiosamente, HTTP Flood ha anche un soprannome storico chiamato attacco CC. CC è l'abbreviazione di Challenge Collapsar, un dispositivo di protezione DDoS di una nota azienda di sicurezza in Cina. A giudicare dalla situazione attuale, non solo Collapsar, ma anche tutte le attrezzature hardware di difesa sono ancora oggetto di sfida, e il rischio non è stato rimosso.

Quando si tratta di attacchi, la prima reazione è traffico massiccio e pacchetti enormi. Ma esiste un attacco che fa l'opposto, noto per essere lento, così che alcuni bersagli vengono uccisi senza sapere come muoiono, che è l'attacco slow connection; il più rappresentativo è lo Slowloris inventato da rsnake.

Il protocollo HTTP stabilisce che le richieste HTTP terminino in \r\n\r\n, indicando che il client ha terminato di inviare e che il server ha iniziato l'elaborazione. E cosa succede se non mandi mai \r\n\r\n? Slowloris sfrutta questo a suo vantaggio negli attacchi DDoS. L'attaccante imposta la Connessione su Keep-Alive nell'intestazione della richiesta HTTP, chiede al server web di mantenere la connessione TCP non disconnessa, e poi invia lentamente un formato chiave-valore al server ogni pochi minuti, come a:b\r\n, facendo pensare al server che l'intestazione HTTP non sia stata ricevuta e aspettando. Se un attaccante utilizza il multithreading o un puppet per fare lo stesso, il container web del server verrà rapidamente sopraffatto dall'attaccante e non accetterà più nuove richieste.

Presto iniziarono a comparire varie varianti di Slowloris. Ad esempio, il metodo POST invia dati al Web Server, riempie un grande contenuto di lunghezza di contenuto ma lento byte per byte contenuto contenuto di dati reali POST, ecc. Per quanto riguarda l'attacco Slowloris, rsnake fornisce anche un codice di test, vedi http://ha.ckers.org/slowloris/slowloris.pl.

Quanto sopra introduce diversi metodi di attacco di base, ognuno dei quali può essere usato per attaccare la rete e persino sconfiggere giganti siti web come Alibaba, Baidu e Tencent. Ma non è tutto, diversi livelli di attaccanti possono lanciare attacchi DDoS completamente diversi, e il loro uso è la stessa cosa.

Gli attaccanti avanzati non usano mai un singolo vettore per attaccare, ma li combinano in modo flessibile in base all'ambiente target. Il Flood SYN ordinario è facile da filtrare tramite dispositivi di pulizia del traffico tramite rilevamento inverso, cookie SYN e altri mezzi tecnici, ma se i pacchetti SYN+ACK sono miscelati in SYN Flood, in modo che ogni pacchetto SYN falsificato abbia un pacchetto di conferma client falsificato corrispondente, il corrispondente qui si riferisce all'indirizzo IP sorgente, porta sorgente, IP di destinazione, porta di destinazione, dimensione della finestra TCP, TTL, ecc. sono tutti in linea con le caratteristiche dello stesso host e dello stesso flusso TCP. La pressione sulle prestazioni della rilevazione inversa e dei cookie SYN delle apparecchiature di pulizia del flusso aumenterà significativamente. In effetti, i pacchetti dati SYN e vari altri bit flag hanno effetti di attacco speciali, che qui non vengono introdotti. Esistono anche tecniche uniche per il DNS Query Flood.

Innanzitutto, il DNS può essere diviso in DNS ordinario e DNS di dominio autorizzato, attaccando il DNS ordinario, l'indirizzo IP deve essere falsificato casualmente e il server richiede una risoluzione ricorsiva; Tuttavia, quando si attacca il DNS del dominio autorizzato, l'indirizzo IP sorgente falsificato non dovrebbe essere puramente casuale, ma dovrebbe essere raccolto in anticipo gli indirizzi DNS degli ISP di tutto il mondo, per ottenere il massimo effetto di attacco, così che il dispositivo di pulizia del traffico si trovi nella situazione imbarazzante di aggiungere o non aggiungere una blacklist IP. Aggiungerlo porterà a un gran numero di omicidi colposi e, se non aggiungi una blacklist, ogni pacchetto deve essere verificato al contrario, il che aumenta la pressione sulle prestazioni.

D'altra parte, come accennato prima, per aumentare la pressione di pulizia del dispositivo, è necessario randomizzare il nome di dominio richiesto senza dover usare la cache, ma va notato che il nome di dominio da risolvere deve avere una certa regolarità nella falsificazione, come falsificare solo una certa parte del nome di dominio e solidificare una parte per superare la whitelist impostata dal dispositivo di pulizia. La ragione è semplice: i server di Tencent possono risolvere solo i nomi di dominio di Tencent, e nomi di dominio completamente casuali possono essere scartati direttamente e devono essere consolidati. Ma se è completamente riparato, è facile scartarlo direttamente, quindi deve essere forgiato.

In secondo luogo, gli attacchi al DNS non dovrebbero concentrarsi solo sulle porte UDP, che sono anch'esse servizi standard secondo il protocollo DNS. In caso di attacco, possono essere eseguiti contemporaneamente attacchi UDP e TCP.

L'obiettivo di HTTP Flood è quello di superare la cache nel frontend e raggiungere direttamente il Web Server stesso tramite le impostazioni del campo nell'intestazione HTTP. Inoltre, HTTP Flood è anche molto critico per la selezione dei bersagli, e gli attaccanti ordinari sceglieranno pagine che richiedono molte query dati come la ricerca come target di attacco, il che è molto corretto e può consumare quante più risorse possibile del server. Ma questo attacco è facile da identificare tramite l'attrezzatura di pulizia tramite l'identificazione uomo-macchina, quindi come risolvere questo problema? È molto semplice, cerca di scegliere pagine che gli utenti normali possono accedere anche tramite l'APP, generalmente varie Web API. Gli utenti normali e il traffico malevolo provengono dall'APP, e la differenza tra uomo e macchina è molto piccola, ed è difficile distinguere tra l'integrazione di base.

Ogni connessione TCP esiste sia sul lato server che su se stessa, e deve anche consumare risorse per mantenere lo stato TCP, quindi la connessione non può essere mantenuta troppo. Se questo può essere risolto, l'aggressività sarà notevolmente aumentata, cioè Slowloris può lanciare attacchi in modo senza stato, catturare il numero di serie TCP e confermare la manutenzione delle connessioni TCP sul client tramite sniffing, e il kernel di sistema non deve prestare attenzione ai vari cambiamenti di stato di TCP, e un notebook può generare fino a 65.535 connessioni TCP.

Le descrizioni precedenti sono tutte miglioramenti tecnici per l'attacco. Dal lato umano, ci sono altri mezzi. Se SYN Flood invia un gran numero di pacchetti ed è accompagnato da connessioni lente di Slowloris, quante persone scopriranno il segreto? Anche se il server si blocca, possono essere trovati solo attacchi SYN, che cercano di rafforzare la pulizia del livello TCP e ignorano il comportamento del livello applicativo. Tutti i tipi di attacchi possono lavorare insieme per ottenere il massimo effetto. La scelta dell'orario di attacco è anche un punto chiave, come scegliere il personale di manutenzione quando pranza, quando il personale di manutenzione è bloccato sulla strada dopo il lavoro o quando non c'è segnale sulla scheda di rete wireless della metropolitana, e quando l'azienda target sta organizzando un evento su larga scala e il traffico aumenta.

Si tratta di un attacco puro, quindi non viene fornito alcun codice né spiegazioni approfondite.

I metodi di attacco precedenti richiedono più o meno alcuni bot, anche HTTP Flood richiede la ricerca di un gran numero di proxy anonimi. Se c'è un attacco, basta emettere alcune istruzioni, e la macchina si avvicinerà automaticamente per eseguirlo, che è la soluzione perfetta. Questo attacco è già apparso, e questo proviene da reti P2P.

Come tutti sappiamo, gli utenti P2P e il traffico su Internet sono un numero estremamente elevato. Se tutti vanno in un luogo designato per scaricare dati e collegare migliaia di indirizzi IP reali, nessun dispositivo può supportarlo. Prendiamo ad esempio il download di BT: falsificare torrent di alcuni video popolari e pubblicarli sui motori di ricerca è sufficiente a ingannare molti utenti e traffico, ma questo è solo un attacco di base.

Gli attacchi P2P avanzati sono spoofing diretto dei server di gestione delle risorse. Ad esempio, il client Thunder caricherà le risorse trovate sul server di gestione delle risorse e poi le invierà ad altri utenti che devono scaricare le stesse risorse, così che un link venga pubblicato. Attraverso l'inversione dei protocolli, gli attaccanti creano una grande quantità di informazioni sulle risorse popolari e le distribuiscono attraverso il centro di gestione delle risorse, che possono essere distribuite istantaneamente in tutta la rete P2P. Ciò che è ancora più spaventoso è che questo attacco non può essere fermato, nemmeno dall'attaccante stesso, e l'attacco continua finché il funzionario P2P non individua il problema e aggiorna il server e l'utente scaricabile riavvia il software scaricato.

Questo è tutto ciò che c'è nell'introduzione agli attacchi DDoS, e non voglio andare oltre—basta capire che tanta difesa è sufficiente.

In generale, gli attacchi DDoS possono essere abili e aggraziati. La bellezza dell'applicazione risiede nell'unità della mente.