ZitierenDie Filterregeln
Zuvor möchte ich darauf hinweisen, daß die Programmentwickler von Jetico die neue Version multilingual anbieten möchten. Wie die verschiedenen engl. Begriffe letztlich übersetzt werden, weiß ich nicht. Deswegen kann es (in der neuen Vers.) zu Unterschieden in der Bezeichnung kommen.
Jetico bietet uns geneigten Surfern die beste Möglichkeit, einen Einblick in die Arbeitsweise einer FW zu bekommen, allerdings mit einem Unterschied zu allen anderen FWs:
Jetico sortiert die erstellten Regeln in Listen/Gruppen (Tables) und weist diese einer bestimmten Eigenschaft eines Prozeßes zu.
Wie ihr sicher schon alle bemerkt habt, führt Jetico nach der Installation ein Popup aus, wenn ein Programm, Prozeß oder Dienst Zugriff auf das Netz haben möchte:
Der Grund liegt vor allem in der Optimal Protection, die erreicht werden soll.
Oben erfuhren wir, daß dies unsere Hauptschaltzentrale und gleichzeitig unser Ziel (bester Schutz) ist.
Um die Arbeitsweise der FWs besser zu verstehen, möchte ich euch ein kleines Bsp. geben:
Stellt euch vor, es klingelt an der Haustüre.
Unser Butler schaut durch den Türspion und sieht Alice von nebenan. Sie will auf eine Tasse Kaffee bei uns vorbeischauen und bringt neben lecker Süßem, einen Vierbeiner mit, den wir nicht mögen. Aber Alice mit lecker Süßem soll natürlich unbedingt herein.
Der Butler weiß nicht, was er tun soll, also fragt er uns danach. Und damit er auch behalten kann, wer rein darf und wer nicht, schreiben wir kurzerhand eine Regel auf. Die soll er dann immer verwenden, wenn’s klingelt.
Jetzt könnte natürlich in der Regel stehen:
Aufmachen, wenn Alice vor der Türe steht und sie hineinlassen, ebenso Süßes, aber Vierbeiner bleiben draußen.
Kurze Ansage, paßt.
Leider nicht ganz, denn Alice kann jede Nachbarin heißen, Süßes kann Kuchen sein oder nicht und Vierbeiner können auch Katzen sein.
Also braucht der Butler mehr Details. Und die bekommt er in Form von Eigenschaften mitgeteilt. Und so könnte dann die 1. Regel lauten:
Reinlassen (Inbound):
Wenn es klingelt, dann
- fragen
- Alice, wenn sie von nebenan ist, akzeptieren,
- Süßes, wenn es Kuchen ist, akzeptieren
- den Vierbeiner, wenn es ein Hund ist, blockieren
Das wäre nun die Regelentscheidung (Verdict (Urteil)) für 4 Ereignisse, die der Butler immer befolgen soll. Anhand der verschiedenen Eigenschaften kann er eindeutig entsprechend der regelentscheidung handeln..
Der Nachmittag ist vorbei, mit Alice haben wir nett geplauscht und die letzten Urlaubsbilder durchstöbert. Jetzt will Alice gehen. Aber:
der lecker Kuchen soll unbedingt da bleiben!
Der Butler weiß davon nichts, also müssen wir ihm das mitteilen:
Rauslassen (Outbound):
Wenn Alice gehen will, dann
- fragen, dann
- Alice akzeptieren und rauslassen
- aber den lecker Kuchen blockieren
Das sind nochmals 3 Regeln, weil es in die andere Richtung geht.
Mit den Inbound - Regeln von oben sind das 7 Regeln für 7 Ereignisse.
Ereignis -> beim 1. Mal: nachfragen -> Eigenschaften (Parameter) vergleichen -> bei Übereinstimmung -> Regel ausführen
Zusammenfassend steht dann auf dem Zettel für den Butler:
Wenn es klingelt und Alice von nebenan steht vor der Tür, dann darf Alice rein und raus, der lecker Kuchen darf zwar rein aber nicht mehr raus und der Vierbeiner darf überhaupt nicht rein, weil er ein Hund ist.
Wie ihr seht, haben wir die Regel (oder das Urteil) für den Butler über die Eigenschaften von Alice, dem Kuchen und dem Hund festgelegt:
Alice darf alles, weil sie nebenan wohnt, das Süße muß dableiben, weil es Kuchen ist und der Vierbeiner bleibt draußen, weil es Hund ist.
Der Butler vergleicht unsere Bedingungen für Alice, Süßem und Vierbeiner mit den Eigenschaften der Personen/Objekte, die draußen vor der Türe stehen. Und wenn die Bedingungen für die Eigenschaften zutreffen, handelt der Butler entsprechend unseren Wünschen, nämlich die Person oder das Objekt durchlassen oder nicht.
So, zumindest grundsätzlich, funktioniert eine FW.
Regeln bestehen immer aus 2 Teilen: die Bedingung und die Handlung
Wenn A zutrifft ist, muß B ausgeführt werden.
Bedingung (Condition) sind die Eigenschaften, die ein Ereignis identifizieren und die Handlung (Action) ist die Folge, die aus dieser Bedingung resultiert.
Die Befehle für die Handlung sind in Jetico:
- ask - nachfragen
- accept - durchlassen
- reject - blockieren/ablehnen
- go to table - eine andere, schon vorhandene Regel aufrufen und nach dieser handeln
- continue - das Ereignis wird zur nächsten, folgenden Regel weitergeleitet
Wir klicken jetzt auf den Reiter Configuration (übrigens, wir sind wieder bei der Firewall, nicht bei Alice), dann sehen wir zunächst oben in der Menüleiste und auf der linken Browserseite die 3 Hauptrichtlinien: Optimal Protection, Allow all und Block all.
Das sind die verschieden Modi, in die die Firewall generell versetzt werden kann. Ändern wir den Modus, muß die Änderung gesondert bestätigt werden (Apply Button).
In Jetico wird der aktive Modus als Active Security Policy angezeigt.
Default bei Jetico ist der Lernmodus, die Optimal Protection und alle Ports sind geschlossen, d.h., alle Ereignisse, die Netzwerkzugriff haben möchten, müssen “nachfragen“. Alle?
Nicht ganz, einige Systemkomponenten haben immer Zugang zum Netzwerk, denn ohne diese wäre eine Kommunikation nicht möglich und jede FW überflüssig. Jetico erlaubt diesen Prozessen und Diensten den Zugang, außer wir sind im Block All - Modus.
Welche Prozesse das im Einzelnen sind, ist hier erstmal sekundär und würde sicher den Rahmen des Tuts sprengen.
Wir wollen uns aber hauptsächlich mit dem bestmöglichen Schutz beschäftigen, also Doppel – Klick auf Optimal Protection:
- - Application Table - Liste der Programme
- Process Attack Table - Liste der verdächtigen Prozesse
- Protocols Table - Liste der benutzten Internetprotokolle
- System IP Table - Liste der systembedingten Prozesse
(Zu Process Attack Table, Protocols Table und System IP Table und den unteren Listen, FTP- und Mail - Client/Server, komme ich im 3. Teil)
Die Inhalte der Tables (Gruppen oder Listen), sind die Regeln der Zugriffe (von Programmen, Protokollen, Diensten, etc.) und können individuell abgerufen und bearbeitet werden. In den Tables werden die Regeln für alle netzwerkzugreifende Prozeße abgelegt und verwaltet, die wir manuell und für jeden Prozeß individuell und eindeutig erstellt haben.
Über den Regelprozess (Ruleprocess) wird eindeutig die richtige Regel für das richtige Ereignis ermittelt.
Wie funktioniert der Regelprozeß eigentlich?
Jeder Netzwerkzugriff, egal von welchem Programm, Dienst oder Prozess, ob ankommend oder abgehend, kann als (Netzwerk-) Ereignis beschrieben werden.
Die von uns gesetzten Regel im Popupfenster bezieht sich auf die Eigenschaften des Prozesses, der dieses Ereignis auslöst und auf die Eigenschaften des Ereignisses selbst. Die Eigenschaften wiederum werden beim Regelprozeß mit den Eigenschaften des aktuellen Netzwerkpakets so lange verglichen, bis diese Eigenschaften übereinstimmen..
Der Regelprozess, die Regelsuche, beginnt bei Root, das haben wir bereits gelernt.
Hier stehen die generellen Regeln des jeweiligen Modus, die dann für alle Zugriffe gelten (Any). Die Suche verläuft von oben nach unten.
Erst in den nächstfolgenden Tables werden die Zugriffe gefiltert. Die Eigenschaften des Ereignisses werden mit den Bedingungen der Regeln verglichen.
Hat ein Eintrag diese Parameter, hat die Regelsuche einen Treffer und ist beendet. Die mit der Bedingung verknüpfte Aktion wird durchgeführt.
Treffen die Bedingungen nicht zu, setzt Jetico seine Suche nun in der nächstfolgenden Gruppe fort, bis er eindeutig das Ereignis gefunden hat, daß alle Kriterien erfüllt.
Welche Parameter welchen Ereignissen zugeordnet werden, sind hier einmal aufgelistet:
Application Table (Programmliste) :
- - access to network - Zugriff auf das Netzwerk
- inbound connection (TCP) - ankommende Verbindung (TCP)
- outbound connection (TCP) - abgehende Verbindung (TCP)
- listening port (TCP) - Listen Port
- receive datagrams (UDP) - ankommende Daten
- send datagrams (UDP) - gesendete Daten
- listening datagrams (UDP) - Listen nach neuen Daten
Process Attack Table (Liste der verdächtigen Prozesse) :
- - attacker installs system-wide Windows hook – setzt einen systemweiten Hook*
- Attacker starts application with hidden window – startet eine Anwendung in einem versteckten Fenster
- Attacker writes to application's memory – schreibt in den Speicherplatz einer Anwendung
- Attacker injects own code into application – schreibt einen fremden Code in eine Anwendung
- Attacker modifies child process - modifiziert einen Kindprozess**
- Low-level access to system memory - Zugriff zum Systemspeicher***
* Hook = ein Programmcode, der dann ausgeführt wird, wenn best. Kriterien erfüllt sind
** Kindprozess = eine Art Unterprozess einer Anwendung
*** System memory = dort legt das BS alle zur Zeit laufenden Prozesse ab
Protocols Table (Protokoll Liste) und System IP Table (Liste der systembedingten Prozesse):
- - incoming packet - ankommender Datensatz (z.B. ein Ping)
- outgoing packet - abgehender Datensatz
Durch die Gliederung der unterschiedlichen Ereignisse anhand ihrer Eigenschaften, haben wir 3 Grundregeln, die Jetico eindeutig die Zuweisung der Aktion (blockieren oder akzeptieren) dem entsprechenden Prozeß ermöglichen:
- Programmregeln betreffen nur Programmereignisse
- Netzwerkregeln betreffen nur Netzwerkereignisse
- Regeln für verdächtige Prozeße betreffen nur verdächtige Prozeßereignisse
Uff, hoffentlich konnten bisher alle folgen, denn ab jetzt wird’s einfacher – denke ich.
Mit Firefox zeige ich euch das oben schnell Überflogene nocheinmal:
Firefox soll ins Netz und so ich wähle zuerst die generelle Art und Weise, wie es von der FW behandelt werden soll (Zugriff erlauben).
Zur Auswahl haben wir
- Allow this activity = erlaube den generellen Zugriff
- Block this activity = verbiete den generellen Zugriff
- Handle as = behandle das Ereignis wie
- Custom (reject) * = Benutzdefiniert
*(reject (ablehnen) ist die Default Einstellung, wenn noch nichts definiert wurde)
Die Regeln sind durch eindeutige Zeichen gekennzeichnet
: dieses Ereignis wird durchgelassen
: das Ereignis darf nicht ins Netzwerk
: das Ereignis darf nach folgender allgemeiner Regel ins Netzwerk oder nicht.
: Frag den Benutzer
: das Ereignis wird zur nächsten Regel weitergeleitet
In dem Kästchen vor den Regel - Zeichen ist ein Haken gesetzt, wenn die Regel aktiviert ist, und keiner, wenn sie deaktiviert und übersprungen wird.
Ein schwarzes T steht für eine temporäre Regel, die nicht gespeichert wurde (das kann ein z.B. Kind - Prozeß sein) oder es fehlt der Haken im PopUp Fenster bei Remember my answer (Speicherung der Regel).
Das rote Ausrufezeichen erscheint dann, wenn ein Fehler beim Laden der Regel auftritt.
Diese Regel wird in diesem Fall nicht durchgeführt und der Fehler (meist ein Konfigurationskonflikt) sollte möglichst rasch behoben werden. Ein Fehler kann z.B. eine falsch gesetzte Regel sein.
Firefox soll wie Web Browser behandelt werden. Bestätigen und OK.
Die Abfrage zeigt Jetico als aktives Ereignis in Form eines Lämpchens an.
Letztlich ist das alles, was wir mit unseren Programmen machen müssen.
Und hier wäre das Tutorial eigentlich schon am Ende.
Wenn es da nicht ein paar Kleinigkeiten gäbe, die wir berücksichtigen sollten.
Denn wir können, da es die eindeutigen Eigenschaften der Ereignisse gibt, der FW sagen, was sie machen soll, wenn eine bestimmte Eigenschaft zutrifft.
Der Anwendung oder dem Ereignis kann ich Unterregeln erteilen, die dann eine andere Regel bekommen.
Firefox kann nun als Web Browser ins Netz. Allerdings würde ich ihm gerne verbieten, über NetBIOS ins Netz zu gehen. Dafür benötige ich eine neue Regel, und die soll für alle Browser gelten.
Meine Schritte wären dann:
Configuration – Reiter -> Root - > Ask User -> Web Browser -> auf der rechten Seite R-Klick -> New -> Application rule
Hier wähle ich
Verdict: reject und unter
Packet parameters -> Event: access to network und bei
Protocol markiere ich NetBIOS
Alles andere kann so bleiben.
Mit OK bestätigen und eine 2. Regel für den Web Browser wurde erstellt.
Da wir die Regel nicht nur für den FF erstellt haben, sondern für Web Browser allgemein, gelten diese Regeln natürlich für alle Browser, sofern deren Zugriffe im Popup Fenster über Handle as … Web Browser definiert wurden.
Wenn wir einen Browser separat konfigurieren wollen, müssen wir im Application rule – Fenster unter Packet parameters -> Application: die entsprechende Anwendung
auswählen.
Mit einen R- Klick könnt ihr die Regel löschen, clonen (in eine andere Table/Gruppe), editieren oder den Text der Regel in die Zwischenablage nehmen um ihn woanders einzufügen.
Wie für den Browser funktionieren alle anderen Konfigurationen, auch für die Programme, die in der Trusted zone oder Blocked zone eingetragen wurden.
Wenn weitere Fragen auftauchen, nur zu.
Und nächste Woche kommen wir im 3. Teil zu Protokoll-, Systemprozess-, Angreifer- und FTP/Mail – Server/Client Geschichten
Zitat von arcanoa
