iptables > pf

N

notwithme

New Member
Hallo zusammen, wie würde die folgende iptables Regel bei pf lauten?

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -i eth0 -s 192.168.0.1 -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -o eth0 -d 192.168.0.1 -p tcp --dport 80 -j ACCEPT
 
Code: 
ext_if=ix0 # oder was auch immer dein "eth0" ist
pass in quick on $ext_if proto tcp from 192.168.0.1 to any port 80
pass out quick on $ext_if proto tcp from any to 192.168.0.1 port 80
block all
Das ist erstmal 1:1 "uebersetzt" - auch wenn die Regeln nicht so wirklich sinnig sind.
 
Dankeschön. Ist das richtig das any einfach mit der lokalen IP meines Rechners ersetzt werden könnte? Muss block all nicht am Anfang stehen um erstmal alles zu Droppen? Und ext_if könnte auch weggelassen werden und direkt die entsprechende Schnittstelle eingetragen werden, ist das korrekt?

Ich vermute sehr bald wird mein Debian durch FreeBSD ersetzt werden. ;)
 
notwithme schrieb:
Dankeschön. Ist das richtig das any einfach mit der lokalen IP meines Rechners ersetzt werden könnte? Muss block all nicht am Anfang stehen um erstmal alles zu Droppen? Und ext_if könnte auch weggelassen werden und direkt die entsprechende Schnittstelle eingetragen werden, ist das korrekt?

Ich vermute sehr bald wird mein Debian durch FreeBSD ersetzt werden. ;)
Zum Vergrößern anklicken....
Wenn du das any ersetzt ist es nicht mehr gleich mit deinen IPTables Regeln. Das ext_if kannst du gerne ohne Variable machen, das block all MUSST du nicht am Anfang haben, kannst es aber - auch das würde aber vom Verhalten der IPTables Regeln leicht abweichen.
 
Ein großer Unterschied zwischen iptables und pf ist, dass bei iptables die erste passende Regel greift und bei pf die letzte. Einen unterschied macht dabei das quick Schlüsselwort. Dann wird der Filter bei passenden Paketen direkt verlassen. Ohne quick wäre es also:
Code: 
ext_if=ix0 # oder was auch immer dein "eth0" ist
block
pass in on $ext_if proto tcp from 192.168.0.1 to  port 80
pass out  on $ext_if proto tcp  to 192.168.0.1 port 80
Bei OpenBSD würde auch noch der Verbindungsstatus verwaltet. Bei FreeBSD bin ich mir da gerade nicht sicher.
 
Ihr überseht die Regel

iptables -A INPUT -i eth0 -s 192.168.0.1 -p tcp --sport 80 -j ACCEPT

iptables ist per default stateless. Die Regel erlaubt einfach nur die Antworten vom Webserver und ist bei pf gar nicht nötig.
 
TCM schrieb:
iptables -A INPUT -i eth0 -s 192.168.0.1 -p tcp --sport 80 -j ACCEPT

iptables ist per default stateless. Die Regel erlaubt einfach nur die Antworten vom Webserver ...
Zum Vergrößern anklicken....
Nein, mit iptables erlaubt diese Regel auch eine (erste) syn-Verbindung mit dem source-Port 80 (von der source-IP 192.168.0.1). Z. B.:
Code: 
sudo nping -c 1 --tcp --flags syn -g 80 -p 443 192.168.0.10
... und nicht nur RELATED/ESTABLISHED-Verbindungen.
 
Davon angesehen ist es immer schwierig, wenn man eine Transformation macht ohne die eigentliche Absicht dahinter zu kennen. Ich würde in beiden Fällen mit States arbeiten.
 
morromett schrieb:
Nein, mit iptables erlaubt diese Regel auch eine (erste) syn-Verbindung mit dem source-Port 80 (von der source-IP 192.168.0.1). Z. B.:
Zum Vergrößern anklicken....

Lies "Die Regel erlaubt einfach nur die Antworten vom Webserver", nicht "Die Regel erlaubt einfach nur die Antworten vom Webserver".

Ich habe nicht behauptet, dass kein anderer Traffic durchgeht, sondern nur gesagt, wozu diese Regel wohl dient, weil das niemand erkannt hat und alle irgendwelche Regeln mit Zielport 80 in die umgekehrte Richtung bauen, die im Original nirgendwo vorkam. Dass untypischer Traffic mit Source-Port 80 erlaubt wird, ist selbstverständlich die Folge von stupidem stateless Filtern und stand gar nicht zur Debatte.
 
