Re: Welche Firewall bzw. Paketfilter verwenden

Bernd Schwendele wrote:
> Ja an _keine_ FW hab ich auch schon gedacht. Nunja an Diensten läuft
> eigentlich nur ein SSH-Server. Die anderen Dienste, außer X11 und
> ntp-client, muss ich noch ausschalten, z.B. sendmail, syslogd usw.
> Nur dachte ich, ich könnte mal noch was dazu lernen und eine einfache FW
> aufsetzen, es sei denn es stellt sich als Nachteil heraus.
> Im übrigen hab ich auf meinem FreeBSD Webserver auch keine FW. DMZ und
> Jail müssen reichen
> Allerdings lassen sich DOS-Attaken ohne FW afaik nicht ganz abfangen.

Michaelas Kommentar ist nicht völlig von der Hand zu
weisen. Man sollte tatsächlich keine unnötigen Dienste
laufen haben, insbesondere keine fragwürdigen, und wenn
(wenn!) man seinen Usern vertrauen kann, dass die keine
Services starten und sich auch sonst sicherheitsbewusst
verhalten, ist der Nutzen eines Paketfilters zweitrangig.

Allerdings gibt es (leider) Dienste, die man zuweilen
lokal benötigt und die keine Option dafür haben, sich
nur auf ein bestimmtes Interface zu binden. Typisches
Beispiel wäre der mountd(8). Auch der ntpd(8) bindet
sich auf alle Interfaces, die er findet, ob man will
oder nicht. Es gibt sicherlich noch mehr Beispiele.
Die Ausgabe von "sockstat" ist da immer recht aufschluss-
reich.

Um solche Daemonen nach außen abzuschotten, braucht man
einen Paketfilter. In manchen Fällen gibt es Alterna-
tiven, z.B. den Daemon in einem Jail laufen zu lassen
und ihn somit auf eine bestimmte IP-Adresse zu zwingen,
aber auch das geht nicht in jedem Fall.

Ein weiteres Argument, das man häufig hört, lautet, dass
man einem Angreifer möglichst viele Steine in den Weg
legen sollte. Je mehr Schlösser an der Tür, desto besser.
Folgt man dieser Argumentation, sollte man _mindestens_
einen Paketfilter verwenden (besser mehrere zugleich),
und zusätzlich noch tcpwrapper per /etc/hosts.allow, und
was es sonst noch so an Mechanismen gibt.

Um auf die eigentliche Frage zurückzukommen: Das Schwie-
rige an einem Paketfilter ist nicht, die Syntax zu lernen
oder wie eine Konfigurationsdatei geschrieben wird. Das
Schwierige daran ist, zu verstehen, wie TCP/IP funktio-
niert -- und _das_ ist völlig unabhängig vom verwendeten
Paketfilter. Nur um ein paar Beispiele zu nennen: Man
sollte wissen, welche Arten von ICMP-Paketen für welche
Zwecke benötigt werden, und welche man besser nicht sperren
sollte. Und was die einzelnen TCP-Flags bedeuten. Und
die Vor- und Nachteile von Stateful-Filtering kennen.
Und in welchen Fällen man IP-Fragmente sperren kann und
in welchen besser nicht. Welche Pakete man erlauben muss,
damit DNS funktioniert (was nicht unbedingt so trivial
ist, wie viele glauben). Und welche Pakete man für trace-
route erlauben muss. Und und und ... Ein Schnitzer in
der Paketfilter-Konfiguration kann das System unsicherer
machen anstatt sicherer.

Dabei ist es vollkommen wurscht, ob Du IPFW, IPF oder PF
verwendest. Meine Empfehlung wäre, sich ein gutes Buch
über TCP/IP zu kaufen und sich zu Gemüte zu führen. Oder
lass Dir den Paketfilter von jemanden einrichten, der
sich mit sowas auskennt und dem Du vertraust. :-)

Aber um nun wirklich noch auf die ursprüngliche Frage ein-
zugehen: PF ist von der Konfiguration her stark an IPF
angelehnt, hat aber mehr Features und macht insgesamt
einen moderneren Eindruck. IPF existiert meiner Meinung
nach nur aus historischen Gründen, sowie für die Fälle,
wo man in heterogenen Umgebungen (z.B. mit Solaris) einen
einheitlichen Paketfilter haben möchte.

Daher fallen bei Dir eigentlich nur IPFW und PF in die
engere Wahl. Mir persönlich gefällt die Syntax von IPFW
besser, da sie expressiver ist, aber das ist wirklich
Geschmackssache und/oder Gewöhnungssache. Es gibt sicher-
lich ebensoviele Leute, die Dir eher zu PF reaten würden.
Du könntest einfach eine Münze werfen. ;-)
Auch vom Umfang und Lesbarkeit der Dokumentation unter-
scheiden sich beide nicht substantiell.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783
Any opinions expressed in this message are personal to the author and may
not necessarily reflect the opinions of secnetix GmbH & Co KG in any way.
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"Python tricks" is a tough one, cuz the language is so clean. E.g.,
C makes an art of confusing pointers with arrays and strings, which
leads to lotsa neat pointer tricks; APL mistakes everything for an
array, leading to neat one-liners; and Perl confuses everything
period, making each line a joyous adventure <wink>.
        -- Tim Peters
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message