{"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 realizziamo 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, e conduce test di stress e di carico. Alla conferenza HighLoad++ 2018 abbiamo parlato di come proteggere le risorse da vari tipi di attacchi. In sintesi: isolate le parti del sistema, utilizzate servizi cloud e CDN e aggiornatevi regolarmente. Tuttavia, senza aziende specializzate nella protezione, non ce la farete comunque \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nPrima di leggere il testo, puoi consultare un breve riassunto sul sito della conferenza<\/a><\/noindex>.
\nE se non ti piace leggere o vuoi semplicemente guardare un video, la registrazione della nostra presentazione \u00e8 qui sotto nel spoiler.<\/p>\n

Registrazione video della presentazione<\/b>

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

Molte aziende gi\u00e0 effettuano test di carico, ma non tutte realizzano test di stress. Alcuni nostri clienti pensano che il loro sito sia invulnerabile perch\u00e9 possiedono un sistema highload, che offre una buona protezione dagli attacchi. Mostriamo invece che non \u00e8 del tutto vero.
\nNaturalmente, prima di effettuare i test, otteniamo l'autorizzazione dal cliente, con firma e timbro; inoltre, non \u00e8 possibile effettuare un attacco DDoS senza il nostro consenso. I test vengono eseguiti in un momento scelto dal cliente, quando il traffico del suo sito \u00e8 minimo, in modo che i problemi di accesso non influiscano sui clienti. Inoltre, poich\u00e9 durante i test pu\u00f2 sempre verificarsi qualche imprevisto, siamo in costante contatto con il cliente. Questo permette non solo di comunicare i risultati ottenuti, ma anche di apportare modifiche durante il testing. Al termine dei test, redigiamo sempre un rapporto che evidenzia le eventuali problematiche riscontrate e forniamo raccomandazioni per eliminare le vulnerabilit\u00e0 del sito. <\/p>\n

Come lavoriamo<\/h3>\n

\nDurante i test, emuliamo un botnet. Poich\u00e9 collaboriamo con clienti che non sono all'interno delle nostre reti, per evitare che il test finisca nella prima istante a causa dell'attivazione di limiti o misure di protezione, inviamo il carico non da un solo IP, ma dalla nostra rete. Inoltre, per generare un carico significativo, abbiamo a disposizione un server di test piuttosto potente.<\/p>\n

Postulati<\/h3>\n

<\/p>\n

Molto non significa necessariamente bene<\/b>
\nMinore \u00e8 il carico al quale possiamo far crollare la risorsa, meglio \u00e8. Se riusciamo a far s\u00ec che il sito smetta di funzionare con una richiesta al secondo, o addirittura con una richiesta al minuto, \u00e8 perfetto. Perch\u00e9, secondo la legge di Murphy, gli utenti o i malintenzionati inavvertitamente colpiranno proprio questa vulnerabilit\u00e0. <\/p><\/blockquote>\n

Il guasto parziale \u00e8 migliore del guasto totale<\/b>
\nConsigliamo sempre di rendere i sistemi eterogenei. Inoltre, dovrebbero essere separati a livello fisico, non solo mediante containerizzazione. In caso di separazione fisica, anche se qualcosa nel sito smette di funzionare, c'\u00e8 una buona probabilit\u00e0 che non smetta di funzionare completamente, e gli utenti manterranno l'accesso almeno a parte delle funzionalit\u00e0.<\/p><\/blockquote>\n

Una buona architettura \u00e8 la base della resilienza<\/b>
\nLa resilienza della risorsa e la sua capacit\u00e0 di resistere a attacchi e carichi devono essere integrate nella fase di progettazione, praticamente nel momento in cui si schizzano i primi diagrammi a blocchi nel taccuino. Perch\u00e9 se si introducono errori fatali, \u00e8 possibile correggerli in seguito, ma \u00e8 molto difficile.<\/p><\/blockquote>\n

Non solo il codice deve essere buono, ma anche la configurazione<\/b>
\nMolti pensano che un buon team di sviluppo sia una garanzia di resilienza del servizio. Un buon team di sviluppo \u00e8 certamente necessario, ma \u00e8 altrettanto importante una buona gestione operativa, un buon DevOps. Ci\u00f2 significa che sono necessari specialisti in grado di configurare correttamente Linux e la rete, scrivere adeguatamente le configurazioni in nginx, impostare limiti e altre impostazioni. Altrimenti, la risorsa funzioner\u00e0 bene solo in fase di test, mentre in produzione, a un certo punto, tutto potrebbe rompersi.<\/p><\/blockquote>\n

Differenze tra test di carico e test di stress<\/b>
\nIl test di carico permette di identificare i limiti di funzionamento del sistema. Il test di stress \u00e8 volto a trovare i punti deboli del sistema e viene utilizzato per 'rompere' il sistema e osservare come si comporta durante il fallimento di determinate parti. Inoltre, il tipo di carico rimane solitamente sconosciuto al cliente fino all'inizio dei test di stress.<\/p><\/blockquote>\n

<\/p>\n

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

\nLe tipologie di carico sono solitamente suddivise in carichi a livello L7 e L3&4. L7 si riferisce al carico a livello applicativo, che nella maggior parte dei casi \u00e8 inteso solo per HTTP, mentre noi consideriamo qualsiasi carico a livello di protocollo TCP.
\nGli attacchi L7 presentano alcune caratteristiche distintive. In primo luogo, arrivano direttamente all'applicazione, quindi \u00e8 difficile contrastarli con strumenti di rete. Questi attacchi utilizzano la logica e, grazie a ci\u00f2, consumano in modo molto efficace CPU, memoria, disco, database e altre risorse anche con poco traffico.<\/p>\n

HTTP Flood<\/h3>\n

\nIn caso di qualsiasi attacco, \u00e8 pi\u00f9 facile generare il carico rispetto a gestirlo, e questo \u00e8 vero anche per L7. Il traffico di attacco non sempre \u00e8 facile da distinguere da quello legittimo, e spesso questo riesce a farlo in base alla frequenza, ma se tutto \u00e8 pianificato con cura, nei log \u00e8 impossibile capire dove ci sia un attacco e dove ci siano richieste legittime.
\nCome primo esempio, consideriamo un attacco HTTP Flood. Dal grafico si pu\u00f2 notare che generalmente 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 metodo pi\u00f9 semplice per generare carico. Di solito si utilizza uno strumento di stress test, come ApacheBench, e si impostano la richiesta e l'obiettivo. Con questo approccio semplice, c'\u00e8 una grande probabilit\u00e0 di incappare nel caching del server, ma \u00e8 facile aggirarlo. Ad esempio, aggiungendo stringhe casuali alla richiesta, si costringe il server a restituire continuamente una pagina fresca.
\nNon bisogna dimenticare il user-agent durante la creazione del carico. Molti user-agent dei popolari strumenti di test vengono filtrati dagli amministratori di sistema, e in tal caso il carico potrebbe semplicemente non arrivare al backend. \u00c8 possibile migliorare significativamente il risultato inserendo nell'intestazione della richiesta un'intestazione di browser pi\u00f9 o meno valida.
\nNonostante la semplicit\u00e0 dell'attacco, gli attacchi HTTP Flood hanno anche i loro svantaggi. In primo luogo, per generare carico sono necessarie grandi risorse. In secondo luogo, tali attacchi vengono rilevati molto facilmente, soprattutto se provengono da un solo indirizzo. Di conseguenza, le richieste iniziano immediatamente a essere filtrate dagli amministratori di sistema o addirittura a livello del fornitore. <\/p>\n

Cosa cercare<\/h3>\n

\nPer ridurre il numero di richieste al secondo senza compromettere l'efficienza, \u00e8 necessario mostrare un po' di creativit\u00e0 e esplorare il sito. \u00c8 possibile caricare non solo il canale o il server, ma anche parti specifiche dell'applicazione, come database o sistemi di file. Inoltre, \u00e8 utile cercare aree del sito che effettuano calcoli pesanti: calcolatrici, pagine di selezione dei prodotti e altro ancora. Infine, spesso ci sono script PHP sul sito che generano pagine da centinaia di migliaia di righe. Questi script possono caricare significativamente il server e diventare un obiettivo per un attacco.<\/p>\n

Dove cercare<\/h3>\n

\nQuando scansioniamo una risorsa prima di effettuare un test, guardiamo innanzitutto al sito stesso. Cerchiamo vari campi di input, file pesanti \u2014 insomma, tutto ci\u00f2 che pu\u00f2 creare problemi alla risorsa e rallentare il suo funzionamento. Qui aiutano i comuni strumenti di sviluppo in Google Chrome e Firefox, che mostrano i tempi di risposta della pagina.
\nScansioniamo anche i sottodomini. Ad esempio, supponiamo che ci sia un negozio online, abc.com, e abbia un sottodominio admin.abc.com. Probabilmente si tratta di un'area di amministrazione con autenticazione, ma se viene sovraccaricata, potrebbe causare problemi al sito principale.
\nIl sito potrebbe avere un sottodominio api.abc.com. Probabilmente \u00e8 una risorsa per applicazioni mobili. L'applicazione pu\u00f2 essere trovata su App Store o Google Play, installando un punto di accesso speciale, analizzando l'API e registrando account di prova. Il problema \u00e8 che spesso le persone pensano che tutto ci\u00f2 che \u00e8 protetto da autenticazione sia immune agli attacchi di negazione di servizio. Si crede erroneamente che l'autenticazione sia la migliore CAPTCHA, ma non \u00e8 cos\u00ec. Creare 10-20 account di prova \u00e8 semplice, e una volta creati, abbiamo accesso a funzionalit\u00e0 complesse e non schermate.
\nNaturalmente, analizziamo la storia, il robots.txt e WebArchive, ViewDNS, cercando vecchie versioni della risorsa. A volte capita che gli sviluppatori rilascino, ad esempio, mail2.yandex.net, mentre una vecchia versione, mail.yandex.net, rimane attiva. Questo mail.yandex.net non viene pi\u00f9 supportato, non riceve risorse di sviluppo, ma continua a consumare il database. Di conseguenza, utilizzando la vecchia versione, possiamo sfruttare in modo efficace le risorse del backend e tutto ci\u00f2 che supporta il rendering. Certamente, non accade sempre, ma ci imbattiamo comunque abbastanza spesso in situazioni simili.
\nNaturalmente, esaminiamo tutti i parametri della richiesta, la struttura dei cookie. Possiamo, ad esempio, inserire un valore all'interno di un array JSON nei cookie, creare una grande nidificazione e costringere la risorsa a funzionare in modo irragionevolmente lento.<\/p>\n

Carico della ricerca<\/h3>\n

\nLa prima cosa che viene in mente quando si esplora un sito \u00e8 caricare il database, poich\u00e9 la ricerca \u00e8 presente nella maggior parte dei casi, e spesso \u00e8 purtroppo poco protetta. Per qualche motivo, gli sviluppatori non attribuiscono sufficiente attenzione alla ricerca. Tuttavia, c'\u00e8 un consiglio: evitare di effettuare richieste monotone, poich\u00e9 si pu\u00f2 incorrere nel problema della cache, 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 pertinenti alla ricerca. Ritornando all'esempio di un negozio online: supponiamo che il sito venda pneumatici per auto e consenta di specificare il raggio delle gomme, il tipo di auto e altri parametri. Pertanto, combinazioni di parole rilevanti costringeranno il database a lavorare in condizioni molto pi\u00f9 complesse.
\nInoltre, \u00e8 utile utilizzare la paginazione: per la ricerca \u00e8 molto pi\u00f9 difficile restituire la penultima pagina dei risultati rispetto alla prima. Quindi, attraverso la paginazione, \u00e8 possibile diversificare un po' il carico.
\nNell'esempio sottostante, dimostriamo il carico sulla ricerca. Si osserva che fin dal primo secondo del test, con una velocit\u00e0 di dieci richieste al secondo, il sito ha smesso di rispondere.<\/p>\n

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

Se non ci sono risultati nella ricerca?<\/h3>\n

\nSe non ci sono risultati, non significa che il sito non contenga altri campi vulnerabili. Un campo del genere potrebbe essere l'autenticazione. Oggi gli sviluppatori amano utilizzare hash complessi per proteggere il database delle credenziali dagli attacchi tramite tabelle arcobaleno. \u00c8 un buon approccio, ma tali hash richiedono grandi risorse CPU. Un elevato volume di tentativi di accesso non validi porta al 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 flooding massiccio. A volte i siti accettano file allegati, anche in formato gzip. In tal caso, prendiamo un file di dimensione 1TB, lo comprimiamo con 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 molto popolari al giorno d'oggi come Rest API. Proteggere un Rest API \u00e8 molto pi\u00f9 difficile rispetto a un sito web normale. Per i Rest API non funzionano nemmeno i banali metodi di protezione contro l'attacco a forza bruta e altre attivit\u00e0 illecite.
\nLe REST API \u00e8 molto facile da compromettere, poich\u00e9 si connette direttamente al database. Un malfunzionamento di questo servizio pu\u00f2 avere conseguenze piuttosto gravi per l'attivit\u00e0. Infatti, il REST API \u00e8 spesso legato non solo al sito principale, ma anche all'app mobile e ad alcune risorse aziendali interne. Se tutto questo smette di funzionare, l'impatto \u00e8 molto pi\u00f9 forte rispetto a un semplice sito web che si guasta. <\/p>\n

Carico su contenuti pesanti<\/h3>\n

\nQuando ci viene proposto di testare un'applicazione semplice, una landing page o un sito vetrina senza funzionalit\u00e0 complesse, cerchiamo contenuti pesanti. Ad esempio, immagini di grandi dimensioni fornite dal server, file binari, documentazione PDF: proviamo a scaricare tutto questo. Test del genere mettono a dura prova il sistema di file e saturano i canali, risultando quindi efficaci. Anche se non si va a sovraccaricare il server scaricando un grande file a bassa velocit\u00e0, si saturer\u00e0 comunque il canale del server target, causando un rifiuto nel servizio.
\nDa questo test si pu\u00f2 notare che a una velocit\u00e0 di 30 RPS il sito ha smesso di rispondere o restituiva errori 500 del server.<\/p>\n

\"DDoS
\n
\nNon dimentichiamo la configurazione dei server. Spesso ci si imbatte in persone che acquistano una virtual machine, installano Apache, configurano tutto con le impostazioni predefinite e posizionano un'applicazione php, e di seguito si pu\u00f2 vedere il risultato. <\/p>\n

\"DDoS
\n
\nQui il carico era concentrato all'origine e si attestava a soli 10 RPS. Abbiamo atteso 5 minuti, e il server si \u00e8 bloccato. Non si sa esattamente perch\u00e9 sia successo, ma si ipotizza che abbia semplicemente esaurito la memoria, smettendo quindi di rispondere.<\/p>\n

Wave based<\/h3>\n

\nNegli ultimi uno o due anni, gli attacchi a onde sono diventati abbastanza popolari. Questo \u00e8 dovuto al fatto che molte organizzazioni acquistano vari hardware per proteggersi dagli attacchi DDoS, che richiedono un certo tempo per accumulare statistiche prima di iniziare a filtrare l'attacco. Ci\u00f2 significa che non filtrano l'attacco nei primi 30-40 secondi, mentre raccolgono dati e si affinano. Di conseguenza, in quei 30-40 secondi, si pu\u00f2 inondare il sito con richieste tali da farlo collassare per un lungo periodo, fino a quando tutte le richieste non vengono gestite.
\nNel caso dell'attacco sottostante, c'\u00e8 stato un intervallo di 10 minuti, dopo il quale \u00e8 arrivata una nuova e modificata ondata di attacco.<\/p>\n

\"DDoS
\n
\nCio\u00e8, la protezione si \u00e8 addestrata, ha avviato la filtrazione, ma \u00e8 arrivato un nuovo attacco completamente diverso, e la protezione ha ricominciato l'addestramento. Di fatto, la filtrazione smette di funzionare, la protezione diventa inefficace e il sito non \u00e8 accessibile.
\nGli attacchi a onda presentano valori molto elevati al picco, possono raggiungere centomila o addirittura un milione di richieste al secondo, nel caso dell'L7. Per quanto riguarda l'L3&4, ci possono essere centinaia di gigabit di traffico, o, rispettivamente, centinaia di mpps, se consideriamo i pacchetti.
\nIl problema di tali attacchi \u00e8 la sincronizzazione. Gli attacchi provengono da una botnet, e per creare un picco singolo molto elevato, \u00e8 necessaria un'alta sincronizzazione. E questa coordinazione non sempre riesce: a volte il risultato \u00e8 un picco parabolico, che appare piuttosto misero.<\/p>\n

Non di solo HTTP si vive<\/h3>\n

\nOltre all'HTTP a livello L7, ci piace sfruttare anche altri protocolli. In genere, un normale sito web, specialmente un comune hosting, espone protocolli di posta e MySQL. I protocolli di posta sono meno soggetti a sovraccarichi rispetto ai database, ma possono comunque essere caricati in modo sufficientemente efficace, causando un sovraccarico della CPU sul server.
\nAbbiamo effettivamente avuto successo sfruttando la vulnerabilit\u00e0 SSH del 2016. Ora questa vulnerabilit\u00e0 \u00e8 stata corretta dalla maggior parte, ma ci\u00f2 non significa che non si possa generare carico su SSH. Si pu\u00f2 fare. Viene semplicemente generato un enorme carico di autorizzazioni, e SSH consuma quasi tutta la CPU del server, portando il sito web a collassare con solo uno o due richieste al secondo. Di conseguenza, queste uno o due richieste non possono essere distinte nei log da un carico legittimo.
\nRimangono rilevanti anche molti collegamenti che apriamo nei server. In passato, questo era un problema con Apache, ora affligge praticamente anche nginx, poich\u00e9 spesso viene configurato di default. Il numero di connessioni che nginx pu\u00f2 mantenere aperte \u00e8 limitato; di conseguenza, una volta raggiunto questo numero, nginx non accetta pi\u00f9 nuove connessioni, e il sito web smette di funzionare.
\nIl nostro cluster di test ha una potenza di CPU sufficiente per attaccare il SSL handshake. 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 classifica di Google e sulla sicurezza. D'altra parte, sfortunatamente, SSL ha un problema di CPU. <\/p>\n

L3&4<\/h3>\n

\nQuando parliamo di attacchi ai livelli L3&4, ci riferiamo generalmente ad 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 mezzi di protezione risiede nel loro elevato volume. La massima dimensione per L3&4 ha raggiunto i 1,5-2 Tbps. Tale traffico \u00e8 molto difficile da gestire anche per grandi aziende, compresi Oracle e Google.
\nSYN e SYN-ACK sono pacchetti utilizzati per l'instaurazione di una connessione. Pertanto, \u00e8 difficile distinguere un attacco SYN-flood da un carico legittimo: non \u00e8 chiaro se sia un SYN ricevuto per stabilire una connessione o parte di un flood.<\/p>\n

UDP-flood<\/h3>\n

\nDi solito, gli attaccanti non dispongono della potenza di fuoco che abbiamo noi, quindi per eseguire attacchi possono sfruttare l'amplificazione. In altre parole, un attaccante scansiona Internet e trova server vulnerabili o configurati in modo errato, che, ad esempio, rispondono con tre SYN-ACK a un solo pacchetto SYN. Fingendo l'indirizzo sorgente dell'indirizzo del server obiettivo, \u00e8 possibile aumentare la potenza di un pacchetto, ad esempio, di tre volte e reindirizzare il traffico sulla vittima.<\/p>\n

\"DDoS
\n
\nIl problema delle amplificazioni risiede nella loro difficile individuazione. Tra gli ultimi esempi, si ricorda il caso noto relativo a memcached vulnerabile. Inoltre, ora ci sono molti dispositivi IoT e telecamere IP che, per lo pi\u00f9, sono configurati di default in modo errato, quindi gli attaccanti li utilizzano frequentemente per effettuare attacchi. <\/p>\n

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

SYN-flood complesso<\/h3>\n

\nL'attacco SYN-flood \u00e8 probabilmente il pi\u00f9 interessante di tutti per un sviluppatore. Il problema \u00e8 che spesso gli amministratori di sistema utilizzano il blocco degli indirizzi IP per proteggersi. Purtroppo, non solo gli amministratori che seguono script ne risentono, ma anche alcuni sistemi di sicurezza costosi.
\nQuesto metodo pu\u00f2 rivelarsi catastrofico, poich\u00e9 se i malintenzionati sostituiscono Indirizzi IP<\/a>, l'azienda bloccher\u00e0 la propria subnet. Quando il Firewall blocca il proprio cluster, le interazioni esterne si interrompono e il servizio va in down.
\nIn effetti, ottenere il blocco della propria rete non \u00e8 difficile. Se nel ufficio del cliente \u00e8 presente una rete Wi-Fi, oppure se l\u2019efficacia dei servizi viene monitorata tramite diversi strumenti, prendiamo l'indirizzo IP di questo sistema di monitoraggio o quello della rete Wi-Fi dell'ufficio e lo utilizziamo come sorgente. In apparenza, il servizio \u00e8 accessibile, ma gli indirizzi IP target sono bloccati. Potrebbe anche essere bloccata la rete Wi-Fi della conferenza HighLoad, dove viene presentato un nuovo prodotto dell'azienda, il che comporta determinati costi aziendali ed economici.
\nDurante il test, non possiamo utilizzare l'amplificazione tramite memcached con risorse esterne a causa di accordi che limitano il traffico solo agli indirizzi IP autorizzati. Pertanto, utilizziamo l'amplificazione tramite SYN e SYN-ACK, quando l'invio di un SYN provoca la risposta di due o tre SYN-ACK, aumentando cos\u00ec l'attacco di due o tre volte. <\/p>\n

Strumenti<\/h3>\n

\nUno dei principali strumenti che utilizziamo per il carico a livello L7 \u00e8 Yandex-tank. In particolare, come artiglieria utilizziamo Phantom, e ci sono anche diversi script per generare munizioni e analizzare i risultati.
\nPer analizzare il traffico di rete, utilizziamo Tcpdump; per analizzare il server, utilizziamo Nmap. Per generare carico a livello L3&4, utilizziamo OpenSSL e un po' della nostra magia con la libreria DPDK. DPDK \u00e8 una libreria di Intel che consente di lavorare con l'interfaccia di rete, bypassando lo stack Linux, migliorando 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 diversi milioni di richieste al secondo da una sola macchina.
\nUtilizziamo anche generatori di traffico specifici e strumenti creati per test specifici. Se consideriamo la vulnerabilit\u00e0 sotto SSH, il set di strumenti sopra menzionato non pu\u00f2 essere sfruttato. Se attacchiamo il protocollo di posta, utilizziamo utility di posta o semplicemente scriviamo script per esse.<\/p>\n

\n

Conclusioni<\/h3>\n

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