TCM schrieb:
Lies "Die Regel erlaubt einfach nur die Antworten vom Webserver", nicht "Die Regel erlaubt einfach nur die Antworten vom Webserver".

Ich habe nicht behauptet, dass kein anderer Traffic durchgeht, sondern nur gesagt, wozu diese Regel wohl dient, weil das niemand erkannt hat und alle irgendwelche Regeln mit Zielport 80 in die umgekehrte Richtung bauen, die im Original nirgendwo vorkam. Dass untypischer Traffic mit Source-Port 80 erlaubt wird, ist selbstverständlich die Folge von stupidem stateless Filtern und stand gar nicht zur Debatte.
Zum Vergrößern anklicken....


Die Leute haben die Frage richtig gelesen und eine möglichst nahe Transformation der genannten Regeln gemacht. Du hingegen interpretierst, was wohl gemacht werden soll, und ziehst deine Schlüsse daraus wie die Regeln sein sollten. IPTables kann btw. genauso mit States arbeiten.
 
  • Like
Reaktionen: jmt
medV2 schrieb:
Die Leute haben die Frage richtig gelesen und eine möglichst nahe Transformation der genannten Regeln gemacht.
Zum Vergrößern anklicken....
Falsch. Lies doch einfach, was da steht:

iptables -A INPUT -i eth0 -s 192.168.0.1 -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -o eth0 -d 192.168.0.1 -p tcp --dport 80 -j ACCEPT

Auf eth0 rein: alles VON 192.168.0.1 QUELLPORT 80
Auf eth0 raus: alles NACH 192.168.0.1 ZIELPORT 80

Und das deckt nunmal ausgehende Verbindungen zu 192.168.0.1:80 und mangels irgendeines State-Handlings die Antworten ab (und noch weiteren irrelevanten Kram wie eingehende Verbindungen von 192.168.0.1:80 zum Host).

Was es nicht abdeckt, sind eingehende Verbindungen zum Host auf Port 80.

medV2 schrieb:
IPTables kann btw. genauso mit States arbeiten.
Zum Vergrößern anklicken....
Ja, "kann", wenn man es explizit hinschreibt. Ich habe geschrieben "per default".
 
TCM schrieb:
Falsch. Lies doch einfach, was da steht.


Ja, "kann", wenn man es explizit hinschreibt. Ich habe geschrieben "per default".
Zum Vergrößern anklicken....
Wahr. OP schreibt "wie würde die folgende iptables Regel bei pf lauten?". Nichts von States oder Webservern. Und da steht nunmal eine Regel, die JEDEN Traffic von source 192.168.0.1 mit sport 80 erlaubt. JEDEN. Und nicht nur established. Daher braucht es auch bei pf diese Regel um das Verhalten abzubilden.
 
medV2 schrieb:
Wahr. OP schreibt "wie würde die folgende iptables Regel bei pf lauten?". Nichts von States oder Webservern. Und da steht nunmal eine Regel, die JEDEN Traffic von source 192.168.0.1 mit sport 80 erlaubt. JEDEN. Und nicht nur established. Daher braucht es auch bei pf diese Regel um das Verhalten abzubilden.
Zum Vergrößern anklicken....
Und wo steht hier im Thread eine Regel mit "from 192.168.0.1 port 80"?

Können wir nicht einfach bei realen Szenarien bleiben und nicht wie die Autisten auf Unsinn rumhacken? Welcher reale Traffic kommt von Port 80, der keine Antwort auf initialen Traffic ist?

Einfach mit etwas Empathie sehen, was der User will...
 
Der zweite Post von double-p hat das gut übersetzt, aber in der Tat, er hat nicht den sourceport mit angegeben sondern dest, ist mir beim drüberlesen auch nicht aufgefallen. OP teilt uns nicht mit was er bezweckt, daher betreibe ich kein Rätselraten. Das auch die ursprünglichen Regeln nicht optimal sind wurde ja auch schon genannt.

Aber du bist hier in den Thread reingepoltert, dass alle anderen ja "übersehen" dass man das garnicht braucht und States und blah. Das basiert alles nur auf deiner Annahme - die mag vernünftig und wahrscheinlich sein - aber eben nur ne Annahme und so solltest du dann auch formulieren.
 
OK, ich nahm an. Hier deshalb die 1:1 Übersetzung mit Credits an pp ;) und dem Disclaimer, dass die Regeln so wenig Sinn ergeben:

Code: 
ext_if=ix0 # oder was auch immer dein "eth0" ist
pass in  quick on $ext_if proto tcp from 192.168.0.1 port 80 no state
pass out quick on $ext_if proto tcp to   192.168.0.1 port 80 no state
block all
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben