7. Oktober 2026Eigenes Projekt · SicherheitEigener Beitrag

SYN-ACK-Reflexion: Wenn der eigene Webserver für einen fremden Angriff arbeitet

Zusammenfassung

Im Oktober 2026 zeigte das Firewall-Log meines Heimnetzes plötzlich Hunderte Verbindungsversuche auf meinen Reverse Proxy, alle aus zwei Netzen eines polnischen Providers. Die Auswertung ergab gebastelte SYN-Pakete, auf deren Antwort nie jemand reagierte, und damit sehr wahrscheinlich keinen Angriff auf mich, sondern einen auf das Netz der angeblichen Absender. Dieser Beitrag zeigt, woran man eine SYN-ACK-Reflexion erkennt, warum meine Ländersperre nicht gegriffen hat und wie ich die Pakete mit OPNsense befristet verwerfe.

Viele Zugriffe, aber keine einzige Anfrage

Mein Heimnetz hängt hinter einer OPNsense-Firewall, auf der Caddy als Reverse Proxy einige selbst betriebene Dienste nach außen anbietet. Die Freigaberegel für Caddy protokolliert jede neue Verbindung. Normalerweise stehen dort wenige Einträge pro Stunde.

An einem Abend waren es plötzlich 361 Einträge in einer knappen halben Stunde. Sie kamen von 313 verschiedenen Adressen, alle aus demselben /21-Netz, dazu einige aus einem /23 desselben Providers. Jede Adresse tauchte nur ein- bis dreimal auf, insgesamt gleichmäßig 8 bis 20 Pakete pro Minute.

Das sah nach einem verteilten Angriff aus. Caddy selbst hatte aber keine einzige dieser Verbindungen zu sehen bekommen. Der Grund: Die Firewall protokolliert schon das erste Paket eines Verbindungsaufbaus. Ob daraus jemals eine Verbindung wird, steht im Log nicht.

Was du mitnehmen kannst: Ein „pass“ im Firewall-Log ist ein Verbindungsversuch, kein Zugriff. Bevor du von einem Angriff auf deine Anwendung ausgehst, prüfe, ob überhaupt eine Verbindung zustande gekommen ist.

Was die Pakete verraten

Ein TCP-Verbindungsaufbau besteht aus drei Schritten: Der Client schickt ein SYN, der Server antwortet mit SYN-ACK, der Client bestätigt mit ACK. Die Zustandstabelle der Firewall zeigt, wie weit jeder Versuch gekommen ist.

Bei 160 von 190 offenen Verbindungen aus diesen Netzen sah es gleich aus: ein Paket herein, vier Pakete hinaus, also das SYN-ACK und drei Wiederholungen. Der Rest unterschied sich nur durch ein wiederholtes SYN. Eine Antwort auf das SYN-ACK kam in keinem Fall, weder ein ACK noch ein RST. Laut RFC 4987 antwortet ein echter, erreichbarer Rechner auf ein unerwartetes SYN-ACK mit einem RST.

Auch die Pakete selbst waren ungewöhnlich. Jedes SYN war 44 Byte groß. Ein Linux-Rechner schickt typischerweise 60 Byte, weil er Optionen wie Zeitstempel, Fensterskalierung und SACK mitsendet. Dazu kamen TTL-Werte zwischen 64 und 185 aus ein und demselben Netz. Ein Betriebssystem startet mit einem festen Wert, meist 64, 128 oder 255, und innerhalb eines Providernetzes ist die Zahl der Hops ähnlich. So stark streuende Werte deuten auf Pakete hin, die ein Programm einzeln zusammenbaut.

Was du mitnehmen kannst: Sieh dir bei auffälligen Zugriffen die Zustandstabelle an, nicht nur das Log. Paketgröße, TTL und die Frage, ob jemals ein ACK kommt, unterscheiden einen echten Client von gebastelten Paketen.

Reflexion statt Angriff auf mich

Das Muster passt zu einer SYN-ACK-Reflexion. Der Angreifer verschickt SYN-Pakete an viele Server im Internet und trägt als Absender Adressen aus dem Netz seines eigentlichen Ziels ein. Jeder Server antwortet brav mit SYN-ACK und Wiederholungen, und zwar an das Opfer. Mein Caddy war damit einer von vermutlich sehr vielen unfreiwilligen Helfern.

Dass die Absender über ein ganzes /21 verteilt waren und jede Adresse nur selten vorkam, passt ebenfalls. Diese Verteilung wird oft „Carpet Bombing“ genannt: Schutzsysteme, die nach einzelnen stark belasteten Zieladressen suchen, schlagen dabei später oder gar nicht an.

Beweisen kann ich das von meiner Seite aus nicht. Denkbar wäre auch ein Scanner, der seine eigenen Antworten unterdrückt. Dagegen sprechen aber die stark streuenden TTL-Werte und das Fehlen jeder Reaktion aus über 300 Adressen.

Für mich selbst war die Gefahr gering. Es kam keine Verbindung zustande, die Anwendung wurde nie erreicht, und von knapp 792.000 möglichen Einträgen in der Zustandstabelle waren rund 3.200 belegt.

