Wat gebeurt er tijdens een DDoS-evenement

Er wordt niets ingeschakeld

Er is geen knop. Scrubbing draait permanent voor elke site, van vier terabit per seconde op de kleinere locaties tot twaalf op de grootste, en de beslissing om een pakket te droppen wordt in hardware aan de rand genomen bij binnenkomst. De eerste dertig seconden van een aanval worden dus exact hetzelfde gefilterd als de laatste dertig, wat niet geldt voor welk systeem dan ook dat een aanval moet detecteren, een prefix moet omleiden en moet wachten tot de aankondiging zich verspreidt.

Wat je van binnenuit ziet

Meestal helemaal niets. Gereflecteerde UDP, een SYN-flood, een stel versterkte DNS-antwoorden: een volumetrische aanval van welke vorm dan ook wordt upstream gedropt en bereikt je poort nooit. De grafiek in het paneel laat het zien. Je interface-tellers niet.

Wat jou kan bereiken is alles wat niet te onderscheiden is van echt verkeer: een langzame HTTP-flood, een stroom verzoeken naar je duurste endpoint, een credential-stuffing-run. Laag 7 is waar de rand niet kan helpen zonder je applicatie te kennen, en daar bestaat de DDoS Pro-add-on voor: aangepaste signatures, rate limits per pad, en iemand om ze mee te schrijven terwijl het gebeurt.

Controleer je eigen limieten voordat je conclusies trekt

Een goede helft van de aanvallen die bij ons worden gemeld, is een conntrack-tabel die vol raakt of een luisterwachtrij die overloopt onder gewoon maandagverkeer.

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 in de kernellog is je firewall die over zichzelf praat, niet het netwerk dat een aanval meldt.

Wat wij doen

Detectie is flow-gebaseerd en per bestemming. Een signature-match dropt het overeenkomende verkeer binnen enkele seconden en laat de rest van het jouwe met rust. Waar het volume groter is dan een site kan absorberen, wat zeldzaam is en is voorgekomen, wordt het bestemmingsadres geheel gefilterd voor een vermeld venster in plaats van de site te laten degraderen voor iedereen erop. Je krijgt een e-mail met het venster, en het wordt gemeten in minuten.

Aanvalsverkeer wordt nooit meegeteld tegen fair use. Het is niet jouw verkeer en je hebt er niet om gevraagd.

Wat we je achteraf kunnen vertellen

Vector, piekbitsnelheid, piekpakketsnelheid, duur en de ruwe geografie van de bronnen. Dat is wat flow-tellers bevatten.

Wat we niet kunnen overhandigen is een packet capture, want die is er niet. We nemen het verkeer dat je instantie binnenkomt niet op, en dat beleid kent geen uitzondering die zichzelf inschakelt wanneer het verkeer vijandig wordt. De details staan in wat we loggen. Mensen vinden dit af en toe frustrerend midden in een incident, en het is dezelfde eigenschap die de rest van het beleid de moeite waard maakt.

Wat je niet moet doen

• Verander het adres niet. De aanval volgt het binnen een minuut en nu is je DNS ook fout.
• Reboot niet. Een herbootte instantie is een tragere instantie, niet een gefilterde.
• Plak niet in paniek een nftables-regelset van duizend regels. Alles wat je op de instantie dropt, heeft al het dure deel van het netwerk doorkruist.
• Check eerst /status. Als de site zelf een incident heeft, wordt dat daar gepubliceerd voordat je ticket is geschreven.

Open het ticket toch

Instantie-ID, tijdstempels met een tijdzone, wat het symptoom werkelijk was en of de service bereikbaar was vanaf een tweede netwerk. Mediane eerste reactie is elf minuten op elk uur van de dag, en tijdens een live evenement komt het antwoord van iemand die de grafiek al in de gaten houdt.