Einen VPS unter DDoS online halten

„DDoS“ beschreibt eine Absicht, keinen Mechanismus, und die Mechanismen haben fast nichts gemeinsam. Sie sauber zu sortieren ist keine Pedanterie: Es ist die eigentliche Arbeit, denn jeder ist auf genau einer Schicht stoppbar und auf den anderen unsichtbar.

Volumetrische Floods zielen auf Ihre Bandbreite. UDP-Amplification – DNS, NTP, memcached und neuerdings alles, was eine kleine Frage mit einer großen Antwort beantwortet – lässt einen Angreifer aus 1 Gbps eigener Kapazität 50 Gbps machen, die auf Sie gerichtet werden. Das Ziel ist die Leitung, nicht der Server. Ihre CPU langweilt sich währenddessen.

Protokoll- und Zustandsangriffe zielen auf eine endliche Tabelle in Ihrem Kernel. Ein SYN-Flood versucht, die Accept-Queue zu erschöpfen; ein generischer Small-Packet-Flood versucht, die Connection-Tracking-Tabelle zu erschöpfen. Beide werden in Paketen pro Sekunde gemessen, nicht in Bit pro Sekunde, und beide können eine Maschine auf einer Leitung töten, die zu 97 % im Leerlauf ist. Das ist die Klasse, die kleine Server umbringt, und die Klasse, die die meisten Anleitungen auslassen.

Angriffe auf der Anwendungsschicht zielen auf Ihre CPU oder Ihre Datenbank, mit Anfragen, die von echten nicht zu unterscheiden sind, weil sie echt sind. Hundert Anfragen pro Sekunde an einen Such-Endpunkt sind für ein Netzwerk nichts und für eine PHP-Anwendung tödlich. Kein vorgelagerter Scrubber kann das für Sie herausfiltern: Von außen sieht es exakt wie Erfolg aus.

Es gibt noch ein Viertes, das verkleidet als alle drei ankommt und überhaupt kein Angriff ist: ein Link, der irgendwo gut ankam, ein eigener Client, der sich schlecht benimmt, oder ein Crawler ohne Manieren. Das zuerst auszuschließen kostet nichts, und es ist peinlich, wie oft genau das die Antwort ist.

Wenn 60 Gbps auf Ihre Adresse gerichtet werden und Ihr Port ein 1-Gbps-Port ist, fällt die Entscheidung über diese Pakete in einem Router oberhalb von Ihnen, mehrere Hops bevor irgendetwas beginnt, das Sie selbst verwalten. Ihre Firewall bekommt sie nie zu Gesicht. Sie kann gar nicht: Sie wurden verworfen, um eine Leitung zu schützen, die Ihnen nicht gehört. Das ist die mit Abstand wichtigste strukturelle Tatsache über volumetrische Angriffe, und der Grund, warum „härten Sie Ihre Firewall gegen DDoS“ größtenteils Unsinn ist.

Die einzig sinnvollen Fragen sind also, was Ihr Anbieter automatisch tut und wo seine Schwellenwerte liegen. Unsere sind veröffentlicht statt bloß versprochen: Unter 10 Gbps wird ohne sichtbaren Effekt absorbiert, 10–100 Gbps werden beim Transit-Provider gescrubbt und Sie bemerken womöglich einen kurzen Latenzanstieg, und oberhalb von 100 Gbps wird das Präfix auf einen dedizierten Scrubbing-Pfad umgeleitet – die Latenz steigt spürbarer, aber der Dienst bleibt erreichbar. Das Null-Routing einer Adresse steht nur bei anhaltenden Angriffen zur Debatte, die den gesamten PoP bedrohen, und wir informieren Sie innerhalb von Minuten, falls es passiert. Es gibt nichts zu kaufen und nichts einzuschalten.

