Umgeht tcpdump iptables?

Ich habe fälschlicherweise einen DNS-Server mit offenem Resolver eingerichtet, der bald für eine Reihe von DDoS-Angriffen aus Russland verwendet wurde. Aus diesem Grund habe ich Port 53 auf beiden DNS-Servern für alle außer für vertrauenswürdige IP-Adressen vollständig blockiert. Es funktioniert, ich kann keine Verbindung mehr herstellen, aber was mir komisch vorkommt, ist, dass ich beim Ausführen von tcpdump auf eth1 (der Schnittstelle zwischen Server und öffentlichem Internet) viele eingehende Pakete vom Angreifer zum Port 53 sehe.

Ist es normal, dass tcpdump diese Pakete anzeigt, auch wenn iptables sie fallen lässt? Oder habe ich iptables falsch konfiguriert?

Auf der anderen Seite sehe ich keine ausgehenden Pakete von meinem Server, was ich vorher getan habe, also denke ich, dass die Firewall funktioniert. Es überrascht mich nur, dass der Kernel Pakete nicht vollständig fallen lässt? Oder ist er so tcpdumpan den Kernel gebunden, dass er die Pakete sieht, noch bevor sie zu iptables gelangen?

Das ist eine schöne Frage.

Tatsächlich ist tcpdump die erste Software, die nach dem Draht (und der Netzwerkkarte, wenn Sie so wollen) auf dem Weg nach IN und der letzte auf dem Weg nach OUT gefunden wird .

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

Auf diese Weise werden alle Pakete angezeigt, die Ihre Schnittstelle erreichen, und alle Pakete, die Ihre Schnittstelle verlassen. Da Pakete an Port 53, wie von tcpdump angezeigt, keine Antwort erhalten, haben Sie erfolgreich überprüft, ob Ihre iptables-Regeln korrekt konfiguriert wurden.

BEARBEITEN

Vielleicht sollte ich ein paar Details hinzufügen. tcpdump basiert auf libpcap , einer Bibliothek, die einen Paket-Socket erstellt . Wenn ein reguläres Paket im Netzwerkstapel empfangen wird, prüft der Kernel zuerst , ob es einen Paketsocket gibt, der an dem neu angekommenen Paket interessiert ist, und leitet das Paket, falls vorhanden, an diesen Paketsocket weiter. Wenn die Option ETH_P_ALL gewählt ist, gehen alle Protokolle durch den Paketsocket .

libpcap implementiert einen solchen Paketsocket mit aktivierter Option, speichert eine Kopie für den eigenen Gebrauch und dupliziert das Paket zurück auf den Netzwerkstapel, wo es vom Kernel auf die übliche Weise verarbeitet wird, einschließlich der Übergabe an netfilter , den Kernel -space Gegenstück von Iptables . Das Gleiche gilt in umgekehrter Reihenfolge ( dh zuerst Netzfilter, dann letzter Durchgang durch den Paketsocket) auf dem Weg nach draußen.

Ist dies anfällig für Hacking? Aber natürlich. Es gibt zweifellos Proof-of-Concept-Rootkits, die libpcap verwenden , um die Kommunikation mit dem Rootkit abzufangen, bevor die Firewall die Hand darauf legen kann. Aber auch dies verblasst im Vergleich zu der Tatsache, dass eine einfache Google-Abfrage den funktionierenden Code aufdeckt, der den Datenverkehr sogar vor libpcap verbirgt . Dennoch sind die meisten Fachleute der Ansicht, dass die Vorteile beim Debuggen von Netzwerkpaketfiltern die Nachteile bei weitem überwiegen.