Si sta verificando un attacco Denial of Service. Se vedi traffico proveniente da più reti (IP diversi su diverse sottoreti) hai un Denial of Service distribuito (DDoS); se proviene tutto dallo stesso posto, hai un vecchio DoS semplice. Può essere utile controllare, se sei in grado; usa netstat per verificare. Questo potrebbe essere difficile da fare, però.
La negazione del servizio di solito rientra in un paio di categorie: basata sul traffico e basata sul carico. L'ultimo elemento (con il servizio di crash) è DoS basato sull'exploit ed è abbastanza diverso.
Se stai cercando di stabilire quale tipo di attacco sta accadendo, potresti voler catturare un po 'di traffico (usando WireShark, TCPDump o LibPcap). Dovresti, se possibile, ma anche essere consapevole che probabilmente catturerai molto traffico.
Il più delle volte provengono da botnet (reti di host compromessi sotto il controllo centrale di alcuni aggressori, di cui faranno le offerte). Questo è un buon modo per l'attaccante di acquisire (molto a buon mercato) la larghezza di banda a monte di molti host diversi su reti diverse con cui attaccarti, coprendo le sue tracce. Il cannone ionico a bassa orbita è un esempio di botnet (nonostante sia volontario anziché derivato da malware); Zeus è più tipico.
basata Traffico-
Se sei sotto un DoS basato sul traffico, stai scoprendo che c'è così tanto traffico che arriva al tuo server che la sua connessione a Internet è completamente satura. C'è un alto tasso di perdita di pacchetti quando si esegue il ping del server da un'altra parte e (a seconda dei metodi di routing in uso) a volte si riscontra anche una latenza molto elevata (il ping è elevato). Questo tipo di attacco è di solito un DDoS.
Sebbene si tratti di un attacco veramente "forte", ed è ovvio ciò che sta accadendo, è difficile per un amministratore di server mitigarlo (e sostanzialmente impossibile per un utente di hosting condiviso da mitigare). Avrai bisogno dell'aiuto del tuo ISP; fai sapere loro che sei sotto un DDoS e potrebbero essere in grado di aiutarti.
Tuttavia, la maggior parte degli ISP e dei provider di transito realizzeranno in modo proattivo ciò che sta succedendo e pubblicheranno un percorso blackhole per il proprio server. Ciò significa che pubblicano un percorso verso il tuo server con il minor costo possibile tramite 0.0.0.0: rendono il traffico verso il tuo server non più instradabile su Internet. Questi percorsi sono in genere / 32s e alla fine vengono rimossi. Questo non ti aiuta affatto; lo scopo è proteggere la rete dell'ISP dal diluvio. Per tutta la durata, il tuo server perderà effettivamente l'accesso a Internet.
L'unico modo in cui il tuo ISP (o te, se hai il tuo AS) sarà in grado di aiutarti è se stanno utilizzando shaper di traffico intelligenti in grado di rilevare e limitare il probabile traffico DDoS. Non tutti hanno questa tecnologia. Tuttavia, se il traffico proviene da una o due reti o da un host, potrebbero anche essere in grado di bloccare il traffico davanti a te.
In breve, c'è molto poco che puoi fare su questo problema. La migliore soluzione a lungo termine è quella di ospitare i tuoi servizi in molte posizioni diverse su Internet che dovrebbero essere DDoSed singolarmente e contemporaneamente, rendendo il DDoS molto più costoso. Le strategie per questo dipendono dal servizio che devi proteggere; Il DNS può essere protetto con più nameserver autorevoli, SMTP con record MX di backup e scambiatori di posta e HTTP con DNS round-robin o multihoming (ma un certo degrado potrebbe essere evidente comunque per la durata).
Il bilanciamento del carico è raramente una soluzione efficace a questo problema, poiché il bilanciamento del carico stesso è soggetto allo stesso problema e crea semplicemente un collo di bottiglia. IPTables o altre regole del firewall non saranno di aiuto perché il problema è che la pipa è satura. Una volta che le connessioni vengono visualizzate dal firewall, è già troppo tardi ; la larghezza di banda nel tuo sito è stata consumata. Non importa cosa fai con le connessioni; l'attacco viene mitigato o terminato quando la quantità di traffico in entrata torna alla normalità.
Se sei in grado di farlo, prendi in considerazione l'uso di una rete di distribuzione di contenuti (CDN) come Akamai, Limelight e CDN77 o usa un servizio di lavaggio DDoS come CloudFlare o Prolexic. Questi servizi adottano misure attive per mitigare questi tipi di attacchi e hanno anche una larghezza di banda così ampia disponibile in così tanti luoghi diversi che inondazioni non è generalmente fattibile.
Se decidi di utilizzare CloudFlare (o qualsiasi altro CDN / proxy), ricorda di nascondere l'IP del tuo server. Se un utente malintenzionato rileva l'IP, può nuovamente eseguire direttamente DDoS sul tuo server, ignorando CloudFlare. Per nascondere l'IP, il tuo server non dovrebbe mai comunicare direttamente con altri server / utenti a meno che non siano sicuri. Ad esempio, il tuo server non dovrebbe inviare e-mail direttamente agli utenti. Questo non si applica se si ospitano tutti i contenuti sulla CDN e non si dispone di un server personale.
Inoltre, alcuni provider di servizi di hosting e hosting sono in grado di mitigare meglio questi attacchi rispetto ad altri. In generale, più sono grandi, meglio saranno in questo; un provider con un ottimo rapporto qualità-prezzo e molta larghezza di banda sarà naturalmente più resiliente e uno con un team operativo di rete attivo e completamente attrezzato sarà in grado di reagire più rapidamente.
Carico basata
Quando si verifica un DDoS basato sul carico, si nota che la media del carico è anormalmente elevata (o CPU, RAM o utilizzo del disco, a seconda della piattaforma e delle specifiche). Anche se il server non sembra fare nulla di utile, è molto occupato. Spesso, ci saranno abbondanti quantità di voci nei registri che indicano condizioni insolite. Molto spesso questo proviene da molti luoghi diversi ed è un DDoS, ma non è necessariamente così. Non ci devono essere nemmeno molti host diversi .
Questo attacco si basa sul rendere il tuo servizio molto costoso. Questo potrebbe essere qualcosa come aprire un numero enorme di connessioni TCP e costringerti a mantenere lo stato per loro, o caricare file eccessivamente grandi o numerosi sul tuo servizio, o forse fare ricerche davvero costose o fare davvero qualcosa di costoso da gestire. Il traffico rientra nei limiti di ciò che hai pianificato e può assumere, ma i tipi di richieste in corso sono troppo costosi per gestirne così tanti .
In primo luogo, che questo tipo di attacco sia possibile è spesso indicativo di un problema di configurazione o bugal tuo servizio. Ad esempio, è possibile che la registrazione sia troppo dettagliata e che i registri vengano archiviati in qualcosa su cui è molto lento scrivere. Se qualcuno lo capisce e fa un sacco di cose che ti fanno scrivere quantità abbondanti di log su disco, il tuo server rallenterà a gattonare. Il tuo software potrebbe anche fare qualcosa di estremamente inefficiente per determinati casi di input; le cause sono numerose quanti sono i programmi, ma due esempi potrebbero essere una situazione che impedisce al servizio di chiudere una sessione altrimenti finita e una situazione che causa la generazione di un processo figlio e la lascia. Se finisci con decine di migliaia di connessioni aperte con lo stato per tenere traccia di, o decine di migliaia di processi figlio, potresti avere problemi.
La prima cosa che potresti essere in grado di fare è utilizzare un firewall per eliminare il traffico . Questo non è sempre possibile, ma se c'è una caratteristica che puoi trovare nel traffico in entrata (tcpdump può essere utile per questo se il traffico è leggero), puoi lasciarlo cadere sul firewall e non causerà più problemi. L'altra cosa da fare è correggere il bug nel tuo servizio (mettiti in contatto con il fornitore ed essere pronto per una lunga esperienza di supporto).
Tuttavia, se si tratta di un problema di configurazione, inizia da lì . Abbassa la registrazione dei sistemi di produzione a un livello ragionevole (a seconda del programma, questo è di solito il valore predefinito e di solito implica che i livelli di "debug" e "verbose" di registrazione siano disattivati; se tutto ciò che fa un utente è registrato esattamente e dettagli precisi, la registrazione è troppo dettagliata). Inoltre, controlla processo figlio e richiedere limiti , possibilmente farfallati richieste in arrivo, connessioni per IP, e il numero di processi figli al seguito, a seconda del caso.
Va da sé che quanto più è configurato e meglio fornito il server, tanto più difficile sarà questo tipo di attacco. Evita di essere avaro di RAM e CPU in particolare. Assicurati che le tue connessioni a cose come database back-end e archiviazione su disco siano veloci e affidabili.
basata Exploit-
Se il servizio si arresta in modo anomalo in modo estremamente rapido dopo essere stato attivato, in particolare se è possibile stabilire un modello di richieste che precedono l'arresto anomalo e la richiesta è atipica o non corrisponde ai modelli di utilizzo previsti, è possibile che si verifichi un DoS basato sull'exploit. Questo può provenire da un solo host (con praticamente qualsiasi tipo di connessione a Internet) o da molti host.
Questo è simile a un DoS basato sul carico per molti aspetti e ha fondamentalmente le stesse cause e mitigazioni. La differenza è semplicemente che in questo caso il bug non causa sprechi al tuo server, ma muore. L'aggressore di solito sta sfruttando una vulnerabilità di arresto anomalo remota, ad esempio un input confuso che provoca una null-dereference o qualcosa del servizio.
Gestire questo in modo simile a un attacco di accesso remoto non autorizzato. Firewall contro gli host di origine e il tipo di traffico se possono essere bloccati. Utilizzare i proxy inversi di convalida, se applicabile. Raccogli prove forensi (prova a catturare parte del traffico), invia un ticket bug al venditore e considera di presentare un reclamo per abuso (o reclamo legale) anche contro l'origine.
Questi attacchi sono abbastanza economici da montare, se si può trovare un exploit, e possono essere molto potenti, ma anche relativamente facili da rintracciare e fermare. Tuttavia, le tecniche utili contro il DDoS basato sul traffico sono generalmente inutili rispetto al DoS basato sull'exploit.