Cosa succede durante un evento DDoS

Non si accende nulla

Non c'è alcun pulsante. Lo scrubbing è eseguito in permanenza davanti a ogni sito, da quattro terabit al secondo nelle sedi più piccole a dodici in quelle più grandi, e la decisione di scartare un pacchetto è presa nell'hardware periferico, all'ingresso. I primi trenta secondi di un attacco sono quindi filtrati esattamente come gli ultimi trenta, cosa che non è vera per alcun sistema che debba rilevare un attacco, reindirizzare un prefisso e attendere che l'annuncio si propaghi.

Ciò che vedi dall'interno

Di solito assolutamente nulla. UDP riflesso, una SYN flood, un set di risposte DNS amplificate: un attacco volumetrico di qualsiasi forma viene scartato a monte e non raggiunge mai la tua porta. Il grafico nel pannello lo mostra. I contatori della tua interfaccia no.

Ciò che può raggiungerti è tutto ciò che è indistinguibile dal traffico reale: una slow HTTP flood, un flusso di richieste al tuo endpoint più costoso, un tentativo di credential stuffing. Il livello 7 è dove la periferia non può aiutare senza conoscere la tua applicazione, ed è a questo che serve il componente aggiuntivo DDoS Pro: firme personalizzate, limiti di frequenza per percorso e una persona con cui scriverle mentre accade.

Controlla i tuoi limiti prima di concludere qualcosa

Una buona metà degli attacchi segnalati a noi è una tabella conntrack che si riempie o una coda di ascolto che va in overflow sotto il normale traffico del lunedì.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
nstat -az TcpExtListenOverflows TcpExtSyncookiesSent
ss -s
journalctl -k --since "15 min ago" | tail -50

nf_conntrack: table full, dropping packet nel registro del kernel è il tuo firewall che parla di sé, non la rete che segnala un attacco.

Cosa facciamo

La rilevazione è basata sui flussi e per destinazione. Una corrispondenza della firma scarta il traffico corrispondente entro secondi e lascia da solo il resto del tuo traffico. Quando il volume supera ciò che un sito può assorbire, cosa rara ma già accaduta, l'indirizzo di destinazione viene filtrato interamente per una finestra dichiarata, invece di lasciare che il sito si degradi per tutti. Ricevi un'email che indica la finestra, ed è misurata in minuti.

Il traffico di attacco non viene mai conteggiato ai fini dell'uso equo. Non è il tuo traffico e non l'hai richiesto.

Cosa possiamo dirti in seguito

Vettore, picco di bitrate, picco di pacchetti al secondo, durata e geografia approssimativa delle sorgenti. Questo è ciò che contengono i contatori di flusso.

Quello che non possiamo consegnare è una cattura dei pacchetti, perché non esiste. Non registriamo il traffico che attraversa la tua istanza, e questa politica non ha eccezioni che si attivano quando il traffico diventa ostile. I dettagli sono in cosa registriamo. Le persone a volte lo trovano frustrante a metà incidente, ed è la stessa proprietà che rende prezioso il resto della politica.

Cosa non fare

• Non cambiare l'indirizzo. L'attacco lo segue entro un minuto e ora anche il tuo DNS è sbagliato.
• Non riavviare. Un'istanza che si riavvia è più lenta, non filtrata.
• Non incollare in preda al panico un ruleset nftables di mille righe. Qualunque cosa scarti sull'istanza ha già attraversato la parte costosa della rete.
• Controlla per prima cosa /status. Se il sito stesso ha un incidente, viene pubblicato lì prima che il tuo ticket venga scritto.

Apri comunque il ticket

ID istanza, timestamp con fuso orario, qual era effettivamente il sintomo e se il servizio era raggiungibile da una seconda rete. La prima risposta media è di undici minuti a ogni ora del giorno, e durante un evento in corso la risposta arriva da qualcuno che sta già guardando il grafico.