Zwei Dinge über Scrubbing lohnen sich zu wissen, die Anbieter selten von sich aus erwähnen. Das Erste: Sie werden von der Nachbarschaft geschützt, nicht nur von Ihren eigenen Verteidigungsmaßnahmen – ein Angriff auf einen Kunden, der sich Ihr vorgelagertes /20 teilt, wird absorbiert, bevor er irgendjemandes Präfix erreicht. Ein ~340-Gbps-Flood, der auf einen benachbarten Bereich in Paris zielte, ging bei uns ohne messbare Auswirkung durch – genau das Ergebnis, das niemand bemerkt. Das Zweite: Scrubber arbeiten mit Heuristiken, und Heuristiken liegen manchmal falsch – im selben Netzwerk hat ein Scrubber einmal neun Minuten lang TCP-Resets gegen legitime Verbindungen verschickt, während er einen Angriff auf einen Nachbarn herausfilterte. Beide Vorfälle stehen im öffentlichen Incident-Log. Wenn Ihre Sitzungen während des Angriffs von jemand anderem auf eine Art sterben, die wie ein aktiver Reset statt wie ein Timeout aussieht, ist das ein echter Fehlerfall, und es lohnt sich, ihn zu melden, statt eine Stunde lang lokal zu debuggen.

Jede falsche DDoS-Reaktion beginnt mit einer Änderung, die vorgenommen wurde, bevor irgendjemand wusste, was eigentlich passiert. Holen Sie sich zuerst vier Zahlen. Sie passen auf einen Bildschirm, und sie benennen die Schicht für Sie.

# 1. bits vs packets  — which axis is saturated?
sar -n DEV 1 5            # or: ifstat -i eth0 1

# 2. socket states     — SYN-RECV piling up means a SYN flood
ss -s
ss -tan state syn-recv | wc -l

# 3. kernel drop counters (these are the ones that matter)
nstat -az | grep -E 'ListenDrops|ListenOverflows|SyncookiesSent|TCPReqQFullDrop'
dmesg -T | tail -20       # look for: nf_conntrack: table full, dropping packet

# 4. connection tracking headroom
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Lesen Sie sie zusammen. Viele Bits pro Sekunde, wenige Pakete pro Sekunde, niedrige CPU-Last ist ein volumetrischer Angriff, und Ihr Job ist es, das zu bestätigen und aufzuhören zu tippen. Viele Pakete pro Sekunde, wenige Bits pro Sekunde – viele winzige Pakete – ist ein Zustandsangriff; schauen Sie sofort auf SyncookiesSent und den conntrack-Zähler. Mäßiger Traffic auf beiden Achsen bei ausgereizter CPU ist Layer 7, und die Antwort liegt in Ihrem Webserver und Ihrer Datenbank, nicht in Ihrer Firewall.

Eine kontraintuitive Lesart lohnt sich zu verinnerlichen: Während eines echten volumetrischen Floods kann Ihr Interface fast ruhig aussehen. Sie sehen die Überlebenden – das, was durch eine bereits volle Leitung noch passt, oder das, was der vorgelagerte Scrubber durchgelassen hat. Ein Interface, das 900 Mbps auf einem 1-Gbps-Port zeigt, während Nutzer totale Unerreichbarkeit melden, ist kein Beweis gegen einen Angriff. Es ist die Form, die einer annimmt.

Prüfen Sie dann, ob der Traffic nicht einfach echt ist. tail -f Ihr Access-Log für zehn Sekunden lang: Ein einzelner Pfad, wiederholt von Tausenden verschiedenen Adressen ohne Referrer, ist ein Angriff; eine Streuung normaler Pfade von normalen Browsern ist ein Publikum, und es zu drosseln erledigt die Arbeit des Angreifers für ihn.

Jeder offene Port ist eine Warteschlange, die ein Angreifer füllen kann, und jedes Paket, das sich Ihr Gastsystem ansehen muss, kostet Sie CPU und einen conntrack-Eintrag, selbst wenn Sie es verwerfen. Das billigste Paket ist das, welches Ihre Maschine nie erreicht – und genau deshalb ist Filtern oberhalb des Gastsystems mehr wert als Filtern darin.

Es gibt hier zwei Schichten, und sie sind nicht dasselbe. Der Edge-Filter ist optional, wird pro Server konfiguriert, ist zustandsbehaftet und arbeitet mit Default-Deny, und er läuft auf dem Hypervisor – Traffic, den Sie dort ablehnen, erreicht Ihre virtuelle NIC überhaupt nie, kostet Sie also weder CPU noch Speicher noch einen Zustandseintrag. Die Gast-Firewall – Ihr nftables-Regelwerk – gehört vollständig Ihnen, und wir fassen sie nie an. Das Muster, das den Kontakt mit einem Angriff übersteht, besteht darin, die grobe, stabile Layer-4-Wahrheit am Edge auszudrücken („diese Maschine bedient 80, 443 und SSH von diesen Adressen, und sonst existiert nichts“) und das Gast-Regelwerk für die feingranulare Arbeit aufzuheben, die sich mit Ihrer Anwendung ändert. Beides ist in der Firewall-Dokumentation beschrieben.

