VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
Februar 2003
[Inhaltsverzeichnis]
|
| Von Doug Bissett © Februar 2003, Übersetzung: Karl Reinberg |
Eine Anleitung zur Einrichtung einer rudimentären Firewall, indem man die Möglichkeiten der letzten Versionen von IBM's TCP/IP Pakete für OS/2 und eComStation (grundsätzlich TCP/IP 4.1 und höher) nutzt.
Gut, es gab eine Menge Diskussionen darüber, was man benötigt und was nicht, um eine effektive Firewall einzurichten. Hier sind meine Ideen, wie Sie beim Einstieg vorgehen müssen. Ich gebe keine Versprechen, daß dies bei jedem funktioniert. Das Endresultat wird ein unsicheres System sein, solange Sie es nicht in ein sicheres ändern. Benutzen Sie Ihre eigene Umsicht, wenn Sie diese Anweisungen nutzen. Ich werde keinen Versuch einer Erklärung unternehmen, was einige dieser Dinge tun. Sehen Sie sich:
http://www.os2.spb.ru/guru/tcpip/ipsece.html
und
an, wo Sie mehr Informationen und Details finden können.
Beachten Sie, daß diese Anweisungen nur für Anwender sind, die keine Ahnung haben, wie sie anfangen sollen, und daß sie nicht für jemanden geeignet sind, der einen Server betreibt. Es könnte ein Einstieg sein, wenn Sie bei dem, was Sie tun, vorsichtig sind.
Benutzen Sie diese Anweisungen auf eigene Gefahr!
1) Erstens: Sie benötigen eine grundsätzliche Menge an Regeln, um beginnen zu können. Editieren, oder erzeugen Sie die Datei
<systemlaufwerk>:\MPTN\ETC\SECURITY\FWFILTRS.CNF
und ändern Sie den Inhalt in:
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure both both l=yes f=no
(genau eine Zeile).
Diese Regel erlaubt jeden Verkehr in beiden Richtungen, hinein und heraus. Beachten Sie daher, daß dies von den Auswirkungen her die gleiche Sache ist, wie ein Betrieb ohne Firewall. Ich benutze diese Regel, da sie Protokollierung (Logging) einschaltet. Es erlaubt Ihrem System genauso zu arbeiten, als wäre dort keine Firewall. Es sollte weiter ohne Probleme laufen. Wir werden zu einem späteren Zeitpunkt weitere Regeln aufbauen und diese dann löschen.
2) Als nächstes brauchen Sie eine Datei
<systemlaufwerk>:\MPTN\ETC\FWLOG.CNF
welche die gewünschte Protokollstufe enthält. Stellen Sie die einzelne Zeile
level=20
in die Datei.
Und sie benötigen die Datei
<systemlaufwerk>:\MPTN\ETC\FWSECAD.CNF
die eine Tabelle von jeder sicheren Schnittstelle auf Ihrem System enthalten sollte (solche Schnittstellen, bei denen es für einem Außenstehenden unmöglich wird, darauf zuzugreifen). In meinem Fall sind die beiden einzigen Schnittstellen, die ich habe, mein normales Interface, das mit der Außenwelt verbunden ist und die 'loopback'-Adresse (127.0.0.1). Ich nehme an, daß 127.0.0.1 sicher ist, da sie nicht dafür vorgesehen ist, überhaupt Verkehr in oder aus der lokalen Maschine zur erlauben (möglicherweise liege ich aber falsch). Daher habe ich eine einzelne Zeile in dieser Datei:
127.0.0.1
3) Dann sollten Sie sichergehen, daß Sie alle entsprechenden Treiber geladen haben. Sie sollten die folgenden Zeilen in Ihrer CONFIG.SYS vorfinden und natürlich auch die zugehörigen Dateien (falls Sie die Dateien nicht haben, haben Sie wahrscheinlich die Firewall-Unterstützung nicht installiert):
DEVICE=<systemlaufwerk>:\MPTN\PROTOCOL\IPSEC.SYS DEVICE=<systemlaufwerk>:\MPTN\PROTOCOL\FWIP.SYS DEVICE=<systemlaufwerk>:\MPTN\PROTOCOL\CDMF.SYS DEVICE=<systemlaufwerk>:\MPTN\PROTOCOL\MD5.SYS
4) Dann müssen Sie das Firewall-Programm mit eingeschalteter Protokollierung tatsächlich starten. Um dies zu tun, editieren (oder erzeugen) Sie <systemlaufwerk>:\TCPIP\BIN\TCPEXIT.CMD und fügen Sie die folgenden drei Zeilen hinzu:
inetcfg -s firewall 1 DETACH FSSD.EXE CFGFILT -i -u -d
Dies startet die Firewall, dann das Protokollprogram und aktiviert dann die Firewall mit den entsprechenden Optionen.
Führen Sie einen Neustart des Systems durch.
Zu diesem Zeitpunkt sind Sie nicht geschützt, in keinster Weise, aber Sie können in die Protokolldateien schauen um nachzusehen, was passiert.
5) Ok, nun da Sie die Firewall gestartet und die Protokollierung eingeschaltet haben, müssen Sie die Möglichkeit schaffen, sich die Protokolldateien (Logs) anzuschauen. Das Protokollprogramm erzeugt eine Datei mit dem Namen FWmmtt (dabei ist mm der Monat und tt der Tag) im Verzeichnis <systemlaufwerk>:\MPTN\ETC. "Simpel", sagen Sie. Nun, nicht wirklich. Der aktuelle Tag ist vom Protokollprogramm gesperrt (ältere Logs sind nicht gesperrt), und wenn Sie mit einem Editor wie dem Systemeditor hineinschauen, wird Ihnen das sowieso nicht viel sagen. Es gibt ein Programm, das für die Anzeige der Protokolle konstruiert ist. Es ist ein Befehlszeilenprogramm, und Sie könen es benutzen, indem Sie auf der OS/2-Befehslzeile in das Verzeichnis <systemlaufwerk>:\MPTN\ETC wechseln und
FWLSLOG FILE=FWmmdd
tippen (wobei mm der Monat und tt der Tag des Protokolls ist, das Sie sich ansehen möchten, den aktuellen Tag miteingeschlossen). Starten Sie das Programm ohne Parameter für weitere verfügbare Optionen.
Die erste Sache, die Sie feststellen werden, ist, daß dort eine zu große Menge Daten stehen, und Sie jeden verschiedenen Typ des Protokolleintrags studieren müssen um zu lernen, wie man die Information liest. Ich werde nicht einmal versuchen, Sie das zu lehren, aber ich werden Ihnen helfen, einen Satz von neuen Regeln aufzubauen, die die Anzahl und Typen von Protokolleinträgen reduziert.
6) Regeln zu erzeugen, ist mehr Kunst als Wissenschaft. Um Ihnen dabei zu helfen, empfehle ich, daß Sie sich das Programm ZAMPA besorgen. Das Programm wird mit eComStation ausgeliefert, aber Sie können es von http://www.mo.himolde.no/~ltning/os2/index.htm bekommen. Warnung: Selbst die Autoren geben zu, daß dieses Programm einige Mängel hat. Ich finde es zum Bearbeiten der Regeln nützlich, aber ich empfehle, es für nichts anderes zu nutzen.
Der ZAMPA Editor, die ALLES-erlauben-Regel (Permit ALL) anzeigend
Als erstes möchten wir einige der Protokolle des "normalen" Verkehrs eliminieren. Dieser Verkehr ist Zeug, was passieren soll, damit Sie im Internet arbeiten können. Nun, Sie können eine Regel festlegen, die jede spezifizierte Aktion erlaubt, oder Sie definieren einige generelle umfassende Regeln. (Die Regel, die zur Zeit eingestellt ist, ist vom letzteren Typ). Ein Ansatz ist, jeden Verkehr zu erlauben, der das TCP/ACK-Flag gesetzt hat. Dies sollte nur der Fall sein, wenn ein beliebiger Webserver Ihnen Daten schickt, die Sie gerade angefordert haben. Das sollte ziemlich sicher sein, und auf den meisten legitimen ankommenden Verkehr zutreffen. Öffnen Sie daher ZAMPA, und Sie sollten die eine Regel in der Liste sehen, die alles erlaubt. Wählen Sie diese aus, und klicken Sie auf Change Rule. Sie sollten die Basisregel, die alles erlaubt, formatiert im Editor sehen. Ändern Sie diese nicht, schauen Sie sich sie nur an und klicken Sie Cancel. Jetzt klicken Sie auf Add rule, und Sie sollten eine Grundregel sehen, die alles verweigert. Das ist tatsächlich die Grundregel, falls keine andere Regel mit der Situation übereinstimmt, daher brauchen Sie diese nicht zu definieren. Ok, wir wollen jeden ankommenden Verkehr erlauben, solange das TCP/ACK-Flag aktiv ist. Wählen Sie das folgende aus (lassen Sie alles andere, was nicht erwähnt ist, in der Grundeinstellung):
Permit - diese Regel wird die definierten Aktionen erlauben
Logging disabled - wir brauchen dies nicht zu protokollieren
TCP/ACK packets - anwenden auf Pakete mit TCP/ACK gesetzt
Non-secure - nur auf das Non-secure-Interface anwenden
Inbound - nur anwenden auf ankommenden Verkehr
Sie können die Zieladresse und Netzmaske ändern, falls Sie eine feste IP-Adresse haben (falls Sie es nicht wissen, haben Sie wahrscheinlich keine, daher lassen Sie es fürs erste unverändert - nur Nullen bedeutet jede Adresse). Ok, sichern Sie das mit Add. Nun müssen Sie wissen, daß diese Regeln vom Anfang der Liste bis zum Ende hin überprüft werden. Die erste Regel, die speziell den Verkehr erlaubt oder verweigert, ist diejenige, die angewandt wird. Damit endet auch die Überprüfung. So, Sie haben jetzt eine Regel, die sagt, erlaube alles, und eine, die einschränkt, was erlaubt ist. Nun, es sollte eine gute Idee sein, diejenige, die Aktivitäten einschränkt auf eine Stelle zu verschieben, in der sie vor derjenigen getestet wird, die alles erlaubt. Wählen Sie die neue Regel aus (sie wurde am Ende hinzugefügt), und klicken Sie Move up (falls dort mehr Regeln sind, müssen Sie sie zur Position verschieben, die Sie wünschen). Für den Augenblick lassen Sie die Regel, die alles erlaubt, am Ende.
Als nächstes sichern Sie die Änderungen, indem Sie auf den Write Config-Knopf drücken. Dann (WICHTIG) klicken Sie auf die Start/update-Schaltfläche, um die neue Konfigurationsdatei zu aktivieren.
Wir haben weiterhin eine Firewall, die alles erlaubt, daher sind Sie immer noch nicht geschützt, aber was wir getan haben, ist die Protokollierung für legitimen ankommenden Verkehr zu eliminieren (nun ja, zumindest eine Menge davon).
Wenn Sie sich das Protokoll ansehen, werden Sie weiterhin eine enorme Menge von Müll sehen, daher werden wir ein paar Regeln bauen, die legitimen Verkehr erlauben, aber nicht protokollieren. Zurück zu ZAMPA und erzeugen Sie einige neue Regeln:
Nun, da wir schlußendlich die Regel entfernen werden, die alles erlaubt, hätten wir besser eine Regel erstellt, die es uns erlaubt, alles ins Internet zu senden.
Permit
Logging disabled
Any protocol
Non-secure
Outbound
Klicken Sie Add, und ziehen Sie es nach oben.
Sie möchten Zugriff auf Domain Name Server (DNS) haben:
Permit
Logging disabled
UDP packets
Source port equals 53
Destination port greater than 49152
Non-secure
Inbound
Klicken Sie Add, und ziehen Sie es nach oben. Der Zielport, größer als 49152, wird vorgeschlagen, da OS/2 Ports oberhalb dieses Werts nutzt.
Die folgende Regel wird nicht unbedingt benötigt, da Sie jeden ausgehenden Verkehr erlaubt haben, aber ich werde es mit einschließen, als Beispiel, wie man spezielle ausgehende Regeln vornimmt:
Permit
Logging disabled
UDP packets
Source port greater than 49152
Destination port equals 53
Non-secure
Outbound
Hinzufügen, nach oben verschieben.
Das soll im Moment reichen. Klicken Sie auf Write config und Start/update.
Nun haben Sie weiterhin ein unsicheres System, aber die Protokolle sollten klein genug sein, um aussortieren zu können, was notwendig ist. Es werden einige andere Regeln benötigt, um Ihr System sicher zu machen. aber ich werde das Ihnen überlassen herauszufinden. Sobald Sie ein Protokoll haben, das Ihnen nur den Verkehr zeigt, von dem Sie denken, er müsse blockiert werden, erzeugen Sie eine Regel, die alles (das ist üblicherweise die Grundeinstellung) bei eingeschalteter Protokollierung verweigert, und bewegen Sie sie oberhalb der Regel, die alles erlaubt. Nachdem Sie diesen Satz Regeln aktiviert haben, sollten Sie ein angemessen sicheres System haben. Möglicherweise zu sicher, und irgendetwas wird nicht funktionieren. Falls dies passiert, schauen Sie in die Protokolle, um zu erkennen, was verweigert wird und Sie somit freigeben müssen. Dann erzeugen Sie eine neue Regel, die dies erlaubt. Falls Sie die blockierte Anwendung benötigen, verschieben Sie die Permit-All-Regel vor die Deny-All-Regel und erledigen Sie- was getan werden muß. Finden Sie es raus, wenn Sie Zeit haben. Vergewissern Sie sich, die Deny-All- vor die Permit-All-Regel zurückzuschieben, wenn Sie mit dem betroffenen Programm fertig sind. Sie können beide Regeln entfernen, sobald Sie die Firewall ordentlich lauffähig haben. Deny all ist die Grundeinstellung, wenn keine andere Regel greift.
Nun, Sie sind noch weit vom Ende des Projekts entfernt, aber solange wie Sie die Deny-All-Regel vor der Permit-All-Regel haben, ist Ihr System um einiges sicherer als zu Anfang. Ich empfehle außerdem, daß Sie grundsätzlich jede deny-Regel vor jeder permit-Regel plazieren, aber es kann Gründe geben, es anders zu tun. Erinnern Sie sich daran, daß die Regeln vom Anfang der Liste aus überprüft werden, und die erste Regel, die ausdrücklich den Verkehr erlaubt oder verweigert, ist diejenige, die sich durchsetzt. Durchdenken Sie Schritt für Schritt, was Sie tun, um zu erkennen, was die Regeln mit individuellen Datenpaketen anstellen.
Ich empfehle, sich eher auf der Seite "zu sehr abgesichert" zu verhalten, wenn Sie Regeln erzeugen. Besser man hat eine Regel, die man etwas aufweichen muß, damit alles ordnungsgemäß funktioniert, als eine Regel, die zu weit offen ist (ein paar der obigen sind möglicherweise zu weit offen). Falls etwas nicht funktioniert, überprüfen Sie die Protokolle und die Aktivität sollte augenscheinlich sein (aber vergessen Sie nicht, daß etwas auch aus anderen Gründen nicht funktionieren könnte). Nach einiger Zeit werden Sie begreifen, wie man die Protokolle überprüft und festlegt, was erlaubt sein sollte, während Sie über die fehlschlagen Versuche lachen, auf Ihr System zuzugreifen. Sie möchten möglicherweise die Protokollierung für individuelle Regeln einschalten um sicherzugehen, daß sie das tun, von dem Sie denken, was sie tun sollten, aber das ist Teil des weiteren Projekts.
Als interessante Übung, gehen Sie zu https://grc.com/x/ne.dll?bh0bkyd2 um nachzuschauen, was die Außenwelt von Ihrem System denkt. (LESEN Sie die Information, was die Site versucht zu tun, und was Sie in den Protokollen sehen müßten, wenn sie Dinge testet). Es gibt dort auch eine Referenz zu einer scheinbar guten Firewall für Windows (wichtiger als bei OS/2).
Sie haben nun eine grundsätzliche Firewall, und Sie haben ein paar Hinweise, wie Sie sie optimieren können, sodaß sie besser arbeitet. Sind Sie geschützt? Nun, das hängt davon ab, was Sie erlauben (die Regeln, die ich oben skizziert habe, sind möglicherweise nicht korrekt, aber scheinbar funktionieren sie bei mir), und was die Hacker anstellen, um in Ihr System einzubrechen. Es gibt möglicherweise Sicherheitslöcher im OS/2-System und in der Firewall, aber es ist unwahrscheinlich, daß ein Hacker überhaupt erkennt, daß Sie OS/2 laufen haben, und das für sich genommen hilft bereits, Sie zu schützen. Alles, was ich sagen kann, ist, daß es ausschaut, als wenn diese einfache Konfiguration den meisten (wenn nicht sogar allen) unerwünschten Verkehr stoppt. Durch Hinzufügen von mehr Regeln können Sie das Protokollieren unerwünschten Verkehrs unterdrücken, aber vergewissern Sie sich, daß Sie ihn wirklich löschen wollen...
Sie können außerdem die Regel löschen, die jeden ausgehenden Verkehr erlaubt und spezielle Regeln dafür anlegen, aber das wäre eine Menge mehr Arbeit, und wird in den meisten Fällen nicht benötigt.
Sie können einige Hinweise erhalten, welche verschiedenen Ports für was benutzt werden, indem Sie die Datei <systemlaufwerk>:\MPTN\ETC\SERVICES untersuchen, aber evtl. müssen Sie in den Newsgruppen fragen, falls Sie etwas nicht verstehen. Eine "Regel" über Regeln. Erlauben Sie nichts, bevor Sie nicht angemessen sicher sind, daß Sie es benötigen, um etwas zum Laufen zu bekommen. Vielleicht ist es eine gute Idee, einige Regeln zu erstellen, bestimmte Dinge zu verweigern, um die Anzahl Protokolleinträge zu verringern, aber das ist etwas, mit dem Sie experimentieren können (Hinweis: suchen Sie nach ankommenden Zugriffen auf die Ports 137, 138 und 139, obwohl ich vermute, das ist normal, falls, und nur falls Sie ein internes Netzwerk mit NETBIOS über TCP/IP nutzen - wie auch immer nicht empfehlenswert, aber das ist allgemein die Grundeinstellung bei Windows).
Falls Sie sich wundern, wer gerade versucht, auf Ihr System zuzugreifen, können Sie den HOST-Befehl nutzen, und/oder sich das WHOIS-Paket (zu finden bei Hobbes) besorgen, aber ich empfehle, sich mit dem Versuch, diese zu stoppen zurückzuhalten. Ich vermute, daß eine Menge Aktivitäten durch Viren hervorgerufen werden, und die "verantwortliche" Person noch nicht mal weiß, was passiert. Sie riskieren außerdem Zielscheibe für schlimmere Dinge zu werden, falls die Person, die dies tut so entscheidet. Es ist besser zu denken "Gut, dies hat mich nicht erwischt", und es dabei zu belassen.
Daten und Quellen:
|
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org