Was du mitnehmen kannst: Nicht jeder Angriff, den du siehst, gilt dir. Wer Dienste offen ins Internet stellt, kann als Verstärker für fremde Angriffe dienen.

Warum die Ländersperre nicht gegriffen hat

Auf meiner Firewall verwirft eine Floating-Regel ganz oben alle Pakete aus einigen Ländern. Grundlage ist ein GeoIP-Alias, der aus der kostenlosen GeoLite2-Datenbank von MaxMind gefüllt wird. In einer Logansicht wurden die Absender als russisch angezeigt, deshalb habe ich mich zuerst gewundert, warum die Regel nicht greift.

Die Antwort war einfach: Die Firewall hat korrekt gearbeitet. Laut RIPE-Registrierung und laut MaxMind gehören beide Netze zu einem Provider in Polen, und Polen steht nicht auf meiner Liste. Verschiedene Geo-Datenbanken ordnen dieselbe Adresse unterschiedlich zu.

Dazu kam ein Messfehler auf meiner Seite. Die Listenabfrage der OPNsense-API lieferte mir nur die ersten 9.999 Einträge des Alias, nach Adresse sortiert. Ich hielt den Alias deshalb kurz für unvollständig und für reines IPv4. Tatsächlich enthält er über 58.000 Netze, knapp die Hälfte davon IPv6. Erst eine Suche über die vollständige Tabelle zeigte das.

Was du mitnehmen kannst: Prüfe die Herkunft einer Adresse mit derselben Datenbank, die auch deine Firewall verwendet, zum Beispiel über RIPEstat. Und wenn eine Liste rund 9.999 oder 10.000 Einträge hat, ist sie vermutlich abgeschnitten.

Gegenmaßnahme: befristet verwerfen

Gegen den Angriff auf das Opfer kann ich wenig tun. Ich kann aber aufhören, daran mitzuwirken. Dafür habe ich einen eigenen Alias mit den beiden betroffenen Netzen angelegt und eine Floating-Regel direkt nach der Ländersperre eingefügt. Sie verwirft eingehende Pakete aus diesen Netzen auf beiden Internetanschlüssen, bevor die Freigabe für Caddy greift.

Wichtig ist „block“ mit Verwerfen, nicht „reject“. Ein Reject schickt dem Absender ein RST oder eine ICMP-Meldung, und die landen wieder beim Opfer. In pf-Syntax sieht die Regel ungefähr so aus, hier mit Beispielnetzen aus RFC 5737:

table <reflexion> { 198.51.100.0/24 203.0.113.0/24 }
block drop in log quick on $wan inet from <reflexion> to any

Gleich nach dem Anwenden lässt sich die Wirkung im Log prüfen: Neue SYN-Pakete aus diesen Netzen erscheinen dort als „block“. Bei mir waren es in der ersten Minute neun, alle verworfen. Verbindungseinträge von vorher laufen von selbst ab.

Die Sperre gilt bewusst nur einen Monat. Hinter den Adressen stehen echte Kunden eines Providers, die nichts für den Angriff können. Eine dauerhafte Sperre würde sie ohne Grund aussperren. Der Rückbau steht mit Datum in meiner Aufgabenliste.

Was du mitnehmen kannst: Sperren gegen Reflexion immer mit Verwerfen umsetzen, eng auf die betroffenen Netze begrenzen und mit einem Ablaufdatum versehen.

Die eigentliche Ursache

Möglich ist so ein Angriff nur, weil irgendwo im Internet ein Netz Pakete mit gefälschter Absenderadresse hinauslässt. BCP 38, veröffentlicht als RFC 2827, beschreibt seit dem Jahr 2000 die Gegenmaßnahme: Provider lassen aus ihren Kundennetzen nur Pakete mit Absendern aus diesen Netzen heraus.

Solange das nicht überall umgesetzt ist, bleibt Reflexion ein billiger Angriff. Der Angreifer braucht wenig eigene Bandbreite und versteckt sich hinter fremden Servern.

Was du mitnehmen kannst: Wer ein eigenes Netz mit öffentlichem Adressbereich betreibt, sollte ausgehend nur die eigenen Absenderadressen erlauben. Das kostet eine Regel und schützt alle anderen.

Zahlen im Überblick

In knapp 30 Minuten kamen 361 SYN-Pakete von 313 Adressen aus einem einzigen /21-Netz an.
160 von 190 Verbindungen bestanden aus einem Paket herein und vier Paketen hinaus; ACK oder RST kamen in keinem Fall zurück.
Die SYN-Pakete waren 44 Byte groß, ein typisches Linux-SYN hat 60 Byte.
Der GeoIP-Alias enthielt über 58.000 Netze; die Listenabfrage der API zeigte nur die ersten 9.999.
BCP 38 (RFC 2827) beschreibt das Filtern gefälschter Absenderadressen beim Provider seit Mai 2000.

Referenzen

Bemerkungen

Die Einordnung als Reflexion ist eine Schlussfolgerung aus dem Paketmuster. Den Angreifer und sein eigentliches Ziel kenne ich nicht.
Die betroffenen Netze nenne ich bewusst nicht: Dort sitzen wahrscheinlich die Opfer, nicht die Täter.

RFC 4987 zu SYN-Flooding lesen