Verengen Sie dann, was übrig bleibt. SSH, beschränkt auf die Adressen, von denen aus Sie tatsächlich administrieren, ist hier keine nette Härtungsgeste – es entfernt eine ganze Klasse von Connection-Exhaustion-Angriffen von Ihrer Maschine. Eine Datenbank, gebunden an 127.0.0.1 oder eine WireGuard-Adresse, lässt sich vom Internet aus überhaupt nicht fluten. Und wenn Sie eine rein interne Steuerungsebene bedienen, stellen Sie sie hinter ein WireGuard-Interface, statt einen öffentlichen Port mit einem Passwort davor zu betreiben.

Ein SYN-Flood nutzt den Handshake aus: Der Angreifer schickt einen Strom von Verbindungsanfragen und schließt sie nie ab, und jede belegt einen Platz in der SYN-Queue des Kernels, bis sie in ein Timeout läuft. Ist die Queue voll, werden legitime Handshakes verworfen – Ihr Dienst läuft, lauscht, und ist unerreichbar.

Linux hat dafür seit den Neunzigern eine saubere Antwort, und sie ist standardmäßig aktiv. SYN-Cookies lassen den Kernel komplett darauf verzichten, Speicher für halboffene Verbindungen zu reservieren: Er kodiert den Verbindungszustand in die Sequenznummer, die er zurückschickt, und rekonstruiert ihn, falls der Client den Handshake abschließt. Bestätigen Sie das, statt es anzunehmen, und geben Sie den Queues genug Spielraum, um einen Burst durchzustehen:

# /etc/sysctl.d/99-flood.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_abort_on_overflow = 0

sysctl --system

tcp_synack_retries = 2 ist wichtiger, als es aussieht: Der Standardwert fünf bedeutet, dass ein gefälschter Handshake den Kernel etwa drei Minuten lang beschäftigt, und zwei senkt das auf ungefähr sieben Sekunden. somaxconn zu erhöhen ist nur die halbe Arbeit – die Queue-Tiefe ist das Minimum aus diesem Wert und dem, was die Anwendung angefordert hat, sodass nginx listen 443 ssl backlog=8192; und einen Reload braucht, bevor die Kernel-Einstellung überhaupt etwas bedeutet. Das ist der klassische Fall eines sysctl-Werts, der angewendet aussieht und nichts bewirkt.

Wenn Sie den Flood stoppen wollen, bevor er die Anwendung überhaupt erreicht, kann nftables Handshakes stellvertretend für den Kernel abschließen und nur Verbindungen durchreichen, die sich als echt erweisen:

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport { 80, 443 } ct state new synproxy mss 1460 wscale 7 timestamp sack-perm
    tcp dport { 80, 443 } accept
    ip protocol icmp icmp type echo-request limit rate 5/second accept
  }
}

Testen Sie synproxy auf einer Maschine, die Sie notfalls noch per Konsole erreichen, bevor Sie sich darauf verlassen; falsch konfiguriert ist es eine hervorragende Methode, sich selbst aus dem eigenen Server auszusperren. Für die meisten reicht der sysctl-Block von oben, und die ehrliche Rangfolge lautet: zuerst Syncookies, dann Backlog, synproxy nur, wenn Sie gemessen haben, dass die ersten beiden nicht ausreichten.

Das hier ist es, was auch erfahrene Leute erwischt. Eine zustandsbehaftete Firewall muss sich jeden Flow merken, den sie gesehen hat, und dieses Gedächtnis ist nf_conntrack, eine Hash-Tabelle mit fester, beim Booten festgelegter Größe. Ist sie voll, verwirft der Kernel neue Verbindungen – alle, Angreifer wie Kunden gleichermaßen – und schreibt eine einzige Zeile nach dmesg, die niemand beobachtet:

nf_conntrack: table full, dropping packet

