Nachfolgend skizziere ich einen prototypischen Angriffspfad, bei dem der Angreifer zwar keinen neuen, verdächtigen Domain-Namen registriert, wohl aber eine bereits routbare, aber reputationsbelastete IP-Adresse in Szene setzt. Ein reiner Domain-Filter (AdGuard o. ä.) greift ins Leere; erst IP-basierte Policing-Mechanismen im Upstream-Resolver stoppen die Exfiltration. Die Schritte sind bewusst granular dargestellt, um die Rolle des lokalen Resolvers zu illustrieren.
| Phase | Ablauf | Warum Domain-Listen scheitern | Rolle Unbound (ohne respip) |
|---|---|---|---|
| 1) Initial Foot-in-the-Door | Spear-Phishing-Mail verweist auf assets.company-cdn.net/logo.js. Domain gehört zu einem legitimen, grossen CDN. | Domain steht nicht in ThreatFox, OISD etc.; sie ist völlig unauffällig. | Leitet Anfrage unbeanstandet an den autoritativen NS weiter, cached das Ergebnis. |
| 2) Silent Take-over | Angreifer kompromittiert via RCE das Kunden-Dashboard des CDN und ersetzt die A-Records durch 185.244.25.47 (bekanntes DDoS-Hosting, gelistet in FireHOL L4). | Die Domain bleibt dieselbe; selbst DNSSEC bleibt intakt – nur die IP geändert. | Holt den neuen A-Record (30-s TTL) ab, cached ihn identitätsgläubig. |
| 3) Client Side – Malware Drop | Browser des Opfers lädt das „Logo-Script“, welches nun Spyware nachlädt und C2-Beacons sendet. | Domain-Listen blocken weiterhin nicht – derselbe FQDN ist ja „sauber“. | Auflösungen wiederholt auf dieselbe FireHOL-IP, reicht sie an den Client durch. |
| 4) Fast-Flux / Spare IPs | CDN-Angreifer rotiert minütlich zwischen fünf Subnetzen (31.210.20.0/24, 93.123.92.0/24 usw.), alle im FireHOL-Feed. | Keiner der Wechsel erzeugt Domain-IOC-Rauschen. | Ohne IP-Filter cached Unbound jeden Wechsel für die TTL und bleibt Mittäter. |
| 5) Exfiltration & C2 | Inbound POST-Requests gehen über HTTPS 443 nach assets.company-cdn.net → 185.244.25.47. IPS/IDS erkennen nur TLS; SNI und ALPN sehen legitim aus. | Domain-Filter ignorieren den Traffic, TLS macht DPI mühsam. | Resolver liefert weiterhin die (malicious) Routing-Information; Attacke bleibt unentdeckt. |
Resultat: Rein domänenbasiertes Blocken greift 0-fach; der Angreifer gewinnt Ausführungs- & Exfiltration-Fähigkeit, obwohl kein einziger „auffälliger“ Host-Name im Spiel ist.
Wie respip im lokalen Unbound den Schalter umlegt
Sobald ich die FireHOL-Netze via:
response-ip: 185.244.25.0/24 deny
eingespeist habe, ändert sich die Choreografie fundamental:
| Step | Effekt | Upstream-Unbound-Log |
|---|---|---|
| 2) Record-Flip | Unbound prüft die Antwort, matcht das Präfix, ersetzt sie durch NXDOMAIN. | info: response-ip deny 185.244.25.47/32 matched firehol.rule |
| 3) Browser-Abruf | Client erhält keine IP → Script kann nicht geladen werden. | – |
| 4) Fast-Flux | Jeder weitere Wechsel auf belastete Netze wird identisch annuliert, ohne Reload. | – |
| 5) Exfiltration | C2-Handshake nie etabliert, IDS schweigt, Incident-Response entfällt. | – |
Der Resolver wird also vom stummen Dilligent zum Wächter, noch bevor der Paketfluss entsteht. Kein TCP SYN, kein TLS ClientHello – pure Prävention.
Warum nicht schon in AdGuard?
- AdGuard operiert FQDN-basiert; er kennt keine IP-Reputation.
- Würde ich die FireHOL-Netze in AdGuard als „regexp-Filter“ abbilden, müsste ich hunderttausende Regex-Zeilen parsen: RAM- und CPU-Harakiri.
- Unbound verarbeitet CIDR-Präfixe in C-Strukturen; das ist Speicher-sparender und schafft Cache-Treffer bereits in O(1).
Take-Away
- Domain-IOC ≠ IP-IOC – beide Layer haben eigenständige Angriffsflächen.
- Geroutete, aber bösartige Netze unterlaufen jede Domain-Watchlist, wenn der Namensträger kompromittiert ist.
respipin Unbound ist der elegante Weg, reputationsbelastete IP-Ranges zu neutralisieren – ohne Deep-Packet-Inspection und ohne Gateway-Zugriff.
Damit verwandelt sich mein Upstream-Resolver in eine Schweizer Taschenmesser-Firewall, die Namen und Netze beurteilt – präzis, ressourcenarm und ohne zusätzliches Lizenz-Geflecht.