<b11bmr$u5dda$1@ID-152804.news.dfncis.de> zu
finden ist und die Antworten darauf.
> > Zähle doch mal auf was aus deiner Sicht für eine PFW spricht, wir
> > können das ja dann ausdiskutieren.
>
> http://www.pflock.de/computer/za_faq.htm#36
ZoneAlarm ist auch noch ein sehr schlechtes Beispiel für eine PFW, aber egal.
| Gehen wir von einem unkompromittierten Zonealarm auf nicht
| kompromittiertem Betriebsystem aus und schauen, was es dann
| kann:
Tolle Prämissen, siehe die von Felix von Leitner in seinen beiden
Papers beschriebenen Argumente. ZA hat sogar noch den Status
von Spyware, da es öfter mal 'nach Hause telefoniert' (siehe den "Bug in einer neueren Version, die sofort beim Start eine Internet-
Verbindung aufbauen wollte)
| Es kann zunächst mal sämtliche Internetverbindung blockieren.
Falsch. Es kann maximal alle Internetverbindungen, die über den
normalen TCP/IP-Stack des Betriebssystems gehen blockieren. Wenn ein
Schadprogramm seinen eigenen mitbringt (oder gar eigene Treiber) ist
eine PFW nutzlos. Zudem existieren immer wieder Bugs in den
Implementierungen der gängigen PFWs, wie z.B. in
http://cert.uni-stuttgart.de/ticker/article.php?mid=1071
beschrieben.
| Es kann Programmen nach Name, Dateigröße, Erstellungsdatum
| und Pfad dauerhaft Netzzugang erlauben. Zudem wird eine
| Prüfsumme des Programmes verglichen, um bei dessen Änderung
| den Anwender zu warnen und nur nach erneuter Rückfrage das
| Programm Verbindung in's Netz aufbauen lassen.
Jedes Programm (das unter den selben User-Rechten) läuft hat
(Schreib-)Zugriff auf die entsprechenden Registry-Schlüssel oder Files
und kann diese ersetzen (ohne dass Rückfragen kommen). Diese
Rückfragen lassen sich simpelst durch einen einzigen WIN-API Aufruf
wegblenden (ohne die selben User-Rechte wie die PFW zu haben) ohne dass der
Anwender auch nur ein Flackern sehen würde (Ein Beispiel hierfür
findet sich unter http://my-forum.netfirms.com/zone/zcode.htm)
| Es erkennt Programme, wenn sie eine Netzverbindung aufbauen
| wollen, erkennt den Name, mit dem sich dieses Programm
| meldet und bildet eine Prüfsumme von dem Programm, um
| Täuschunsversuche zu erkennen.
Hier tritt auch wieder das im vorhergehenden Punkt beschriebene
Problem auf. Hinzu kommt das (auch von richtigen Firewalls schwer
vermeidbare) Problem des Tunnelns (oder würdest du deinem Web-Browser
den Netz-Zugang verwehren?)
Außerdem läßt sich eine PFW problemlos mittels eines kurzen Win-API
Aufrufs beenden, das hat sogar noch den Nebeneffekt, dass das Tray-Bar
Symbol noch solange angezeigt wird, bis man mit der Maus drüber
fährt. Ein Beispiel hierfür findet sich unter
http://www.stud.tu-ilmenau.de/~traenk/zaweg.htm
sowie eine ausführlichere Erklärung wie PFWs umgangen werden unter
http://home.arcor.de/nhb/pf-umgehen.html.
Ernstzunehmende Würmer/Viren (wie z.B. Bugbear zeigte, siehe z.B.
http://www.percomp.de/cgi-bin/info.cgi?char=B&virus=TANATOS)
beenden auf diesem Weg einfach entsprechende Schutz-Programme (im
übrigen auch residente Virescanner) bevor sie ihre Netzwerk-
funktionalität aktivieren.
| Ërlaubtman so einem Programm die Verbindung, so öffnet
| Zonealarm alle nötigen Ports, jedoch nur zu diesem Programm.
| Ist dieses Programm mit einer Schadfunktion versehen, findet
| diese Schadfunktion ebenfalls eine Verbindung!
Auch hier muß man natürlich wieder sagen, dass man erst den Anwendungen
(zumindest auf dem Firewall-Host) vertrauen können muß, ehe man einem
Firewall-Konzept annähernd trauen kann.
| Schwächen oder auftretende Angriffspunkte können über gezielte
| Abwehrmechanismen mit Updates kompensiert werden.
Das ist schon bald Marketing Gefasel. Erstmal müssen die Fehler gefunden
werden. Hinzu kommt, dass durch die vergrößerte Codebasis neue
Angriffspunkte und Instabilitäten erst entstehen. So hatte z.B.
Norton Internet Security einen (exploitbaren) Buffer-Overflow (siehe
http://cert.uni-stuttgart.de/ticker/article.php?mid=888)...
und konnte in einem anderen Fall zumindest auch mittels eines
entsprechend aufgebauten Datenpakets zum Absturz gebracht werden (siehe
http://www.securityfocus.com/archive/1/306774)
Bernd Eckenfels hat in einem offenen Brief an Steve Gibson von Gibson
Research Corp. sehr detailiert beschrieben warum PFWs auch durch ständig
neue Updates nicht sicherer werden. Der Text des Briefes findet sich unter:
http://sites.inka.de/sites/lina/freefire-l/grc-letter.html
| "Nuken" (zufälliges oder wenn deine IP bekannt ist auch gezieltes
| abstürzen lassen eines Windows-PC) geht nicht, solange Zonealarm
| an ist.
Mit den entsprechenden aktuellen Patches des Betriebssystems bzw. einer
korrekten Konfiguration der laufenden Dienste geht das auch ohne eine PFW
nicht.
| Die sogenannte "Druckerfreigabe/Laufwerksfreigabe" die eigentlich
| nur lokal funktionieren sollte funktioniert wirklich nur noch lokal.
Mit entsprechender Konfiguration (wie es z.B. im Linkblock erklärt
wird) kann auch hier das entsprechende Verhalten ohne eine Personal
Firewall nur mit Bordmitteln erreicht werden.
| Dieses Problem lässt sich auch durch entsprechende Konfiguration
| der Bindungen in den Netzwerkeinstellungen ohne Zonealarm vermeiden.
Genau!
| DOS-Attacken benötigen eher mehr Aufwand, da Zonealarm Anfragen an
| nicht verwendete Ports ohne weitere Überprüfung sofort verwirft. Das
| bedeutet, dass die Anfragen an deinen Rechner weniger Last
| verursachen.
Falsch. Anfragen an nicht geöffnete Ports werden sofort vom IP-Stack
verworfen mit einem passenden Paket als ``Fehlermeldung'' (TCP-RST oder
ICMP-Destination-Unreachable) beantwortet (wie's in den entsprechenden
Standards steht) und erzeugt genau keine Last. Eine PFW droppt diese Pakete,
sendet also keinerlei "Fehlermeldungän die Gegenstelle (die dann in
einen Time-Out läuft und es evtl. noch mehrmals probiert eine Verbindung
aufzubauen), was nicht RFC konform ist. Zusätzlich zeigt die PFW
dann noch die hinlänglich bekannten Meldungen über abgewehrte ``Angriffe'' an
und schreibt noch entsprechende Protokolleinträge. In der Summe dürfte eine
PFW wesentlich mehr Leistung fressen als das standardkonforme
Verhalten des IP-Stacks.
DoS wird sogar einfacher, da man beispielsweise gespoofte (Datenpakete
mit gefälschtem Absender) Pakete an einen Rechner mit PFW schicken kann,
dieser dann evtl. die entsprechende IP-Adresse sperrt und somit
unzugänglich macht.
| Eventuell kompensieren die Logfileeinträge diesen Effekt
| teilweise. Die "durchgelassenen" Pakete verursachen dafür etwas mehr
| Last.
Die Logfiles von einer PFW sind meist extrem größenbeschränkt und so
unbrauchbar in ihrer Aussage, dass man sie grade vergessen kann. Die
von einer PFW verursachte Last (schlimmer sind da nur noch residente
Virenscanner) ist nicht unerheblich, genauso wie der Speicherverbrauch.
> Aber genau das ist der Punkt. Das ganze mit Bordmitteln zu
> konfigurieren, überfordert die meisten Benutzer. Mit der Installation
> einer PF kommen sie in den meisten Punkten zurecht.
Eine PFW richtig einzurichten wird sie dann noch mehr überfordern, da
sie dazu wesentlich mehr Detailwissen brauchen. Und in den Standard-
konfigurationen kann man eine PFW grad' vergessen. Norton Internet
Security bringt z.B. einen Wust von Standardregeln mit, die sogar
bekannte Adware Programme bewußt freischalten, um Klagen durch deren
Hersteller zu verhindern.
Da dürfte es doch wesentlich einfacher sein den step-by-step
Anleitungen mit ausführlichen Erklärungen warum was gemacht wird, die
als Alternative dazu existieren und oft erwähnt werden, zu folgen.
Diese regen dann zusätzlich dazu an sich mit den anderen verlinkten
Seiten zu beschäftigen.
Wenn man unvoreingenommen rangeht wird man dann sehr schnell einsehen,
dass eine PFW zum größten Teil nur ein teilweise sehr teures Plazebo ist.
> Um es nochmals klarzustellen: es geht nicht darum, den Einsatz von PFs
> zu befürworten, sondern schlichtweg um eine ausgewogenere Darstellung
> der Vor- und Nachteile. Und in dieser Linksammlung konnte ich wirklich
> nicht einen positiven Aspekt von PFs entdecken.
Da diese mit dem Raster-Tunnel-Mikroskop zu suchen sind. Gegen einige
der Argumente gegen eine PFW kann man zwar anführen, dass unter Windows
NT/2K/XP ACLs unterstützt werden und die PFW als Prozess mit
System-Rechten laufen kann und so gegen einen Teil der lokalen Angriffe
resistent ist. Dies trifft aber nur einen Teil der Wahrheit:
Man konnte dies in Studien nach der Einführung des ABS in
Autos (die
Zahl der Unfälle mit ABS-Autos war höher, als bei Autos
ohne das
System, da die Fahrer der mit ABS ausgestatteten Autos zu
höheren
Geschwindigkeiten und späterem Bremsen neigten) und der
Nutzung von
Fahrradhelmen (Radfahrer mit Helm stürzen häufiger als
Fahrer ohne
Helm, da auch hier ein riskanterer Fahrstil zu beobachten war)
empirisch
nachweisen. Es hat sich gezeigt, dass dieser Effekt besonders
stark
auftritt, wenn der Mensch die Beseitigung des Risikos direkt vor
Augen
geführt bekommt, sei es durch eigene Erfahrungen oder durch
plakative
Werbung.
Beide Einflussfaktoren bieten die verbreiteten Personal
Firewall
Produkte, zum einen durch die Werbung und die ``Fachpresse'',
zum
anderen durch die ständigen ``Erfolgsmeldungen'' (in Form
von
Mitteilungen über Abgewehrte ``Angriffe'') während der
Nutzung. Das
Fatale ist aber, dass die vermeintliche deutliche Minderung
der
Risikos nicht eingetreten ist. Das Verhalten des Nutzers wird
also
unvorsichtiger, obwohl sich am realen Gefährdungspotential
nichts
geändert hat, weshalb das Gesamtrisiko sehr viel höher
ist, als ohne
eine Personal Firewall.
Zusammenfassend kann man sagen, dass es zwar Bereiche gibt, in denen
eine PFW brauchbare Funktionalität anbieten kann, diese ist jedoch ebenso
mit Bordmitteln (Dienste abschalten, Tools wie netstat, tdimon, Sniffern
usw.) schneller, einfacher und vor allem kostengünstiger erreichbar.
Wenn man wirklich im Rahmen eines Firewallkonzeptes einen Paketfilter
braucht, dann sollte man unter Windows NT/2000/XP die IPSec-Policies nutzen,
da diese schon im OS enthalten sind und einigermaßen sicher zu sein scheinen.
Weiterführende Informationen zum Thema:
This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)
Copyright © 1993, 1994, 1995, 1996, Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics
Department, Macquarie University, Sydney.
The command line arguments were:
latex2html pfargumente.tex -split 0
-nonavigation
The translation was initiated by Ralf Schroth on
2005-07-28