Der Grund, warum das so wirksam ist, ist reine Arithmetik. Eine Standardtabelle auf einem kleinen VPS fasst irgendwo im niedrigen Zehntausenderbereich an Einträgen, und jedes Paket von einer neuen Quelladresse erzeugt einen – einschließlich UDP-Pakete, einschließlich Pakete, die Sie verwerfen, einschließlich des Floods selbst. Zwanzigtausend Pakete pro Sekunde aus gefälschten Quellen füllen sie in weniger als zwei Sekunden, auf einer Leitung, die dabei nur ein paar Megabit trägt. Ihr Bandbreiten-Graph wird rein gar nichts zeigen.

# /etc/sysctl.d/99-conntrack.conf
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_buckets = 65536
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
net.netfilter.nf_conntrack_udp_timeout = 20

Die Timeouts bringen mehr als die Größe. Die Standard-Lebensdauer für einen etablierten TCP-Flow beträgt fünf Tage, was bedeutet, dass ein Server, der seit einer Woche läuft, noch Zustand für Verbindungen vorhält, die am Dienstag endeten; eine Stunde reicht für alles, was keine untätige SSH-Sitzung ist, und net.ipv4.tcp_keepalive_time = 600 hält solche Sitzungen absichtlich am Leben statt zufällig. Kalkulieren Sie beim Dimensionieren mit etwa 300 Byte Kernel-Speicher pro Eintrag: 262.144 Einträge sind rund 80 MB, was auf einer 4-GB-Maschine völlig in Ordnung ist – und nicht in Ordnung, wenn Sie zehn Millionen einstellen, weil das irgendwo in einem Forum stand.

Wenn Sie etwas wirklich Zustandsloses mit hohem Volumen betreiben – einen autoritativen DNS-Server, einen öffentlichen Gameserver, ein Tor-Relay –, ist die bessere Antwort, das Tracking dafür ganz abzuschalten. Connection-Tracking für einen Dienst ohne sinnvolle Verbindungen ist reine Kosten:

table ip raw {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    udp dport 51820 notrack
    tcp dport 9001 notrack
  }
}

Denken Sie daran, dass solcher Traffic dann Ihre ct state established-Regeln umgeht und deshalb explizite Accept-Regeln in der Filter-Chain braucht. Das ist der Tausch: Sie geben für diesen Port die Zustandsbehaftung auf und bekommen dafür eine Tabelle, die sich nicht mehr füllen lässt.

Der effizienteste Angriff auf einen kleinen Server ist überhaupt kein Flood. Es sind ein paar hundert sorgfältig gewählte HTTP-Anfragen pro Sekunde, jede für sich völlig valide, jede gezielt auf den einen Endpunkt, der eine nicht indizierte Abfrage ausführt oder eine ungecachte Seite rendert. Die Ökonomie dahinter ist brutal: Die Anfrage kostet den Angreifer ein paar hundert Byte und kostet Sie 200 Millisekunden CPU-Zeit und eine Datenbankverbindung. Dieses Rennen verlieren Sie bei jedem Volumen, das Sie sich leisten können zu bedienen.

Der Instinkt ist, den Angreifer zu blockieren. Gegen ein Botnetz, verteilt über Tausende Privatadressen, von denen jede zwei Anfragen pro Sekunde schickt, ist Blockieren nach IP reines Theater – kein Rate-Limit pro Adresse, das Ihre echten Nutzer noch durchlässt, wird je auslösen, und Sie verbringen den Ausfall damit, Regeln hinzuzufügen, während die Seite unten bleibt. Der Zug, der gewinnt, ist es, die Kosten zu ändern, nicht die Anzahl.

Zuerst cachen – und auch den Miss cachen. Ein Full-Page-Cache macht aus einer teuren Anfrage einen Speicherzugriff, und die Direktive, die während eines Angriffs am meisten zählt, ist die, die verhindert, dass tausend gleichzeitige Cache-Misses zu tausend gleichzeitigen Datenbankabfragen werden:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app:64m max_size=2g inactive=60m;

server {
  location / {
    proxy_cache app;
    proxy_cache_valid 200 301 302 10m;
    proxy_cache_lock on;              # one origin request per key, not a thousand
    proxy_cache_lock_timeout 5s;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on; # serve stale, refresh behind it
    add_header X-Cache $upstream_cache_status always;
    proxy_pass http://127.0.0.1:8080;
  }
}

