Warum Personal Firewalls prinzipiell versagen

Konfiguration

Auf einem typischen Desktop System will der Benutzer mindestens im Internet surfen und E-Mails lesen. Dazu kommt, dass manchmal Dateien mit Freunden z.B. über FTP ausgetauscht werden sollen. Das bedeutet, dass die Personal Firewall dahingehend konfigurierbar sein muss, welcher Netzwerkverkehr stattfinden darf, und welcher nicht. Damit ist der Anwender allerdings in der Verlegenheit, sich über die Sicherheit seines Systems Gedanken machen zu müssen. Das eigentliche Ziel, dem Anwender diese Aufgabe abzunehmen, ist also von vorneherein nur teilweise zu erreichen.

Die Konfiguration vieler Personal Firewalls funktioniert so, dass vorerst das meiste verboten ist. Dann wird jeder einzelne verteitelte "Angriffsversuch" dem Benutzer gemeldet, der entscheiden muss, ob es sich hierbei wirklich um einen Angriff handelt, oder ob die Kommunikation jetzt zugelassen werden soll oder gar muss. Außerdem muss er entscheiden, ob der Verkehr nur dieses mal oder generell erlaubt werden soll.

Mit dieser Entscheidung ist der Benutzer oft überfordert. Das kann man z.B. in der Usenetgruppe de.comp.security.firewall sehen, in der viele Benutzer mit Problemen ihrer Personal Firewall aufschlagen, die oft auf mangelndes technisches Verständnis zurück zu führen sind. So trifft man z.B. immer wieder auf den Fall, dass sich ein Benutzer fragt, wie er auf den Angriff von der Adresse 127.0.0.1 reagieren soll. Dass es sich dabei auf keinen Fall um einen Angriff aus dem Internet handeln kann, weil die Adresse zu seinem lokalen Rechner gehört, weiß er leider nicht. Er muss es aber auch eigentlich nicht wissen. So wie ein Autofahrer nicht wissen muss, wie ein Auto technisch funktioniert um es zu fahren. muss ein Benutzer nicht wissen, wie der Computer technisch funktioniert, um ihn zu verwenden.

Da der Benutzer aber Technikverständnis besitzen muss, um seine Personal Firewall zu konfigurieren, führt das dazu, dass viele Konfigurationen in der Praxis unsicher sind. Man kann als Angreifer schon fast darauf vertrauen, dass der Benutzer den Verkehr zulassen wird, wenn man ihm nur glaubhaft macht, dass das jetzt wichtig ist. Allein schon deshalb geht das Konzept einer Personal Firewall nicht auf.

Sicherheit, die sich auf Personen verlässt, die nicht das nötige technische Wissen haben, kann nicht funktionieren.

Benutzersimulation

Es gibt für Windowsprogramme keine zuverlässige Möglichkeit festzustellen, ob Eingaben von der Tastatur oder von der Maus tatsächlich vom Benutzer gemacht wurden, oder ob hier ein anderes Program diese Benutzerinteraktivität nur vorgibt. Das bedeutet, dass ein Program immer genau das tun kann, was auch der Benutzer tun kann. Alexander Bernauer hat in einem Artikel für die Datenschleuder ein paar Hintergründe zum Nachrichtendienst für Windows (copton.net).

Diese Tatsache eröffnet einem Angreifer viele Möglichkeiten. So hat Jonathan Häberle z.B. einen Autoklicker geschrieben, der die Konfigurationsfenster der Personal Firewall einfach mit einer Bestätigung weg klickt. Ein anderes Beispiel ist die www Shell, welche als trojanisches Pferd auf den Rechner des Opfers gelangt und dort mit Hilfe von vergetäuschter Bentuzerinteraktivität den installierten Browser dazu verwendet, Informationen mit dem Internet auszutauschen.

Um diese Angriffe zu verhindern muss man tief ins Windows System eingreifen. Manche aktuelle Personal Firewalls tun das und überfordern damit den Bentuzer noch mehr, in dem er jetzt auch noch entscheiden muss, welches Program mit welchem Program Nachrichten austauschen darf. Und dabei haben die meisten Windows Nachrichten nichts mit Kommunikation mit dem Internet zu tun. So war es bisher mit jedem neuen Schritt im Wettrüsten.

Wettrüsten

Ganz am Anfang gab es einfache Packetfilter, die Verkehr an Hand von Adressen und Ports zuließen oder unterbunden haben. Bald merkte man, dass das nicht genügt, weil ein Angreifer einfach die erlaubten Ports verwenden kann. Also führte man die Filterung an Hand der Applikationen ein. Der Benutzer musste nun festlegen, welche Applikationen ins Internet verbinden dürfen, und welche nicht. Doch auch das war nicht genug, weil ein Angreifer einfach eines der zugelassenen Applikationen als Wirt verwenden kann. Als Reaktion darauf wurde also das Starten eines neuen Programs abgefangen um den Benutzer zu fragen, ob das zugelassen werden soll. Dieser war nun zusätzlich mit der Aufgabe konfrontiert, entscheiden zu müssen, welches Program welches andere starten darf. Dabei hat das Starten eines Programmes meistens überhaupt nichts mit Netzwerkkomunikation zu tun. Das Chaosseminar über Personal Firewalls zeigte dann, dass das auch nicht genügt. Ein Angreifer muss das Wirtsprogram nicht starten, um es fernsteuern zu können. Man kann einfach das Nachrichtensystem von Windows verwenden, um Benutzerinteraktion zu simulieren. Die vorhersehbare Reaktion war, dass manche neue Versionen von Personal Firewalls jetzt Windowsnachrichten abfangen. Da, wie schon im Fall von Netzwerkverkehr, manche Nachrichten zugelassen werden müssen und die Personal Firewall nicht automatisiert entscheiden kann, welche das sind, wird wieder der Benutzer gefragt. Und wieder haben Fensternachrichten eigentlich nichts mit Netzwerkkommunikation zu tun. Und einmal mehr wird der Benutzer mit der Komplexität des Systems belastet. Dabei wollte man ihm das eigentlich abnehmen.

Die jüngste Entwicklung scheint die Implementierung von Rootkit-Techniken (beispielsweise Kernel-Hooks) in Personal Firewalls zu sein. Dahinter steckt anscheinend der Versuch, das System vor seinem Administrator zu schützen. Anstatt den Anwender zum Arbeiten mit einem normalen Benutzerkonto zu bewegen, will man ihn hier schützen, indem man dem Systemverwalter die Kontrolle über sein System entzieht. Mark Russinovich hat dazu mal sehr treffend gesagt:

"If a software developer ever believes a rootkit is a necessary part of their architecture they should go back and re-architect their solution." Quelle

Das Wettrüsten wird weiter gehen. Mit jeder neuen Runde steigt die Komplexität der Personal Firewalls und damit der Bedarf an technischem Hintergrundwissen des Benutzers. Erst wenn am Ende ein nicht benutzbares System dabei herauskommt, wird man vielleicht einmal umdenken und die von uns schon lange gezeigten Alternativen wieder entdecken.


zurück zur Startseite