von Thomas Barlen
Über den Autor
Thomas Barlen ist ein Consulting IT Specialist für iSeries und AS/400 im IBM eServer iSeries Technical Sales Support bei IBM Deutschland. Sie können Herrn Barlen unter barlen@de.ibm.com erreichen.
In vielen Firmen wird der Einsatz einer Firewall als ausreichend betrachtet, um sich gegen Angriffe aus dem Internet zu schützen. Dabei wird oft übersehen, dass die meisten Schäden durch Angriffe, sei es absichtlich oder aus Versehen, aus dem Intranet heraus initiiert werden. Diese Tatsache bedeutet, dass Ihr iSeries Server allen Angriffsversuchen aus dem Intranet voll ausgesetzt ist. Wäre es nicht schön, einen Service zu haben, der es Ihnen erlaubt, unerwünschten Netzwerkverkehr direkt an der Kommunikationsschnittstelle in das System abzuweisen? Es gibt tatsächlich einen Service, der es erlaubt, IP Datenverkehr in und aus dem System auf physischer Schnittstellenebene zu kontrollieren.
IP Paketregeln
Unter OS/400 ist dieser Service als „IP Paketregeln“ bekannt und er ermöglicht Ihnen, als primären Schutz Intranetverkehr zu filtern und eine zweite Verteidigungslinie gegenüber dem Internet aufzubauen. IP Paketregeln wurden erstmals mit V4R3 im OS/400 zur Verfügung gestellt und mit V5R2 erheblich erweitert. Das Filtern von IP Verkehr findet auf der IP Ebene (Netzwerkebene) statt. Die Entscheidung, ob ein Paket die IP Schnittstelle passieren kann, wird beim Filtern anhand von Informationen im IP Header getroffen. Die meisten Paketfilter erlauben das Filtern anhand folgender Kriterien:
- Quellen- und Zieladresse
- Quellen- und Zielport
- Protokoll (TCP, UDP, ESP, etc.)
- Datenrichtung (INBOUND oder OUTBOUND)
V5R2 erlaubt das Filtern auf allen physischen und virtuellen (LPAR und Windows Integration) LAN Schnittstellen, Point-to-Point und Layer 2 Tunneling Protocol (L2TP) Schnittstellen. Für PPP und L2TP Schnittstellen können unterschiedliche Filterregelgruppen für verschiedene Benutzer aktiviert werden. Ein gutes Basiswissen des IP Protokolls sollte vorhanden sein, um IP Paketregeln erfolgreich einzusetzen. Eine typische Implementierung von IP Paketregeln setzt sich aus der Planungs-, Konfigurations- und Aktivierungsphase zusammen.
Planung
Paketregeln können Datenverkehr erlauben oder blockieren sowie Daten einer VPN Verbindung verarbeiten. Im Falle eines VPNs muss die sogenannte IPSec-Regel vor dem Aktivieren der VPN Verbindung eingerichtet sein. Ist der VPN Tunnel aktiv und ein Paket entspricht einer IPSec-Regel, so wird dieses Paket entsprechend der zugehörigen Konfiguration verschlüsselt. Da VPN nicht das Hauptthema dieses Artikels ist, widme ich mich wieder der reinen Filterfunktion. Sobald Filterregeln für eine Schnittstelle aktiviert sind, wird jeglicher IP Datenverkehr, der nicht ausdrücklich erlaubt ist, automatisch durch eine implizite „Deny“-Regel abgewiesen. Deswegen ist es außerordentlich wichtig, vor der Konfiguration eine sorgfältige Planung durchzuführen. Dies erfordert die Sammlung von Informationen, z.B. welche Anwendungen (Ports und Protokoll) aktiv und in Gebrauch sind sowie die fernen Adressen, welche auf diese Anwendungen zugreifen sollen. Während dieser Planungsphase werden Sie wahrscheinlich feststellen, dass einige Anwendungen aktiv sind aber nicht benötigt werden oder Sie sehen Benutzer, die auf Anwendungen zugreifen, für die sie eigentlich nicht autorisiert sind. Obwohl die Planung die meiste Zeit in Anspruch nimmt, so ist diese Phase aber auch die wichtigste Phase in der gesamten Implementierung. Grundsätzlich stehen zwei unterschiedliche Wege zur Verfügung, um festzustellen, welche Pakete erlaubt oder explizit abgewiesen werden sollen. Die erste Methode nutzt die NETSTAT Funktion, welche über die 5250 Befehlszeile (NETSTAT *CNN) oder über den iSeries Navigator (Netzwerk->TCP/IP Konfiguration->IPv4-> Verbindungen) genutzt werden kann. NETSTAT gibt Auskunft über alle aktiven Verbindungen, alle Anwendungen, die gestartet sind und über IP Adresse, Protokoll und Port, die der Anwendung zugeordnet sind. Die über NETSTAT erlangten Informationen verschaffen Ihnen einen guten Überblick über die genutzten Anwendungen und Zugriffe, stellen aber nur eine Momentaufnahme zum Zeitpunkt der Ausführung dar. Um eine detailliertere Aufstellung zu erhalten, können Sie eine einzelne IP Paketregel konfigurieren. Diese Regel erlaubt jeglichen Verkehr, sei es ein- oder ausgehend, nutzt aber die Journaloption. Dabei schreibt OS/400 für jedes eingehende und ausgehende Paket einen Journaleintrag. Diese Methode stellt Ihnen eine komplette Aufstellung zur Verfügung, hat aber auch einen negativen Einfluss auf die Systemperformance und den Plattenbereich. Die Filterjournaloption sollte nur während der Planungsphase oder für spezielle Einsätze (z.B. Problemeingrenzung) aktiviert werden. Das Ergebnis der Datensammlung sollte sich mit den Sicherheitsrichtlinien Ihres Unternehmens decken.
Konfiguration
Während der Konfigurationsphase werden alle Regeln konfiguriert, die IP Datenverkehr explizit erlauben oder abweisen. Die Konfiguration erfolgt auf der Basis der Informationen aus der Planungsphase. In diesem Beispiel werden die mit V5R2 zur Verfügung gestellten Konfigurationsassistenten genutzt. IP Paketregeln können nur über den iSeries Navigator konfiguriert werden. Dies geschieht über den Regeleditor, der über folgende Schritte geöffnet werden kann:
- iSeries Navigator starten
- Den Navigationspfad auf Netzwerk-> IP Richtlinien->Paketregeln erweitern
- Mit der rechten Maustaste auf Paketregeln klicken und Regeleditor auswählen
Die Konfiguration basiert auf dem in Bild 1 dargestellten Beispielszenario.
Das Szenario basiert auf folgenden Informationen:
- Alle lokalen Benutzer (Netzwerk 172.16.10.0/24) können auf den iSeries Server mit iSeries Access für Windows und einer 5250 Emulationssitzung (verschlüsselt und unverschlüsselt) zugreifen.
- Außendienstmitarbeiter, welche unterwegs oder von zuhause arbeiten, können über das Internet nur eine verschlüsselte (SSL) 5250 Sitzung zum iSeries Server aufbauen.
- Der interne SMTP Mailserver akzeptiert nur eingehende Mail von dem SMTP Mailrelay, welches in der DMZ installiert ist.
Dieses Szenario implementiert eine zweite Verteidigungslinie gegenüber Nutzern aus dem Internet und einen primären Schutz gegenüber Intranetbenutzern. Die Konfiguration über den Assistenten erlaubt die Eingabe von IP Adressen oder die Auswahl von Aliasnamen, welche IP Adressen repräsentieren. Da die meisten Menschen sich Namen besser merken können als numerische Adressen, ist es einfacher mit Aliasnamen zu arbeiten. Bild 2 zeigt ein Beispiel zur Erstellung eines Namens für ein Teilnetz (subnet).
Ich empfehle immer die Erstellung von Aliasnamen für Server, Gateways, Teilnetze, usw. Ein Alias kann eine einzelne IP Adresse, ein Teilnetz, ein Adressbereich, eine Liste von IP Adressen oder Hostnamen beinhalten. Nachdem alle Aliasnamen erstellt sind, fahren Sie mit der Erstellung der Filterregeln unter Verwendung der Assistenten fort. Der Assistent stellt eine vordefinierte Liste von Anwendungen bereit. Mit V5R2 stehen drei Konfigurationsassistenten zur Verfügung : Service gestatten, Spoof-Schutz und Adressumsetzung. Um bestimmten Datenverkehr über eine Schnittstelle zu erlauben, wird der Assistent „Service gestatten“ verwendet. Der große Vorteil des Assistenten wird Ihnen erst bewusst, wenn Sie Regeln für iSeries Access Datenverkehr konfigurieren müssen. Sollten Sie jemals über NETSTAT die Ports gesehen haben, welche von iSeries Access genutzt werden, so haben Sie festgestellt, daß dies 11 Ports (449, 8470-8479) sind. Dies schließt nicht die Ports ein, welche für Management Central oder SSL-geschützten Datenverkehr (9470-9479) benötigt werden. Zum Glück besitzt der „Service gestatten“- Assistent alle notwendigen Informationen, um automatisch die entsprechenden Serviceports zu konfigurieren. Bild 3 zeigt ein Beispiel des Assistenten „Service gestatten“.
Wenn Sie eine „Service“-Anwendung verwenden, die keinen Standardport (well-known port) nutzt oder nicht in der vordefinierten Liste von Anwendungen aufgeführt ist, so können Sie diese auch manuell im Assistenten eingeben. In Weiterführung des Assistenten müssen Sie auch die Quellen- und Zieladressen angeben. Da die Serveradressen und Teilnetze bereits als Aliasnamen definiert sind, können diese im Assistenten direkt ausgewählt und später auch wieder verwendet werden. Die letzte Eingabe, die der Assistent anfordert, ist die Schnittstelle, für welche die Regeln gelten und die Datenrichtung. In meinem Beispiel wurden für iSeries Access (CLIENTACCESS Service) insgesamt 48 Filterregeln, eine Filterschnittstelle und eine Include-Anweisung durch den Assistenten erstellt. Die Include-Anweisung spezifiziert eine Service-Datei. Diese Datei enthält von IBM vordefinierte Servicenamen, welche Serviceports und Protokolle als Aliasnamen zur Verfügung stellen. Include-Anweisungen können auch unterschiedliche Filterregeln aus verschiedenen Regeldateien einbinden, welche in logische Gruppen aufgegliedert sind.
Auch wenn der Assistent manchmal mehr Regeln erstellt als tatsächlich notwendig sind, empfehle ich grundsätzlich immer die Verwendung der Assistenten, denn es ist einfacher ein paar Regeln zu löschen als alle Regeln manuell zu erstellen. Zum Beispiel definiert der Assistent für den Telnet Service der Außendienstmitarbeiter die Regeln für unverschlüsselte (non-SSL) und verschlüsselte (SSL) 5250-Sitzungen. Da laut unseren Anforderungen diese Mitarbeiter aber nur verschlüsselte Sitzungen aufbauen dürfen, werden die zwei Regeln (INBOUND und OUTBOUND) für den unverschlüsselten Verkehr wieder aus der Regeldatei entfernt. Wenn Sie die Filterregeln erstellen, sollten Sie immer daran denken, dass OS/400 die Regeln sequentiell von oben nach unten verarbeitet. Sobald ein Datenpaket einer Regel entspricht, wird nur diese Regel verarbeitet. Regeln, die weiter unten in der Regeldatei aufgeführt sind und auch dem Datenpaket entsprechen kommen somit nicht zur Verarbeitung. Wird keine entsprechende Regel gefunden, tritt die implizite Deny-Regel am Ende der Datei in Kraft und blockiert das Datenpaket. Die Verarbeitungsreihenfolge ist insbesondere dann zu beachten, wenn Sie Regeln definieren, die eine Untermenge von anderen Regeln darstellen. Zum Beispiel, wenn alle Benutzer PCs aus dem Teilnetz 172.16.10.0 Zugriff über Telnet auf den iSeries Server erhalten sollen, außer dem PC mit der Adresse 172.16.10.7, so müssen Sie zuerst eine explizite Deny-Regel für den einzelnen PC definieren und anschließend die Permit-Regel für das gesamte Teilnetz. Werden die Regeln in umgekehrter Reihenfolge definiert, würde die Permit-Regel den einzelnen PC (172.16.10.7) mit einbeziehen und somit den Zugriff erlauben. Sobald alle Regeln erstellt sind, müssen die Regeln noch geprüft und abgespeichert werden.
Aktivierung
Beginnend mit OS/400 V5R1 können Sie Filterregeln für eine einzelne Schnittstelle aktivieren bzw. deaktivieren. Diese Funktion ist dann besonders sinnvoll, wenn Sie Filterregeln für eine bestimmte Schnittstelle testen möchten, ohne andere Schnittstellen zu beeinflussen. Insbesondere am Anfang ist es ratsam, die Filterregeln nach Feierabend oder an Wochenenden zu aktivieren und zu testen. Viele Administratoren begehen bei der erstmaligen Konfiguration den Fehler, dass sie vergessen, den Datenverkehr des eigenen PCs zu gestatten. Keine Angst, die Symptome dieses Fehlers lassen nicht lange auf sich warten. Wenn das Aktivierungssymbol betätigt wird, die Sanduhr sich auf dem Bildschirm verewigt und keine Bestätigungsmeldung angezeigt wird, ist es ein Zeichen dafür, dass die Antwort das System nicht mehr verlassen kann. Aber was können Sie tun, wenn es wirklich soweit kommt? So ist es z.B. nicht mehr möglich über iSeries Navigator die Filter zu deaktivieren. Auch ein IPL hilft hier nicht weiter, da die Filterregeln beim IPL automatisch wieder aktiviert werden. In diesem Fall bleibt nur noch der Ausweg über die Systemkonsole. Dort können Sie über den Befehl RMVTCPTBL TBL(*IPFTR) die IP Filterregeln deaktivieren. Der Befehl wird auch dazu benutzt, die IP Adressumsetzung zu deaktivieren. Dies geschieht mit dem Befehl RMVTCPTBL TBL(*IPNAT).
Fazit
OS/400 stellt IP Paketregeln auf dem iSeries Server zur Verfügung. Diese Funktion ist eine effektive Methode, um einen wesentlich höheren Schutz in Ihrer IT Umgebung zu erreichen. Mehr Informationen zu diesem Thema finden Sie im InformationCenter (http://publib.boulder.ibm.com/iseries/v5r2/ic2929/index.htm unter Sicherheit->IP-Filterung und Netzwerkadressumsetzung (NAT)).
Ähnliche Artikel:
