Freie Paketfilter

H

heesen

Rainer Heesen
Hallo,

in der iX von Juni 2007 ist ein Artikel über freie Paketfilter, in der u.a. PF, IPF oder IPFW bewertet werden. Diese drei Firewalls sind auch unter FreeBSD einsetzbar. Teilt ihr das Vorgehen und die Bewertung im Artikel?

Viele Grüße

Rainer
 
PF ist die einzige Firewall die ich je eingesetzt habe. Damit bin ich bisher vollkommen zufrieden.
 
PF und Netfilter sind am besten bewertet worden; PF vor allem durch die einfachere Konfiguration und Administration der Filterregeln.
 
Moin Moin,

ich hab den Artikel noch nicht gelesen. Aber nachdem ich ziemlich viel mit IPTables in Shell Skripten rumgefrickelt habe, bin ich von PF begeistert und sehr zufrieden. Selbst die Hilfsmittel, die es unter Linux gibt, finde ich alle irgendwie umstaendlich.
Eigentlich moechte ich nur noch PF verwenden. :)

Wie ist denn so das Fazit in Kurzform?

Just my 2 cent... ;)
 
Ich hab auch nur das Fazit gelesen, weil ich fuer den Rest keine Zeit hatte.

"Gewinner" mit klarem Vorsprung sind pf und iptables, weil Erstes praktische Makros bietet und Zweites Funktionen beinhaltet, die es ermoeglichen, VoIP und FTP problemlos ohne Proxy benutzen zu koennen.
 
Danke fuer die Information.

Dann werde ich mir den Artikel mal organisieren und lesen. Mal schauen, was dann noch fuer Details auftauchen.
 
Eigentlich ist die Sache ganz einfach:

- PF ist das derzeit beste Filtersystem für FreeBSD. Einfacher Syntax, viele Möglichkeiten, durchdacht und schnell. Wenn man neue Firewalls aufsetzt, würde ich immer PF nehmen.

- IPFW ist eine FreeBSD Eigenentwicklung. Direkt sprichts nichts gegen sie, allerdings ist das System mit den nummerierten Regeln und dem "First Match" Vorgehen aus heutiger Sicht umständlich und es kann beim Schreiben der Regeln einem schon Kopfschmerzen bereiten. Gerade bei komplexeren Regelsätzen. Außerdem ist IPFW verglichen mit PF relativ langsam und benötigt relativ viel Rechenleistung. Das gilt insbesondere für NAT. Weiter hat Inet6 hier sowohl in der alten Variante (eigenes Kernelmodul) und in der neuen (Ein gemeinsames Modul) immer etwas Ärger gemacht, wirklich sauber lief es nie.
Einen wirklichen Grund existierende Firewalls von IPFW auf PF zu migrieren sehe ich nicht, wenn denn alles funktioniert. Neue würde ich allerdings auch nicht mehr aufsetzen, sondern stattdessen PF nehmen.
 
Ein Nachteil von PF sollte imho aber nicht verschwiegen werden: für traffic shaping mit altq muss man einen eigenen Kernel bauen -- damit fällt bequemes patchen des Kernels mit freebsd-update flach. Das Problem hat ipfw2 mit dummynet nicht.
 
ich hatte auch längere zeit iptables im einsatz. da ich allerdings mit fwbuilder die regelsätze erstellt habe, hatte ich da weniger kopfschmerzen bei (ich find die syntax irgendwie nicht so den hit). bei pf hab ich dann die dateien selber geschrieben und bin begeistert von den möglichkeiten mit pf (allerdings ist ftp wirklich nicht sehr schön damit). wir haben das hier im einsatz (allerdings unter obsd) und es läuft sehr gut :).

ps: zur zeit läuft der hackathon in calgary und henning hat auch ein wenig an pf rumgeschraubt, was zu starken performancesprüngen geführt hat (quelle: http://undeadly.org)
 
IPTables ist ja auch nur die Bibliotheksfunktionen 1:1 in Command Line Parameter migriert. ;)

Ansonsten hatte der Author des iX Artikels als Vorteil von IPTables noch aufgefuehrt, dass man dort FORWARD Regeln definieren kann, um Pakete zu matchen, die nur durch die Maschine geroutet werden. Allerdings sehe ich da keinen wirklichen Vorteil, da die Konfiguration dadurch aus meiner Sicht nicht einfacher wird.
 
Zum genannten Artikel habe ich noch eine Frage:

Ich beschäftige mich im Moment mal wieder mit der Konfiguration meiner m0n0wall, die bis dato gute Dienste leistet (dort wird ipf eingesetzt, wenn ich mich nicht irre). Mit den BSD-Paketfiltern habe ich mich noch nicht so intensiv auseinandergesetzt wie früher(tm) mit netfilter...

Im Artikel ist ein Bildchen abgedruckt, in dem gezeigt wird, wie unter BSD ein durchs System geschleustes Paket auf beiden Interfaces (IN, OUT) gefiltert wird. Eingangsseitig ist mir das noch klar, ausgangsseitig soll das Paket über OUT ins Interface reinkommen und über IN wieder verlassen... so etwa:
Code: 
eingehend                                      ausgehend

    +-----------+       Routing-       +-----------+
    |Interface 1|     Entscheidung     |Interface 2|
--> |IN      OUT| --> oder lokaler --> |OUT      IN| -->
    +-----------+       Prozess        +-----------+

Ist das tatsächlich so? Kommen die Daten rechts über "Ausgang" aufs Interface rein?

Ich frage deshalb, weil einige Regeln Probleme verursachen (manche greifen, andere blocken ohne zu dürfen... :rolleyes:)

Die m0n0wall-Doku ist, was das Thema betrifft, recht lückenhaft.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben