Wie markiere ich eingehende iptables-Anfragen von unbekannten MAC-Adressen mit der Markierung 99 mithilfe von conntrack

Wie markiere ich eingehende iptables-Anfragen von unbekannten MAC-Adressen mit der Markierung 99 mithilfe von conntrack

Meine iptables-Regeln laufen seit Jahren ohne Probleme, aber nachdem ich allen vertrauenswürdigen MACs den Zugriff gestattet habe, indem ich:

/sbin/iptables -A INPUT -m mac --mac-source $MAC -j ACCEPT
/sbin/iptables -A FORWARD -m mac --mac-source $MAC -j ACCEPT

Ich versuche, andere Mac-Adressen zu markieren, wie:

/sbin/iptables -A PREROUTING -t mangle -i $INT_DEV -p tcp --dport 80 -j MARK --set-mark 99

aber wenn ich versuche, diese Adresse jetzt zu lesen, indem ich tue,
conntrack -L | grep "src=10.1.1.234"
sehe ich meinen unbekannten Freeloader 10.1.1.234 nirgendwo ...
Dennoch möchte ich in iptables fortfahren, um meinen Freeloader auf eine Anmeldeseite umzuleiten, indem ich

/sbin/iptables -t filter -A FORWARD -m mark --mark 99 -j DROP```  
And obviously it doesn't work because I can't even see it from my conntrack listing.  
What am I doing wrong here..?

Antwort1

Es gibt einen Unterschied zwischen einemPaketMark, auch bekannt alsmarkieren,Firewall-Markierungoderfwmarkund eine Conntrack-Eintragsmarkierung, auch bekannt alsctmark,Verbindungsmarkeoderconnmark: Ersteres wird an das Paket angehängtAbonnieren, letztere ist verbunden mit demConntrack-EintragEs gibt verschiedeneiptables Matte-chesUndTeer-bekommtfür beide, einschließlich Möglichkeiten zurÜbergeben Sie die Markierung vom Paket an den Verbindungseintragodervom Verbindungseintrag bis zum Paket.

Hier ist es nicht notwendig, dieses Zeichen zu verwenden mitKontaktfür diesen Fall und conntrack -List einfach nicht das richtige Tool, um ein verlorenes Paket anzuzeigen (siehe letzter Absatz). Wenn Sie die iptables-nftVariante verwenden, ist der einfachste Weg, markierte Pakete zu Debugzwecken anzuzeigen (sonst -j LOGwürde die Verwendung von die Markierung des Pakets in seine Protokolle einfügen), sie zu verfolgen und zu verwenden, xtables-monitor --traceum ihr Schicksal anzuzeigen ( iptables-legacywürde dies an Kernelprotokolle senden und könnte Protokolle leicht überfluten, außerdem funktioniert es nicht gut mit Netzwerk-Namespaces: das ist eine seltene nicht kompatible Änderung zwischen der -legacy- und der -nft-Variante).

Ein mögliches Beispiel:

iptables -A PREROUTING -t mangle -i $INT_DEV -p tcp --dport 80 -j MARK --set-mark 99
iptables -A PREROUTING -t mangle -m mark --mark 99 -j TRACE

[...]

iptables -A FORWARD -m mark --mark 99 -j DROP

Das detaillierte Schicksal aller derart markierter Pakete zwischen -j TRACEund -j DROP(oder -j ACCEPTzuzüglich aller weiteren Verarbeitung für diese wenigen Auserwählten) kann nun sehr ausführlich wie folgt verfolgt werden:

xtables-monitor --trace

Um die Ausführlichkeit zu begrenzen, könnte man nur Pakete verfolgen, die einen neuen Fluss starten, indem man die TRACERegel wie folgt ändert:

iptables -A PREROUTING -t mangle -m mark --mark 99 -m conntrack --ctstate NEW -j TRACE

Darüber hinaus: Das erste Paket eines solchen Datenflusses löst die Erstellung einesKontaktEintrag, der (auch ohne Markierung) normalerweise im Ereignismodus mit sichtbar wäre conntrack -E -p tcp --dport 80. Aber wenn dieses Paket gelöscht wird, wird der vorläufige Conntrack-Eintrag niebestätigtund das Ereignis wird nie verfügbar gemacht conntrack. Obwohl es mit dem Befehl unsichtbar ist conntrack, wäre es in den Regeln, die verwendet werden, immer noch sichtbar, -m conntrack --ctproto tcp --ctorigdstport 80bevor es gelöscht wird. Jeder weitere Wiederholungsversuch wird wieder ein erstes Paket sein, das einen vorläufigen Eintrag erstellt, der nicht bestätigt wird, weil das Paket gelöscht wurde usw.

Kann daher conntracknur verwendet werden, um Flows anzuzeigen, deren erstes Paket nicht gelöscht wurde, andernfalls wird ihnen kein Flow zur Verfügung gestellt.

verwandte Informationen