proxy_cache_lock und use_stale sind die beiden Zeilen, die entscheiden, ob eine Traffic-Spitze überlebbar ist. Ohne sie wird in dem Moment, in dem ein heißer Key abläuft, jede noch offene Anfrage zu einer Origin-Anfrage – die Stampede, die aus einem beherrschbaren Angriff einen Ausfall macht. Mit ihnen bedient Ihr Backend eine Anfrage pro Key und Intervall, und alle anderen bekommen eine leicht veraltete Seite, was in jeder Situation der richtige Tausch ist, in der die Alternative gar keine Seite ist.

Drosseln Sie dann gezielt die teuren Pfade, großzügig bemessen und so, dass es sichtbar fehlschlägt:

limit_req_zone $binary_remote_addr zone=general:16m rate=20r/s;
limit_req_zone $binary_remote_addr zone=costly:16m  rate=2r/s;
limit_conn_zone $binary_remote_addr zone=conn:16m;
limit_req_status 429;
limit_conn_status 429;

server {
  limit_req  zone=general burst=40 nodelay;
  limit_conn conn 24;

  location /search { limit_req zone=costly burst=5 nodelay; proxy_pass http://127.0.0.1:8080; }
  location /login  { limit_req zone=costly burst=3 nodelay; proxy_pass http://127.0.0.1:8080; }
}

burst ohne nodelay stellt überschüssige Anfragen in eine Warteschlange, statt sie abzulehnen, was unter einem Angriff bedeutet, dass nginx höflich Tausende Verbindungen für Sie offenhält – Sie haben einen Request-Flood in einen Connection-Flood verwandelt. Verwenden Sie nodelay, liefern Sie sofort 429 zurück, und überlassen Sie den Rest dem Client. Und denken Sie hinter jedem Proxy daran, dass $binary_remote_addr die Adresse des Proxys ist, sofern Sie set_real_ip_from und real_ip_header nicht korrekt konfiguriert haben; ein Rate-Limit, das auf die Adresse Ihres eigenen Frontends schlüsselt, sperrt beim ersten Auslösen sämtliche Nutzer auf einen Schlag aus.

Angriffe im Slowloris-Stil – viele Verbindungen, jede tröpfelt eine Anfrage byteweise – bringen nginx' Event-Modell kaum in Bedrängnis, aber die Timeouts lohnt es sich trotzdem zu straffen: client_header_timeout 8s; client_body_timeout 8s; send_timeout 10s; reset_timedout_connection on;. Zusammen mit limit_conn ist das die gesamte Verteidigung.

fail2ban ist wirklich nützlich, zielt aber auf ein anderes Problem. Es liest Logdateien, entscheidet nach N Fehlschlägen in M Minuten, und fügt eine Firewall-Regel ein. Jeder einzelne Teil davon hat die falsche Form für einen Flood.

Es ist zu langsam: Ein Burst, der vierzig Sekunden dauert, ist vorbei, bevor sich das Ban-Fenster schließt. Es liest Logs, sodass der Angriff Sie bereits den vollen Preis jeder Anfrage gekostet hat – das Parsen passiert erst nach dem Schaden. Es bannt einzelne Adressen, sodass es gegen zehntausend Quellen entweder gar nichts tut oder zehntausend lineare Regeln einfügt, an welchem Punkt die Firewall selbst zum Flaschenhals wird und Sie den Angriff stellvertretend für den Angreifer zu Ende gebracht haben. Und es hängt von Ihren Logs ab, sodass ein Flood, der groß genug ist, um eine Platte mit Log-Zeilen zu füllen, den Server über einen Pfad lahmlegen kann, an den Sie nie gedacht haben.

Wenn Sie dynamisches Blockieren wollen, tun Sie es in der Datenebene, wo das Lookup ein Hash ist und das Verfallen automatisch passiert. Ein dynamisches nftables-Set ist O(1), unabhängig von der Größe, und vergisst von selbst:

table inet filter {
  set flooders {
    type ipv4_addr
    flags dynamic, timeout
    timeout 10m
    size 65535
  }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    ip saddr @flooders drop
    tcp dport { 80, 443 } ct state new add @flooders { ip saddr limit rate over 50/second burst 100 packets } drop
    tcp dport { 80, 443 } accept
  }
}

Lesen Sie die Regel genau, denn die Verneinung bringt Leute durcheinander: Die Adresse wird nur dann zum Set hinzugefügt und verworfen, wenn die Rate über dem Limit liegt. Heben Sie sich fail2ban für das auf, worin es gut ist – langsames Erraten von Zugangsdaten gegen SSH und Anwendungs-Logins, wo ein Bann im menschlichen Zeitmaßstab auf eine bestimmte Adresse genau richtig ist.

Jeder große volumetrische Angriff wird von Servern angetrieben, deren Betreiber nicht wussten, dass sie mitmachen. Der Mechanismus ist ein UDP-Dienst, der eine kleine gefälschte Anfrage mit einer großen Antwort beantwortet: Ein offener DNS-Resolver liefert das 50-Fache dessen zurück, wonach gefragt wurde, falsch konfiguriertes NTP und memcached sind noch schlimmer, und jedes Protokoll, das antwortet, bevor es prüfen kann, wer da fragt, ist ein Kandidat.

Die Konsequenzen treffen Sie, bevor sie das Opfer treffen. Ihr Uplink füllt sich mit Ihren eigenen ausgehenden Antworten, Ihr Anbieter sieht anhaltenden missbräuchlichen Traffic, der Ihren Port verlässt, und die Transit-Anbieter, die ihn empfangen, beginnen, die Bereiche, aus denen er kommt, per Null-Routing zu sperren – weshalb die Acceptable-Use-Policy bei Angriffsursprung und Amplification eine harte Grenze zieht, während sie im Grunde alles andere erlaubt. Ein unwissentlicher Reflektor zu sein, ist der schnellste Weg, eine Adresse zu verlieren, die mit dem, was Sie eigentlich betreiben wollten, nichts zu tun hat.

# bind a recursive resolver to localhost, never 0.0.0.0
# unbound: interface: 127.0.0.1  +  access-control: 0.0.0.0/0 refuse

# what is actually listening on a public address?
ss -ulpn
ss -tlpn

# from another machine, confirm you do not answer strangers
dig @your.server.ip example.com +short          # must time out
ntpq -c rv your.server.ip                        # must fail

Wenn Sie absichtlich einen öffentlichen UDP-Dienst betreiben – einen Gameserver, einen autoritativen Nameserver, einen WireGuard-Endpunkt –, gilt dieselbe Regel wie überall sonst: Drosseln Sie die Antwort, niemals die Anfrage. Sowohl bind als auch knot implementieren Response Rate Limiting; nutzen Sie es, denn es ist der Unterschied zwischen dem Bedienen Ihrer Nutzer und dem Ausliefern des Angriffs eines anderen.

Alles bisher Genannte ist Schadensbegrenzung für einen Angriff, der Ihre Adresse bereits gefunden hat. Es lohnt sich, das zu tun, aber es ist die zweitbeste Lösung. Ein Origin, den niemand benennen kann, ist auf Layer 3 oder 4 überhaupt nicht angreifbar, und die Adresse, die den Traffic bedient, von der Adresse zu trennen, die die Welt kennt, ist der Hebel mit der größten Wirkung auf dieser Seite.

Origin-Adressen sickern fast nie durch raffinierte Angriffe durch. Sie sickern durch Geschichte und durch Nachlässigkeit, auf einer kurzen und gut bekannten Liste. Alte DNS-Einträge sind der übliche Übeltäter: Passive-DNS-Archive erinnern sich für immer an den A-Eintrag, den Sie hatten, bevor Sie ein Frontend davorgesetzt haben. Certificate-Transparency-Logs sind öffentlich und dauerhaft, sodass ein Zertifikat, das für einen Hostnamen ausgestellt wurde, der direkt auf den Origin zeigte, ein signierter, zeitgestempelter Nachweis dafür ist, wo Sie früher gewohnt haben. Ausgehende E-Mail stempelt die Adresse des sendenden Servers in die Header jeder Nachricht. Und der leise Fall: Ihr Webserver, der auf seiner nackten IP antwortet, wodurch jeder, der den Adressraum nach dem HTML Ihrer Seite durchsucht, Sie an einem Nachmittag über den Inhalt findet.

Der letzte Fall ist eine Zwei-Zeilen-Lösung, und fast niemand setzt sie um. Sorgen Sie dafür, dass der Default-Server alles ablehnt, was nicht mit einem Hostnamen ankam, den Sie bedienen:

server {
  listen 80 default_server;
  listen 443 ssl default_server;
  ssl_reject_handshake on;      # nginx 1.19.4+: no certificate, no fingerprint
  return 444;                   # close without a response
}

Wählen Sie dann ein Frontend. Ein kommerzielles CDN ist die naheliegende Antwort und kommt mit realen Kosten, die hier zählen: Sie holen sich ein Unternehmen ins Boot, das Ihr TLS terminiert, Ihren Klartext sieht, Ihren Origin kennt und in einer Jurisdiktion, die Sie sich nicht ausgesucht haben, mit einer gerichtlichen Anordnung belangt werden kann – was einen guten Teil dessen zunichtemacht, wozu der Server überhaupt in Krypto ohne Namensangabe bezahlt wurde. Wenn Sie es trotzdem tun, seien Sie sich bewusst, dass der Origin niemals öffentlich gewesen sein darf und dass die ganze Konstruktion in dem Moment scheitert, in dem jemand einen alten Eintrag findet.

Die Alternative, die die Eigenschaft erhält, für die Sie bezahlt haben, ist, Ihr eigenes Frontend zu sein. Eine Fünf-Dollar-Instanz in einer zweiten Region, auf der nginx als Reverse-Proxy läuft, wobei der Edge-Filter des Origins nur Traffic von genau dieser einen Adresse akzeptiert und sonst nichts, gibt Ihnen eine Wegwerf-Adresse, die Sie in fünf Minuten umnummerieren können, und eine Steuerungsebene, die nur Ihnen antwortet. Es ist dieselbe Architektur, minus den Dritten. Und wo das Publikum es nutzen kann, entfernt ein Tor-Onion-Dienst die IP vollständig aus der Gleichung – es gibt keine Adresse zu fluten, auch wenn Onion-Dienste an ihren Introduction Points eine eigene Angriffsfläche haben, weshalb modernes Tor genau dafür eine Proof-of-Work-Verteidigung mitbringt.

Früher oder später schlägt jemand vor, ein ganzes Land zu blockieren. Das ist grobschlächtig, gelegentlich richtig, und meistens eine Methode, sich beschäftigt zu fühlen.

Es ist vertretbar, wenn Ihr Dienst ein wirklich begrenztes Publikum hat – ein regionaler Gameserver, ein internes Tool, ein Control Panel – und Sie bereit sind, die Falsch-Positiven zu verantworten, darunter Ihre eigenen Nutzer auf Reisen und jeder, der seltsam geroutet wird. Gegen ein modernes Botnetz, das über Privatanschlüsse in jedem Land verteilt ist, Ihr eigenes eingeschlossen, ist es nahezu nutzlos, und für alles Öffentliche ist es aktiv schädlich: Sie verlieren stillschweigend echte Menschen und bekommen nie zu sehen, wer gegangen ist.

Blockieren nach ASN ist präziser. Angriffs-Traffic, der von einer Handvoll Hosting-Anbietern ausgeht – billige VPS-Bereiche, stundenweise gemietet – lässt sich per Präfix verwerfen, mit weit weniger Kollateralschaden als ein Länderblock, weil gewöhnliche Nutzer nicht aus einem Rechenzentrum heraus browsen. Rechenzentrums-Bereiche sind praktischerweise auch dort, wo Scraping und Credential-Stuffing herkommen.

Die dauerhafte Version dieser Idee ist aber überhaupt keine Geografie: Es ist das Filtern nach der Form des Traffics statt nach seiner Herkunft. Ein Angriff teilt üblicherweise etwas Strukturelles – denselben User-Agent, denselben fehlenden Header, dieselbe URL mit demselben Query-Parameter, denselben TLS-Fingerabdruck, ein vollständiges Fehlen der zweiten Anfrage, die ein echter Browser immer stellt. Finden Sie die gemeinsame Eigenschaft, und Sie schreiben eine Regel, die nichts kostet und es übersteht, wenn der Angreifer die Adressen wechselt – was er schneller tun wird, als Sie sie auflisten können.

# in an attack: what do these requests have in common?
awk '{print $1}'  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # addresses
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # user agents
awk '{print $7}'  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # paths

Wenn ein einziger User-Agent für 90 % der Anfragen verantwortlich ist, sind Sie neunzig Sekunden von einer Lösung entfernt. Wenn die zwanzig größten Adressen jeweils 2 % des Traffics ausmachen, hören Sie auf, nach Adressen zu suchen – das ist ein verteilter Angriff, und die Antwort heißt Caching und Rate-Limits.

Manchmal ist der Angriff gezielt, anhaltend und richtet sich gegen Sie persönlich statt gegen eine zufällige Adresse, und die richtige Reaktion ist, aufzuhören, die Adresse zu verteidigen, und sie aufzugeben. Das ist keine Niederlage; für einen kleinen Dienst ist es oft das günstigste denkbare Ergebnis, und schmerzhaft ist es nur, wenn Sie es nicht geprobt haben.

Was das schnell macht, wird im Voraus entschieden. Halten Sie DNS-TTLs standardmäßig bei 300 Sekunden – die Kosten sind vernachlässigbar, und der Nutzen ist, dass Sie in fünf Minuten umziehen können statt in einem Tag. Halten Sie Ihr Deployment reproduzierbar, denn ein Server, den Sie neu aufbauen können, ist ein Server, den Sie verlegen können; wenn Neuaufbau bedeutet, sich zu erinnern, was Sie im März gemacht haben, haben Sie keinen Plan, sondern eine Geisel. Halten Sie ein wiederherstellbares Backup in einer anderen Region vor, und wissen Sie aus einer echten Übung heraus, wie lange eine Wiederherstellung dauert.

Der eigentliche Umzug ist dann kurz: In einer anderen Region deployen, wiederherstellen, auf der neuen Adresse per Hostname-Override verifizieren, bevor Sie DNS anfassen, den Eintrag umstellen, und den alten Server lange genug weiterlaufen lassen, damit die letzten Resolver nachziehen. Der Migrations-Guide behandelt die Reihenfolge im Detail, und es ist dieselbe Abfolge, ob Sie wegen der Performance umziehen oder weil jemand wütend ist.

Das Abrechnungsmodell macht die Generalprobe im Grunde kostenlos: Gebühren werden tagesgenau gegen Ihr Guthaben abgerechnet, sodass eine zweite Maschine, die Sie innerhalb eines Nachmittags deployen, testen und wieder zerstören, ein paar Cent kostet – kein Vertrag, keine Karte, keine Kündigung nötig. Es gibt keinen Grund, warum Ihre erste Umnummerierung ausgerechnet während eines Angriffs stattfinden sollte.

Zwei ehrliche Schlussbemerkungen, denn der Rest dieser Seite ist konstruktionsbedingt optimistisch.

Die erste ist, dass kein Hoster alles absorbiert, und jeder Anbieter, der das Gegenteil behauptet, verkauft Ihnen etwas. Kapazität ist endlich, Scrubbing-Kapazität ist noch endlicher, und ab einer gewissen Größenordnung ist es für ein Netzwerk, das Tausende Kunden schützt, die ökonomisch rationale Handlung, irgendwann eine einzelne Adresse nicht mehr anzukündigen. Wir behandeln das als letztes Mittel gegen anhaltende Angriffe, die den gesamten PoP bedrohen, und wir sagen es Ihnen, statt Sie es selbst debuggen zu lassen – aber ein Versprechen, dass das nie passieren kann, wäre eine Lüge, und Sie sollten jedem Hoster misstrauen, der eines gibt.

Die zweite ist, dass Vergeltung nicht zur Auswahl steht. Booter- und Stresser-Dienste sind Angriffe zum Mieten, verkleidet als Testwerkzeuge, sie sind in den meisten relevanten Jurisdiktionen illegal, sie werden intensiv überwacht, und sie führen hier unter einer Policy, die so ziemlich alles andere erlaubt, zur Kündigung Ihres Servers. Die Asymmetrie, die DDoS für einen Angreifer attraktiv macht, macht es für einen Verteidiger wertlos: Sie können niemanden zurück-fluten, der nichts zu verlieren hat. Absorbieren, cachen, umziehen, und es langweilig werden lassen – was es, für jeden, der für den Traffic bezahlt, den er verschickt, irgendwann tatsächlich wird.