Artikel der RedaktionWeitere Artikel

So verhindern Sie IP-Spoofing-Angriffe

Wo Quellfilter hingehören, wann strenge Reverse-Path-Prüfungen gültigen Datenverkehr stören und warum Authentifizierung und IPv6 gesondert betrachtet werden müssen.

Inhalt

Ein Umschlag liegt an einem weißen Sortiertresen auf einem blauen Weg; neben einer separaten blauen Tür liegt ein Schlüssel.

Den Weg einer Zustellung zu prüfen und zu entscheiden, wer eintreten darf, sind getrennte Aufgaben. Quellvalidierung und Authentifizierung benötigen eigene Kontrollen.

Eine Empfangsstelle kann prüfen, ob eine Zustellung über einen erwarteten Weg gekommen ist. Die Person, die sie entgegennimmt, muss trotzdem entscheiden, wer das Gebäude betreten darf. Netzwerke teilen diese Aufgaben ähnlich auf: Sie validieren, woher der Datenverkehr angeblich stammt, und authentifizieren anschließend den Zugriff auf den Dienst.

Die erste Prüfung nahe an der Quelle platzieren

Ein Netzbetreiber weiß, welche Adressbereiche an der Verbindung eines Kunden eintreffen sollten. Pakete, die eine nicht zugehörige Quelladresse angeben, können dort zurückgewiesen werden, bevor sie weiterlaufen. Dies ist der in BCP 38 beschriebene Ansatz der Quellvalidierung.

In einem Unternehmensnetz sollte sowohl der zum Internet abgehende als auch der von außen kommende Datenverkehr geprüft werden. Dieselbe Grenze ist der Ausgang aus einem Netzwerk und der Eingang in ein anderes. Legen Sie für jede Verbindung die erwarteten Quellen fest, einschließlich rechtmäßig delegierter Bereiche, statt überall eine pauschale Regel anzuwenden.

Eine Bereichsprüfung identifiziert nicht die Person hinter einem Paket. Innerhalb eines zulässigen Bereichs kann sie außerdem Raum für Fälschungen lassen. Betrachten Sie sie als nützliche Grenzkontrolle, nicht als Identitätsnachweis.

Reverse-Path-Prüfungen an die tatsächlichen Routen anpassen

Unicast Reverse Path Forwarding, kurz uRPF, vergleicht die Quelle eines Pakets mit den Routinginformationen. Im strikten Modus muss die eingehende Schnittstelle mit dem ausgewählten Rückweg übereinstimmen. Das kann gut funktionieren, wenn die Wege vorhersehbar sind.

Legitimer Datenverkehr kann jedoch über eine Verbindung eintreffen, während die beste Rückroute eine andere verwendet. Das geschieht bei asymmetrischem Routing und in Netzwerken mit mehreren Anbietern. Strenge Prüfungen können dann gültigen Datenverkehr verwerfen. RFC 3704 erläutert diese Abwägungen. Ansätze mit zulässigen Pfaden berücksichtigen erlaubte Alternativen; lockere Prüfungen fragen im Allgemeinen nur, ob eine Route vorhanden ist, und liefern damit einen schwächeren Test. Wählen und überprüfen Sie den Modus anhand der tatsächlichen Topologie einschließlich Failover.

Dienst und Benutzer authentifizieren

Behalten Sie Adressbeschränkungen dort bei, wo sie nützlich sind, machen Sie sie aber nicht zum alleinigen Identitätsnachweis für sensible Zugriffe. Verwenden Sie für Webdienste korrekt validiertes TLS und für Administration und Netzwerkpartner geeignete authentifizierte Protokolle. Kontenauthentifizierung und Berechtigungen haben weiterhin eigene Aufgaben.

TLS 1.3 authentifiziert den Server, kann auch den Client authentifizieren und schützt den Anwendungsverkehr. Es bescheinigt nicht jede IP-Quelladresse und verhindert nicht, dass eine Überflutung eine Verbindung auslastet. Verschlüsselung und Quellvalidierung schützen unterschiedliche Dinge.

Gelegenheiten für Reflexion verringern

Wenn Sie rekursives DNS betreiben, beschränken Sie die Rekursion auf die Clients, die Sie bedienen wollen. Das unterscheidet sich von autoritativem DNS, das die Öffentlichkeit möglicherweise für Ihre Domains beantworten muss. RFC 5358 erklärt, warum offene Rekursion einen Server in einen Reflektor verwandeln kann.

Prüfen Sie andere exponierte Dienste auf unnötige Erreichbarkeit und übergroße Antworten. Planen Sie Unterstützung gegen DDoS beim Upstream vor einem Vorfall: Ein Filter auf Ihrem eigenen Server kann keine Verbindung wiederherstellen, die bereits gesättigt ist, bevor der Datenverkehr sie erreicht.

Auch IPv6 braucht diese Entscheidungen

Der Umstieg auf IPv6 aktiviert nicht automatisch Verschlüsselung und verhindert keine Quellfälschung. IPsec erfordert bewusste Konfiguration und Schlüsselverwaltung und kann mit beiden IP-Versionen verwendet werden. Leitlinien zur Betriebssicherheit von IPv6 behandeln die tatsächlich benötigten Kontrollen. Prüfen und testen Sie in einem Dual-Stack-Netz beide Wege.

Prüfen, dass der Schutz funktioniert, ohne den Dienst zu beeinträchtigen

Dokumentieren Sie erwartete Bereiche und Routen, testen Sie autorisierten Datenverkehr und Failover und untersuchen Sie anschließend verworfene Pakete und den Zustand des Dienstes. Ein Intrusion-Detection-System kann Sie auf Muster aufmerksam machen; zum Blockieren braucht es eine Präventionsfunktion oder die Reaktion eines Operators. Protokolle sollten erklären, was geschehen ist, und eine behauptete Quelle nicht in eine angenommene Identität verwandeln.

Als gewöhnlicher Internetnutzer sollten Sie sich auf Updates, authentifizierte Verbindungen und Kontosicherheit konzentrieren. Fragen Sie bei Bedarf Ihren Anbieter nach Quellfilterung; die vorgelagerte Paketvalidierung können Sie nicht über einen Browser beheben. Für den Hintergrund lesen Sie wie eine gefälschte Quelle funktioniert oder welches Angriffsmuster durch welche Kontrolle adressiert wird.