Die PF-Regel mit return-rst unter Mac OS X antwortet nicht mit dem TCP-Reset

1079
ldx

Ich versuche, eine einfache PF-Regel hinzuzufügen:

block return-rst out proto tcp from any to any port 33128 

um den gesamten ausgehenden Verkehr auf den TCP-Port 33128 zu filtern, und ich möchte, dass er mit einem Reset reagiert. Wenn ich es jedoch mit teste nc, gibt es eine Zeitüberschreitung, anstatt sofort mit einem Fehler wegen abgelehnter Verbindung zurückzukehren. Dies bedeutet, dass Pakete, die an Port gehen, verworfen 33128werden, ohne dass ein TCP-Reset gesendet wird:

$ nc -v 172.22.2.2 33128 nc: connectx to 172.22.2.2 port 33128 (tcp) failed: Operation timed out 

So aktiviere ich PF und füge diese Regel hinzu:

$ echo "block return-rst out proto tcp from any to any port 33128" > pf.conf $ sudo pfctl -f pf.conf $ sudo pfctl -e 

Was ist los mit dieser Regel?

2
das gleiche Problem haben. Ich versuche, pfctl zu verwenden, um eine vollständig tote Verbindung zu einer bestimmten Domäne für einige Tests zu simulieren, aber alles, was ich bekomme, ist ein Timeout Fernando Mazzon vor 9 Jahren 0
Welche Version von MacOS verwenden Sie? Das funktioniert am 10.10 für mich perfekt. Ich gehe davon aus, dass "pfctl -e" fehlerfrei zurückgegeben wird. eradman vor 9 Jahren 0
@eradman Läuft auch 10.10. $ sudo pfctl -e Keine ALTQ-Unterstützung im Kernel ALTQ-bezogene Funktionen deaktiviert pfctl: pf bereits aktiviert. Andere Regeln funktionieren gut, es ist nur diese Regel, die Probleme hat, Timeouts statt Zurücksetzen Fernando Mazzon vor 9 Jahren 0

1 Antwort auf die Frage

0
zhovner

Ich habe festgestellt, dass einige der PF-Firewall-Regeln nach dem Anschluss von Thunderbolt-Ethernet nicht ordnungsgemäß funktionieren, funktionieren jedoch ordnungsgemäß, wenn WLAN der einzige Netzwerkadapter ist. Beispielsweise gibt die Aktion "return-rst" keine TCP-RST-Pakete zurück.

Update
Ich habe herausgefunden, dass dieser Fehler eine kabelgebundene Ethernet-Verbindung betrifft . Sogar eingebauter iMac-Ethernet-Adapter gegenüber integriertem WLAN-Adapter. Getestet auf alten und neueren iMacs.

Schritte zum Reproduzieren: Im ersten Schritt versuchen wir das richtige Verhalten. Dafür benötigen wir ein Macbook / iMac mit WLAN-Verbindung und kein Thunderbolt-Ethernet.

  1. Spülen Sie alle PF-Regeln
    sudo pfctl -F all

  2. Erstellen Sie eine einfache Regel, um die TCP-Verbindung zu Port 81 zu blockieren. Das TCP-RST-Paket sollte zurückgegeben werden, um die Verbindung sofort abzubrechen.
    echo "block return-rst out proto tcp from any to any port 81" | sudo pfctl -e -f -

  3. Prüfen Sie, ob die neue Regel korrekt hinzugefügt wurde.
    Hier können wir den Zähler von Paketen sehen, die der Firewall-Regel entsprechen.
    pfctl -vsr Packets: 0 Bytes: 0

  4. Versuchen Sie jetzt, die Firewall-Regel mit curl zu testen, das eine Verbindung zu Port 81 herstellt
    curl http://example.com:81 curl: (7) Failed to connect to example.com port 81: Connection refused

Wie erwartet wird diese Verbindung sofort durch die Firewall-Regel abgelehnt. Es ist ein korrektes Verhalten.

Testen Sie jetzt das falsche Verhalten. Dazu müssen wir ein echtes Apple Thunderbolt Ethernet mit einer aktiven Kabelverbindung anschließen. Die WiFi-Verbindung kann deaktiviert sein oder aktiviert bleiben. Dies ist nicht wichtig. In beiden Fällen wird ein Fehler angezeigt.

  1. Lassen Sie die Firewall-Regeln gleich

  2. Curl erneut verwenden
    curl http://example.com:81 .....waiting.... curl: (28) Connection timed out
    Jetzt hängt die Verbindung und wird nach einiger Zeit durch Timeout geschlossen. Die Firewall-Regel ist jedoch noch aktiv und funktioniert.

  3. Wir können die Paketzähler betrachten pfctl -vsr und feststellen, dass die Regel übereinstimmt und die Verbindung immer noch blockiert. Aber ohne TCP-RST-Antwort.

Mein Setup:
macOS: 10.14.1 (18B75)
MacBook Pro (Retina, 15 Zoll, Mitte 2015)
Apple Thunderbolt 2 Ethernet-Adapter (57762)