Ich habe versehentlich einen Open-Resolver-DNS-Server eingerichtet, der bald für eine Reihe von DDoS-Angriffen verwendet wurde, die irgendwo aus Russland stammten oder dorthin gingen. Aus diesem Grund habe ich Port 53 auf beiden DNS-Servern für alle außer vertrauenswürdigen IPs vollständig blockiert. Es funktioniert zwar, da ich keine Verbindung mehr zu ihnen herstellen kann, aber was mir seltsam vorkommt, ist, dass ich, wenn ich tcpdump ausführe eth1(das ist die Schnittstelle auf dem Server mit öffentlichem Internet), viele eingehende Pakete vom Angreifer an Port 53 sehe.
Ist es normal, dass tcpdump diese Pakete anzeigt, auch wenn iptables sie verwirft? Oder habe ich iptables falsch konfiguriert?
Andererseits sehe ich keine ausgehenden Pakete von meinem Server, was vorher der Fall war, also gehe ich davon aus, dass die Firewall einigermaßen funktioniert. Es überrascht mich nur, dass der Kernel Pakete nicht vollständig verwirft? Oder ist er tcpdumpso an den Kernel angeschlossen, dass er die Pakete sieht, noch bevor sie zu iptables gelangen?
Antwort1
Das ist eine schöne Frage.
In der Tat,tcpdumpist die erste Software, die nach dem Kabel (und der Netzwerkkarte, wenn Sie so wollen) auf dem Weg gefunden wirdINund der letzte auf dem WegAUS.
Wire -> NIC -> tcpdump -> netfilter/iptables
iptables -> tcpdump -> NIC -> Wire
Somit werden alle Pakete erkannt, die Ihre Schnittstelle erreichen und alle Pakete, die Ihre Schnittstelle verlassen. Da Pakete an Port 53 keine Antwort erhalten, wie tcpdump erkennt, haben Sie erfolgreich überprüft, dass Ihre iptables-Regeln richtig konfiguriert wurden.
BEARBEITEN
Vielleicht sollte ich ein paar Einzelheiten hinzufügen.tcpdumpbasiert auflibpcap, eine Bibliothek, die einePaket-Socket. Wenn ein reguläres Paket im Netzwerkstapel empfangen wird,Ersteprüft, ob es einen Paket-Socket gibt, der an dem neu eingetroffenen Paket interessiert ist, und leitet das Paket, wenn dies der Fall ist, an diesen Paket-Socket weiter. Wenn die OptionETH_P_ALLgewählt wird, dannalleProtokolle gehen über den Paket-Socket.
libpcapimplementiert einen solchen Paket-Socket mit aktivierter Option, behält eine Kopie für den eigenen Gebrauch und dupliziert das Paket zurück auf den Netzwerk-Stack, wo es vom Kernel auf die übliche Weise verarbeitet wird, einschließlich der Übergabe anNetzfilter, das Kernel-Space-Gegenstück zuiptablesDasselbe in umgekehrter Reihenfolge (dh, zuerst der Netzfilter und dann zuletzt der Durchgang durch den Paket-Socket), auf dem Weg nach draußen.
Ist das anfällig für Hackerangriffe? Aber natürlich. Es gibt sicherlich Proof-of-Concept-Rootkits, dielibpcapum die an das Rootkit gerichtete Kommunikation abzufangenVordie Firewall kann sie erfassen. Aber selbst das verblasst im Vergleich zu der Tatsache, dass eine einfache Google-Abfrage zutage fördertArbeitenCode, der den Verkehr verbirgt, sogar vorlibpcapDie meisten Experten sind jedoch der Meinung, dass die Vorteile beim Debuggen von Netzwerkpaketfiltern die Nachteile bei weitem überwiegen.
Antwort2
Heute habe ich etwas Paketanalyse geübt. Ich interessiere mich besonders für IPsec und tcpdump. So bin ich auf diese Webseite gestoßen, auf der die Beziehung zwischen Abhören und Paketfluss besprochen wird. Ich denke, sie könnte hilfreich sein, um Ihre Verwirrung zu beseitigen.
Abbildung 9: ICMP-Echoanforderung h1 → h2, R1-Durchlauf, Verschlüsseln + Kapseln:
