netfilter (war: Re: [Debian] ntpd frisst den gesamten Speicher)
Waldemar Brodkorb <waldemar.brodkorb@web.de> writes:
> > Stateful Filter sind erstmal reine Spielerei und haben neben ein paar
> > Vorteilen in Spezialbereichen erstmal auch eine paar Nachteile
> > (fehleranfälliger in der Implementierung, Anfällig gegen DoS-Angriffe).
>
> reine Spielerei? nur Vorteile in Spezialbereichen? Und auch noch
> Nachteile?
> Kannst du deine Ausführungen in irgendwelcher Form belegen?
Nun, die Grundregel für eine Firewall lautet: So simpel wie möglich. Für den
Hausgebrauch reichen bei stateless Filtern normalerweise eine handvoll
Regeln. Damit ist das Regelsystem recht einfach und übersichtlich. Die
Implementation des stateless Filters ist ebenfalls relativ einfach und damit
wenig fehleranfällig.
Ein stateful Filter soll helfen sehr komplizierte Regelsysteme zu
vereinfachen. Damit wäre das Aufstellen der Regeln für Benutzer/Admins
leichter. Im Gegenzug wird aber die Implementation komplizierter und damit
fehleranfälliger, man verlagert also bei komplexen Regelsystemen die
Fehleranfälligkeit von den benutzerdefinierten Regeln in den Filterkern und
bei entsprechend komplexen Regelsystemen macht das auch Sinn, nicht aber bei
relativ einfachen Regelsystemen.
Bei relativ einfachen Regelsystemen kann man diese nicht nennenswert durch
stateful Filterregeln vereinfachen (von max. 40-60 Regeln reduziert auf
vielleicht max. 5-20 Regeln zähle ich hier als keine nennenswerte
Vereinfachung). Man hat aber dennoch den Nachteil der komplizierten,
fehleranfälligen Implementation, so dass insgesamt, bei eh schon einfachen
Regelsystemen, das Gesamtsystem aus Filtersoftware und Regeln komplizierter
und fehleranfälliger ist und damit eben unsicherer (als für Firewalls sehr
kontraproduktiv).
Dann sind da noch ein paar Spezialfälle, die man mit stateful Filtern besser
in den Griff bekommt oder mit stateless Filtern praktisch gar nicht abdecken
kann. Dazu gehören Probleme wie aktives FTP, auf das man für den Hausgebrauch
aber gut verzichten kann (FTP-Server-Betreiber haben da schon viel eher
Verwendung für stateful Filter). Es gibt weitere Beispiele dieser Art, die
aber i.d.R. noch exotischer sind als das FTP-Beispiel (z.B. dieses Netshow
oder so ähnlich von MS -- klar, mit stateful Filtern kann man das einigermaßen
ordentlich durchlassen, sofern der Filter das Protokoll unterstützt, aber wer
das einsetzt, benötigt eigentlich keine Paketfilter mehr, der ist darüber so
angreifbar, dass der Filter völlig uninteressant ist; ähnliches gilt
allgemein, denn was bringt mir der tolle Paketfilter, der nur HTTP durchlässt,
wenn ich im Browser alles von Cookies über Java bis ActiveX aktiviere --
richtig, nämlich exakt gar nichts, die Mühe kann ich mir dann sparen).
Als Grundregel gilt übrigens: Wo keine Dienste lauschen, brauche ich auch
keinen Paketfilter.
Ach ja, noch ein Nachteil der stateful Filter: Sie müssen sich die Zustände
der aktiven Verbindungen merken. Ein Angreifer kann jetzt künstlich sehr viele
Verbindungen erzeugen und so die Zustandstabellen des Filters zum Überlaufen
bringen. Damit kann der Filter keine neuen Verbindungen verwalten und lehnt
diese daher ab -> DoS-Angriff. Allerdings ist dies für den Hausgebrauch kein
so ganz großes Problem, da man z.B. über eine ISDN-Verbindung die Tabellen des
Filters nicht ganz so leicht zum Überlaufen bringt (bei DSL sieht das schon
wieder etwas anders aus).
Und was will man als normaler Nutzer, der nicht gerade Serverfarmen betreibt,
schon schützen resp. filtern? UDP-Verkehr bis auf DNS komplett (geht mit
beiden Filterarten gleich schwer oder leicht), Zugriff auf priv. Ports
(0-1023, evtl. außer DNS) von außen blocken (geht bei beiden Filtertypen
gleich leicht) und eingehende Verbindungsanfragen auf die unpriv. Ports
sperren (geht wieder bei beiden Arten etwa gleich leicht). Man spart also bei
diesem Szenario vielleicht 2-5 Regeln bei Verwendung eines stateful Filters,
erkauft sich diese Ersparnis aber mit einer sehr viel komplexeren und damit
fehleranfälligeren Basissoftware.
Deshalb sagte ich, dass stateful Filter nicht nur Vorteile haben.
--
Until the next mail...,
Stefan.
--
-----------------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie bitte eine
E-Mail an debian-user-de-request@lehmanns.de die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@Lehmanns.de
-----------------------------------------------------------
795 eingetragene Mitglieder in dieser Liste.
Reply to: