{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS a supporto: come eseguiamo test di stress e di carico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nL'azienda Variti sviluppa soluzioni di protezione da bot e attacchi DDoS, oltre a condurre test di stress e di carico. Alla conferenza HighLoad++ 2018 abbiamo parlato di come mettere in sicurezza le risorse da vari tipi di attacchi. In breve: isola le parti del sistema, utilizza servizi cloud e CDN e aggiorna regolarmente. Ma senza aziende specializzate nella protezione non ce la farete comunque \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nPrima di leggere il testo puoi consultare i brevi punti chiave sul sito della conferenza<\/a><\/noindex>.
\nE se non ami leggere o vuoi semplicemente guardare un video, la registrazione della nostra presentazione si trova qui sotto nel spoiler.<\/p>\n

Registrazione video della presentazione<\/b>

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Molte aziende sono gi\u00e0 in grado di effettuare test di carico, ma non tutte eseguono test di stress. Alcuni dei nostri clienti pensano che il loro sito sia invulnerabile perch\u00e9 hanno un sistema highload, e questo li protegge bene dagli attacchi. Noi dimostriamo per\u00f2 che non \u00e8 del tutto vero.
\nNaturalmente, prima di eseguire i test otteniamo autorizzazione dal cliente, con firma e timbro, e con il nostro aiuto non \u00e8 possibile effettuare un attacco DDoS su nessuno. I test vengono condotti nel momento scelto dal cliente, quando il traffico sul suo sito \u00e8 minimo, evitando che eventuali problemi di accesso coinvolgano i clienti. Inoltre, poich\u00e9 durante i test possono sempre verificarsi imprevisti, manteniamo un contatto costante con il cliente. Questo consente non solo di comunicare i risultati raggiunti, ma anche di apportare modifiche durante i test. Al termine dei test redigiamo sempre un rapporto in cui evidenziamo le vulnerabilit\u00e0 riscontrate e forniamo raccomandazioni su come affrontare i punti deboli del sito. <\/p>\n

Come lavoriamo<\/h3>\n

\nDurante i test emuliamo un botnet. Poich\u00e9 lavoriamo con clienti che non si trovano nelle nostre reti, affinch\u00e9 il test non si concluda nel primo minuto a causa dell'attivazione dei limiti o delle protezioni, applichiamo il carico non da un solo IP, ma dalla nostra sottorete. Inoltre, per generare un carico significativo disponiamo di un potente server di test.<\/p>\n

Postulati<\/h3>\n

<\/p>\n

Molto non significa necessariamente bene<\/b>
\nMeno carico ci vorr\u00e0 per portare il servizio al collasso, meglio sar\u00e0. Se riusciamo a far s\u00ec che il sito smetta di funzionare con una richiesta al secondo, o addirittura con una richiesta al minuto, sar\u00e0 fantastico. Questo perch\u00e9, per legge di Murphy, gli utenti o i malintenzionati cadranno esattamente in questa vulnerabilit\u00e0. <\/p><\/blockquote>\n

Un guasto parziale \u00e8 meglio di uno totale<\/b>
\nConsigliamo sempre di rendere i sistemi eterogenei. Inoltre, \u00e8 importante separarli a livello fisico, e non solo attraverso la containerizzazione. In caso di separazione fisica, anche se qualcosa sul sito smette di funzionare, \u00e8 molto probabile che non smetta di funzionare completamente, e gli utenti possano ancora accedere, almeno a una parte delle funzionalit\u00e0.<\/p><\/blockquote>\n

Una corretta architettura \u00e8 la base della resilienza<\/b>
\nLa resilienza di una risorsa e la sua capacit\u00e0 di resistere ad attacchi e carichi devono essere integrate fin dalla fase di progettazione, praticamente nella fase di creazione dei primi diagrammi a blocchi. Infatti, se si introducono errori fatali, pu\u00f2 essere difficile correggerli successivamente.<\/p><\/blockquote>\n

Non deve essere solo il codice a essere buono, ma anche il configurazione<\/b>
\nMolti pensano che un buon team di sviluppo garantisca la resilienza del servizio. Un buon team di sviluppo \u00e8 sicuramente necessario, ma \u00e8 altrettanto importante avere una buona gestione, un buon DevOps. Ossia, dobbiamo avere specialisti che configurino correttamente Linux e la rete, scrivano le configurazioni giuste in nginx, impostino limiti e altro. Altrimenti, la risorsa funzioner\u00e0 bene solo in test, ma in produzione, a un certo punto, tutto si romper\u00e0.<\/p><\/blockquote>\n

Differenze tra test di carico e test di stress<\/b>
\nIl test di carico consente di identificare i limiti di funzionamento del sistema. Il test di stress \u00e8 finalizzato a identificare i punti deboli del sistema e viene utilizzato per cercare di romperlo e vedere come si comporta durante il collasso di alcune parti. A tal fine, il carico caratteristico rimane solitamente sconosciuto per il cliente fino all'inizio del test di stress.<\/p><\/blockquote>\n

<\/p>\n

Caratteristiche distintive degli attacchi L7<\/h3>\n

\nDi solito suddividiamo i tipi di carico in carichi a livello L7 e L3&4. L7 \u00e8 il caricamento a livello applicativo, di solito si intende solo HTTP, noi invece intendiamo qualsiasi carico a livello di protocollo TCP.
\nGli attacchi L7 hanno alcune caratteristiche distintive. Innanzitutto, arrivano direttamente all'applicazione, quindi \u00e8 difficile rifletterli con mezzi di rete. Questi attacchi utilizzano la logica e, grazie a ci\u00f2, consumano in modo molto efficiente e con un traffico ridotto CPU, memoria, disco, database e altre risorse.<\/p>\n

HTTP Flood<\/h3>\n

\nIn caso di qualsiasi attacco, \u00e8 pi\u00f9 semplice generare un carico che gestirlo, e nel caso di L7 questo \u00e8 altrettanto vero. Il traffico dell'attacco non \u00e8 sempre facile da distinguere da quello legittimo e, nella maggior parte dei casi, si riesce a farlo in base alla frequenza, ma se tutto \u00e8 pianificato in modo intelligente, \u00e8 impossibile capire dai log dove ci sia un attacco e dove ci siano richieste legittime.
\nCome primo esempio, consideriamo l'attacco HTTP Flood. Dal grafico si pu\u00f2 vedere che di solito questi attacchi sono molto potenti; nell'esempio qui sotto, il numero massimo di richieste ha superato le 600.000 al minuto.<\/p>\n

\"DDoS
\n
\nHTTP Flood \u00e8 il modo pi\u00f9 semplice per generare un carico. Di solito, si utilizza uno strumento di testing del carico, come ApacheBench, e si impostano le richieste e l'obiettivo. Con questo approccio semplice, c'\u00e8 una grande possibilit\u00e0 di imbattersi nella cache del server, ma \u00e8 facile aggirarlo. Ad esempio, aggiungendo stringhe casuali nella richiesta, costringendo cos\u00ec il server a restituire continuamente una nuova pagina.
\nNon bisogna dimenticare l'user-agent durante la generazione del carico. Molti user-agent degli strumenti di test pi\u00f9 popolari vengono filtrati dagli amministratori di sistema, e in tal caso il carico potrebbe semplicemente non arrivare al backend. \u00c8 possibile migliorare notevolmente i risultati inserendo nella richiesta un'intestazione pi\u00f9 o meno valida di un browser.
\nNonostante la semplicit\u00e0, gli attacchi HTTP Flood presentano anche i loro svantaggi. In primo luogo, per generare un carico sono necessarie grandi risorse. In secondo luogo, questi attacchi sono molto facili da rilevare, soprattutto se provengono da un singolo indirizzo. Di conseguenza, le richieste iniziano immediatamente a essere filtrate dagli amministratori di sistema o anche a livello del fornitore. <\/p>\n

Cosa cercare<\/h3>\n

\nPer ridurre il numero di richieste al secondo e mantenere comunque l'efficienza, \u00e8 necessario avere un po' di fantasia e analizzare il sito. Ad esempio, si pu\u00f2 caricare non solo il canale o il server, ma anche singole parti dell'applicazione, come database o sistemi di file. Si possono anche cercare posti sul sito che effettuano calcoli complessi: calcolatrici, pagine di selezione dei prodotti e altro. Infine, spesso capita che ci sia uno script php sul sito che genera una pagina da centinaia di migliaia di righe. Questo script carica notevolmente il server e pu\u00f2 diventare un obiettivo per attacchi.<\/p>\n

Dove cercare<\/h3>\n

\nQuando scansioniamo una risorsa prima di effettuare un test, innanzitutto guardiamo, naturalmente, il sito stesso. Cerchiamo vari campi di input, file pesanti: insomma, tutto ci\u00f2 che pu\u00f2 creare problemi alla risorsa e rallentare il suo funzionamento. In questo ci aiutano gli strumenti di sviluppo banali di Google Chrome e Firefox, che mostrano i tempi di risposta della pagina.
\nScansioniamo anche i sottodomini. Ad esempio, c'\u00e8 un negozio online, abc.com, e ha un sottodominio admin.abc.com. Probabilmente si tratta di un'area admin con autenticazione, ma se la si sottopone a carico, potrebbe creare problemi per la risorsa principale.
\nIl sito potrebbe avere un sottodominio api.abc.com. Probabilmente \u00e8 una risorsa per applicazioni mobili. L'app pu\u00f2 essere trovata su App Store o Google Play, impostare un punto di accesso speciale, decodificare l'API e registrare account di test. Il problema \u00e8 che spesso le persone pensano che tutto ci\u00f2 che \u00e8 protetto da autenticazione sia immune agli attacchi di negazione del servizio. Si crede che l'autenticazione sia la migliore CAPTCHA, ma non \u00e8 cos\u00ec. Creare 10-20 account di test \u00e8 semplice, e una volta creati, si ottiene accesso a funzionalit\u00e0 complesse e non protette.
\nNaturalmente, guardiamo la storia, il robots.txt e il WebArchive, ViewDNS, cercando vecchie versioni della risorsa. A volte capita che gli sviluppatori abbiano rilasciato, ad esempio, mail2.yandex.net, mentre la vecchia versione, mail.yandex.net, \u00e8 rimasta. Questo mail.yandex.net smette di essere supportato, non vengono allocati risorse di sviluppo, ma continua a consumare il database. Di conseguenza, utilizzando la vecchia versione, si possono sfruttare efficacemente le risorse del backend e tutto ci\u00f2 che sta dietro il layout. Certamente, ci\u00f2 non accade sempre, ma ci troviamo comunque di fronte a situazioni simili piuttosto frequentemente.
\nNaturalmente, analizziamo tutti i parametri della richiesta e la struttura dei cookie. Possiamo, per esempio, inserire un valore in un array JSON all'interno dei cookie, creare un'elevata nidificazione e costringere la risorsa a lavorare irragionevolmente a lungo.<\/p>\n

Carico della ricerca<\/h3>\n

\nLa prima cosa che viene in mente quando si esplora un sito web \u00e8 di sovraccaricare il database, poich\u00e9 la ricerca \u00e8 presente quasi ovunque e, purtroppo, \u00e8 mal protetta nella maggior parte dei casi. Per qualche motivo, gli sviluppatori non prestano sufficiente attenzione alla ricerca. Tuttavia, c'\u00e8 un consiglio: non dovresti fare richieste simili, poich\u00e9 potresti incontrare caching, come nel caso di un attacco HTTP flood.
\nEffettuare richieste casuali al database non \u00e8 sempre efficace. \u00c8 molto meglio creare un elenco di parole chiave relative alla ricerca. Se torniamo all'esempio di un negozio online: supponiamo che il sito venda pneumatici per auto e permetta di impostare il raggio delle gomme, il tipo di auto e altri parametri. Di conseguenza, le combinazioni di parole pertinenti costringeranno il database a lavorare in condizioni molto pi\u00f9 complesse.
\nInoltre, \u00e8 opportuno utilizzare la paginazione: \u00e8 molto pi\u00f9 difficile per la ricerca restituire la penultima pagina dei risultati rispetto alla prima. In altre parole, grazie alla paginazione puoi diversificare il carico.
\nNell'esempio qui sotto mostriamo il carico sulla ricerca. Si vede che fin dai primi secondi del test, a una velocit\u00e0 di dieci richieste al secondo, il sito \u00e8 andato in crash e non ha risposto.<\/p>\n

\"DDoS
\n<\/p>\n

Se non c'\u00e8 ricerca?<\/h3>\n

\nSe non c'\u00e8 ricerca, non significa che il sito non contenga altri campi di input vulnerabili. Un campo del genere potrebbe essere l'autenticazione. Al giorno d'oggi, gli sviluppatori amano creare hash complessi per proteggere il database delle credenziali dagli attacchi tramite tabelle arcobaleno. Questo \u00e8 positivo, ma tali hash consumano molte risorse CPU. Un grande afflusso di false autenticazioni pu\u00f2 portare a un sovraccarico della CPU e, di conseguenza, il sito smette di funzionare.
\nLa presenza di vari moduli per commenti e feedback sul sito \u00e8 un motivo per inviare testi molto lunghi o semplicemente creare un massiccio flood. A volte i siti accettano file allegati, incluso nel formato gzip. In tal caso, prendiamo un file di 1 TB, lo comprimiamo tramite gzip fino a pochi byte o kilobyte e lo inviamo al sito. Successivamente, viene decompresso e si ottiene un effetto molto interessante. <\/p>\n

Rest API<\/h3>\n

\nVorrei dedicare un po' di attenzione a servizi attualmente molto popolari come le Rest API. Proteggere una Rest API \u00e8 molto pi\u00f9 complicato rispetto a un sito web normale. Per le Rest API nemmeno i metodi banali di protezione contro attacchi di forza bruta e altre attivit\u00e0 illegittime sono efficaci.
\nLe Rest API sono molto facili da compromettere, perch\u00e9 accedono direttamente al database. Questo comporta conseguenze piuttosto gravi per le aziende nel caso in cui il servizio venga interrotto. La questione \u00e8 che le Rest API sono spesso collegate non solo al sito principale, ma anche all'app mobile e ad alcune risorse aziendali interne. Se tutto questo non funziona, l'impatto \u00e8 molto pi\u00f9 forte rispetto a un semplice sito web che smette di funzionare. <\/p>\n

Carico su contenuti pesanti<\/h3>\n

\nSe ci viene proposto di testare un normale singolo sito web, un landing page, una pagina vetrina, che non dispone di funzionalit\u00e0 complesse, cerchiamo contenuti pesanti. Ad esempio, grandi immagini che il server restituisce, file binari, documentazione in pdf - cerchiamo di scaricare tutto ci\u00f2. Questi test caricano bene il sistema di file e saturano le linee di rete, rendendoli cos\u00ec efficaci. Anche se non si spegne il server durante il download di un grande file a bassa velocit\u00e0, si saturer\u00e0 semplicemente la linea del server target e si verificher\u00e0 un'interruzione del servizio.
\nNell'esempio di questo test si vede che a una velocit\u00e0 di 30 RPS il sito ha smesso di rispondere o ha restituito errori del server 500.<\/p>\n

\"DDoS
\n
\nNon bisogna dimenticare anche la configurazione dei server. \u00c8 comune incontrare persone che hanno acquistato una macchina virtuale, hanno installato Apache, hanno impostato tutto di default, e hanno posizionato un'applicazione PHP, e qui sotto \u00e8 possibile vedere il risultato. <\/p>\n

\"DDoS
\n
\nQui il carico era diretto alla radice e ammontava a soli 10 RPS. Abbiamo atteso 5 minuti e il server \u00e8 crollato. Non si sa esattamente perch\u00e9 sia crollato, ma si sospetta semplicemente che abbia esaurito la memoria e quindi ha smesso di rispondere.<\/p>\n

Wave based<\/h3>\n

\nNegli ultimi uno o due anni sono diventati abbastanza popolari gli attacchi a onde. Questo \u00e8 dovuto al fatto che molte organizzazioni acquistano vari dispositivi per proteggersi dagli attacchi DDoS, i quali richiedono un certo periodo di accumulo di statistiche per iniziare a filtrare l'attacco. In altre parole, non filtrano l'attacco nei primi 30-40 secondi, poich\u00e9 stanno accumulando dati e imparando. Di conseguenza, in questi 30-40 secondi si possono inviare cos\u00ec tanti attacchi che il sito rimane gi\u00f9 per un lungo periodo, finch\u00e9 tutte le richieste non vengono elaborate.
\nNel caso dell'attacco qui sotto, c'era un intervallo di 10 minuti, dopo il quale \u00e8 arrivata una nuova ondata di attacco modificata.<\/p>\n

\"DDoS
\n
\nCio\u00e8, la protezione ha imparato, ha avviato la filtrazione, ma \u00e8 arrivata una nuova ondata di attacco completamente diversa, e la protezione ha di nuovo iniziato a imparare. Di fatto, la filtrazione smette di funzionare, la protezione diventa inefficace e il sito non \u00e8 accessibile.
\nGli attacchi a onda si caratterizzano per valori molto alti al picco, possono raggiungere cento mila o milioni di richieste al secondo, nel caso dell'L7. Se parliamo dell'L3&4, l\u00ec possono esserci centinaia di gigabit di traffico, o, di conseguenza, centinaia di mpps, se calcolati in pacchetti.
\nIl problema di tali attacchi \u00e8 la sincronizzazione. Gli attacchi provengono da un botnet, e per creare un picco molto grande in un colpo solo \u00e8 necessaria un'alta sincronizzazione. Questa coordinazione non sempre funziona: a volte si verifica un picco parabolico che appare piuttosto misero.<\/p>\n

Non di solo HTTP<\/h3>\n

\nOltre a HTTP a livello L7, ci piace anche sfruttare altri protocolli. In genere, un normale sito web, specialmente un normale hosting, espone protocolli di posta e MySQL. I protocolli di posta sono meno soggetti a carichi rispetto ai database, ma possono anche essere sovraccaricati in modo abbastanza efficace, portando a un'CPU satura sul server.
\nSiamo riusciti a ottenere risultati utilizzando una vulnerabilit\u00e0 SSH del 2016. Attualmente questa vulnerabilit\u00e0 \u00e8 corretta quasi ovunque, ma ci\u00f2 non significa che non si possa caricare il SSH. Si pu\u00f2. Viene semplicemente inviata una enorme quantit\u00e0 di tentativi di autenticazione, il SSH consuma quasi tutta la CPU sul server e poi il sito web crolla gi\u00e0 con uno o due richieste al secondo. Di conseguenza, queste uno o due richieste nei log non possono essere distinte da un carico legittimo.
\nRimangono pertinenti anche numerose connessioni che apriamo nei server. In passato, Apache ha avuto questo problema, ora in realt\u00e0 anche nginx lo presenta, poich\u00e9 spesso viene configurato di default. Il numero di connessioni che nginx pu\u00f2 mantenere aperte \u00e8 limitato, quindi quando raggiungiamo questo numero, nginx non accetta pi\u00f9 nuove connessioni e il sito non funziona.
\nIl nostro cluster di test dispone di CPU sufficienti per attaccare il handshake SSL. In linea di principio, come dimostra la pratica, anche i botnet a volte amano farlo. Da un lato, \u00e8 chiaro che non si pu\u00f2 fare a meno di SSL, poich\u00e9 influisce sulla visibilit\u00e0 di Google, sul ranking e sulla sicurezza. D'altra parte, purtroppo, SSL ha un problema con la CPU. <\/p>\n

L3&4<\/h3>\n

\nQuando parliamo di attacchi ai livelli L3&4, parliamo generalmente di attacchi a livello di canale. Questo tipo di carico \u00e8 quasi sempre distinguibile da quello legittimo, a meno che non si tratti di un attacco SYN-flood. Il problema degli attacchi SYN-flood per i sistemi di protezione risiede nel grande volume. La massima entit\u00e0 per L3&4 \u00e8 stata di 1,5-2 Tbit\/s. Tale traffico \u00e8 molto difficile da gestire anche per le grandi aziende, inclusi Oracle e Google.
\nSYN e SYN-ACK sono i pacchetti utilizzati per stabilire una connessione. Pertanto, \u00e8 difficile distinguere un SYN-flood dal carico legittimo: non \u00e8 chiaro se si tratti di un SYN che \u00e8 arrivato per stabilire una connessione o di parte di un flood.<\/p>\n

UDP-flood<\/h3>\n

\nDi solito, i malintenzionati non hanno le risorse che abbiamo noi, quindi possono utilizzare l'amplificazione per organizzare attacchi. Vale a dire, il malintenzionato scansione di internet e trova server vulnerabili o configurati in modo errato, che ad esempio, in risposta a un pacchetto SYN, rispondono con tre SYN-ACK. Alterando l'indirizzo sorgente dall'indirizzo del server di destinazione, si pu\u00f2 aumentare la potenza di un pacchetto, per esempio, di tre volte e indirizzare il traffico contro la vittima.<\/p>\n

\"DDoS
\n
\nIl problema delle amplificazioni sta nella loro difficile individuazione. Tra gli ultimi esempi possiamo citare il noto caso del memcached vulnerabile. Inoltre, ora ci sono molti dispositivi IoT e telecamere IP, che sono principalmente configurati di default e, per di pi\u00f9, in modo errato, per cui attraverso tali dispositivi i malintenzionati effettuano attacchi nella maggior parte dei casi. <\/p>\n

\"DDoS
\n<\/p>\n

Non semplice SYN-flood<\/h3>\n

\nIl SYN-flood \u00e8 senza dubbio il tipo di attacco pi\u00f9 interessante dal punto di vista di un sviluppatore. Il problema \u00e8 che spesso gli amministratori di sistema utilizzano il blocco degli IP per proteggersi. Tuttavia, non solo gli amministratori che agiscono secondo script ne risentono, ma purtroppo anche alcuni sistemi di protezione acquistati a caro prezzo.
\nQuesto metodo pu\u00f2 rivelarsi catastrofico, poich\u00e9 se i malintenzionati sostituiscono Indirizzi IP<\/a>, l'azienda bloccher\u00e0 la propria sottorete. Quando il Firewall blocca il proprio cluster, ci saranno conseguenze negative per le interazioni esterne, e il servizio si guaster\u00e0.
\nInoltre, non \u00e8 difficile ottenere il blocco della propria rete. Se l'ufficio del cliente dispone di una rete Wi-Fi, oppure se la funzionalit\u00e0 delle risorse \u00e8 monitorata attraverso vari strumenti, possiamo prendere l'indirizzo IP di questo sistema di monitoraggio o del cliente Wi-Fi e usarlo come fonte. Cos\u00ec, il servizio apparir\u00e0 disponibile, ma gli indirizzi IP target saranno bloccati. Ad esempio, pu\u00f2 essere bloccata la rete Wi-Fi della conferenza HighLoad, dove verr\u00e0 presentato un nuovo prodotto dell'azienda, il che comporterebbe determinati costi commerciali ed economici.
\nDurante i test non possiamo utilizzare l'amplificazione tramite memcached con risorse esterne, poich\u00e9 ci sono accordi per instradare il traffico solo verso indirizzi IP autorizzati. Pertanto, utilizziamo l'amplificazione tramite SYN e SYN-ACK, quando l'invio di un SYN provoca una risposta della macchina con due o tre SYN-ACK, moltiplicando cos\u00ec l'attacco da due a tre volte. <\/p>\n

Strumenti<\/h3>\n

\nUno dei principali strumenti che utilizziamo per il carico a livello L7 \u00e8 Yandex-tank. In particolare, viene utilizzato un phantom come arma e ci sono diversi script per generare munizioni e analizzare i risultati.
\nPer analizzare il traffico di rete utilizziamo Tcpdump e per analizzare il server Nmap. Per generare carichi a livello L3&4 utilizziamo OpenSSL e un po' della nostra magia con la libreria DPDK. DPDK \u00e8 una libreria di Intel che permette di lavorare con l'interfaccia di rete, bypassando lo stack Linux e aumentando cos\u00ec l'efficienza. Naturalmente, utilizziamo DPDK non solo a livello L3&4, ma anche a livello L7, perch\u00e9 consente di generare un flusso di carico molto elevato, nell'ordine di milioni di richieste al secondo da un'unica macchina.
\nUtilizziamo anche determinati generatori di traffico e strumenti speciali che sviluppiamo per test specifici. Ricordando la vulnerabilit\u00e0 sotto SSH, il set di strumenti sopra menzionato non pu\u00f2 essere sfruttato. Se attacchiamo il protocollo di posta, utilizziamo strumenti di posta elettronica oppure semplicemente scriviamo script per questi.<\/p>\n

\n

Conclusioni<\/h3>\n

\nIn conclusione, vorrei dire:<\/p>\n