Da pf ein grandioser Paketfilter ist, in den auch schon viele Erfahrungen aus der Praxis eingeflossen sind. Mag ja sein, dass nicht jeder die Syntax von pf mag. Aber die von iptables mag ganz sicher niemand. Man gewöhnt sich vielleicht daran, aber im Grunde genommen ist iptables in der Handhabung eine Zumutung.
Mal ganz davon abgesehen, dass die Dokumentation von iptables grausam ist (kaum vorhanden, lückenhaft und veraltet). Alleine daran kann sich der neue Filter ein Vorbild nehmen, wie es bei pf gelöst ist.
Von Daniel Seuffert am Do, 19. März 2009 um 20:58 #
pf stammt von BSD ab, genau gesagt OpenBSD, daß da die Dokumentation eine andere Qualität hat als bei iptables/Linux überrascht wohl niemand. Ob dies da bei nftables hinbekommen wird man sehen.
Ob die Handhabung von iptables eine Zumutung ist weiß ich nicht, tangiert mich nicht mal periphär
Seuffert, immer noch beleidigt weil keiner dein BSD haben will? Mach doch einfach noch ein Forum auf, wo du deine Fanboys bekehren kannst ... auch wenn nur noch eine handvoll da ist.
> FWBuilder gibt es. Aber eine Firewall kann man auch nur bedienen wenn man weiß wie es geht...
Bei Firewalls solltest Du immer wissen was Du tust. Mit einer Gui kannst das Regelset sehr schön visualisiert erstellen oder bearbeiten. Ist imho auch einer der Gründe für den Erfolg von Checkpoint.
Zum Thema Personal Firewall fällt mir spontan gerade Firestarter ein, wobei ich keinerlei Informationen gefunden habe, ob diese auf iptables aufsetzt. Ich schätze eher nicht. http://www.fs-security.com/
Falls die Informationen auf Wikipedia zutreffen, basiert Firestarter auf netfilter welches offenbar das Herzstück auf das auch iptables aufsetzt darstellt. http://de.wikipedia.org/wiki/Personal_Firewall#Linux
Ich habe zugegeben zu wenig Ahnung von der Materie, doch mit Firestarter war es mir schon einmal mit relativ wenig Wissen und Aufwand möglich, ein Gerät für das Internet Sharing einzurichten. Offenbar kann das Programm/Frontend aber noch eine Menge mehr.
Ich habe zugegeben zu wenig Ahnung von der Materie, doch mit Firestarter war es mir schon einmal mit relativ wenig Wissen und Aufwand möglich, ein Gerät für das Internet Sharing einzurichten.
Wenn du, wie du selbst sagst, zu wenig Ahnung von der Materie hast, wie kannst du dann feststellen, ob dein Konzept sicher ist oder nicht?
Oh das kann ich gar nicht. In meinem Fall Anwendungsfall ging es lediglich um das einfache Verteilen von Internet von einem Lan in ein anderes. Dies hätte bestimmt auch anders gelöst werden können, doch nach ca. zwei Stunden damit beschäftigen konnte ich es mit Firestarter relativ einfach lösen.
Ob sicher oder nicht kann ich mich nur auf Quellen wie Erfahrungsberichte anderer und ähnliches stützen, das stand in meinen beiden Beträgen aber auch gar nicht zur Debatte.
Ich hatte lediglich das Gefühl es könnte auch andere Benutzer dieses Forums bzw. Leser dieses Threads interessieren, was es sonst noch für Grafische Frontends für das errichten einer, in diesem Fall, Personal-Firewall Lösung gibt.
Ich finde den PF Syntax in keiner Weise anschaulicher als iptables. Und einen großen Vorteil von iptables finde ich, das man per Cmdline mal schnell einzelne Regeln dazufügen kann, und nicht immer alle Regeln auf einmal bearbeiten muss
Du kannst auch bei pf einzelne Regeln per Commandline hinzufügen. Normalerweise braucht man das aber nicht, da es sogenannte Tabellen gibt, die das Einfügen von Regeln (die auch hässliche Seiteneffekte haben können) überflüssig machen.
Nicht? Bei pf bilden Regeln fast vollständige englische Sätze, z.B. "pass in from any to host port 22 keep state", dagegen muss man in iptables mit verschiedenen Chains, nicht intuitiven Commandline-Optionen und anderem hantieren, was kompliziert, nicht sehr übersichtlich und fehleranfällig ist. Trotz dieser hohen Komplexität ist iptables nicht flexibler oder schneller als andere, vergleichbare Paketfilter.
pf war für mich geradezu eine Offenbarung. So muss es sein, nicht so ein wortwörtliches "Gefrickel" wie mit iptables. Ich wünsche mir einen pf-Port für Linux sehr!
Von Daniel Seuffert am Do, 19. März 2009 um 21:02 #
pf gibt es nun schon etliche Jahre, die Wahrscheinlichkeit, daß das jemand nach Linux portet ist relativ gering, zumal da einiges an Aufwand aufgewendet werden müsste, wenn man es performant sprich in den Kernel integrieren möchte. Es scheitert aber schon am NIH-Syndrom. Lieber macht man 3-5 konkurrierende Neuentwicklungen.
Ein schönes Beispiel, warum ich mit pf und ähnlich gestrickten Paketfiltern nicht zurecht komme. Menschliche Sprache ist oft zweideutig und unklar. Typische Kommandozeilensystax ist dagegen logisch und lässt keine Zweifel zu.
Das o.g. Beispiel läst sich nun auf vielfältige Weise interpretieren. Ist damit gemeint
Lasse alle eingehenden (in) Pakete von überall (any) auf Port 22 zu, wenn der Status "keep" ist
Forwarde alle Pakete von überall nach host auf Port 22 und behalte (keep) den status
Leite alle eingehenden Pakete auf Port 22 um (Port-Forwarding?)
Ich habe echt keine Ahnung, was diese Regel nun bedeuten soll... Wenn aber eine solche wahrscheinlich einfache Regel Schwierigkeiten bereitet, was wird dann erst mit komlizierteren Regeln, z. B. folgende Regeln für einen transparenten Proxy?
> Lasse alle eingehenden (in) Pakete von überall (any) auf Port 22 zu, wenn der Status "keep" ist
"keep state" ist ein Schlüsselwort, das stateful filtering aktiviert. Mittlerweile nicht mehr zwingend notwendig. Ansonsten macht die Regel genau das, ja.
> Forwarde alle Pakete von überall nach host auf Port 22 und behalte (keep) den status
Wo liest du das aus der Regel? Da steht nichts von "forward".
> Leite alle eingehenden Pakete auf Port 22 um (Port-Forwarding?)
Wo liest du das aus der Regel? Da steht nichts von "redirect" (bzw. der Kurzform "rdr" von pf). Die Regeln sind ja eben nur "fast" wie englische Sätze, da die Grammatik der Eindeutigkeit halber eingeschränkt wird.
Das kommt u. a. daher, weil "to pass" im englischen sehr viele Bedeutungen haben kann. Es kann "durchlassen, passieren lassen" bedeuten, aber auch "übergeben, weitergeben", wäre also vom Sinn her identisch mit "forward".
Also ich halte die iptables-Syntax für wesentlich praktikabler. Dieser Versuch, Kommandos wie gesprochene Sätze aussehen zu lassen, führt nur zu endlosen unlesbaren Romanen, Doppeldeutigkeiten und viel mehr Verwirrung als eine einfache Kommandozeile wo jeder Schalter genau eine Bedeutung hat, die man jederzeit nachschlagen kann.
Abgesehen davon halte ich es für gemeingefährlich, wenn Leute, die nichtmal wissen wie ein TCP-Handshake abläuft, an Firewall-Regeln rumfingern wollen.
> Abgesehen davon halte ich es für gemeingefährlich, wenn Leute, > die nichtmal wissen wie ein TCP-Handshake abläuft, an Firewall-Regeln rumfingern wollen.
Was hat dein TCP-Handshake mit der schwulen iptables-Syntax zu tun?
Die pf-Kommandos und keywords sind absolut eindeutig, aber eben an die englische Sprache angelehnt. Du kannst sie jederzeit in der Manpage nachschlagen. Du kannst mir glauben, pf ist in der Praxis viel einfacher zu lesen als iptables, ich kenne Beide. Romane hast du eher bei iptables, da du selbst für einfache Dinge oft in mehreren Chains Regeln hinzufügen musst.
Was du da mit dem TCP-Handshake meinst, verstehe ich nicht. Ich glaube hier versucht nur jemand zu trollen, der pf überhaupt nicht kennt.
> Die Vorteile der Lösung sind eine geringere Größe, Erweiterbarkeit und Geschwindigkeit.
YMMD. Die deutsche Grammatik birgt schonmal die eine oder andere Falle... Wie war das noch mal mit den Adjektiven vor einer Aufzählung? Egal, man ahnt ja was gemeint ist
Den Kommentar hatte ich auch schon fertig, habe mich dann aber glücklicherweise nicht zum Deppen gemacht. Durch den indirekten Artikel vor dem Adjektiv wird der Bezug klar, reingefallen!
Das Schöne ist ja, dass du trotzdem weißt was gemeint war...
Ich finde den Satz absolut in Ordnung. Eine News sollte keine Referenz für eindeutiges Deutsch (was du im Allgemeinen kaum finden wirst) darstellen, sondern informativ sein. (meine Meinung)
Um es auf den Punkt zu bringen - auch du hast Fehler in deinen wenigen Sätzen ^^
ich darf begründet behaupten, dass iptables der flexibelste und von der Architektur her der mächtigste Paketfilter von allen ist. Dies erkauft man sich jedoch tatsächlich mit einem größeren Lernaufwand bei der Bedienung. Damit ist er sicherlich nicht sehr Einsteiger-freundlich, dafür aber erste Wahl für den Netzwerk-Admin. Die anderen genannten Paketfilter wie IPF, IPFilter oder PF sind vielleicht etwas einfacher zu erlernen, haben aber auch ihre geschichtlich gewachsenene Vor- und Nachteile. Vor allem treffen sie bereit Vorentscheidungen in ihrer Syntax und Architektur, die sich nicht mehr durch Regeln beeinflussen oder abfragen lassen - damit sind sie weniger steuerbar. Ich ziehe iptables jedem anderen Paketfilter vor.
Äh, naja. Du behauptest, pf sei in Syntax und Funktionsumfang mit pf vergleichbar. Das kann man aber kaum behaupten, es ist eine massive Weiterentwicklung. Außer den Ähnlichkeiten in der Syntax sind die Paketfilter mittlerweile sehr unterschiedlich.
Und praktische Belege dafür, dass iptables' Flexibilität Vorteile bringt, habe ich noch nicht gesehen. Features wie traffic normalization findet man m.W. in iptables auch nur ansatzweise.
Naja, da wird iptables aber nur ganz am Rand behandelt, und besonders gut ist die Dokumentation auch ansonsten nicht. Vor allem aber mangelt es eben an *offizieller* Dokumentation von Seitens des netfilter-Projekts.
Na toll. Etwas moderneres und praktikableres wäre schön, Richtung pf. Das sieht aber nicht gerade danach aus.
Und die Syntax von pf mag auch nicht jeder, nicht umsonst gibt es auch ipfw(2) und PIFilter.
pf basiert auf ipf und ipf Regeln lesen sich wie vollständige Sätze.
Mag ja sein, dass nicht jeder die Syntax von pf mag. Aber die von iptables mag ganz sicher niemand. Man gewöhnt sich vielleicht daran, aber im Grunde genommen ist iptables in der Handhabung eine Zumutung.
Mal ganz davon abgesehen, dass die Dokumentation von iptables grausam ist (kaum vorhanden, lückenhaft und veraltet). Alleine daran kann sich der neue Filter ein Vorbild nehmen, wie es bei pf gelöst ist.
Ob dies da bei nftables hinbekommen wird man sehen.
Ob die Handhabung von iptables eine Zumutung ist weiß ich nicht, tangiert mich nicht mal periphär
Werdu bist weiß ich nicht, interessiert mich auch nicht.
Was dein Beitrag zum Thema beiträgt ist mir auch nicht ersichtlich, macht auch nichts.
Egal, wir haben das Recht audf freie Meinungsäusserung, jeder möge deinen post selbst beurteilen.
mfg gwe
Stimmt! Runde Räder jibbet überall, $Bedarfsträger erfindet was neues, auch wenns runde Räder tun würden.
Nachteil: Einstiegshürde für Neulinge, dies saufen wie bisher ab oder lernen mühsam schwimmen.
Egal, der Akzeptanz in Developerkreisen wird es förderlich sein und wo Userspace draufsteht, sind oft auch schicke GUI-Tools nicht weit.
Tendenz
Bei Firewalls solltest Du immer wissen was Du tust. Mit einer Gui kannst das Regelset sehr schön visualisiert erstellen oder bearbeiten. Ist imho auch einer der Gründe für den Erfolg von Checkpoint.
Gz,
Klaus
http://www.fs-security.com/
Ich habe zugegeben zu wenig Ahnung von der Materie, doch mit Firestarter war es mir schon einmal mit relativ wenig Wissen und Aufwand möglich, ein Gerät für das Internet Sharing einzurichten. Offenbar kann das Programm/Frontend aber noch eine Menge mehr.
Wenn du, wie du selbst sagst, zu wenig Ahnung von der Materie hast, wie kannst du dann feststellen, ob dein Konzept sicher ist oder nicht?
Ob sicher oder nicht kann ich mich nur auf Quellen wie Erfahrungsberichte anderer und ähnliches stützen, das stand in meinen beiden Beträgen aber auch gar nicht zur Debatte.
Ich hatte lediglich das Gefühl es könnte auch andere Benutzer dieses Forums bzw. Leser dieses Threads interessieren, was es sonst noch für Grafische Frontends für das errichten einer, in diesem Fall, Personal-Firewall Lösung gibt.
>danach aus.
Hatte mich auch schon auf eine etwas menschenfreundlichere Syntax gefreut...
Und einen großen Vorteil von iptables finde ich, das man per Cmdline mal schnell einzelne Regeln dazufügen kann, und nicht immer alle Regeln auf einmal bearbeiten muss
Normalerweise braucht man das aber nicht, da es sogenannte Tabellen gibt, die das Einfügen von Regeln (die auch hässliche Seiteneffekte haben können) überflüssig machen.
pf war für mich geradezu eine Offenbarung. So muss es sein, nicht so ein wortwörtliches "Gefrickel" wie mit iptables. Ich wünsche mir einen pf-Port für Linux sehr!
Ein schönes Beispiel, warum ich mit pf und ähnlich gestrickten Paketfiltern nicht zurecht komme. Menschliche Sprache ist oft zweideutig und unklar. Typische Kommandozeilensystax ist dagegen logisch und lässt keine Zweifel zu.
Das o.g. Beispiel läst sich nun auf vielfältige Weise interpretieren. Ist damit gemeint
Ich habe echt keine Ahnung, was diese Regel nun bedeuten soll...
Wenn aber eine solche wahrscheinlich einfache Regel Schwierigkeiten bereitet, was wird dann erst mit komlizierteren Regeln, z. B. folgende Regeln für einen transparenten Proxy?
iptables -t nat -A PREROUTING -i $INT -s ! $PROXY -p tcp --dport 80 -j DNAT --to $PROXY:8080
iptables -t nat -A POSTROUTING -o $INT -s $LAN -d $PROXY -p tcp --dport 8080 -j SNAT --to $FWINT
iptables -A FORWARD -s $LAN -d $PROXY -i $INT -o $INT -p tcp --dport 8080 -j ACCEPT
Ich wage mit gar nicht vorzustellen, wie das mit pf umgesetzt werden soll...
"keep state" ist ein Schlüsselwort, das stateful filtering aktiviert. Mittlerweile nicht mehr zwingend notwendig.
Ansonsten macht die Regel genau das, ja.
> Forwarde alle Pakete von überall nach host auf Port 22 und behalte (keep) den status
Wo liest du das aus der Regel? Da steht nichts von "forward".
> Leite alle eingehenden Pakete auf Port 22 um (Port-Forwarding?)
Wo liest du das aus der Regel? Da steht nichts von "redirect" (bzw. der Kurzform "rdr" von pf).
Die Regeln sind ja eben nur "fast" wie englische Sätze, da die Grammatik der Eindeutigkeit halber eingeschränkt wird.
Und mit
iptables -t nat -A PREROUTING -i $INT -s ! $PROXY -p tcp --dport 80 -j DNAT --to $PROXY:8080
iptables -t nat -A POSTROUTING -o $INT -s $LAN -d $PROXY -p tcp --dport 8080 -j SNAT --to $FWINT
iptables -A FORWARD -s $LAN -d $PROXY -i $INT -o $INT -p tcp --dport 8080 -j ACCEPT
Das ist recht einfach, ungefähr so:
rdr on $interface proto tcp from $internes_netz to !$internes_netz port www -> $proxy port $proxy_port
Das kommt u. a. daher, weil "to pass" im englischen sehr viele Bedeutungen haben kann. Es kann "durchlassen, passieren lassen" bedeuten, aber auch "übergeben, weitergeben", wäre also vom Sinn her identisch mit "forward".
Super einfache Syntax!!!
Abgesehen davon halte ich es für gemeingefährlich, wenn Leute, die nichtmal wissen wie ein TCP-Handshake abläuft, an Firewall-Regeln rumfingern wollen.
> die nichtmal wissen wie ein TCP-Handshake abläuft, an Firewall-Regeln rumfingern wollen.
Was hat dein TCP-Handshake mit der schwulen iptables-Syntax zu tun?
Du kannst mir glauben, pf ist in der Praxis viel einfacher zu lesen als iptables, ich kenne Beide.
Was du da mit dem TCP-Handshake meinst, verstehe ich nicht.
Ich glaube hier versucht nur jemand zu trollen, der pf überhaupt nicht kennt.
YMMD. Die deutsche Grammatik birgt schonmal die eine oder andere Falle...
Wie war das noch mal mit den Adjektiven vor einer Aufzählung? Egal, man ahnt ja was gemeint ist
Ich finde den Satz absolut in Ordnung. Eine News sollte keine Referenz für eindeutiges Deutsch (was du im Allgemeinen kaum finden wirst) darstellen, sondern informativ sein. (meine Meinung)
Um es auf den Punkt zu bringen - auch du hast Fehler in deinen wenigen Sätzen ^^
Ja wie war das denn noch gleich?
Sieht für mich völlig in Ordnung aus.
ich darf begründet behaupten, dass iptables der flexibelste und von der Architektur her der mächtigste Paketfilter von allen ist. Dies erkauft man sich jedoch tatsächlich mit einem größeren Lernaufwand bei der Bedienung. Damit ist er sicherlich nicht sehr Einsteiger-freundlich, dafür aber erste Wahl für den Netzwerk-Admin. Die anderen genannten Paketfilter wie IPF, IPFilter oder PF sind vielleicht etwas einfacher zu erlernen, haben aber auch ihre geschichtlich gewachsenene Vor- und Nachteile. Vor allem treffen sie bereit Vorentscheidungen in ihrer Syntax und Architektur, die sich nicht mehr durch Regeln beeinflussen oder abfragen lassen - damit sind sie weniger steuerbar. Ich ziehe iptables jedem anderen Paketfilter vor.
NF
Und praktische Belege dafür, dass iptables' Flexibilität Vorteile bringt, habe ich noch nicht gesehen.
Features wie traffic normalization findet man m.W. in iptables auch nur ansatzweise.
Mal vom Traffic-Shaping mit tc und iptables Durcheinandergefummel abgesehen.
desweiteren... wer eine nahezu aehnliche syntax heute schon einsetzen will:
http://ferm.foo-projects.org/
ist ein frontend zu iptables, liefert sehr kompakte ueberschaubare firewalls.
Vor allem aber mangelt es eben an *offizieller* Dokumentation von Seitens des netfilter-Projekts.