WICHTIG:

Das hier vorgestellte System ist nicht mehr "up-to-date". Lediglich die Grundlagen sind noch verwendbar.





Fachhochschule Aalen

Studiengang Elektronik / Technische Informatik

 

LAN-Sicherheitskonzept und Aufbau eines Firewall-Systems

Diplomarbeit von Gregor Domhan

 

Betreuer: Prof. Dr.-Ing. Manfred Strahnen

Durchgeführt im WS 00/01

Inhalt:
 
Vorwort
1. Allgemeines
1.1 Angriffsmöglichkeiten
1.2 Möglichkeiten einer FW
2. Firewall Intensiv
2.1 Konkrete Arbeitsweise
2.2 Der Paketfilter
2.3 Application Gateway
2.4 Aufbaukonzepte
2.5 Dienstservern
2.6 Logfile
2.7 Angriffsversuchen
3. Firewall konkret
3.1 Ausgangssituation
3.2 Sicherheitskonzept
3.3 HW- und SW-Auswahl
3.4 Subnetze
3.5 Installation und Konfig
Anhang

Vorwort

Die Informations- und Kommunikationstechnologien sind Schlüsseltechnologien für weite Bereiche unserer Arbeits- und Lebenswelt. In manchen Bereichen unserer Arbeitswelt sind rechnergestützte Informationsquellen bzw. Informationsaustausch eine zwingende Notwendigkeit. Immer mehr zieht der Rechner auch in unser privates Leben ein Stichwort Internet.

Aber genauso, wie die Informationstechnolgie in unser Leben eingezogen ist, sind auch die kriminellen Energien gestiegen. Für viele Unternehmen und Institutionen beginnt dadurch eine Gradwanderung zwischen Nutzen und Risiken.

Ein Instrument zum Schutz vor Gefahren aus unsicheren Netzen, wie z.B. dem Internet, sind Firewall-Systeme. Allerdings werden unter diesem Begriff Sicherheitslösungen zusammengefaßt, die sich in Technik, Realisierung und Einsatzmöglichkeiten sehr unterscheiden.

Diese Diplomarbeit befaßt sich mit der Technik und Realisierung eines solchen Firewall-Systems für den Fachbereich Elektronik/Informatik der Fachhochschule Aalen. Die Aufgabenstellung dabei ist zum ersten, ein an das Fachbereichsnetz angepaßtes Sicherheitskonzept zu erstellen. Als Nächstes wird dann der Hardwareaufbau der Firewall-Rechner sowie die Konfiguration der Rechner auf der Pflichtenliste stehen. Die dritte Aufgabe beschäftigt sich mit der Sicherheitslösung von "Stand-Alone-Rechnern", die nicht durch eine Firewall zu schützen sind. Natürlich wird auch der Test der Firewall zum Aufdecken von Sicherheitsmängeln ein Punkt sein.

Die Diplomarbeit befaßt sich im speziellen mit dem Fachbereichsnetz E der Fachhochschule Aalen, kann aber genauso für jede andere schützenswerte Institution angewandt werden.

Natürlich sind dann die Randbedingungen anders, und an einigen Punkten ist die Konfiguration anders zu wählen.

 

1. Allgemeines

1.1 Angriffsmöglichkeiten in vernetzten Kommuniktaionssystemen

Die wohl bekannteste Möglichkeit in ein Intranet einzudringen ist über das Internet oder andere Kommunikationsanschlüsse. Also über einen öffentlichen Zugang zum Netz. Das dies jedoch nicht immer der Fall ist, wird in folgendem dargestellt.

1.1.1 Passive Angriffe

Unter passiven Angriffen versteht man das Abhören von Daten, die über einen Kommunikationskanal versendet werden. Unter einem Kommunikationskanal versteht man z.B. ein Computernetzwerk oder auch eine Telefonleitung. Bei passiven Angriffen wird nur der Verkehr, also die übertragenen Daten abgehört. Die Daten werden nicht verändert.

Dabei gibt es drei Angriffsmöglichkeiten:

- Abhören von Daten:

  Der Angreifer gelangt an die übertragenen Daten und kann sie für seine Zwecke verwenden (Spionage). Es kann sich dabei um eine reine Dateiübertragung handeln, oder auch um Benutzerdaten. Also z.B. Login-Daten für eine Servereinwahl. Damit ist es dann dem Angreifer möglich, sich mit einer falschen Identität ohne großes Aufsehen zu einem späteren Zeitpunkt in z.B. einen Server einzuloggen

- Abhören des Teilnehmer-Verhaltens:

  Ein Angreifer kann dadurch erfahren, wer mit wem zu welchen Zeitpunkt kommuniziert. Diese Information kann dann z.B. nach Regelmäßigkeiten untersucht werden. Das kann auch für ganz legale Zwecke verwendet werden. Z.B. kann man damit das Besucherverhalten eine Webservers kontrollieren, also ob jemand regelmäßig eine Seite abruft.

- Datenflußanalyse:

  Selbst wenn der Datenfluß verschlüsselt ist, kann man trotzdem gewisse Informationen, wie z.B. Größenordnungen, Zeitpunkt und Häufigkeit der Datenpakete erfahren. Daurch lassen sich unter Umständen Rückschlüsse auf z.B. Börsen-Transaktionen oder militärische Operationen ziehen.

 

1.1.2 Aktive Angriffe

Eine andere Form eines Angriffes, neben dem reinen Abhören, sind aktive Angriffe. Unter aktiven Angriffen versteht man das verfälschen des Datenstromes oder des Betriebes der Kommunikation. Aktive Angriffe können z.B. durch Auftrennen eines Kommunikations-kanales und Zwischenschalten eines fremden Systems geschehen. Dieses fremde System empfängt dann den ankommenden Datenstrom, manipuliert ihn nach belieben und schickt ihn dann in den ausgehenden Datenkanal. Die Manipulationen können dabei folgende sein :

- Informationen wiederholen oder verzögern :

  Durch Aktionen wie wiederholen oder verzögern kann der Empfänger zu einer falschen Aktion veranlaßt werden. Z.B. mehrfachübertragung von Geldtransaktionen.

- Löschen oder Einfügen von Daten:

  Um z.B. eine Geld-Transaktion zu manipulieren, können Daten gelöscht oder verändert werden. Z.B. anstatt kaufe eine Aktie kaufe keine Aktie.

- Verändern von Daten:

  Der Angreifer greift aktiv in den Datenstrom ein und verändert ihn nach belieben. Das kann z.B. bei Online-Banking verherende Folgen haben, wenn die Kontonummer oder der Geldbetrag verändert wird.

- Denial of Service:

  Unter Denial of Service versteht man den Boykott des Kommunikations-Systems. Durch z.B. einen dauernden Verbindungsaufbau kann ein Server boykottiert werden, so daß keine anderen Daten mehr zu ihm durchdringen können, oder daß der Server sich einfach "aufhängt".

- Maskerade-Angriff:

  Wie der Name schon sagt, versucht der Angreifer sich eine falsche Identität aufzusetzen. Er maskiert sich also. Dadurch kann der Angreifer ohne irgendwelche Sicherheitsschranken umgehen zu müssen, Zugriff auf z.B. Datenbankserver haben.

- Kommunikationsverbindungen leugnen:

  Durch das stetige Wachstum des Internets, wird auch immer mehr über das Web online bestellt und gekauft. Wenn nun nicht genau klar ist, von wem die Bestellung oder der Vetragsabschluß kommt, kann auch dies wiederum verherende Folgen haben. Z.B. wenn irgend jemand auf Ihren Namen etwas bestellt oder einkauft.

- Trittbrettfahrer:

  Da immer mehr Unternehmen und Institutionen ihr Intranet absichern, haben es die Angreifer auch immer schwerer in das System einzudringen. Um sich dennoch Zugang zu verschaffen, kann man den Datenverkehr abhören. Sobald dann die Identifikation und Authentifikation abgeschlossen sind, trennt der Angreifer die Verbindung desjenigen, der versucht sich einzuloggen. Dann startet der Angreifer einen Maskerade-Angriff. Er gibt sich also für denjenigen aus, der sich versucht hat einzuloggen.

1.1.3 Ausnützen von Implementierungsfehlern

Rechner sind zwar Maschinen, und von Haus aus sehr fehlertolerant, aber die Programmierung der Rechner erfolgt immer noch durch den Menschen. Der Mensch wird, durch seine Eigenschaft, Fehler zu machen, somit zum Sicherheitsrisiko. D.h. daß der Mensch durch die Programmierung der Maschinen Fehler macht. In Zahlen gesprochen, hat ein heutiges Softwareprojekt laut MIT eine Fehleranzahl von 0,05-0,2 je 1000 Codezeilen. Das hört sich nach wenig an. Ein Beispiel, ein Fehlerniveau von 0,1 würde z.B. pro Tag 16.000 verlorene Briefe der Post bedeuten ! Das ist der Grund, warum man beim Faktor Mensch von einem Sicherheitsrisiko sprechen kann.

Heutige Anwendungen habe eine kaum vorstellbare Komplexität in Hinsicht auf die Funktionsvielfalt. Je mehr Funktionen in eine Anwendung implemetiert wurden, desto höher ist auch die Fehleranzahl.

In der Vergangenheit gab es ein bekanntes Beispiel: Sendmail. Sendmail enthielt Implementierungs- und Designfehler, die es ermöglichten, auf einem entfernten Rechnersystem beliebige privilegierte Kommandos ausführen zu lassen. Mit anderen Worten gesprochen: Durch die Fehler im Anwendungsprogramm Senmail war es einem Angreifer möglich, z.B. Daten zu löschen oder Netzverbindungen aufzubauen. Jeder kann sich denken, daß dies nicht im Sinn der Programmierer war.

 

1.2 Was kann ein Firewall System nun dagegen tun ?

Durch die Integration eines Firewall-Systems wird eine Entkopplung des Intranet zum Internet oder jedem anderen öffentlichen Zugang erreicht. Kurz gesprochen besteht eine Firewall aus einem oder mehreren Paketfiltern. Diese habe die Aufgabe, nur diejenigen Datenpakete durchzulassen, die auch benötigt werden. Desweiteren besteht eine Firewall auch aus Stellvertretern, sogenannten Proxies. Die Proxies haben die Aufgabe, daß Anwendungsprogramme wie z.B. Sendmail nicht direkt ansprechbar sind, sondern einen (hoffentlich) sicheren Stellvertreter in der Firewall haben. Dadurch werden Implementierungsfehler im Anwendungsprogramm als Sicherheitsrisiko vermieden.

 

2. Firewall Intensiv

2.1 Konkrete Arbeitsweise der Firewall gegen Bedrohungen

2.1.1 IP-Adressen-Spoofing

IP-Adressen-Spoofing ist identisch mit einem Maskerade-Angriff, jedoch auf IP-Ebene des Netzwerkes. Bei dieser Angriffsart verfälscht der Angreifer die Absender-IP-Adresse der IP-Pakete. Wenn der Angreifer nun auch noch eine IP-Adresse des internen Netzes wählt, dann kann er ohne jegliche Beschränkungen in das Netz eindringen.

Die eindeutige Entscheidung, ob der Netzverkehr vom Internet oder Intranet kommt, kann durch die Integration einer Firewall mit dem Sicherheitsdienst "Eindeutige Erkennung der Seite im Vorfeld verhindert werden. Die Firewall erkennt nun, daß z.B. ein Angreifer sich mit einer internen IP-Adresse von außen in das Netz einloggen will, und kann dies abwehren.

2.1.2 ICMP-Angriffe

Ein sehr wichtiger Bestandteil des TCP/IP-Protokolls ist das ICMP-Protokoll. ICMP steht für Internet Control Message Protokoll. Es ist ein Protokoll zur Übetragung von Informations- und Fehlermeldungen, das von vielen Tools benutzt wird, um Informationen über ein Internet einzuholen.

ICMP-Angriffe können z.B. sein:

- Mißbrauch des Kommandos "Destination Unreachable":

  "Destination Unreachable" steht für "Ziel nicht erreichbar". Wenn ein Sender solch ein Kommando erhält, dann bricht er die Verbindung ab, da ja das Ziel nicht erreichbar ist. Angreifer sind dadurch also in der Lage, durch das Senden von falschen "Destination Unreachable"-Kommandos bestehende TCP/IP-Verbindungen abzubrechen.

- Mißbrauch des Kommandos "Fragmentation Needed":

  Das "Fragmentation Needed"-Kommando veranlaßt den Sender, seine Datenpakete kleiner zu machen bzw. sie zu fragmentieren, also zu zerhacken. Durch diese Fragmentierung kann der Angreifer eine Erhöhung der Netzlast provozieren

- Mißbrauch des Kommandos "Source Quench":

  Mit dem "Source Quench"-Kommando kann die Übertragungsrate des Rechnersystems des Senders reduziert werden. Dem Angreifer ist es damit möglich, die Kommunikation zu verlangsamen und dadurch zu stören.

- Mißbrauch des "Redirect"-Kommandos:

  Durch das "Redirect"-Kommando kann ein Angreifer die Routing-Tabellen der Router des Netzes verändert. Z.B. so, daß alle Pakete über seinen Rechner gehen und er dort dann die Daten lesen, manipulieren oder löschen kann.

Durch ein Firewall-System mit ICMP-Rechteverwaltung kann verhindert werden, daß ein Angreifer von außen die oben beschriebenen Angriffe ausführen kann.

2.1.3 Internet-Routing-Angriffe

Der IP-Header des TCP/IP-Protokolls enthält ein Optionenfeld, das für verschiedene Zusatzfunktionen verwendet werden kann. Dabei sind mit Optionen wie "Loose Source Routing" oder "Strict Source Routing" eine Manipulation und Veränderung der Route von außen möglich. Durch z.B. "Strict Source Routing" ist der Angreifer in der Lage, alle zu durchlaufende Verbindungsknoten in einer von ihm vorgegebenen Reihenfolge anzugeben.

Der Angreifer hat dann die Möglichkeit die Pakete auf seinem Rechnersystem zu lesen, manipulieren oder löschen.

Ein Firewall-System bietet die Möglichkeit, eine Rechteverwaltung der Optionen im IP-Protokoll durchzuführen.

 

2.2 Der Paketfilter

2.2.1 Elemente der Firewall Der Paketfilter

Ein Paketfilter kontrolliert und analysiert den ein- und ausgehenden Datenstrom auf der Netzzugangs-, der Netzwerk- und der Transportebene. Die Analyse wird derart durchgeführt, daß die Datenpakete, die durch das physikalische Kabel übertragen werden, aufgenommen und analysiert werden.

Der Paketfilter öffnet jedes einzelne Datenpaket und verifiziert den Inhalt, ob die Daten den definierten Regeln entsprechen. Die Regeln werden so festgelegt, daß nur die absolut notwendige Kommunikation erlaubt ist. Dadurch lassen sich bekannte sicherheitskritische Einstellungen vermeiden. Ein Beispiel wäre die IP-Fragmentierung. Paketfilter werden transparent in das Netzwerk integriert, sie haben also einen Eingangs- und Ausgangs-Port.

Die genaue Arbeitsweise eines Paketfilters stellt sich folgendermaßen dar:

- Es wird eine Überprüfung vorgenommen, von welcher Seite die Pakete empfangen werden.
- Auf der Netzzugangsebene werden der Protokolltyp und die Ziel- und Quell-MAC-Adressen kontrolliert
- In der Netzwerkebene werden die Ziel- und Quell-Adresse und das verwendete Schicht-4-Protokoll, aber auch das Optionsfeld und Flags überprüft. ICMP-Kommandos werden ebenfalls analysiert.
- Auf Transportebene werden die Portnummern (Quell- und Ziel-Port) des UDP/TCP-Protokolls überprüft. Bei TCP findet zusätzlich eine Analyse der Richtung des Verbindungsaufbaus statt.
- Es kann auch überprüft werden, ob Datenpakete in einem bestimmten Zeitraum versendet werden dürfen oder nicht.

Die entsprechenden Analyse- und Prüfinformationen werden einer Rechteliste entnommen, die bei der Anlyse des Netzwerkes und der Programmierung der Firewall aufgestellt wird.

Bei einem Verstoß gegen die aufgestellten Regeln wird dies entsprechend protokolliert und, falls eingerichtet, eine Meldung an den Systemadministrator verschickt. Dadurch wird sichergestellt, daß eine schnelle Reaktion auf das sicherheitsrelevante Ereignis erfolgen kann.

2.2.1.1 Netzzugangsebene

Auf der Netzzugangsebene wird zunächst eine Überprüfung der Ziel- und Quell-MAC-Adresse auf Korrektheit vorgenommen. Als nächstes wird dann das "Datentyp"-Feld analysiert. Dadurch wird genau spezifiziert, mit welchen Kommunikationsprotokollen eine Kommunikation mit der nächst höheren Schicht stattfindet. Also z.B. IPX oder IP. Des weiteren wird bei einer IP-Kommunikaton unterbunden, daß mehrere IP-Pakete in einem MAC-Frames enthalten sind.

2.2.1.2 Netzwerkebene

Auf der Netzwerkebene werden z.B. bei dem IP-Protokoll wieder die Ziel- und Quell-Adresse und das Transportprotokoll überprüft. Dann wird anhand der Ziel- und Quell-Adresse festgelegt, ob eine Kommunikation über den Paketfilter erlaubt ist oder nicht. Im "Protokoll"-Feld wird wiederum analysiert, mit welchem Protokoll eine Verbindung zur nächst höheren Schicht aufgebaut werden darf. Also z.B. TCP oder UDP.

Das "IP-Option"-Feld wird auch analysiert, um z.B. Optionen wie "Source-Routing" zu erlauben oder nicht. Bei ICMP kann das "Type"- also das Kommando-Feld überprüft werden. Dadurch können Kommandos wie Echo Request, Echo Reply, Destination Unreachable usw. erlaubt oder verboten werden.

2.2.1.3 Transportebene

Durch Analyse auf der Transportebene kann eine Überprüfung, im Fall von UDP/TCP, der Portnummern und damit indirekt eine Überprüfung der TCP/IP-Anwendungen erfolgen.

Bei TCP/IP gibt es eine Anzahl von fest definierten Ports, den sogenannten Well-Known-Ports. Diese sind eindeutig einer Anwendung, also z.B. Telnet, FTP, HTTP usw. zugeordnet. Es ist deshalb unvermeidlich, daß eine genaue Analyse der notwendigen Ports durchgeführt wird. Jeder weitere nicht benötigte Port ist unbedingt zu sperren.

Tranportprotokoll TCP

Bei TCP findet durch den Paketfilter eine Überprüfung der Richtung des Verbindungsaufbaus statt. Da TCP ein verbindungsorientiertes Protokoll ist, kann anhand des ACK-Bits im "Code Bits"-Feld eine Überprüfung des Verbindungsaufbaus stattfinden. Beim Verbindungsaufbau wird von TCP das ACK-Bit = 0 gesetzt. Alle weiteren Pakete einer TCP-Verbindung haben dann ACK=1 gesetzt. Dadurch sind TCP-Pakete durch den Paketfilter kontrollierbar.

Transportprotokoll UDP

Da UDP ein verbindungsloses Kommunikationsprotokoll ist, werden UDP-Pakete unabhängig voneinander übertragen. Zwischen einem Aufbau einer Verbindung oder den Paketen innerhalb einer UDP-Verbindung wird nicht unterschieden.

Beim UDP-Paket werden der Quell- und Ziel-Port durch den Paketfilter analysiert. Anhand der Rechteliste wird dann analysiert, um welche Anwendung es sich handelt (z.B. SNMP, TFTP usw.).

Allgemein sollte mit UDP möglichst sparsam umgegangen werden, weil dadurch sonst mehrere Angriffsmöglichkeiten geöffnet werden. Recherchen im Internet haben gezeigt, daß die meisten Angriffs- und Hackertools mit UDP arbeiten.

 

2.2.2 Regeln für den Paketfilter

Um die Regeln für den Paketfilter aufzustellen, sollte zunächst eine sehr detaillierte Analyse des Netzwerkes und der benötigten Anwendungen bzw. Ports unternommen werden.

Für die Implementierung der Filterregelen gibt es zwei Ansätze:

1. Positive Filterregeln:

- Es muß genau festgelegt werden, was erlaubt ist.
- Alles was nicht erlaubt ist, ist verboten.

2. Negative Filterregeln:

- Es ist zunächst alles erlaubt.
- Durch spezielle Einträge wird festgelegt, was nicht erlaubt ist.

Um eine sichere und sinnvolle Implementierung der Filterregeln zu erzielen, empfiehlt sich die Anwendung der Positiven Filterregeln. Mit der Anwedung der Positiven Filterregelen wird sichergestellt, daß kein "Schlupfloch" vergessen wurde. Sollte dann nach der ersten Implementierung irgendeine Anwendung nicht oder nur unvollständig funktionieren, ist es einfacher, die bestehenden Regeln zu erweitern.

2.2.2.1 Feste Regeln

Die Filterregeln werden einmal definiert und implementiert. Wenn dann alles funktioniert, bleiben sie unverändert. Natürlich nur so lange, bis z.B. ein Kommunikationsport nicht mehr benötigt wird, oder ein anderer benötigt wird.

2.2.2.2 Dynmische Paketfilter

Verbindungslose Kommunikationsverbindungen über z.B. UDP können nicht dahingehend analysiert werden, von wem ein Verbindungdaufbau durchgeführt wird.

Dynmische Paket Filter besitzen im Fall der Verwendung des UDP-Kommunikationsprotokolls die Eigenschaft, sich alle nach "außen" geschickte UDP-Pakete anhand der Quell- und Ziel-IP-Adressen und Ports zu merken. Es ist damit möglich, nur die entsprechenden passenden Antworten der virtuellen Verbindung zu merken. Das bedeutet, daß z.B. nur Antwortpakete für einen bestimmten Zeitraum durchgelassen werden.

Es ist damit möglich, einige Anwendungen wie z.B. SNMP sicherer anzubieten.

2.2.2.3 Benutzerorientierte Paketfilter

Paketfilter arbeiten adressorientiert. D.h. sie orientieren sich an den IP-Adressen der einzelnen Rechner. Es gibt aber auch Paketfilter, die sich an den einzelnen Benutzern orientieren. In diesem Fall wird dann durch eine Identifikation und Authentifikation eine Verbindung zum Benutzer hergestellt. Es ist damit möglich, dem einen Benutzer mehr Ports durch den Paketfilter zu öffnen als einem anderen. Die Identifikation und Authentifikation kann sowohl anhand der IP-Adresse als auch auf der Benutzerebene geschehen.

Diese Form des Paketfilter ist bis jetzt leider noch nicht realisiert worden. Verschiedene Hersteller, z.B. die Sinus-Firewall wollen jedoch in eine der zukünftigen Versionen benutzerorientierte Paketfilter implementieren.

2.2.2.4 Protokollierung von sicherheitsrelevanten Ereignissen

Die meisten Paketfilter bieten die Funktion der Protokollierung an. Mit der Protokollierung lassen sich sicherheitsrelevante Ereignisse protokollieren, um sie bei einem versuchten Angriff zur Schwachstellenanalyse zu verwenden.

Für die Protokollierung in einem Logbuch durch den Paketfilter sollten folgende Daten festgehalten bzw. mitprotokolliert werden:

- Datum und Uhrzeit des aufgetretenen Ereignisses.
- Laufzähler für die fortlaufende Zählung der Ereignisse. Damit kann man sich sehr viel Sucharbeit sparen.
- Die Art des sicherheitsrelevanten Ereignisses, das aufgetreten ist.
- IP-Adresse und Portnummer. Das kann sehr nützlich sein, um eventuell einen Angriff zurückverfolgen zu können.
- Eventuell sollten auch die Informationen des IP-Paketes mitprotokolliert werden.

Für das Logbuch gibt es auch verschiedene Modi, wie es betrieben werden kann :

Free-Run-Modus:

  Das Logbuch arbeitet wie eine Endlosschleife. D.h. beim Überlauf wird der älteste Eintrag überschrieben. Es werden so immer nur die aktuellen Ereignisse festgehalten. Es birgt jedoch die Gefahr, daß ein Angreifer sich dadurch unkenntlich machen will, indem er einfach eine Menge an nicht sicherheitsrelevanten Ereignissen erzeugt, um damit seinen eigentlichen Angriff zu verschleiern.

Single-Shot-Modus:

  Bei dieser Art der Protokollierung werden beim Überlauf des Logbuches die neuen Logbucheinträge überschrieben. Die alten Ereignisse bleiben dann erhalten. Dies birgt aber die Gefahr, daß ein Angreifer schon im Vorfeld seines Angriffes den eigentlichen Angriff verschleiern könnte.

Block-If-Full:

  Dieser Modus hat eine sehr hohe sicherheitstechnische Wirkung, jedoch mit einigen Nachteilen. Beim Überlauf des Logbuches wird einfach der Paketfilter zu gemacht. D.h. es kann kein Paket mehr passieren. Natürlich hat es dann ein Angreifer sehr schwer, seine Tat zu verschleiern. Jedoch hat das Ganze den Nachteil, daß nach Möglichkeit immer ein Administrator zur Stelle sein muß, falls das Logbuch voll ist. Es könnte sonst verheerende Folgen haben, wenn z.B. bei einer Nachtschicht das Logbuch voll ist!

 

2.2.3 Mögliche Formen für die Realisierung eines Paketfilters

Es gibt verschiedene Möglichkeiten, einen Paketilter zu implementieren und zu realisieren. Es seien hier nur die drei Wichtigsten genannt.

2.2.3.1 Realisierung im Router

Es gibt einige Router, die einen Paketfilter bereits implementiert haben. Jedoch hat diese Möglichkeit einige entscheidende Nachteile :

- Der Tiefengrad ist niedriger als bei dedizierten Paketfiltern.
- Router bieten, da sie kein Sicherheitsprodukt sind, nur unzureichende Möglichkeiten der Konfiguration und Administration.
- Router bieten meistens nur eine sehr eingeschränkte Protokollierung und Alarmierung über sicherheitsrelevante Ereignisse.
- Router sind eigentlich dazu gedacht, ankommende Pakete möglichst schnell an ihren Zielort zu bringen. Wenn dann zusätzlich noch eine Paketfilterfunktion implementiert wird, sinkt die Performance.
- Router mit integriertem Paketfilter und ordentlicher Performance sind meistens teurer als eine separate Paketfilterung.

 

2.2.3.2 Separate Paketfilter

Separate Paketfilter haben nur eine Aufgabe, Pakete zu filtern. Sie sind deswegen meistens schneller, gründlicher und kostengünstiger als eine Implementierung in einem Router.

Weitere Vorteile sind:

- Durch separate Paketfilter wird eine saubere Abgrenzung zwischen Kommunikations- und Sicherheitsanforderungen getroffen.
- Separate Sicherheitskomponenten sind flexibler als z.B. eine Routerimplementierung.
- Es ist eine vollständige Protokollierung und Alarmierung möglich.

Nachteil:

- Dedizierte Paketfilter sind manchmal teurer als ein Softwareupgrade eines bestehenden Routers.

 

2.2.3.3 Paketfilter im Microchip

Es gibt mittlerweile auch einige Lösungen, die direkt in einem Microchip implementiert sind. Die Vorteile liegen klar auf der Hand. Es damit möglich, z.B. die Filterung schon gleich auf der Netzwerkkarte des Application-Gateway zu vollziehen. Jedoch überwiegen die Nachteile noch erheblich. So ist z.B. die Porgrammierung der Filterregeln etwas komplizierter als bei einer Softwarelösung. Genauso ist auch die Protokollierung und Alarmierung nur eingeschränkt möglich.

 

2.3.3.4 Paketfilter mit Masquerading-Funktionalität

Paketfilter, die die Masquerading-Funktionalität besitzen, verschleiern die interne Netzwerkstruktur. Anstatt, daß die einzelnen Rechner der internen Nertzwerkes sichtbar sind, wird das komplette interne Netz durch nur eine IP-Adresse repräsentiert. Es ist dadurch auch möglich, daß intern private und extern öffentliche IP-Adressen verwendet werden.

Beim IP Masquerading - manchmal auch als PAT (Port and Address Translation) bezeichnet - bildet alle Adressen eines privaten Netzwerkes auf eine einzelne öffentliche IP-Adresse ab. Dies geschieht dadurch, daß bei einer existierenden Verbindung zusätzlich zu den Adressen auch die Portnummern ausgetauscht werden. Auf diese Weise benötigt ein gesamtes privates Netz nur eine einzige registrierte öffentliche IP-Adresse.

Schutzwirkung: Die Rechner im privaten Netzwerk können nicht aus dem Internet angewählt werden.

2.2.4 Anwendungsgebiete eines Paketfilters

Ein Paketfilter alleine genügt natürlich noch nicht, um ein Intranet vollkommen abzusichern.

Es zeigt sich, daß Paketfilter keinen Schutz für Protokolle der oberen Ebenen sind. Es ist z.B. auch möglich, wenn man den Port 25 für SMTP aufmacht, daß dann Implementierungsfehler in den Anwendungen wie Sendmail ausgenützt werden können.

Des weiteren ist ein Schutz der inneren Struktur nicht möglich. Ein Angreifer hat also trotz eines Paketfilters die Möglichkeit, die innere Struktur des Netzwerkes zu analysieren. Ein letzter Nachteil ist, daß die Protokollierung nur bis zur Transportebene vollzogen wird.

Natürlich haben Paketfilter auch einige Vorteile:

- Sie sind transparent. D.h. der Anwender merkt und sieht von dem Paketfilter nichts.
- Die Erweiterung für weitere Protokolle ist relativ einfach implementiert.
- Flexibel für neue Dienste.
- Für verschiedene Protokollfamilien anwendbar (IPX, DECNET, SNA, TCP/IP ...).
- Leichte Realisierung.

 

2.3 Das Application Gateway

Das Application Gateway, auch Proxy genannt, zeichnet sich dadurch aus, daß es die Netze sowohl logisch als auch physikalisch entkoppelt.

In vielen Firewall-Konzepten ist das Application Gateway das einzige vom unsicheren Netz erreichbare Rechnersystem. Es ist deshalb notwenig, daß das Application Gateway besonders geschützt werden muß. Aus diesem Grund wird es auch als Bastion bezeichnet.

Das Application Gateway wird meistens als dual-homed Gateway realisiert. D.h. es besitzt zwei Netzanschlüsse, einen für das sichere Netz, und einen für das unsichere Netz. Damit wird sichergestellt, daß das Application Gateway eine vollständige Kontrolle über alle Pakete hat, die zwischen dem unsicheren und dem sicheren Netz ausgetauscht werden.

Es gibt auch Ansätze, das Application Gateway als single-homed, also mit nur einem Netzanschluß, zu realisieren. Jedoch birgt diese Form folgende Schwachstelle: Ein Angreifer könnte durch irgendwelche Mechanismen versuchen, den Application Gateway zu umgehen.

2.3.1 Ansatz

Über die Netzzugangsebene und den TCP/IP-Treiber empfängt das Application Gateway Pakete mit den entsprechenden Ziel- und Quell-Informationen. Also Ziel- und Quell-Ports.

Wenn dann über einen bestimmten Port eine Verbindung hergestellt werden soll, dann bekommt dem Application Gateway die Aufgabe zu, einen speziellen Stellvertreter dafür bereitzustellen. Somit ist sichergestellt, daß der Anwender nicht direkt mit dem unsicheren Netz kommuniziert, sondern nur über den Proxy also de Stellvertretern.

Die Problematik dabei liegt bei den Proxies. Das Application Gateway muß also für jeden Dienst einen speziellen dafür zugeschnittenen Proxy bereitstellen. Natürlich ergeben sich durch die Spezialisierung entsprechend hohe Sicherheitsanforderungen.

Da die Analyse auf der Kommunikationsebene intensiv möglich ist und der Kontext der Anwendungsdaten für den jeweiligen Dienst klar definiert sind, haben Proxies entscheidende Vorteile :

Kleine überschaubare Module, die bedingt durch ihre Größe sehr fehlerfrei sind. Implementierungsfehler können dann also zu einem hohen Grad ausgeschlossen werden.

2.3.2 Konzept eines Application Gateway

Für jeden möglichen Dienst, der über das Application Gateway möglich ist, muß ein entsprechender Proxy bereitgestellt werden.

Nicht benötigte Dienste, oder Dienste die generell nicht möglich sind, sind nicht durch Proxies auf dem Application Gateway vertreten. Es ist somit möglich diese Dienste in keiner Art und Weise zu verwenden in legaler wie in illegaler Hinsicht.

Aus diesem Grund ist es auch unabdingbar, auf dem Application Gateway so wenig wie möglich Software zu installieren und laufen zu lassen. Denn jedes weitere Softwarepaket kann unter Umständen ein Sicherheitsrisiko darstellen.

Es darf auch unter keinen Umständen eine dynamische Routing-Funktionalität installiert werden. Somit kann sichergestellt werden, daß nicht an den Proxies "vorbeigeroutet" werden kann.

Das Application Gateway besitzt immer eine Verbindung zum Rechnersystem im sicheren Netz. Um dies nicht als "Sicherheitsloch" zu verwenden, bieten Paketfilter die vorher beschriebene Masquerading-Funktionalität an. Somit wird sichergestellt, daß sogar vor dem Application Gateway das interne Netz verborgen bleibt.

2.3.3 Die Proxies

Proxies gibt es für viele Dienste. Die Funktionsweise sei hier aber nur allgemein dargestellt.

1. Verbindungsaufbau zum Application Gateway:

  Über das Application Gateway versucht der Benutzer eine Verbindung von seinem Rechnersystem im sicheren Netz zum Ziel-Rechenersystem im unsicheren Netz aufzubauen. Das Application Gateway nimmt nun den Verbindungsaufbauwunsch an, und fordert den Anwender zu Identifikation und Authentifikation auf.

2. Identifikation und Authentifikation:

  Der Zugreifende gibt nun seine Identifikation ein. Das Application Gteway überprüft nun, ob der Benutzer von seinem Quell-Rechnersystem auf das gewünschte Ziel-Rechnersystem zugreifen darf. Ist dies der Fall, dann verlangt das Application Gateway eine Authentifikation, als z.B. ein Paßwort.
Die Indentifikation und Authentifikation kann bei Firewall-Systemen in vielerlei Hinsicht realisiert werden. Z.B. über Chipkarte oder Paßworten die je nach Sicherheitsanforderungen auch verschlüsselt werden können.

3. Verbindungsaufbau:

  Nach der Identifikation und Authentifikation wird durch den entsprechenden Proxy im Application Gateway eine zweite Verbindung aufgebaut. Nämlich zum gewünschten Ziel-Rechnersystem. In dieser Phase wird auch die NAT (Network Adress Translation) durchgeführt. Der Anwender greift z.B. mit seiner privaten IP-Adresse auf das Application Gateway zu, und das Application Gateway wiederum mit seine offiziellen IP-Adresse auf das gewünschte Ziel-Rechnersystem.

4. Datentransfer:

  Als vorletzte Phase findet nun der Datentransfer statt. Abhängig vom verwendeten Proxy wird der Datentransfer über den Proxy vom Application Gateway protokolliert und die Pakete auf Korrektheit überwacht. Dies geschieht vollkommen transparent für den Anwender.

5. Verbindungsabbau:

  Zuletzt wird die Verbindung zum Application Gateway abgebaut. Der Applicaton Gateway baut dann die Verbindung zum Ziel-Rechnersystem ab, und löscht wenn verwendet, den entsprechenden Eintrag aus der Translations-Tabelle.

Einige Proxies bieten eine sogenannte "Control Monitor"-Funktionalität. Diese Funktionalität ist nicht bei allen Diensten notwendig. Ein typisches Beispiel ist Telnet. Mit Hilfe des "Control Monitors" ist es möglich einen kompletten "Mitschnitt" der Verbindung zu protokollieren. Der Mitschnitt zeichnet dann alle verwendeten Befehle auf. Dadurch ist es möglich, eine Auswertung zu machen. Diese Sicherheitsfunktion hat auch einen nicht zu unterschätzenden Warneffekt.

Leider gibt es auch Dienste, für die keine entsprechenden Proxies angeboten werden. In diesem Fall ist abzuwägen, ob dieser Dinest gesperrt wird, oder ob sogenannte Blind- oder Dummy-Proxies verwendet werden. Blind- bzw. Dummy-Proxies haben nur eine Aufgabe, Datenströme die über einen bestimmten Port ankommen, durchzulassen. Es werden durch Blind- oder Dummy-Proxies sehr "große" Schlupflöcher aufgemacht, deswegen ist von deren Anwendung allgemein abzuraten.

 

2.4 Aufbaukonzepte für Firewall-Systeme

Für die eigentlich Realisierung der Firewall, also das Zusammenspiel aus Paketfilter und Application Gateway, gibt es viele verschiedene Möglichkeiten. Die wichtigsten seien hier genannt :

2.4.1 Ausschließlicher Einsatz eines Paketfilter

Abbildung 2.1: Ausschließlicher Einsatz eines Paketfilters

Der Einsatz von nur einem Paketfilter bietet entscheidende Vorteile, jedoch kann hier noch nicht von einer sicheren Trennung der Netze gesprochen werden.

Die Vorteile sind:

- Kontrolle und Analyse der MAC-Ziel- und MAC-Quell-Adressen,
- Kontrolle und Analyse der IP-Ziel- und IP-Quell-Adressen,
- Rechteverwaltung, also welche Quell- und Ziel-Ports für TCP und UDP erlaubt sind,
- Optionenverwaltung bei IP-Paketen,
- Verwaltung der ICMP-Kommandos,
- Protokollauswertung und Protokollierung der Pakete,
- Alarmierung, falls unautorisierter Zugriff erfolgt.

Der Einsatz von Paketfiltern ist unbedingt zu empfehlen, jedoch nicht ein ausschließlicher Einsatz. Das Sicherheitsrisiko ist für Firmen und öffentliche Institutionen zu hoch.

 

2.4.2 Ausschließlicher Einsatz eines Application Gateways

Abbildung 2.2: Ausschließlicher Einsatz eines Applicaton Gateways

Das Application Gateway in diesem Beispiel wird als Dual-homed Gateway verwendet.Dadurch ist es dem Application Gateway möglich eine vollkommene Kontrolle über alle Datenpakete zu haben.

Die Vorteile eine Application Gateways sind folgende :

- Zugangskontrolle auf Netzwerkebene, d.h. IP-Ziel- und IP-Quell-Adresse werden in den jeweiligen Netzen überprüft,
- Zugangskontrolle auf Benutzerebene,
- Rechteverwaltung, also mit welchen Protokollen darf welcher Dienst verwendet werden,
- Kontrolle auf der Anwendungsebene,
- Dienste werden entkoppelt, es werden also risikobelastete Dienste nicht direkt zwischen den Teilnehmern ermöglicht,
- Protokollierung der Vorgänge,
- Alarmierung, falls nichtautorisierte Zugriffe erfolgen,

Die Anwendung eines reinen Application Gateways zur Absicherung empfiehlt sich in nahezu keinem Fall. Eine Ausnahme wäre, den Application Gateway mit entsprechendem Cache-Speicher auszustatten, um damit z.B. HTML-Seiten zwischenzuspeichern. Jedoch kann man dann nicht von einer Absicherung des Netzes sprechen.

 

2.4.3 Single-homed Application Gateway

Abbildung 2.3: Ausschließlicher Einsatz eines single-homed Applicaton Gateways

Die Realisierung des Application Gateway als single-homed System ist nur in den seltensten Fällen zu empfehlen. Das Application Gateway verfügt nur über eine Netzwerkschnittstelle über die sowohl der eingehende Datenstrom als auch der ausgehende Datenstrom fließt.

Der große Nachteil bei diesem Konzept ist, daß der Application Gateway nicht garantieren kann, daß er alle Daten kontrolliert und analysiert.

 

2.4.4 Paketfilter und single-homed Application Gateway

 

Abbildung 2.4: Einsatz eines single-homed Applicaton Gateways und eines Paketfilters

Die Kombination aus single-homed Application Gateway und Paketfilter bietet den hauptsächlichen Schutz im Paketfilter, während das single-homed Application Gateway optional zusätzlichen Sicherheitsdienst zur Verfügung stellt.

Um einen zusätzliche Sicherheit zu gewähren sollte der Paketfilter so konfiguriert werden, daß jedes ausgehende Paket zum zu schützenden Netz hin nur über den Applicaton Gateway geschickt wird. Wenn dies der Fall ist, dann kann das Applicaton Gateway alle Sicherheitsdienste erbringen.

Abbildung 2.5: Einsatz eines single-homed Applicaton Gateways und eines Paketfilters

Eine "gespiegelte" Konfiguration, also daß der Paketfilter direkt an an das zu schützende Netz, anstatt an das unsichere Netz, angeschlossen ist, ist auf keinen Fall empfehlenswert. Bei dieser Konfiguration könnte sämmtlicher Datenverkehr, welcher aus dem unsicheren Netz kommt, direkt an den Paketfilter geleitet werden und somit das Application Gateway umgehen.

2.4.5 Paketfilter und dual-homed Application Gateway

Abbildung 2.6: Einsatz eines dual-homed Applicaton Gateways und eines Paketfilters

Das Applicaton Gateway ist in dieser Konfiguration durch den Paketfilter vor dem unsicheren Netz geschützt. Das Zusammenspiel aus Paketfilter und dual-homed Application Gateway ermöglicht es, daß kein Datenpaket in irgendeiner Weise die Firewall umgehen kann. Das Maß an Sicherheit hängt hier in erster Linie von der Konfiguration des Paketfilters ab.

Abbildung 2.7: Einsatz eines dual-homed Applicaton Gateways und eines Paketfilters

Natürlich ist es auch möglich Paketfilter und Application Gateway zu tauschen (Abb. 2.7). Dies hat aber einen Nachteil : Das Application Gateway ist direkt mit dem unsicheren Netz verbunden. Dies erfordert ein Höchstmaß an Widerstandsfähigkeit des Application Gateways gegenüber Angriffen aus dem unsicheren Netz.

 

2.4.6 Screened Subnet

Abbildung 2.8: Screened Subnet

Bei dieser Konstellation handelt es sich um den Einsatz von zwei Paketfiltern. Diese zwei Paketfilter sind jedoch so zusammengeschaltet, daß sich zwischen ihnen ein weiteres Netz bildet. Das sogenannte "Screened Subnet". Durch dieses Screened Subnet oder auch Grenznetz wird das zu schützende Netz vollkommen vom unsicheren Netz entkoppelt.

Im Screened Subnet wird mit Hilfe von den zwei Paketfiltern für die Kontrolle der Verbindung gesorgt.Das Screened Subnet wird auch "De-Militarised Zone" genannt (DMZ)

 

2.4.7 Screened Subnet und ein single-homed Application Gateway

Abbildung 2.9: Screened Subnet und ein single-homed Application Gateway

Die Sicherheit in diesem Firewall-Konzept wird vor allem durch die beiden Paketfilter und das Screened Subnet gewährleistet. Das single-homed Application Gateway stellt nur eine zusätzliche Sicherheit da. Die Sicherheit kann noch erhöht werden, wenn der Eingangspaketfilter so konfiguriert ist, daß er alle Daten an das Application Gateway geschickt werden. Weiter ist eine Erhöhung der Sicherheit noch möglich, wenn das Application Gateway seine ausgehenden Daten nur an den Ausgangspaketfilter schickt.

Der Einsatz einer solchen Konfiguration ist dann sinnvoll, wenn sowohl das unsichere als auch das zu schützende Netz etwa gleiche Schutzniveaus haben. Also z.B. Verbindungen von Firmen oder Abteilungen untereinander.

 

2.4.8 Screened Subnet und ein dual-homed Application Gateway

Abbildung 2.10: Screened Subnet und ein dual-homed Application Gateway

Diese Konfiguration einer Firewall bietet einen sehr hohen Sicherheitsstandard an und garantiert auch ein Höchstmaß an Sicherheit.

Die beiden Paketfilter werden so zusammengeschaltet, daß sich zwischen ihnen ein Screened Subnet bildet. Das Application Gateway, daß sich nun in der DMZ befindet und zwei Netzschnittstellen besitzt, kontrolliert nun jedes Datenpaket. Es ist sichergestellt, daß sich kein Datenpaket am Application Gateway "vorbeischleichen" kann.

Die Vorteile einer solchen High-Security Konstellation sind:

- Einfache Regeln, die Anordnung der Elemente ermöglicht eine einfache Definition der Regeln der einzelnen Firewall-Elemente,
- Gegenseitiger Schutz, Die Paketfilter sorgen dafür, daß nicht jeder auf das Application Gateway zugreifen kann,
- Geschachtelte Sicherheit, es wird nicht jede Sicherheitsanforderung an nur ein System gestellt.

Durch den Einsatz von verschiedenen Betriebssystemen läßt sich das Schutzniveau nochmals eröhen. Denn dadurch schließen sich unter Umständen Implementierungsfehler der verschiedenen Betriebssysteme gegenseitig aus.

Der Einsatz dieser Firewall eignet sich dann, wenn man wirklich von einem zu schützenden Netz (Firmennetz) und einem unsicheren Netz (Internet) sprechen kann. Das nicht einzuschätzende Sicherheitsniveau des Internets wird somit gesenkt.

 

2.4.9 Screened Subnet und mehrere dual-homed Application Gateways parallel

Abbildung 2.11: Screened Subnet und mehrere dual-homed Application Gateways parallel

Diese Konfiguration bietet den gleichen Schutz und die gleichen Vorteile wie mit nur einem Application Gateway. Weitere Vorteile sind jedoch, daß die Application Gateways entlastet werden. Dies ist sinnvoll bei sehr hohem Datenaufkommen.

Der Einsatz dieser Konstellation wird auch verwendet, um Redundanz herzustellen. Wenn also z.B. ein Applicaton Gateway ausfällt, dann kann ein zweiter ohne nennenswerte Verzögerung dessen Aufgaben übernehmen. Dies ist vor allem bei einer 24-Stunden-Verfügbarkeit sinnvoll.

2.5 Anschluß von Dienstservern

Der Anschluß von verschiedenen Dienstservern an ein firewall-gesichertes Netz ist keine leichte Aufgabe. Die grundlegende Frage, die sich stellt, ist: Von welchem Netz soll auf die Dienstserver zugegriffen werden ?

Wenn die Informationen auf dem Dienstserver von außen zugänglich gemacht werden sollen, dann ist es zwingend, daß der Dienstserver "näher" zum äußeren unsicheren Netz plaziert wird [1].

2.5.1 DNS-Server

Ein DNS-Server (Domain Name Service) dient zur Umsetzung von Rechnernamen in IP-Adressen und umgekehrt. Weiterhin stellt er Informationen über im Netz vorhandene Rechnersysteme zur Verfügung.

Die Integration eines DNS-Servers in ein Firewall-System erfordert die Berücksichtigung einiger Aspekte.

Aus dem unsicheren Netz dürfen nur minimale Informationen über das zu schützende Netz bekannt gegeben werden. Es soll sichergestellt werden, daß die interne Struktur im verborgenen bleibt.

Eine sinnvolle Konfiguration sieht folgendermaßen aus:

Abbildung 2.12: Integration von DNS-Servern in ein Firewall-System

Wobei hier eine Vereinfachung der Zeichnung vorgenommen wurde. Das Firewall-System mit Screened-Subnet ist vereinfacht dargestellt, da das Firewall-System in den vorherigen Kapiteln ausgiebig erläutert wurde.

Abbildung 2.13: Vereinfachte Darstellung des Firewall-Systems

Im unsicheren Netz und im zu schützenden Netz wird jeweils ein DNS-Server installiert. Die IP-Adresse und Namen des zu schützenden Netzes sind nur dem DNS-Server im zu schützenden Netz bekannt. Der DNS-Server im unsicheren Netz darf die Struktur des zu schützenden Netzes nicht kennen.

Alle DNS-Anfragen vom zu schützenden Netz werden direkt an den "inneren" DNS-Server weitergeleitet und aufgelöst. Sollte der interne DNS-Server eine Anfrage nicht auflösen können, so wird die Anfrage transparent über das Application Gateway an den äußeren DNS-Server weitergeleitet. Die Auflösung bekommt der interne DNS-Server vom Application Gateway geliefert. Es wird damit sichergestellt, daß der interne DNS-Server dem äußeren unbekannt bleibt. Ein Angreifer hat nun nicht die Möglichkeit, durch Abfrage des äußeren DNS-Servers die interne Struktur des Rechnernetzes in Erfahrung zu bringen.

Eine weitere sichere Möglichkeit der Integration eines DNS-Server in ein Firewall-System ist die Installation des DNS-Dienstes auf dem Application Gateway. Die Auflösung der IP-Adressen und Namen aus dem internen Netz wird dann durch das Application Gateway durchgeführt. Adressen aus dem unsicheren Netz (z.B. Internet) werden dann aus dem zu schützendne Netz heraus vom DNS-Server auf dem Application Gateway aufgelöst.

2.5.2 Internet-Server

Für die Integration von Internet-Servern gibt es verschiedene Möglichkeiten. Drei seien hier erläutert:

Abbildung 2.14: Anschluß eines Internet-Servers an ein Firewall-System

Da die Informationen auf einem Internet-Server öffentlich zugänglich gemacht werden sollen, empfiehlt sich der Anschluß des Servers zwischen dem Application Gateway und dem äußeren Paketfilter. Der Internet-Server befindet sich dann im Screened Subnet.

Die zu veröffentlichen Daten werden vom zu schützenden Netz auf den Internet Server zur Abholung gespeichert. Alle Zugriffe auf den Internet Server vom unsicheren Netz aus werden durch den äußeren Paketfilter kontrolliert. Der äußere Paketfilter schützt den Internet Server zusätzlich noch vor Angriffen. Ein Zugriff auf das zu schützende Netz ist durch den Application Gateway und inneren Paketfilter nahezu unmöglich.

Bei der Konfiguration des äußeren Paketfilters ist jedoch zu berücksichtigen, daß nur Dienste erlaubt sind, die für seinen Betrieb unbedingt notwendig sind, also z.B. nur Port 80 (HTTP-Protokoll). Bei der Konfiguration des Internet Servers ist zu berücksichtigen, daß es einem Angreifer unmöglich gemacht wird, auf die Betriebssystemebene zuzugreifen. Es ist also darauf zu achten, daß nur die minimal notwendige Software darauf zu installieren ist, und auf dem Serversystem nur lesender Zugriff erlaubt ist.

Eine zweite Möglichkeit zur Integration eines Internet Servers in ein Firewall System ist der Anschluß über einen separaten Paketfilter. Man schließt den Internet Server über einen separaten Paketfilter an das unsichere Netz. Durch den Paketfilter kann dann, durch entsprechende Konfiguration, sichergestellt werden, daß der Internet Server genügend abgesichert ist.

Eine weitere Möglichkeit zum Anschluß eines Internet Servers ist folgende:

Abbildung 2.15: Anschluß eines Internet Servers an das Application Gateway

Die Möglichkeit, einen Internet Server über einen dritten Netzanschluß am Application Gateway anzuschließen, hat entscheidende Vorteile.

Der Zugriff vom unsicheren als auch vom zu schützenden Netz auf den Internet Server wird von je einem Paketfilter und dem Application Gateway kontrolliert und analysiert.

Diese Anschlußart empfiehlt sich auch für FTP-Server, Anti-Virus-Systeme. Content Filterung und spezielle URL-Filter/Blocker [1].

2.5.3 Intranet-Server

Intranet Server sind Server, auf denen Informationen für das zu schützende Netz zugänglich gemacht werden. Diese Informationen sollten auf keinen Fall vom unsicheren Netz zugänglich sein.

Die erste Idee, die einem dabei einfällt ist, den Intranet Server einfach hinter das Firewall-System, also in das zu schützende Netz zu stellen. Jedoch muß man auch mit Angriffen von innen rechnen. Deshalb ist es sinnvoll, den Intranet Server in das Firewall-System zu integrieren.

Abbildung 2.16: Anschluß eines Intranet-Servers an das Firewall-System

Die Installation des Intranet Servers zwischen Application Gateway und innerem Paketfilter stellt sicher, daß kein Zugriff vom unsicheren Netz auf den Intranet Server möglich ist. Es wird auch sichergestellt, daß Zugriffe von innen auf den Intranet Server nur über den Paketfilter geschehen. Es ist dadurch möglich, den Datenverkehr zum Intranet Server hin, durch den Paketfilter zu kontrollieren und analysieren.

Die Konstellation, den Intranet Server über ein drittes Interface an das Application Gateway anzuschließen, empfiehlt sich ebenfalls. Durch den Anschluß an das Application Gateway kann zusätzlich zur Paketanalyse noch eine Benutzerauthentifikation und Identifikation erfolgen.

2.5.4 Mail-Server

Da das Medium Email immer mehr in unseren Arbeitsalltag einzieht, möchte ich auch dieses Thema nicht auslassen.

Abbildung 2.17: Anschluß eines Mail-Servers an das Firewall-System

Wenn Mails zwischen Rechnersystemen im zu schützenden Netz ausgetauscht werden, dann geschieht dies ausschließlich über den internen Mailserver. Mails, welche mit dem unsicheren Netz ausgetauscht werden, werden vom internen Mailserver über das Application Gateway zum externen Mailserver gesendet. Genauso werden auch von außen kommende Mails über das Application Gateway an den internen Mailserver geschickt und von dort aus weitergeleitet.

Durch das Application Gateway und die Paketfilter kann sichergestellt werden, daß keine Mails direkt vom unsicheren Netz an den internen Mailserver geschickt werden. Die Analyse kann über die IP-Adresse des externen Mailservers geschehen. Um den Datenfluß vom unsicheren Netz in das zu schützende Netz sicherer und überschaubarer zu gestalten, sollte der externe Mailserver nur in bestimmten Zeitabständen Kontakt mit dem internen Mailserver aufnehmen.

 

2.6 Logbuch

2.6.1 Ziele der Protokollierung:

Ziele der Protokollierung sind:

- Erkennung von Sicherheitsverletzungen,
- Beweissicherung der Handlung von Benutzern,
- Abschreckung,

Es ist für ein Sicherheitssystem sehr wichtig, daß man auch erkennt, welche Sicherheitsverletzungen aufgetreten sind. Die Auswertung von Sicherheitsverletzungen kann sowohl für die Administrierbarkeit des Systems als auch für den Benutzer Auswirkungen haben. Zum einen können anhand der Protokolle Sicherheitsmängel analysiert und behoben werden, zum anderen können Benutzer darauf hingewiesen werden, daß sie z.B. einen bestimmten Dienst nicht benutzen dürfen, da sie ihn für ihre Arbeit nicht benötigen.

In diesem Fall kann eine Protokollierung auch zur Beweissicherung, z.B. vor einem Arbeitsgericht, verwendet werden. Die Beweissicherung kann auch dann verwendet werden, wenn z.B. eine fremde Institution Servicearbeiten durchführt.

Das dritte Ziel der Protokollierung ist ein psychologisches und wird meistens unterschätzt. Die Abschreckung. Viele Benutzer sind vorsichtiger im Umgang mit dem Rechnernetz, wenn sie wissen, daß alle ihre legalen und illegalen Aktivitäten protokolliert werden.

 

2.6.2 Wichtige Ereignisse, die protokolliert werden sollten:

Auf einem Firewall-System können sehr viele unterschiedliche Ereignisse auftreten. Es ist jedoch nicht notwendig, daß alle Ereignisse protokolliert und in einem Logbuch festgehalten werden. Es ist z.B. nicht relevant ob Benutzer X eine Mail an Benutzer Y schickt.

Wichtiger sind sicherheitsrelevante Ereignisse [1]:

Fehlerhafte Identifikations- und Authentifikationsprozesse:

Hier werden alle fehlgeschlagenen Authentifikationsprozesse festgehalten. Mögliche Ursachen hierfür sind :

- Verwendung von falschen Benutzernamen und Passwörtern,
- Fehlerhafte oder falsche kryptographische Authentifikationsprotokolle.

Verstoß gegen die Sicherheitspolitik:

Hier wird festgehalten, ob ein Verstoß gegen das Regelwerk der Sicherheitspolitik vorliegt. Dies könnten z.B. folgende sein:

- Versuch, unerlaubte Kommandos zu verwenden (z.B. "del" bei einer FTP-Verbindung),
- Versuchte Nutzung eines nicht erlaubten Dienstes,
- Versuchte Nutzung zu einer nichterlaubten Zeit.

Erkennen eines Fehlverhaltens der Firewall-Software und -Hardware:

Die einzelnen Firewall-Elemente erkennen eigenständig, ob sie noch einwandfrei funktionieren. Also z.B.:

- Die Software befindet sich in einem undefinierten Zustand,
- Ein Hardwaredefekt wurde entdeckt (z.B. Festplatte).

Erkennung von Angriffsversuchen auf das Firewall-System selbst:

Die Firewall erkennt selbst, ob ein Angriff stattgefunden hat. Beispiel:

- Fehlerhafte Authentifikation als "root" auf dem Firewall-System über eine Konsole,
- Überschreiten des Füllstandes des Logbuches.

 

2.6.3 Auswertung des Logbuches:

Die Auswertung der protokollierten Ereignisse sollte in regelmäßigen Abständen geschehen. Es nützt nichts, wenn man die tollsten Ereignisse protokolliert, dann jedoch nicht auswertet.

Die Überprüfung der Ereignisse kann sowohl stichprobenartig als auch komplett geschehen. Sie sollte von einem Administrator oder einem Sicherheitsbeauftragen geschehen, der sich in der Sicherheitspolitik und im Sicherheitskonzept lückenlos auskennt.

 

2.6.4 Schutz der Protokolldaten:

Protokolldaten kommen als Beweismittel bei straf- bzw. arbeitsrechtlichen Ermittlungen in Frage. Aus diesem Grund sind die ordnungsgemäß erfolgte Speicherung sowie die zweifelsfreie Echtheit bzw. Unversehrtheit der Protokolldaten in den Logbüchern für ihre Verwertbarkeit von besonderer Bedeutung.

Dazu muß verhindert werden, daß Angreifer in der Lage sind, die Protokollierung auszuschalten, die Protokolldaten in Logbüchern zu löschen oder sie inhaltlich zu manipulieren. Dies kann durch folgende Schutzmechanismen erreicht werden [1]:

- Im Sicherheitskonzept muß durch Zugangskontrolle und Rechteverwaltung dafür gesorgt werden, daß nur Berechtigte in der Lage sind, auf die Protokolldaten zuzugreifen.
- Die Protokolldaten aller Firewall-Elemente sollten über einen vertrauenswürdigen Pfad an das Security Management geschickt werden, damit sie vor ihrer Auswertung und endgültigen Speicherung nicht verändert werden können. Also nach Möglichkeit die Protokolldaten ins zu schützende Netz schicken.

 

2.6.5 Datenschutzaspekte:

Protokolldaten unterliegen dem Datenschutz und dürfen nicht mißbraucht werden. Dies wird durch folgende Paragraphen aus dem BDSG (Bundesdatenschutzgesetz) deutlich:

5 Datengeheimnis

Den bei der Datenverarbeitung beschäftigten Personen ist untersagt, personenbezogene Daten unbefugt zu verarbeiten oder zu nutzen (Datengeheimnis). Diese Personen sind, soweit sie bei nicht-öffentlichen Stellen beschäftigt werden, bei der Aufnahme ihrer Tätigkeit auf das Datengeheimnis zu verpflichten. Das Datengeheimnis besteht auch nach der Beendigung der Tätigkeit fort.

31 Besondere Zweckbindung

Personenbezogene Daten, die ausschließlich zu Zwecken der Datenschutzkontrolle, der Datensicherung oder zur Sicherstellung eines ordnungsgemäßen Betriebes einer Datenverarbeitungsanalage gespeichert werden, dürfen nur für diese Zwecke verwendet werden.

In Firmen ist es zu empfehlen, mit dem Personal- oder Betriebsrat eine Betriebsvereinbarung über die Auswertung der Protokolldaten des Firewall-Systems auszuarbeiten, sofern natürlich nicht schon eine für die allgemeinen Protokolldaten existiert. Durch eine solche Vereinbarung kann sichergestellt werden, daß das Instrument der Protokollierung nicht zweckentfremdet wird, etwa für die Durchführung einer Verhaltens- oder Leistungskontrolle der Mitarbeiter. In dieser Vereinbarung sollten die zulässigen Auswertungen der Protokolldateien sowie die Art ihrer Nutzung festgelegt werden. Also wer darf diese wie, mit welchen Hilfsmitteln, zu welchem Zweck auswerten. [1]

 

2.7 Verhalten bei Angriffsversuchen

2.7.1 Anzeichen für einen Angriff bzw. Angriffsversuch :

- Protokollierung im Logbuch:

  Der Angriff wurde erfolgreich im Logbuch bzw. in den Log-Dateien protokolliert. Zu erkennen ist dies an mehreren erfolglosen Identifikations- und Authentifikations-Versuchen. Je nach System kann die Quelle, also z.B. der Domainname oder die IP-Adresse des Angreifers, aus den Log-Dateien entnommen werden.

- Lücken im Logbuch:

  Lücken im Logbuch zeigen einen erfolgreichen Angriff auf. Der Angreifer hat versucht, seinen Angriff zu vertuschen, in dem er seine Aktivitäten aus den Log-Dateien gelöscht hat.

- Ungewöhnliche Login-Zeiten:

  Eine ungewöhnliche Login-Zeit ist in der Regel ein Anzeichen für einen Angriff. Wenn z.B. ein Login-Vorgang in der Nacht oder am Wochenende vorkommt obwohl z.B. die Institution geschlossen ist, dann hat der Angreifer vermutlich Identifikationund Authentifikation eines "realen" Benutzers erlangt.

- Ungewöhnliche CPU-Lasten:

  Bevor ein Firewall-System in den laufenden Betrieb "eingehängt" bzw. installiert wird, ist eine sorgfältige Prüfung unter Laborbedingungen notwendig. Dort soll auf jeden Fall auch die CPU-Belastung unter verschiedenen Bedingungen festgehalten werden. Zu hohe CPU-Lasten deuten auf einen Flushing- oder Bombardement-Angriff. D.h. ein Angreifer versucht durch sehr hohe Netzlasten und daraus resultierenden CPU-Lasten das System zum Absturz zu bringen. Aber auch zu niedrige CPU-Lasten können Anzeichen für einen Angriff sein. Wenn die CPU-Last sehr niedrig ist, dann könnte es einem Angreifer unter Umständen gelungen sein, einen Bypass zu legen. Also um das Firewall-System herum.

- Ungewöhnliche Plattenkapazität:

  Wenn die freie Plattenkapazität drastisch sinkt und die Ursache dafür ein riesiges Logbuch ist, dann kann das auch ein Hinweis auf einen Angriff sein. Der Angreifer versucht dann so viele wie möglich "normale" Logbucheinträge zu erzeugen. Der Grund dafür ist, der Angreifer will damit seinen Angriff, der im Logbuch protokolliert worden ist, durch den Löschmechanismus der Log-Dienste vertuschen.

- Falsche Prüfsummen:

  Die Systemdateien auf einem Firewall-System sollten mit verschiedenen Prüfsummen notiert werden. Also z.B. die Dateigröße oder einen CRC. Wenn dieser Wert vom Normalwert abweicht, ist das ein Hinweis, daß ein Angreifer an den Dateien manipuliert hat, um sich z.B. einen Bypass zu legen.

- "Geisterhafte" Neukonfiguration:

  Sollte sich die Konfiguration des Firewall-Systems ohne ersichtlichen Grund geändert haben, also z.B. neue geöffnete Ports bei den Paketfiltern oder zusätzliche unbekannte Benutzer im Identifikations-Modul, dann ist das auch ein Hinweis auf einen erfolgreichen Angriff.

- Start von Diensten und Daemonen:

  Eine Überprüfung der notwendigen laufenden Dienste und Daemonen auf einem Firewall-System sollte regelmäßig vorgenommen werden. Wenn es einem Angreifer z.B. gelingt, den Routing-Dienst zu aktivieren, dann hat er sich damit einen Bypass geschaffen.

- Systemabstürze:

  Ein Absturz des Firewall-Systems kann ein Anzeichen für einen Angriff sein. Ein Angreifer könnte z.B. durch eine Überlastung des Systems einen Absturz provoziert haben. Es kann sich bei einem Absturz aber auch um einen ganz "normalen" Softwarefehler handeln.

Zusammenfassung der Angriffsanzeichen:

Anzeichen für einen Angriff

erfolgreich

nicht erfolgreich

Protokollierung im Logbuch

?

?

Lücken im Logbuch

ü

-

Ungewöhnliche Login-Zeiten

ü

-

Ungewöhnliche CPU-Lasten

?

?

Ungewöhnliche Plattenkapazität

?

?

Falsche Prüfsummen

ü

-

"Geisterhafte" Neukonfiguration

ü

-

Start von Diensten und Daemonen

ü

-

Systemabstürze

?

?

Tabelle 2.1: Zusammenfassung der Angriffsanzeichen

2.7.2 Vorgehensweise bei einem (vermuteten) Angriff:

In der Überschrift wurde mit Absicht das Wort "vermuteten" Angriff in Klammer gestellt. Denn wie sich bei der Analyse der Angriffsanzeichen herausgestellt hat, ist es oft nicht eindeutig, ob es sich nun um einen Angriff oder eine "unglückliche Verkettung von Zufällen" handelt.

2.7.2.1 Protokollierung im Logbuch:

Wenn ein Angriff im Logbuch auftaucht, dann sollte die Analyse des Protokolls aufzeigen können, ob der Angriff nun abgewehrt wurde oder nicht.

Sollte der Angriff nicht abgewehrt worden sein, dann ist eine komplette Überprüfung des Sicherheitskonzeptes notwendig. Also ob z.B. auf einen bestimmten Dienst verzichtet werden kann oder nicht.

Im Fall, daß der Angriff abgewehrt worden ist, sollte auf jeden Fall eine weitere und genaue Beobachtung der Aktivitäten erfolgen. In der Regel versucht ein Angreiffer es nach einem erfolglosen Angriff nochmals. Ganz unerschrockene Administratoren schicken auch mal eine Email an das Angreifer-System, mit der Bitte, in Zukunft solche Attacken zu unterlassen. Wobei bei dieser Methode der Nutzen fraglich ist. Entweder schreckt der Angreifer dadurch wirklich zurück, oder wird noch aggressiver und wird mehrere neue Angriffe versuchen.

2.7.2.2 Lücken im Logbuch:

Sollten Lücken im Logbuch auftauchen, dann ist das nie ein gutes Zeichen. Dem Angreifer ist es dann nämlich gelungen, in das System einzudringen und die Log-Datei zu editieren. Das Firewall-System zeigt dann also massive Sicherheitslücken auf. Es ist auf jeden Fall eine Überprüfung des Sicherheitskonzeptes und der Firewall-Konfiguration notwendig.

2.7.2.3 Ungewöhnliche Login-Zeiten:

Wenn Login-Versuche oder gar erfolgreiche Login-Versuche zu ungewöhnlichen Zeiten registriert worden sind, dann kann davon ausgegangen werden, daß sich der Angreifer eine falsche Identität verschafft hat. Also z.B. das Passwort eines Benutzers herausgefunden oder vielleicht sogar von ihm bekommen hat.

Als Maßnahme empfiehlt sich hier eine Überprüfung der Benutzer und ggf. eine Vergabe von neuen Passwörtern.

2.7.2.4 Ungewöhnliche CPU-Lasten:

Wenn ungewöhnliche CPU-Lasten auftreten, dann ist Eile angesagt. Die Überprüfung der CPU-Lasten wird während des Betriebes vollzogen.

Sollten sehr hohe Lasten aufgezeigt werden, dann ist eine sofortige Überprüfung der Log-Dateien notwendig. Sollte die Analyse des Logbuches keinen Erfolg bringen, dann kann man z.B. mit einem Netzanalysator die Notwendigkeit der Daten überprüfen. Handelt sich um einen Bombardement-Angriff, dann werden meistens unnütze und wirre Daten verwendet. Im Fall eines solchen Angriffs ist sofort der Datenverkehr zu unterbinden, um einem unkontrollierbaren Absturz vorzubeugen.

Der Datenverkehr ist auch bei ungewöhnlich niedrigen CPU-Lasten zu unterbinden. Wenn es ersichtlich ist, daß einige Benutzer eine Netzverbindung haben, die CPU-Last niedrig ist und es im Logbuch keine neuen Einträge gibt, dann ist es sicher, daß der Angreifer sich einen Bypass verschafft hat. Es stehen ihm damit alle Tore offen. Eine Überprüfung des Sicherheitskonzeptes und der Konfiguration sollte danach auf jeden Fall erfolgen.

2.7.2.5 Ungewöhnliche Plattenkapazität:

Eine ungewöhnliche Plattenkapazität ist meistens auch auf eine ungewöhnliche Logbuchgröße zurückzuführen. Da bei den meisten Firewall-Systemen eine maximale Größe für das Logbuch angegeben werden kann, versucht der Angreifer nun diese auszunützen. Er provoziert sehr viele "normale" Einträge, um dadurch das Firewall-System soweit zu bringen, daß sein Angriff vom System automatisch gelöscht wird.

Genauer gesagt sollte hier nicht die Plattenkapazität sondern die Änderung der Plattenkapaziät bzw. der Logbuchgröße in Abhängigkeit von der Zeit überprüft werden.

Als Gegenmaßnahme ist hier eine genauere Überprüfung der Logbucheinträge in der Zukunft zu empfehlen. Meistens versucht ein Angreifer sein "Glück" ein weiteres mal.

2.7.2.6 Falsche Prüfsummen:

Eine Überprüfung der Prüfsummen, also z.B. Dateigröße oder CRC, sollte in regelmäßigen Abständen erfolgen. Wenn sich Änderungen in den Prüfsummen herausstellen, dann kann das ein Hinweis auf einen erfolgreichen Angriff oder auf einen Virus sein.

Als erste Maßnahme ist ein kompletter Virencheck zu empfehlen. Wenn es kein Anzeichen für einen Virenbefall gibt, dann muß die Analyse weiter geführt werden.

Erstens, um welche Dateien handelt es sich. Sind es Systemdateien, dann hat ein Angreifer z.B. eine "gepatchte" Version eines Programms eingespielt, um damit freien Zugang zum System zu haben. Aber wenn ein Angreifer schon die Möglichkeit hat, Systemdateien zu überspielen bzw. zu ändern, dann sind noch andere Sicherheitslücken im System vorhanden.

Zweitens, was wurde verändert. Sind z.B. Konfigurations-Dateien zu Gunsten des Angreifers verändert worden, dann ist der Urzustand sehr leicht wieder herstellbar. Aber auch in diesem Fall hatte der Angreifer schon die Möglichkeit, auf das System zuzugreifen.

Als Maßnahme ist hier eine Überprüfung des Sicherheitskonzeptes notwendig und natürlich auch eine Wiederherstellung des Urzustandes. Also z.B. Einspielen eines Backups.

2.7.2.7 "Geisterhafte" Neukonfiguration:

Eine "geisterhafte" Neukonfiguration hat die gleichen Auswirkungen und Maßnahmen wie eine falsche Prüfsumme. Jedoch mit dem Unterschied, daß es sich um einen cleveren Angreifer handelt, der es geschafft hat, Dateien zu ändern, aber die Prüfsummen in einem "normalen" Zustand zu belassen.

2.7.2.8 Start von Diensten und Daemonen:

Eine regelmäßige Überprüfung der laufenden Dienste und Daemonen sollte auch erfolgen. Bei Unstimmigkeiten muß der Start im Systemprotokoll mit den Ereignissen im Logbuch verglichen werden. Eine Überprüfung des Sicherheitskonzeptes und der Firewall-Konfiguration ist auch hier zu empfehlen. Schließlich hat es ein Angreifer bis auf die Systemebene geschafft.

2.7.2.9 Systemabstürze:

Die Analyse von Systemabstürzen ist die schwierigste. Zum einen kann ein Systemabsturz z.B. durch ein volles Logbuch oder einen Fehler im Betriebssystem verursacht werden. Zum anderen kann ein Angreifer mit massiven Angriffen das System zum Abstürzen bringen.

Eine wichtige Maßnahme nach einem Systemabsturz ist dabei, daß das System wieder hochfährt, jedoch ohne irgendwelchen Netzzugang. Manche Angreifer warten genau auf eine solche Lücke. Denn wenn z.B. ein NT-System hochfährt, dann werden für kurze Zeit alle Netzwerkverbindungen kurzgeschlossen. D.h. ein Angreifer hätte in diesem kurzen, aber ausreichenden Augenblick Zeit, einen Virus, Trojaner oder einen Sniffer zu installieren.

Aus diesem Grund sollten nach einem Absturz alle Netzverbindungen unterbunden und das Gesamtsystem analysiert werden. Gegebenenfalls ist dann auch wieder eine Überprüfung des Sicherheitskonzeptes und der Konfiguration anzuraten.

3. Firewall konkret

Da nun in den vorherigen Kapiteln ausführlich die Konstellation, Konfiguration und Arbeitsweise von Firewall-Systemen erläutert wurde, wird nun eine konkrete Implementierung für die Fachhochschule Aalen Fachbereich Elektronik/Informatik vorgestellt.

 

Das Sicherheitskonzept und der Netzaufbau der FH-Aalen kann aus Sicherheitsgründen nicht publiziert werden !

 

3.3 Hardware- und Softwareauswahl

3.3.1 Hardwareauswahl

Ein Firewall-System sollte nach Möglichkeit transparent für den Benutzer sein. Unter Transparenz versteht man, daß der Benutzer keine umständlichen und langwierigen Anmeldungen vornehmen muß. Weiter wird unter Transparenz verstanden, daß die Firewall den Anwender nicht in der Bandbreite einschränkt. Um jedoch eine volle Bandbreite zu garantieren, muß die Firewall mit leistungsfähiger Hardware ausgestattet sein.

Für das High-Security-Firewall-System des Fachbereiches Elektronik/Informatik wurde folgende Hardwareausstattung gewählt :

Abbildung 3.4: Hardwareauswahl der High-Security-Firewall

Die beiden Paketfilter haben die gleiche Hardwareausstattung. Sie verfügen jeweils über einen schnellen Pentium III Prozessor, 64 MB Arbeitsspeicher, einer 13 GB Festplatte, einem Grafiksystem und jeweils 2 Netzwerkkarten.

Das Application Gateway ist mit einer leistungsfähigeren Hardware ausgestattet, da er als Stellvertreter fungiert, und somit doppelt so viele Verbindungen offen halten muß wie ein Paketfilter. Es wird über den Application Gateway auch die Identifikation und Authentifikation vorgenommen.

Das Application Gateway hat deshalb auch ein Dual-Motherboard mit 2 Pentium III Prozessoren, 256 MB Arbeitsspeicher, einer 40 GB Festplatte, einem Grafiksystem und 3 Netzwerkkarten spendiert bekommen.

Die Anbindung der einzelnen Komponenten bzw. Rechner erfolgt über 100 MBit/s im Full-Duplex-Betrieb.

3.3.2 Softwareauswahl

Als zu installierende Software wird Linux in der Minimalinstallation verwendet, eine Distribution von SuSE in der Version 6.4.

Linux ist für diese Aufgabe nahezu prädestiniert. Es gibt zwar noch kein Betriebssystem, das hinsichtlich der Kommunikationsanforderungen evaluiert und zertifiziert worden ist, jedoch kann bei einem Open-Source Betriebssystem wie LINUX eine eigene Anpassung erfolgen.

Die Eignung von Linux für ein Firewall-Betriebssystem wird auch durch die Mitteilung des Heise-Tickers vom 14. Januar 2000 deutlich: [1]

"NSA macht Linux zum Firewall-System

Die amerikanische National Security Agency (NSA) läßt ein renommiertes Firewall-Konzept auf Linux portieren. Die Datenschutzbehörde hat der Secure Computing Corporation den Auftrag erteilt, deren patentierte Technik zum Domain Type Enforcement (DTE) auch auf das Betriebssystem Linux zu portieren. DTE ordnet die Netzwerk-Interface von Firewall-Rechnern in getrennte Domains an, die nur durch Proxies miteinander verbunden sind.

Security-Server dieses Konzepts sind unter dem Markennamen Sidewinder bekannt geworden. Bislang verwendeten diese Rechner ein modifiziertes BSD-Unix als Betriebssystem. Der NSA-Auftrag weist aber darauf hin, daß Linux in zunehmendem Maße an Vertrauen gewinnt, so daß es auch für den Einsatz bei Sicherheitssystemen für Industrie und Behörden interessanter wird."

 

3.4 Aufteilung der Subnetze

Das hier vorgestellte und aufgebaute Firewall-System besitzt ein Screened Subnet (siehe 2.4.6 Screened Subnet). Die Vorteile des Screened Subnet wurden bereits in einem vorherigen Kapitel erläutert.

Die interne Netzstruktur, also das zu schützende Netz, besitzt ebenfalls einen privaten IP-Adressbereich.

Die genaue Aufteilung sieht dann wie folgt aus :

Abbildung 3.5: Subnetz Aufteilung der Firewall

 

3.5 Installation und Konfiguration

3.5.1 Paketfilter 1

3.5.1.1 Linux-Installation

Die Installation der SuSE Linux Distribution auf dem Paketfilter 1 geschieht folgendermaßen:

- Linux von CD1 booten,
- Beim Bootprompt "manual" innerhalb der ersten 3 Sekunden eingeben,
- Es wird dann die textorientiere Installation gestartet
- Installation/System starten wählen,
- Installation/Update starten,
- Das Installations- und Konfigurationstool Yast1 wird gestartet,
- Linux neu installieren wählen,

Die Festplatte wie folgt partitionieren :

Geräte-datei

Partitionstyp

Spur, von-bis

Kapazität [MB]

Dateityp

Mount-Point

hda1

Primär

1-26

200

Linux native

/

hda2

erweitert

27-1583

12213

-

-

hda5

logisch

27-52

200

Linux native

/root

hda6

logisch

53-183

1024

Linux native

/usr

hda7

logisch

184-314

1024

Linux native

/var

hda8

logisch

315-331

128

Linux native

/home

hda9

logisch

332-248

128

Linux swap *

-

 

 

 

 

 

 

 


* Der Typ der Swap-Partition muß auf Swap (Typ 83) gesetzt werden.

Tabelle 3.2: Partitionierung der Festplatte des Paketfilters 1

- Konfiguration "SuSE Minimal System" laden,
- Installation starten,
- Im Hauptmenü:

Folgende Einstellungen bei der Installation wählen:

- Standard Kernel,
- Bootdiskette erzeugen (ist immer sinnvoll)
- Lilo konfigurieren: ja
- Append-Zeile für Kernel-Parameter: vga=0c301
- Lilo im Master-Boot-Sektor installieren
- Lilo Wartezeit: 1 Sekunde
- mit F4 neue Boot-Konfiguration mit Namen lin anlegen, dabei Linux booten und bootende Partition /dev/hda1 wählen,
- Zeitzone : MET
- Hardware Uhr: lokale Zeit
- Rechnername: paketfilter1
- Domäne: fbefire1
- TCP/IP: Echtes Netzwerk
- Rechner als DHCP-Client betreiben: Nein
- Typ des Netzwerks: eth0
- IP-Adresse des Rechners: 141.18.253.69
- Netzmask: 255.255.255.0
- Adresse default Gateway: 141.18.253.254
- Inetd starten: ja (vorerst)
- Portmapper starten: nein
- News from-Adresse festlegen: paketfilter1.fbefire1
- Auf Nameserver zugreifen: ja
- Als Nameserver folgende IP-Adressen eintragen: 141.18.1.12 und 141.18.1.12
- Auswahl Netzwerkkarte: 3Com 3c59x/3c90x
- Sendmail Konfiguration: Rechner mit permanenter Netzverbindung (SMTP)
- Passwort für root: *******
- Modem einrichten: nein
- Maus einrichten: ja (PS/2-Maus)
- openssh und sec nachinstallieren: ja

Nach erfolgreicher Installation wird nun die zweite Netzwerkkarte installiert. Um diese zu installieren authentifiziert man sich mit root und gibt dann yast ein.

Yast ist ein Konfigurations- und Installationstool von Suse, welches einem die Administration erleichtert.

Yast meldet sich dann mit folgendem Bildschirm :

Abbildung 3.6: YaST-Hauptmenü

Um die zweite Netzwerkkarte zu installieren wählt man mit den Pfeiltasten das Menü Administration des Systems. Diese Menü mit Return öffnen. Dann den Punkt Netzwerk konfigurieren und abschließend auf Netzwerk Grundkonfiguration.

Abbildung 3.7: YaST-Netzwerk Grundkonfiguration

Nachdem die Netzwerk Grundkonfiguration angewählt wurde, erscheint ein neues Fenster :

Abbildung 3.8: YaST-Netzwerk Konfiguration

Zuerst muß die zweite Netzwerkkarte einen Namen bekommen. Dazu geht man auf die erste Netzwerkkarte (diese hat den Namen eth0 !) und vergibt dann mit F7 den Namen eth1. Mit F6 wird dann folgende IP-Adresse vergeben: 141.18.69.1 Maske 255.255.255.0 und kein Gateway. Mit F4 die Karte aktivieren. Mit F10 die Einstellungen abspeichern.

Linux weiß nun, daß es eine zweite Netzwerkkarte gibt. Jedoch muß für diese Karte noch ein passender Treiber installiert werden. Dies geschieht über das Menü Hardware im System integrieren und nachfolgend auf Netzwerkkarte konfigurieren. Es erscheint dann folgendes Menü:

Abbildung 3.9: YaST-Auswahl der Netzwerk-Karte

Unter Typ des Netzwerkes ist eth1 einzutragen. Die Art der Netzwerk-Karte ist dieselbe wie die erste Netzwerkkarte, nämlich 3COM 3c59x/3c90x. Optionen zum Laden des Moduls werden nicht benötigt. Mit <Weiter> speichern.

Nachdem die zweite Netzwerkkarte installiert ist, wird YaST mit YaST beenden verlassen.

Ein Neustart des Systems mit shutdown r now ist ratsam.

3.5.1.2 Linux-Kernel Konfiguration und Compilierung

Um einen speziell auf einen Paketfilter zugeschnitten Kernel zu haben, muß dieser neu konfiguriert und neu compiliert werden. Dazu startet man YaST und wählt unter Einstellungen zu Installtion den Punkt Installtionsquelle auswählen. YaST gibt dann einige Auswahlmöglichkeiten, wobei hier die Installation von CD-ROM zu wählen ist.

Nachdem YaST nun die CD-ROM gemountet hat, wählt man im YaST Hauptmenü Installation festlegen/starten. Es wird nun ein neuer Bildschirm gezeigt, hier ist Konfiguration ändern/erstellen zu wählen.

Für die Konfiguration und Compilierung des Kernels sind folgende Pakete notwendig :

- lx_suse aus der Serie d,
- make aus der Serie s,

Nachdem die Installation der Pakete abgeschlossen ist, wechselt man mit dem Befehl

 

cd /usr/src/linux

in das Kernel-Verzeichnis. Dort ist folgendes Kommando aufzurufen :

  make menuconfig

Es wird dann das Kernel-Konfigurations-Menü gezeigt :

Abbildung 3.10: YaST-Auswahl zur Kernel Neucompilierung

Folgende Funktionalitäten werden nicht benötigt und sind auf Disable zu setzen :

- Plug & Play support --- > ISA Plug & Play Support,
- SCSI Support,

Eine andere Funktionalität ist zu aktivieren bzw. einzubinden:

- Netzkartentreiber 3C590/3C900,

Als grundlegende Sicherheitseinstellungen für einen Paketfilter sollten folgende Funktionen aktiv sein. Diese gelten nur als allgemeine Richtlinie und können von System zu System variieren. [3]

- loadable module support,
- kernel daemon support,
- networking support,
- network firewalls,
- TCP/IP networking,
- Network firewalls,
- IP: forwarding/gatewaying,
- IP: syn cookies,
- IP: firewall packet logging,
- IP: masquerading,
- ICMP: masquerading,
- IP: accounting,
- IP: drop source routed frames.

Nach der Konfiguration des Kernels ist dieser abzuspeichern. Folgende Kommandos schließen dann die Compilierung ab :

  make dep
  make bzImage
 

lilo

Ob der Kernel erfolgreich konfiguriert und compiliert wurde, läßt sich nach einem weiteren Neustart mit shutdown r now ersehen.

3.5.1.3 Deaktivieren von nicht benötigten Daemonen und Diensten

In der Standard-Installation von Linux sind viele Daemonen und Dienste aktiviert, die es ermöglichen , sich an den Paketfiltern "vorbeizuschmuggeln".

Aus diesem Grund sind folgende Dateien zu editieren, um Änderungen darin vorunehmen :

Die Datei /etc/rc.config :

Bei der /etc/rc.config-Datei handelt es sich um die zentrale Konfigurationsdatei, in der praktisch alles konfiguriert werden kann. Folgende Werte sind zu ändern :

- IP_FORWARD="yes"

  (IP Forwarding ermöglicht ein Weiterleiten von Paketen zwischen mehreren Netzwerkkarten)

- START_INETD="no"

  (Der INET-Daemon ist ein zentraler Daemon, der alle Netzwerkdienste steuert)

- SMTP="no"

  (Es wird sicherlich keiner auf die Idee komme, seine Mails auf einem Paketfilter zu lesen)

- NFS_SERVER="no"

  (Es sollte auch kein NFS >Net File System< laufen)

- START_ROUTED="no"

  (Der Route-Daemon erlaubt eine dynamische Router-Funktionalität, die hier ebenfalls nicht erwünscht ist)

- START_FW="no"

  (FW bedeutet hier die SuSE eigene Firewall. Bei der SuSE Firewall handelt es sich um einen Paketfilter, der über eine zentrale Datei konfiguriert wird. Leider kann die Konfiguration nicht ausführlich genug gemacht werden, deshalb deaktivieren)

Die Datei /etc/inetd.conf :

Ein Datei, in der angegeben werden kann, welche Netzwerkdienste aktiviert werden sollen oder nicht.Zur Sicherheit sind hier alle Einträge mit "#" zu kommentieren und damit zu deaktivieren.

Die Datei /etc/rc.config/firewall.rc.config :

Sollte die SuSE-Firewall bei der Minimal-Installation mitinstalliert worden sein, dann ist auch in dieser Datei sicherheitshalber jeder Eintrag mit "#" zu kommentieren und damit zu deaktivieren.

Anmerkung : Bei der SuSE Linux 6.4 Komplett-Version ist die SuSE-Firewall bei der Minimal-Installation nicht installiert. Im Gegensatz dazu wird die SuSE-Firewall bei der Minimal-Installation von SuSE Linux 6.4 Evaluation Version mitinstalliert.

3.5.1.4 Installation von ipchains

Die Installation des Paketfilter-Programms ipchains wird auch über YaST vorgenommen.

Dazu ist YaST mit YaST aufzurufen, die Installations-CD zu mounten und das Paket ipchains in der Serie sec zu installieren.
ipchains kann so installiert werden, daß es bei jedem Neustart automatisch seine Konfiguration aus einer Konfigurations-Datei liest. Jedoch ist diese Einstellung nicht sinnnvoll.
Die hier beschriebene Lösung eines Paketfilters geht den Weg, daß ipchains über ein Shell-Skript aufgerufen wird. Die Gründe hierfür sind folgende:

Sicherheit:

  Sollte ein Übeltäter einen erfolgreichen Angriff auf das Firewall-System bzw. die Paketfilter ausgeführt haben und die Paketfiltert sind dabei abgestürzt, dann macht es keinen Sinn, die Maschinen einfach neu zu starten. Es sollte auf jeden Fall eine Überprüfung der Filterregeln stattfinden.

Übersichtlichkeit:

  In einem Shell-Skript kann die Konfiguration Schritt für Schritt nachvollzogen bzw. im Falle eines Angriffes kontrolliert und überprüft werden.

 

3.5.1.5 Grundlagen und Funktionsweise von ipchains

Linux 2.2 ipchains ist eine komplette Neuentwicklung des Linux IPv4 Firewall Codes, der hautpsächlich auf den Quellen von BSD 4.4 mit all seinen herausragenden Eigenschaften beruht. Es ist eine Portierung des ipfw Toolkit, welches aus der Feder von Darren Reed stammt, der auch bei den Portierungen auf Solaris 2.5/2.6/2.7 und den BSD Derivaten NetBSD, OpenBSD und FreeBSD mitgewirkt hat. [3]

Der Paketfilter beherrscht in der Standardkonfiguration drei Arten von Regeln. Diese Regeln werden chains genannt und sind : input, output und forward. Wenn ein Paket auf dem Paketfilter-Rechner eintrifft, dann ist dafür die input chain zuständig. Abgehende Datenpakete werden durch die output chain behandelt. Pakete, die von einem Netz-Interface zum nächsten geleitet werden sollen, sind in der forward chain beschrieben.

Eine chain ist eine Liste von Regeln, auch rules genannt. Jede Regel überprüft den Inhalt des Headers des Paketes und entscheidet, was dann zu tun ist. Ob das Paket z.B. abgelehnt oder weitergeleitet wird.

Ein Datenpaket, daß in einer chain ankommt, wird mit jeder Regel dieser chain verglichen und überprüft. Am End der chain angelangt entscheidet der Kernel darüber, welche policy für das Datenpaket zutrifft. policis können folgende sein :

ACCEPT Läßt das Paket in den Paketfilter.
REJECT Schickt ein ICMP Host unreachable reply an den ursprünglichen Sender, läßt dabei das Paket aber nicht in den Paketfilter
DENY Läßt das Paket nicht in den Paketfilter und gibt keine Meldung an den ursprünglichen Sender aus.
MASQ Läßt das Paket in den Paketfilter, maskiert es aber.

Für eine Übersicht aller ipchains-Befehle ist die "IP Chains Quick Reference"-Karte von Scott Bronson zu empfehlen, welche im Postscript-Format dem ipchains-Paket beiliegt.

Weitere Einblicke in ipchains liefert einem auch die Datei /usr/src/linux/net/ipv4/ip_fw.c ausführliche Kenntnisse. Jedoch sollte man über fundierte C-Kenntnisse verfügen.

Die Funktionsweise von den chains und den policies wird anhand der nachfolgenden Diagramme erläutert :

Abbildung 3.11: Schematische Funktionsweise der Input- und Output-Chains

Erklärung zu Abbildung 3.11:

Es handelt sich um eine schematische Darstellung der Input- und Output-Chains.

Jedes abgehende Paket wird durch jede einzelne Regel der Output-Chain geprüft und wenn alle Regeln in Ordnung sind, dann darf das Paket die Netzwerk-Karte passieren.

Die ankommenden Pakete werden durch jede einzelne Regeln der Input-Chain geprüft und dürfen erst dann weiterverarbeitet werden, wenn alle Regeln in Ordnung sind.

Die Forward-Chain funktioniert nach dem selben Prinzip. Die einzelnen Pakete werden durch die Forward-Regeln geprüft und wenn alle Regeln in Ordnung sind, dann wird das Paket "geforwardet", also weitergeleitet.

Abbildung 3.12: Schematische Funktionsweise der Policies

Erklärung zu Abbildung 3.12:

In der Abbildung 3.12 kann man sehr leicht die Funktionsweise der policies erkennen. Jedes IP-Paket wird in den chains überprüft. Wenn eine Regeln nicht zutrifft, dann wird auf die nächste Regel geprüft. Dies wird solange fortgeführt, bis das Ende einer chain erreicht wird.

Am Ende trifft dann die Default-Policy zu.

Wichtig: Immer die erste zutreffende Regel entscheidet über ein Paket. Wenn eine Regel zutrifft, dann werden alle nachfolgenden übergangen. Es ist deshalb besonders wichtig, daß alle Regeln nur einmal definiert werden und daß nachträgliche Regeln an den entsprechenden Stellen eingeführt werden.

 

3.5.1.6 Aufbau der Filterregeln

Für die Aufstellung der Filterregeln benötigt man als erstes eine Liste der notwendigen Ports und deren Umfang, also in welchen Adressbereichen diese Ports gelten (siehe Tabelle 3.1).

Als zweites sollte man sich Gedanken über die voreingestellte Policy machen.

Um die Konfiguration mit einem Shell-Skript zu realisieren ist eine beliebige Text-Datei mit einem Texteditor zu erstellen. In dieser Textdatei werden dann die einzelnen ipchains-Befehle nacheinander eingetragen.

Start des Shell-Skriptes geschieht durch:

  Shell Text-Datei

also z.B.:

  bash paketfilter1.conf

Wichtige Parameter von ipchains:

-A [chain] Hängt die Regel an das Ende der Chain [chain] an.
-I [chain] Fügt die Regel vor den Anfang einer Chain ein.
-i interface Die Netzwerkkarte, für die diese Regel gilt.
-p protokoll IP-Protokoll, für das diese Regel gilt.
-y Das SYN-Flag einer TCP-Nachricht muß gesetzt sein, jedoch darf das ACK-Flag nicht gesetzt sein.
-s adresse[port] Absender-Adresse eines Pakets. Wenn [port] angegeben wurde, dann gilt diese Regel nur für den angegebenen Port.
-d adresse[port] Empfänger-Adresse eines Pakets. Wenn [port] angegeben wurde, dann gilt diese Regel nur für den angegebenen Port.
-j policy Gibt die Polcy dieser Regel an.
-l Jedes mal, wenn diese Regel zutrifft, wird ein Eintrag in /var/log/messages gemacht.
-P [chain] Einstellen der default policy.

Festlegung der Default-Policy:

Die Default-Policy legt fest, was mit einem Paket passieren soll, wenn keine Regel zutrifft.

Eine sinnvolle Einstellung ist, daß alle ankommenden Pakete verworfen werden. Die ipchains-Befehle hierfür sind :

  ipchains P input DENY
  ipchains P ouput ACCEPT
 

ipchains P forward ACCEPT

Sicherheitstechnisch gesehen, kann man auf einem Paketfilter nur alle eingehenden Paketet verschließen. Ein Paketfilter sendet ja keine selbst erzeugten Pakete aus. Genauso mit der Forward-Chain.

Aktivieren des Loopback-Interfaces:

Auf das Loopback-Interface sollte alles zugelassen werden.

 

ipchains A input i lo j ACCEPT

 

ipchains A output i lo j ACCEPT

ICMP-Nachrichten:

ICMP-Nachrichten entstehen als Reaktionen auf bestimmte Fehler oder als Informationsquelle.

Die wichtigsten ICMP-Nachrichtentypen sind:

0 echo-reply Antwort auf ein ping,
3 destination-unreachable Zielhost bzw. Zielnetz ist nicht erreichbar,
4 source-quench Flusskontrolle,
5 redirect Nachricht über Wegstrecken,
8 echo-request Ein abgehendes ping,
11 time-exceeded Nachricht, daß die TTL eines Paketes abgelaufen ist,
12 parameter-problem Der Header des IP-Paketes enthält ungültige Werte

Die Regeln für ICMP-Nachrichten sehen folgender Maßen aus:

- Erlaube Ping (ICMP Typ 0 und 8)
- Erlaube destination-unreachable (ICMP Typ 3)
- Erlaube source-quench (ICMP Typ 4)
- Erlaube time-exceeded (ICMP Typ 11)
- Erlaube parameter-problem (ICMP Typ 12)
- Erlaube keine redirect-Nachrichten (ICMP Typ 5)

Die Variablen $ext_interface und $int_interface bezeichnen die IP-Adressen des Interface zum unsicheren und zu schützenden Netz des Paketfilters.

  # ICMP Echo-Reply
  ipchains -A input -i $ext_interface -s $ext_ip/0 0:0 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 0:0 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 0:0 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 0:0 -p ICMP -j ACCEPT
   
  # ICMP Echo-Request
  ipchains -A input -i $ext_interface -s $ext_ip/0 8:8 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 8:8 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 8:8 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 8:8 -p ICMP -j ACCEPT
   
  # ICMP Destination-Unreachable
  ipchains -A input -i $ext_interface -s $ext_ip/0 3:3 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 3:3 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 3:3 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 3:3 -p ICMP -j ACCEPT
   
  # ICMP Source-Quench
  ipchains -A input -i $ext_interface -s $ext_ip/0 4:4 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 4:4 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 4:4 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 4:4 -p ICMP -j ACCEPT
   
  # ICMP Time-Exceeded
  ipchains -A input -i $ext_interface -s $ext_ip/0 11:11 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 11:11 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 11:11 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 11:11 -p ICMP -j ACCEPT
   
  # ICMP Parameter-Problem
  ipchains -A input -i $ext_interface -s $ext_ip/0 12:12 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 12:12 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 12:12 -p ICMP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/0 12:12 -p ICMP -j ACCEPT

ICMP-Parameter-Problem wird durch die Default-Policy abgefangen.

 

Highports:

Sogenannte Highports, also Ports im Bereich von 1024 bis 65535, werden von verschiedenen Diensten verwendet. Als Beispiele sind FTP, DNS, HTTP und viele weitere zu nennen.

Regel für die High-Ports:

- Erlaube TCP High-Port-Anfragen von überall auf das externe und interne Interface in der input-Chain.
- Erlaube UDP High-Port-Anfragen von überall auf das externe und interne Interface in der input-Chain.

Die Befehle im einzelnen:

  ipchains -A input -i $ext_interface -s $ext_ip/0 1024:65535 -p TCP -j ACCEPT
  ipchains -A input -i $ext_interface -s $ext_ip/0 1024:65535 -p UDP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 1024:65535 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 1024:65535 -p UDP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 1024:65535 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 1024:65535 -p UDP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 1024:65535 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 1024:65535 -p UDP -j ACCEPT

HTTP (Port 80):

HTTP wird für das World Wide Web verwendet. Client und Server bauen dazu ganz normale TCP-Verbindungen auf. Diese geschehen über den TCP Port 80 und TCP Highports.

Die Regel lautet:

- Erlaube TCP Port 80 vom externen Netz über das externe Interface,
- Erlaube TCP Port 80 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 80:80 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 80:80 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 80:80 -p TCP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/0 80:80 -p TCP -j ACCEPT

Der Parameter /0 hinter der IP-Adresse gibt die Zahl der zu maskierenden Bits an. Dabei wird von links, also vom signifikantesten Bit, an gezählt.

SSL (Port 443):

SSL (Secure Socket Layer) dient dem abgesicherten, verschlüsselten Zugang zu WWW-Seiten. Um SSL zuzulassen, lauten die Regeln wie folgt:

- Erlaube TCP Port 443 vom externen Netz über das externe Interface,
- Erlaube TCP Port 443 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 443:443 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 443:443 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 443:443 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 443:443 -p TCP -j ACCEPT

DNS (Port 53):

Der DNS (Domain Name Service) dient zur Umsetzung zwischen IP-Adressen und Rechner-Namen. DNS verwendet sowohl UDP als auch TCP auf Port 53 und auf den Highports.

Die Regeln für DNS lauten :

- Erlaube TCP Port 53 vom FH-Netz über das externe Interface,
- Erlaube TCP Port 53 vom FH-Netz über das interne Interface,
- Erlaube UDP Port 53 vom FH-Netz über das externe Interface,
- Erlaube UDP Port 53 vom FH-Netz über das interne Interface,

Befehle im einzelnen:

  ipchains -A input -i $ext_interface -s $ext_ip/16 53:53 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/16 53:53 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/16 53:53 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/16 53:53 -p TCP -j ACCEPT
   
  ipchains -A input -i $ext_interface -s $ext_ip/16 53:53 -p UDP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/16 53:53 -p UDP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/16 53:53 -p UDP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/16 53:53 -p UDP -j ACCEPT

POP3 (Port 110):

Email braucht fast jeder, deshalb sollten auch für diese Anwendung die Ports geöffnet werden. POP ist ein Protokoll zum Abholen von Mails. POP benutzt ausschließlich TCP-Verbindungen.

Die Regeln für POP lauten:

- Erlaube TCP Port 110 vom externen Netz über das externe Interface,
- Erlaube TCP Port 110 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 110:110 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 110:110 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 110:110 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 110:110 -p TCP -j ACCEPT

SMTP (Port 25):

Das Gegenstück zu POP und IMAP ist SMTP (Simple Mail Transport Protocol). Es dient zum Senden von Mails. Es benutzt ausschließlich TCP-Verbindungen.

Die Regeln für SMTP lauten:

- Erlaube TCP Port 25 vom externen Netz über das externe Interface,
- Erlaube TCP Port 25 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 25:25 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 25:25 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 25:25 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 250:25 -p TCP -j ACCEPT

NNTP (Port 119):

Das Network News Transfer Protocol, kurz auch News genannt, ist ein technologischer Nachfolger von UUCO. Es ermöglicht das Verteilen, Anfordern, Laden und Verschicken von Artikeln auf der Basis eines zuverlässigen, streamorientierten Übertragungsprotokolls also z.B. TCP.

Die Regeln für NNTP lauten:

- Erlaube TCP Port 119 vom externen Netz über das externe Interface,
- Erlaube TCP Port 119 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 119:119 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 119:119 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 119:119 -p TCP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/0 119:119 -p TCP -j ACCEPT

FTP (Port 20/21):

Das File Transfer Protocol dient zum Transferieren von Daten zwischen einem FTP-Client und einem FTP-Server. FTP benutzt im Gegensatz zum Trivial File Transfer Protocol (TFTP) ausschließlich TCP-Verbindungen. Die Übertragung von Steuersignalen wird mit Hilfe von Telnet-Kommandos abgewickelt.

FTP bereitet jedoch Probleme, wenn es durch eine Firewall benutzt wird. Mehr zu diesem Problem steht im Anhang A 3.

Die Regeln für FTP lauten:

- Erlaube TCP Port 20 und Port 21 vom externen Netz über das externe Interface,
- Erlaube TCP Port 20 und Port 21 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 20:21 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 20:21 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 20:21 -p TCP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/0 20:21 -p TCP -j ACCEPT

Forward-Chain:

Bei der Konfiguration des Paketfilter 1, darf kein Maskerading verwendet werden. Es soll ja von außen auf die DMS zugegriffen werden können.

Es ist dann ein "einfaches" Forwarding möglich.

Die Befehle für das Forwarding im einzelnen :

  ipchains -A forward -i $int_interface -s $int_ip/0 -d $ext_ip/0 -j ACCEPT
 

ipchains -A forward -i $ext_interface -s $ext_ip/0 -d $int_ip/0 -j ACCEPT

Um die Konfiguration abschließen zu können, muß nur noch das Forwarding-Modul im Kernel aktiviert werden.

Dies geschieht durch den Befehl :

 

echo 1 > /proc/sys/net/ipv4/ip_forward

à Die ganze Konfigurationsdatei für den Paketfilter 1steht im Anhang.

 

3.5.2 Paketfilter 2

Das hier vorgestellte Firewall-System besteht aus zwei Paketfiltern. Die Installation und Konfiguration des ersten Paketfilters wurde in den vorherigen Kapiteln bereits ausführlich erläutert und erlärt. Die Installation und Konfiguration des zweiten Paketfilters ist im Prinzip genau gleich wie die des ersten. Es sind aber an einigen Punkten andere Werte bzw. Parameter anzugeben. Einer dieser Parameter sind z.B. die IP-Adressen.

Für den Paketfilter 2 werden folgende IP-Adressen vergeben :

  Netzwerkschnittstelle eth0 192.168.1.254
  Netzwerkschnittstelle eth1 192.168.150.254

Die Netzwerkschnittstelle eth0 ist diejenige, die an das zu schützende Netzwerk angeschlossen wird. Dagegen wird die Netzwerkschnittstelle eth1 an die DMZ bzw. an den Application Gateway angeschlossen.

Die Konfiguration der Filterfunktion unterscheidet sich nur in wenigen Punkten, von der des Paketfilter 1.Es werden deshalb die Filterfunktionen nicht in aller Ausführlichkeit erklärt.

Als erstes sind die Einträge für die Protokolle HTTP, SSL und FTP nicht einzutragen. Für diese Protokolle werden Highports verwendet, die schon abgedeckt sind.

Ein weiterer wichtiger Punkt ist die Maskierung. Paketfilter 2, also jender, der das sicherer Netz mit dem Application Gateway verbindet, muß ein Maskierfunktion haben. Damit wird sichergestellt, daß die Rechner, welche sich im zu schützenden Netz befinden, der Außenwelt verborgen bleiben.

Die Befehle für die Maskierung im einzelnen:

  ipchains -A forward -i $int_interface -s $int_ip/0 -d $ext_ip/0 -j MASQ
  ipchains -A forward -i $ext_interface -s $ext_ip/0 -d $int_ip/0 -j MASQ

Es wurde hier eine Maskierung in beide Richtungen gewählt. Damit wird sichergestellt, daß die Konfiguration der IP-Adressen im zu schützenden Netz unabhängig von der Konfiguration des Application Gateways ist. D.h. bei einer Umstellung der internen IP-Adressen muß lediglich der Paketfilter 2 neu konfiguriert werden.

Nachteil: Es ist damit für das Application Gateway keine Authentifikation anhand der IP-Adresse möglich.

à Auch das Konfigurationsskript für den zweiten Paketfilter steht komplett im Anhang.

3.5.3 Das Application Gateway

Das Application Gateway ist das Herzstück der Firewall. Im Application Gateway werden die Benutzerauthetifikation und die Stellvertretung der einzelnen Protokolle durch Proxies durchgeführt.

3.5.3.1 Installation des Application Gateway

Als Betriebssystem auf dem Application Gateway wird auch Linux verwendet.

Die Installation der SuSE Linux Distribution auf dem Application Gateway geschieht folgendermaßen:

- Linux von CD1 booten,
- Warten, bis die Installationsauswahl erscheint, dann Yast 2 wählen.
- Die Partitionierung von Yast2 automatisch durchführen lassen,
- Minimale Installation wählen.
- Als Kernel ist der SMP-Kernel zu wählen, dieser aktiviert den zweiten Prozessor,
- Lilo im Master-Boot-Record installieren,

Es wird hier die Installation mit dem Yast 2 durchgeführt. Versuche haben gezeigt, daß eine Installation mit dem Yast 1 an verschiedenen, nicht rekonstruierbaren Stellen scheitert. Eine Web-Recherche hatgezeigt, daß der momentan eingesetzte Kernel noch Probleme mit IDE-Festplatte, die größer als 32 GB sind, hat.

Die Grund-Installation mit Yast 2 kann diese Problem umgehen.

Alle weiteren nachträglichen Schritte werden aber dann wieder mit dem Yast1 durchgeführt.Hier nun die Stichpunkte, die nach der Grund-Installation noch mit dem Yast 1 druchzuführen sind:

- Rechnername: proxy
- Domäne: fbefire1
- TCP/IP: Echtes Netzwerk
- Rechner als DHCP-Client betreiben: Nein
- Typ des Netzwerks: eth0
- IP-Adresse des Rechners: 141.18.69.250
- Netzmask: 255.255.255.0
- Adresse default Gateway: 141.18.69.1
- Inetd starten: nein
- Portmapper starten: nein
- News from-Adresse festlegen: proxy.fbefire1
- Auf Nameserver zugreifen: ja
- Als Nameserver folgende IP-Adressen eintragen: 141.18.1.12
- Auswahl Netzwerkkarte: 3Com 3c59x/3c90x
- Sendmail Konfiguration: Rechner mit permanenter Netzverbindung (SMTP)
- Passwort für root: *******
- Modem einrichten: nein
- Maus einrichten: ja (PS/2-Maus)
- openssh und sec nachinstallieren: ja
-  

Es ist weiterhin auch die zweite und dritte Netzwerkkarte zu installieren. Die IP-Konfiguration ist folgende :

Device

IP-Adresse

Subnetmask

Gateway

eth0

141.18.69.250

255.255.255.0

141.18.69.1

eth1

192.168.100.1

255.255.255.0

141.18.69.1

eth2

192.168.150.1

255.255.255.0

141.18.69.1

Tabelle 3.3: IP-Parameter des Application Gateway

 

3.5.3.2 Linux-Kernel Konfiguration und Compilierung

Um einen speziell auf einen Application Gateway zugeschnitten Kernel zu haben, muß dieser neu konfiguriert und neu compiliert werden. Dazu startet man YaST und wählt unter Einstellungen zu Installtion den Punkt Installtionsquelle auswählen. YaST gibt dann einige Auswahlmöglichkeiten, wobei hier die Installation von CD-ROM zu wählen ist.

Nachdem YaST nun die CD-ROM gemountet hat, wählt man im YaST Hauptmenü Installation festlegen/starten. Es wird nun ein neuer Bildschirm gezeigt, hier ist Installation ändern/erstellen zu wählen.

Für die Konfiguration und Compilierung des Kernels sind folgende Pakete notwendig :

- lx_suse aus der Serie d,
- make aus der Serie s,
- linux aus der Serie d,

Nachdem die Installation der Pakete abgeschlossen ist, wechselt man mit dem Befehl

 

cd /usr/src/linux

in das Kernel-Verzeichnis. Dort ist folgendes aufzurufen :

  make menuconfig

Es wird dann das Kernel-Konfigurations-Menü gezeigt :

Abbildung 3.13: YaST-Auswahl zur Kernel Neucompilierung

Folgende Funktionalitäten werden nicht benötigt und sind auf Disable zu setzen :

- ISA Plug & Play Support,
- SCSI Support,

Eine andere Funktionalität ist zu aktivieren bzw. einzubinden:

- Netzkartentreiber 3C590/3C900,

Als grundlegende Sicherheitseinstellungen für einen Application Gateway sollten folgende Funktionen aktiv sein. Diese gelten nur als allgemeine Richtlinie und können von System zu System variieren. [3]

- loadable module support,
- kernel daemon support,
- networking support,
- TCP/IP networking,
- IP: forwarding/gatewaying,
- IP: syn cookies,
- IP: accounting,
- IP: drop source routed frames.

Nach der Konfiguration des Kernels ist diese abzuspeichern. Folgende Kommandos schließen dann die Compilierung ab :

  make dep
  make bzImage
 

lilo

Ob der Kernel erfolgreich konfiguriert und compiliert wurde, läßt sich nach einem weiteren Neustart mit reboot ersehen.

3.5.3.3 Deaktivieren von nicht benötigten Daemonen und Diensten

In der Standard-Installation von Linux sind viele Daemonen und Dienste aktiviert, die es ermöglichen , sich an den Paketfiltern "vorbeizuschmuggeln".

Aus diesem Grund sind folgende Dateien zu editieren, um Änderungen darin vorunehmen :

Die Datei /etc/rc.config :

Bei der /etc/rc.config-Datei handelt es sich um die zentrale Konfigurationsdatei, in der praktisch alles konfiguriert werden kann. Folgende Werte sind zu ändern :

- IP_FORWARD="no"

  (IP Forwarding ermöglicht ein Weiterleiten von Paketen zwischen mehreren Netzwerkkarten)

- START_INETD="yes"

  (Der INET-Daemon ist ein zentraler Daemon, der alle Netzwerkdienste steuert)

- SMTP="no"

  (Es wird sicherlich keiner auf die Idee komme, seine Mails auf einem Paketfilter zu lesen)

- NFS_SERVER="no"

  (Es sollte auch kein NFS >Net File System< laufen)

- START_ROUTED="no"

  (Der Route-Daemon erlaubt eine Router-Funktionalität, die hier ebenfalls nicht erwünscht ist)

- START_FW="no"

  (FW bedeutet hier die SuSE eigene Firewall. Bei der SuSE Firewall handelt es sich um einen Paketfilter, der über eine zentrale Datei konfiguriert wird. Leider kann die Konfiguration nicht ausführlich genug gemacht werden, deshalb deaktivieren)

Die Datei /etc/inetd.conf :

Ein Datei, in der angegeben werden kann, welche Netzwerkdienste aktiviert werden sollen oder nicht.Zur Sicherheit sind hier alle Einträge mit "#" zu kommentieren und damit zu deaktivieren, außer den FTP-Dienst. Der FTP-Dienst wird zur Remote-Administration verwendet.

3.5.3.4 Einstellen der statischen Routen

Das Application Gateway muß genau Bescheid wissen, wie es in welche Netze kommt. Dies wird in der Datei /etc/route.conf eingestellt.

Der Inhalt der Datei sieht folgendermaßen aus:

192.168.150.0 0.0.0.0 255.255.255.0 eth2
192.168.100.0 0.0.0.0 255.255.255.0 eth1
192.168.1.0 192.168.150.254 255.255.255.0 eth2
141.18.69.0 0.0.0.0 255.255.255.0 eth0
default 141.18.69.1    

Man gibt genau das Netz an, welches über ein bestimmtes Interface mit einem bestimmten Gateway zu erreichen ist.

3.5.3.5 Installation von DeleGate

Als Proxy-Software wurde eine Produkt mit dem Namen DeleGate ausgewählt. DeleGate hat eintscheidende Vorteile gegenüber anderen Proxy-Paketen.

DeleGate ist als erstes einmal frei verfügbar (unter http://www.delegate.org). Es ist ein Open-Source-Paket, daß für verschiedenste Platformen verfügbar ist. DeleGate bietet darüber hinaus einen vielzahl an Proxies, die sehr flexibel konfigurierbar sind.

Die aktuellste Version ist unter ftp://ftp.delegate.org/pub verfügbar. Jedoch hat man erst dann Zugriff, wenn man sich als anonymous mit einer exisiterenden Email-Adresse anmeldet.

Um DeleGate auf einer Maschine zum laufen zu bringen, muß es kompiliert werden. Die Entwickler von DeleGate haben es einem so einfach wie nur möglich gemacht, das Paket zu erstellen.

Nach dem entpacken von DeleGate in ein eigenes Verzeichnis ( /delegate ) ist in diesem einfach nur noch make aufzurufen. Der Rest wird dann von selbst erledigt. Um jedoch dieses Paket kompilieren zu können muß vorher das Suse-Paket linux aus der Serie d installiert sein (s.o.).

Nach dem Compilieren erhält man einer Datei unter /delegate/src mit dem Namen delegated. Dies ist das eigentliche Programm.

Das Programm delegated ist der komplette Proxy. Er wird nur mit entsprechenden Parametern aufgerufen.

 

3.5.3.6 Wichtige DeleGate-Parameter

DeleGate verfügt über eine Vielzahl an Parametern, die nahezu keine wünsche offen lassen, was die Konfiguration betrifft. Hier sollen jedoch nur die wichtigsten erläutert werden, die auch bei der Konfiguration verwendet werden.

Eine ganaue Beschreibung alles Parameter wird mit jedem DeleGate-Paket mitgeliefert.

-P[PORT] Dieser Port wird von DeleGate überwacht.
SERVER=prot DeleGate fungiert als Proxy für das angegebene Protokoll.
ADMIN=email Dies ist der Deafult-Administrator, an den auch Emails im Fehlerfall gesendet werden.
ROUTE=[IP] Dies ist der Standard-Gateway für DeleGate. DeleGate erkennt dann anhand der IP-Adresse, über welches etzwerkinterface es seine eigene Anfragen stellt.
RES_NS=[IP] IP-Adresse des Nameservers, den DeleGate verwendet, um Namensauflösungen zu machen.
RELIABLE=[IP] DeleGate nimmt nur Anfragen entgegen, die von dieser IP-Adresse, IP-Adressen oder diesem Adressbereich kommen.
CACHE=[opt] Mit dieser Option kann man DeleGate veranlassen, Daten zu cachen, also zwischenzuspeicher.
MAXIMA=[opt] Damit werden z.B. Default-Zeiten, oder maximale Anzahl an FTP-Sitzungen eingestellt.
DGROOT=[vrz] Das Basis-Directory für alle DeleGate-Dateien.
VARDIR=[vrz] Basis-Directory für Log- und Cache-Dateien.
CACHEDIR=[vrz] Verzeichnis für Cache-Dateien.
LOGDIR=[vrz] Verzeichnis für Log-Dateien.
ERRORLOG=[vrz] Verzeichnis für Fehler-Log-Dateien.
WORKDIR=[vrz] Verzeichnis, indem sich DeleGate befindet.
ACTDIR=[vrz] Verzeichnis für temporäre Dateien.

3.5.3.7 DeleGate HTTP-Proxy

Einen HTTP-Proxy kann man über den Aufruf von folgendem starten. Die angegebenen Parameter werden anschließend erklärt.

 

/delegate/src/delegated P8080 SERVER=http CACHE=do ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

DeleGate hört nun auf Port 8080 nach dem Protokoll http. Der Administrator ist der root-User auf dem Application Gateway. Also Gateway soll DeleGate 141.18.69.1 verwenden. Für Namensauflösungen schaut DeleGate beim 141.18.1.12 nach. Erlaubt sind Zugriffe nur aus dem 192.168.150.0er Netz. Das Basisverzeichnis ist / . Das Verzeichnis für Log-Dateien und Fehler-Log-Dateien ist /var/log. Das Arbeitsverzeichnis, also wo sich DeleGate befindet, ist /delegate. Das temporäre Verzeichnis ist /tmp und das Basisverzeichnis für Logdateien ist /var.

3.5.3.8 DeleGate DNS-Proxy

Ein DNS-Proxy unter DeleGate wird mit folgendem Aufruf gestartet:

 

/delegate/src/delegated P53 SERVER=dns ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

Die Konfiguration eines DNS-Proxies unterscheidet sich nur unwesentlich von der eines HTTP-Proxies. Lediglich der "Lauschport" und der Servertyp wird verändert. Das selbe gilt auch für die nun folgenden drei weiteren Proxies.

3.5.3.9 DeleGate POP-Proxy

Aufruf für einen POP-Proxy :

 

/delegate/src/delegated P110 SERVER=pop ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

3.5.3.10 DeleGate SMTP-Proxy

Aufruf für einen SMTP-Proxy :

 

/delegate/src/delegated P25 SERVER=smtp ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

3.5.3.11 DeleGate NNTP-Proxy

Bei der Konfiguration eines NNTP-Proxies verhält sich DeleGate anders als bei den vorher beschriebenen Proxies. Der NNTP-Proxy von DeleGate ist kein Stellvertreter, der die Anfragen an den Zielserver stellt, sondern es wird die komplette Newsgroup auf dem Proxy-Server gespeichert. Es ist dazu notwendig, daß die zu benutzenden Newsgroups bei der Konfiguration angegeben werden. Die DeleGate.ORG arbeitet daran, daß man auch nachträglich verschiedene Newsgroups über die Remote-Administrations-Funktionalität einbinden kann. Hier eine Beispielkonfiguration mit der DeleGate- und der Microsoft-Newsgroup:

 

/delegate/src/delegated P119 SERVER=nntp MOUNT="= nntp://news.delegate.org" MOUNT="= nntp://msnews.microsoft.com" ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

Die Benutzung mehrerer Newsgroups geschieht durch die Angabe weiterer MOUNT-Parameter.

3.4.3.12 DeleGate FTP-Proxy

Ein FTP-Proxy ist unter DeleGate wie folgt zu konfigurieren. Die Parameter für einen FTP-Proxy unter DeleGate sind:

 

/delegate/src/delegated P8021 SERVER=ftp ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

Mögliche Zugangsberechtigungen, wie z.B. schreiben auf einen FTP-Server, sollten bei dem entsprechenden FTP-Server geschehen. Dadurch wird der Umgang mit dem Firewall-System für den Benutzer erleichtert.

3.5.3.13 Umgang mit Konfigurations-Dateien

Bei sehr komplizierten Konfigurationen von DeleGate verliert man schnell den Überblick über die ganzen Parameter. DeleGate bietet deshalb die Möglichkeit, anstatt der Befehlszeilenparameter seine Konfiguration auch aus Dateien zu lesen.

DeleGate wird dann wie folgt aufgerufen:

 

/delegate/src/delegated +=/[PFAD]/[DATEI]

Bei der angegebenen Datei handelt es sich um eine reine Textdatei, die jeden Parameter in einer eigenen Zeile enthält.

Beispiel für eine Konfigurationsdatei für den beschriebenen HTTP-Proxy:

  Datei /delegate/conf/http.conf:
  P8080
  SERVER=http
  CACHE=do
  ADMIN=root@proxy
  ROUTE=141.18.69.1
  RES_NS=141.18.1.12
  RELIABLE=192.168.150.0
  DGROOT=/
  LOGDIR=/var/log
  ERRORLOG=/var/log
  WORKDIR=/delegate
  ACTSIR=/tmp
  VARDIR=/var

Um diesen Proxy mit der Konfigurationsdatei zu starten, ist folgendes einzugeben:

 

/delegate/src/delegated +=/delegate/conf/http.conf

Kommentare können in der Konfigurationsdatei mit # beginnend angegeben werden.Es ist dadruch möglich, sehr verständliche und leicht konfigurierbare Skripte zu schreiben.

3.5.3.14 Remote Administration von DeleGate

DeleGate bietet eine Remote-Administration. Genauer gesagt handelt es sich um eine Abfrage des aktuellen Status.

Die Remote-Administration geschieht über einen beliebigen Webbrowser. Das Kommunikationsinterface ist komplett in HTML gehalten.

Voraussetzungen:

1. Es muß ein User auf dem Application Gateway existieren. Dieser User braucht aber keine besonderen Rechte, wie z.B. root-Rechte zu besitzen.
2. Auf dem Application Gateway muß der FTP-Daemon aktiv sein. DeleGate verwendet für die Authentifikation und Identifikation das FTP-Protokoll. Am einfachsten aktiviert man in der Datei /etc/inetd.conf die Zeile mit FTP.

DeleGate-Parameter:

Die Remote-Administration wird bei DeleGate über nur einen Parameter eingerichtet. Der Parameter hat folgendes Format:

 

AUTH="admin:*:user@Identifikationsmaschine"

Als User ist der unter Linux angelegte User anzugeben. Der Wert für "Identifikations-maschine" ist die IP-Adresse des Rechners, auf dem der Benutzer angelegt wurde.

Web-Aufruf:

Um nun auf die Remote-Administrationsseite von DeleGate zu gelangen, ist folgende URL zu verwenden:

  http://[IP-Adresse von DeleGate]:[Lausch-Port des HTTP-Proxies/-/

Alle weiteren Seiten können über diese zentrale Informationsseite erreicht werden.

So z.B. die "Setup for the client"-Seite und die "Server administration"-Seite.

Beispiel:

1. Anlegen eines neuen Users, der für die Remote-Administration zuständig ist:

Dazu YaST aufrufen, und unter dem Menüpunkt "Administration des Systems" die "Benutzerverwaltung" aufrufen und folgendes eingeben.

Abblidung 3.14: Anlegen eines Users für die Remote-Administration von DeleGate

2. Sicherstellen, daß der FTP-Daemon gestartet ist. In der Datei /etc/inetd.conf muß die Zeile mit FTP aktiviert sein.

3. Den DeleGate-Proxie mit folgendem Parameter aufrufen:

  ... AUTH="admin:*:deleadmin@192.168.1.1"

4. Auf einem beliebigen Browser folgendes eingeben.

 

http://192.168.1.1:8080/-/

Als IP-Adresse kann man auch einen gültigen und eingetragenen DNS-Namen verwenden. Der Wert 8080 gibt den "Lausch"-Port des DeleGate HTTP-Proxies an. DeleGate nimmt nur auf diesem Port HTTP-Anfragen entgegen.

Es erscheint dann folgendes Bild:

Abblidung 3.15: Start-Seite der DeleGate Remote-Administration

Erläuterung der Status-Meldungen:

Version Die verwendete DeleGate-Version.
current-time Natürlich die aktuelle Uhrzeit des Application Gateways.
server-start Die Zeit, zu der der DeleGate-Server gestartet wurde.
server-count Leider keine Angaben (?).
server-alive Die Anzahl der momentan parallel gestarteten HTTP-Proxy-Server.
service-done Wie oft der HTTP-Proxy bisher erfolgreich Anfragen bearbeitet hat.
load_average Die CPU-Auslastung des DeleGate-Rechners.

Erläuterung der Configuration-Meldungen:

DELEGATE Name und "Lausch"-Port des HTTP-Proxies.
SERVER Momentan bearbeitende HTTP-Anfrage (in diesem Fall keine).
EXPIRE Zeit in Sekunden, bis der Cache-Speicher überschrieben wird.
CHARCODE Eingestellter Zeichensatz. DeleGate verfügt über eine Zeichnsatz-Translation, um z.B. japanische Schriftzeichen darstellen zu können.
ADMIN Der Administrator des DeleGate-HTTP-Proxies.

Das Menü "Setup for the Client" wird im folgenden dargestellt und erläutert:

Abblidung 3.16: Client Control von DeleGate-Remote-Administration

Als erstes kann man hier die eigene IP-Adresse und den momentan verwendeten Port erkennen.Des weiteren gibt DeleGate einem Auskunft über das verwendete Betriebssystem und den Browser. Damit ist der Rechner gemeint, von dem die Remote-Administration gemacht wird! Auch weitere Angaben, wie z.B. die verwendete Sprache, welche Dateien man öffnen und betrachten kann und ob ein Pack-Programm installiert ist, erkennt Delegate.

Unter "Current parallel sessions from your host" kann man erkennen, wieviele parallele Proxies DeleGate aufgemacht hat.

Die Angabe "The request number on this connection" gibt an, wie oft man, seit dem Server-Start, diese Seite angewählt hat.

Eine etwas wichtigere Seite ist die "Server administration", die im folgenden dargestellt und erläutert wird:

Abblidung 3.17: Remote-Server-Administration von DeleGate

Auf dieser Seite können Status-Abfragen gemacht werden, die der Öffentlichkeit nicht zugänglich sind.

Alle Menüpunkte auf dieser Seite sind paßwortgeschützt !

Um festzustellen, ob man sich bereits eingeloggt hat, dient die Angabe unter "Callback auth". Wenn nun ein Menüpunkt angewählt wurde, dann erkundigt sich DeleGate nach der Identifikation und Authentifikation, also Benutzername und Paßwort des Remote-Administrators.

 

Abblidung 3.18: Identifikation als Remote-Administrator unter DeleGate

Nachdem die korrekte Benutzerinformationen eingetragen wurden, können z.B. die aktuelle Konfiguration oder das Startup-Logbuch abgefragt werden. Der Server kann auch neu gestartet oder angehalten werden.

In der Zeile "Callback auth" wir nun auch dargestellt, ob man von DeleGate als Remote- Administrator berechtigt wurde oder nicht.

Eine erfolgreiche Identifikation und Authentifikation sieht wie folgt aus:

Abblidung 3.19: Erfolgreiche Identifikation als Remote-Administrator unter DeleGate

Under construction

Die Remote-Administration unter DeleGate befindet sich leider noch im Aufbau. D.h. einige Menüpunkte funktionieren noch nicht oder noch nicht richtig.

Es ist bis jetzt auch nur eine Remote-Administration für den HTTP-Proxy verfügbar. Die Delegate.org ist jedoch dabei, weitere Administrations-Tools zu schreiben.

3.5.4 Client Konfiguration und Benutzung der Proxy-Server

Die Konfiguration der Clients ist relativ einfach, da teilweise transparente Proxies verwendet werden. Transparente Proxies sind Proxies, die keine Port-Translation durchführen. Das bedeutet, daß das Client Programm einfach nur eine neue Serveradresse benötigt. Bei transparenten Proxies wird aber trotzdem die volle Stellvertreterfunktion erfüllt.

Nun aber die Konfiguration im einzelnen.

3.5.4.1 DNS-Server

Der DeleGate DNS-Proxy ist ein transparenter Proxy. Es gibt nahezu kein Betriebssystem, bei dem man für den Namens-Dienst einen anderen Port einstellen kann. Darum hört der DNS-Proxy auf Port 53 und stellt seine Anfragen auch durch Port 53 !

Als DNS-Server ist einfach der DNS-Proxy anzugeben. Die Anfragen werden dann von dem angegebenen DNS-Proxy gestellt und für die Clients präsentiert.

 

 

Bsp.: Microsoft Windows 98

Bsp.: Microsoft Windows NT 4.0

Abblidung 3.20: DNS-Client Konfiguration

Nach dem obligatorischen Neustart von Windows, greift das Betriebssystem nun für Namensauflösungen auf den DNS-Proxy-Server zu.

3.5.4.2 Webbrowser

Bei der Konfiguration des Webbrowsers muß als erstes einmal der Proxy-Server angegeben werden. Dies kann per Name oder IP-Adresse geschehen. Die Porteinstellungen sind im Gegensatz zu der DNS-Konfiguration ebenfalls zu ändern. Der HTTP-Proxy ist kein transparenter Proxy. Er hört auf den Port 8080 und stellt seine Anfragen über den Port 80 an den eigentlichen Webserver.

Bsp.: Microsoft Internet-Explorer 5.5

Bsp.: Opera 4.02

Abblidung 3.21: Konfiguration des Webbrowsers

Die Zugriffssteuerung erfolgt über den Benutzer "anonymous". D.h. der User merkt nichts von einem Proxy-Server.

3.5.4.3 E-Mail-Client

Die Konfiguration des Email-Clients scheint auf den ersten Blick etwas komplexer, jedoch auf den zweiten Blick logisch. Die Problematik die sich dabei stellt ist, woher kennt der Proxy-Server den eigentlichen Mail-Server ? Denn als Mail-Server gibt man ja den Proxy-Server an.

Die Lösung ist der Benutzername. Der DeleGate-Mail-Proxy erwartet als Benutzername folgende Konstellation:

  Benutzername@Mailserver

Somit weiß der Mail-Proxy, welchen Mail-Server man ansprechen möchte. Bei dem Mail-Proxy von DeleGate handelt es sich auch um einen transparenten Proxy. Es gibt immer noch Mail-Clients, bei denen sich die Port-Nummer nicht verstellen läßt. Um auch diese Programme zu verwenden, wurde bei DeleGate ein transparenter Mail-Proxy implementiert.

Sollte der Posteingangsserver ein anderer als der Postausgangsserver sein, so sind weitere Einstellungen notwendig.

 

 

 

Posteingangsserver am Beispiel von Microsoft Outlook Express

Postausgangsserver am Beispiel von Microsoft Outlook Express

Abblidung 3.22: Konfiguration der Email-Cleint-Software

 

3.5.4.4 FTP-Client

Der FTP-Proxy-Server von DeleGate ist ein "echter" Proxy, d.h. es handelt sich hierbei um keinen transparenten Proxy.

Textorientiertes FTP

Um auf den Proxy zu gelangen, gibt man z.B. unter der Eingabeaufforderung von Windows

 

ftp

ein. Es erscheint dann folgendes Bild:

Abblidung 3.23: Der Aufruf von FTP

Um nun auf den DeleGate-FTP-Proxy zu gelangen, ist folgendes einzugeben:

 

open 192.168.150.1 8021

Durch den Befehl open wird eine FTP-Sitzung geöffnet. Daran wird IP-Adresse des Proxy-Servers und die dazugehörende Port Nummer angehängt.

DeleGate meldet sich dann mit folgendem:

Abblidung 3.24: FTP-Proxy-Meldung von DeleGate

Als Anmeldenamen und Paßwort sind diejenigen einzugeben, die für den eigentlichen FTP-Server gelten. Nach der Eingabe erscheint folgendes Bild:

Abblidung 3.25: Authentifikation auf dem DeleGate-FTP-Proxy

Um nun auf den eigentlichen FTP-Server zu kommen, ist folgender Befehl einzugeben:

 

cd //[Remote-Server]

DeleGate nimmt dann selbständig die Verbindung zu dem FTP-Server auf und meldet sich mit den vorher angegebene Benutzereinstellungen an.

CuteFTP

Bei CuteFTP handelt es sich um ein kommerzielles, weit verbreitetes FTP-Programm, daß für die Windows-Plattform erhältlich ist.

Um mit CuteFTP über eine Firewall bzw. einen Proxy-Server arbeiten zu können, muß natürlich auch hier eine etwas andere Anwendung verwendet werden.

Abblidung 3.26: FTP-Zugriff mit CuteFTP

Erläuterung: Als FTP Host Address gibt man den Proxy-Server an. Der Proxy-Server stellt dann für uns die Anfragen an den unter FTP site User Name angegebenen Server. Die Notation hierfür ist wieder das bekannte:

 

User@[Remote-Server]

Als Paßwort wird das entsprechende verwendet.

Ganz wichtig ist auch noch der FTP site connect port Eintrag. Dies ist der Port, auf dem der Proxy-Server auf Anfragen "lauscht". Die Standard FTP-Ports 20 und 21 werden ja von den Paketfiltern blockiert.

LeechFTP

LeechFTP ist ein Freeware FTP-Client, der vor allem wegen seiner Freeware-Eigenschaft in der Beliebtheitsskala weit oben steht.

Auch bei LeechFTP muß nach dem Prinzip user@[Remote-Server] vorgegangen werden.

Abblidung 3.27: Verbindungsaufbau unter LeechFTP

Als Host ist auch hier der Proxy-Server anzugeben. Bei der Portnummer handelt es sich auch hierbei um den "Lausch"-Port des Proxies. Als Username wird wieder das user@[Remote-Server] Format verwendet. Als Paßwort wird das dem entsprechenden User zugeordnete verwendet.

2.5.4.5 News-Client

Die News-Client-Konfiguration wird hier am Beispiel von Microsofts Outlook aufgezeigt. Da die Konfiguration sehr einfach ist, läßt sie sich leicht auf andere News-Programme übertragen.

Die einzigen Unterschiede zur "normalen" News-Konfiguration bestehen darin, daß als News-Server das Application Gateway angegeben wird und daß nur die vorher bei der Proxy-Konfiguration eingebundenen Newsgroups gelesen werden können.

Abblidung 3.28: Konfiguration von Newsgroups

Nach einer Neuübetragung stehen alle eingebundenen Newsgroups zur Verfügung.

3.5.5 Fall-Back-Lösungen

Fall-Back-Lösungen sind sogenannte Notfallpläne, die im Falle eines Ausfalls von Teilsystemen oder des kompletten Systems zum Einsatz kommen. Ausfälle können verschiedene Ursachen haben.

Zum einen können Stromausfälle ein Grund für einen Ausfall sein. Um diesem trivialen Grund vorzubeugen ist auf jeden Fall eine ausreichend dimensionierte USV (Unterbrechungsfreie Stromversorgung) zu empfehlen.

Weitere Gründe können z.B. Hardwaredefekte, Fehlbedienungen, Angriffe oder "Launen" des Betriebssystemes sein.

3.5.5.1 Ausfall des Paketfilter 1

Der Ausfall des Paketfilter 1, also des Paketfilters, der direkt mit dem unsicheren Netz verbunden ist, ist ein großes Sicherheitsrisiko. Durch dessen Ausfall liegt der Application Gateway, also das Herzstück der Firewall, für jedermann offen.

Lösungsansatz für den Ausfall des "äußeren" Paketfilter ist folgender:

· Inneren Paketfilter umkonfigurieren,
  - IP-Adressen anpassen, aus privaten werden offizielle IP-Adressen,
  - DHCP-Server des internen Netz auf die neuen IP-Adressen umstellen,
  - Paketfilterskript anpassen, kein Maskerading, sondern Forwarding.

· Application Gateway umkonfigurieren,
  - Neue IP-Adresse für das Interface, welches bisher zum Paketfilter 2 ging.
  - Proxy-Konfiguration ändern, bisher hatte nur der Paketfilter 2 Zugriff auf die Proxies, nun aber der ganze private IP-Adressbereich (RELIABLE-Variable).

Leider beinhaltet dieser Lödungsansatz einen "Schönheitsfehler". Duch den Wegfall des Paketfilter 2 müssen die IP-Adressen des internen Netzes neu vergeben werden.

3.5.5.2 Ausfall des Paketfilter 2

Ein Ausfall des zweiten Paketfilters, also jener, der das Application Gateway von dem sicheren Netz trennt, stellt kein so schwerwiegendes Sicherheitsrisiko dar. Das Application Gateway ist immer noch komplett vor dem unsicheren Netz geschützt.

Lösungsansatz:

· Application Gateway umkonfigurieren,
  - Neue IP-Adresse für das Interface, welches bisher zum Paketfilter 2 ging.
  - Proxy-Konfiguration ändern, bisher hatte nur der Paketfilter 2 Zugriff auf die Proxies, nun aber der ganze private IP-Adressbereich (RELIABLE-Variable).

3.5.5.3 Ausfall des Application Gateway

Ein Ausfall des Application Gateway stoppt den kompletten Netzverkehr sofort. Es ist auch nicht möglich, ohne eine Umkonfiguration der Clients, nur mit den Paketfiltern zu arbeiten.

Ein Lösungsansatz wäre, einen "Notproxy" auf den Paketfiltern zu installieren. Zu empfehlen ist da der innere, also der zweite, Paketfilter. Der Grund: Die Hilfsproxies bleiben somit vor dem unsicheren Netz geschützt.

Lösungsansatz:

· Umkonfiguration des Paketfilter 2
  - Kernel-Forwarding abschalten (echo 0 > /proc/sys/net/ipv4/ip_forward),
  - ipchains-Funktionalitäten abschalten (ipchains P input ACCEPT, ipchans P output ACCEPT, ipchains P forward ACCEPT, ipchains F ),
  - Eingangsinterface mit neuer offizieller IP-Adresse konfigurieren,
  - Proxy-Skript starten,

Problem:

Die Server, die an das dritte Interface des Application Gateway angeschlossen waren, sind jetzt nicht mehr ansprechbar !

Lösungsmöglichkeit:

Die Server durch einen Switch oder Hub an die DMZ anschließen. Jedoch sind für die Server dann neue IP-Adressen erforderlich.

3.5.5.4 Totalausfall

Ein totaler Ausfall der Firewall stellt das größte Problem da. Als erstes kann auf die Server in der DMZ nicht mehr zugegriffen werden, als zweites können die Clients keinen Netzverkehr mehr mit der Außenwelt herstellen.

Lösungsmöglichkeit 1:

· Komplette Überbrückung der Firewall,
· Neukonfiguration der Clients, z.B. durch neue Images.

Lösungsmöglichkeit 2:

· Ersatzrechner mit DeleGate bereitstellen und vorhandenes Proxy-Skript starten,
· Anschluß der Dienstserver hinter dem Application Gateway,

Bei der zweiten Lösungsmöglichkeit sei jedoch darauf hingewiesen, daß das Application Gateway völlig ungeschützt an das unsichere Netz angeschlossen ist !

3.5.5.5 Anmerkung

Die hier vorgestellten Lösungmöglichkeiten stellen nur einen Lösungsansatz dar. Nach möglichst schnellem Ersatz für das ausgefallene System ist auf jeden Fall zu schauen, da die Sicherheit von dem Zusammenspiel der einzelnen Komponenten abhängt. Ein Ausfall eines Teilsystemes und dessen "Notüberbrückung" stellt ein nicht kalkulierbares Sicherheitsrisiko dar !

Um die Überbrückungszeit so gering wie nur möglich zu halten, sind sogenannte Drive-Images von Vorteil. Diese werden bei einer Ersatzmaschine nur eingespielt und stellen in kürzester Zeit ein System wieder her ohne lästiges Neuinstallieren.

3.5.6 Sicherheitsüberprüfung der Paketfilter

Eine Überprüfung der Sicherheit eines Firewall-Systems muß auf jeden Fall durchgeführt werden. Selbst wenn man beim Aufbau noch so vorsichtig und gewissenhaft vorgeht, schleichen sich immer wieder Sicherheitslücken ein. Diese auszumerzen ist die Aufgabe einer Sicherheitsüberprüfung.

3.5.6.1 Paketfilter mit Einzelpaketen testen.

Das hier verwendete Filtertool ipchains verfügt über einen eigenen Überprüfungsmodus. Ipchains kann seine Filterregeln mit Einzelpaketen testen. Hierzu werden virtuelle Pakete in die Filterchain geschickt und ipchains gibt aus, was mit einem zuvor definierten Paket geschehen wird.

Der Aufruf eines solchen Testpaketes geschieht mit folgender Syntax:

 

ipchains -C [Chain] -i [Interface] -p [Protokoll] -s [Quell IP und Port] -d [Ziel IP und Port]

Ipchains antwortet auf eine solche Anfrage mit der eingestellten Policy. Also accept, reject, deny, masq, redirect oder return.

Beispiel für ein ICMP-Paket:

 

ipchains -C input -i eth0 -p ICMP -s 192.168.1.1 8 -d 192.168.1.254 8

Der Befehl gibt an, es soll die Input-Chain auf dem Interface eth0 getestet werden. Als Protokoll wird ICMP verwendet. Das Paket kommt von der Station 192.168.1.1 und geht an die Station 192.168.1.254. Es handelt sich dabei um den ICMP-Befehl echo request, der mit der 8 angegeben wird.

Ipchains antwortet in unserem aufgebauten Fall mit accepted. D.h. ein Paket, das die angegebenen Parameter enthält, würde von der Input-Chain des Paketfilters angenommen und weitergegeben werden.

Eine komplette Überprüfung der beiden Paketfilter und deren Auswertung steht im Anhang.

3.5.6.2 Allgemeine Tips für die Paketfilter-Entwicklung

Nachfolgend ein paar sinnvolle und vernünftige Tips zur Entwicklung und zum Aufbau eines Paketfilters [5]:

- Regeln immer als vollständiges Skript ausführen. Damit wird im Fall eines Absturzes gewährleistet, daß das System und vor allem die Filterregeln rekonstruierbar sind.
   
- Keine neue Regeln über die Kommandozeile eingeben. Dadurch kann z.B. bei einer Remote-Sitzung die Sitzung komplett abbrechen !
   
- Schrittweise vorgehen. Also immer nur einen Dienst nach dem anderen aktivieren bzw. deaktivieren.
   
- Wichtig: Immer die erste passende Regel gewinnt ! Beim Anfügen von neuen Regeln unbedingt beachten.
   
- Wenn das Skript hängen bleibt, dann benutzt eine Regel vermutlich einen symbolischen Hostnamen statt einer numerischen IP-Adresse. Wenn dann durch Zufall der DNS-Port deaktiviert wurde, kann ipchains keine Namensauflösung mehr machen. Also nach Möglichkeit immer numerische IP-Adressen verwenden.
   
- Sollte ein Dienst nicht funktionieren, dann erst mal mit der Option -l die Protokollierung aktivieren und schauen, was wirklich los ist, als irgendwelche "Verzweiflungstaten" zu tun.
   
-

Bei Forwarding und Masquerading muß die Kernelfunktion IP-Forward aktiviert sein !Am besten nimmt man den Befehl für die Aktivierung in das Skript mit auf !

echo 1 > /proc/sys/net/ipv4/ip_forward

   
- Der Routing-Dämon muß abgeschaltet sein !

 

3.5.6.3 Portscanner

Portscanner sind ein wichtiges Tool, um die Sicherheit eines Systems zu überprüfen. Portscanner arbeiten nach folgendem Prinzip. Sie versuchen, auf allen nur möglichen TCP und UDP-Ports eine Verbindung aufzubauen. Gelingt ihnen ein Aufbau zu einer bestimmten Anwendung auf einem bestimmten Port, dann handelt es sich dabei um eine potentielle Sicherheitslücke.

Portscanner sollten auch beim Aufbau von Paketfiltern als Überprüfungstool eingesetzt werden. Denn was nützen einem die tollsten und aufwendigsten Filterregeln, wenn auf der Maschine der Telnet-Dämon mit anonymous-Rechte läuft ?

Bei der Überprüfung der hier aufgebauten Paketfilter wurde der Port Scanner Super Scan in der Version 2.08 verwendet. Er ist wie viele andere Portscanner frei über das Internet verfügbar, z.B. unter http://members.home.com/rkeir/software.html. Im Internet gibt es eine Vielzahl von Portscannern, für verschiedene Betriebssysteme und mit tausenden Erscheinungsbildern.

Die Überprüfung der hier aufgebauten Paketfilter ergab folgendes Bild :

Ursprungsnetz

Ziel-IP-Adresse

Rechner

Offene Ports

141.18.253.0

141.18.253.69

Paketfilter 1

113 auth

141.18.253.0

141.18.69.1

Paketfilter 1

113 auth

141.18.69.0

141.18.253.69

Paketfilter 1

113 auth

141.18.69.0

141.18.69.1

Paketfilter 1

113 auth

192.168.1.0

192.168.1.254

Paketfilter 2

113 auth

192.168.1.0

192.168.150.254

Paketfilter 2

113 auth

192.168.150.0

192.168.1.254

Paketfilter 2

113 auth

192.168.150.0

192.168.150.254

Paketfilter 2

113 auth

Tabelle 3.4: Portscann-Ergebnis der Paketfilter

Der offene Port auf den Paketfiltern dient dem Ident-Dämon von Linux. Der Ident-Dämon dient zu Identifikation von Benutzer, sowohl lokal als auch per remote. Eine Abschaltung diese Dienstes würde zwar den offenen Port schließen, jedoch auch eine Anmeldung auf der Maschine unmöglich machen.

Da sonst keine anderen Netzwerkdienste, wie etwa Telnet oder FTP laufen, kann man dieses Sicherheitsloch in Kauf nehmen. Schließlich läuft kein anderer Netzwerk-Dienst, der eine Identifikation benötigt.

3.5.6.4 Flushing-Angriff

Unter einem Flushing-Angriff versteht man, das Netzwerkinterface eines Rechners mit Paketen zu überschütten. Nach Möglichkeit mit UDP-Paketen, da diese keine Bestätigung erfordern.

In der Vergangenheit gab es Betriebssysteme und Fehler in solchen, die bei einem Flushing-Angriff abgestürzt sind, oder sich danach in einem unbestimmten Zustand befanden. Bei heutigen Betriebssystemen ist ein solcher Zustand zwar nahezu auschließbar, jedoch sollte trotzdem eine Überprüfung stattfinden, um die Reaktion des Systems zu erfahren. Flushing-Programme wie z.B. ICMP-Bomber oder UDPFlush findet man auch im Internet. Leider sind diese Internetseiten nicht dauerhaft verfügbar oder umgezogen. Jedoch finden die meisten Suchmaschinen diese Programme.

Bei den hier aufgebauten Paketfiltern wurde ein Flushing-Angriff mit UDP- und ICMP-Paketen vollzogen. Als Parameter wurden folgende gewählt :

UDP:

- Port 23 (geschlossen), mit zufälliger Paketgröße und runden 2800 Paketen/s.
- Port 1025 (offen), mit zufälliger Paketgröße und runden 2800 Paketen/s.

ICMP:

- Typ 8 (echo request, offen), mit verschiedenen Paketgrößen (10, 500, 1400, 25000 Bytes) und runden 1900 Paketen/s.
- Typ 5 (redirect, geschlossen), mit verschiedenen Paketgrößen (10, 500, 1400, 25000 Bytes) und runden 1850 Paketen/s.

Der Angriff wurde auf jedes einzelne direkt erreichbare Netzwerkinterface der Paketfilter und auf das gegenüberliegende, also durch die Paketfilter hindurch, gestartet.

Bei allen Angriffen erscheint das gleiche Bild. Die Paketfilter bearbeiteten die ersten 2-4 Sekunden die Anfragen. Lehnten sie ab, oder leiteten sie weiter. Nach den etwa 2-4 Sekunden brach die Verbindung ab. Die Paketfilter hatten den Angriff bemerkt und haben ihre Netzwerkinterfaces geschlossen. Nach etwa weiteren 2 Sekunden wurden die Netzinterfaces wieder geöffnet um nachzuschauen, ob "die Luft rein" ist. Hielt der Angriff an, so wurde alles von vorne wiederholt. Also eine sinnvolle Reaktion der Paketfilter.

3.5.6.5 Resultat

Die Paketfilter habe die Sicherheitsüberprüfung bestanden. Die Reaktionen auf die einzelnen Tests sind als sinnvoll zu bezeichnen.

Jedoch sollte auch während des Betriebes eine regelmäßige Überprüfung der Sicherheit geschehen. Zum einen eine Überprüfung der Log-Dateien und eventuell eine Überprüfung der verwendeten Ports mit dem Tool netstat.

3.5.7 Sicherheitsüberprüfung des Application Gateways

Das Application Gateway ist das Herzstück eines Firewall-Systems. Über das Application Gateway werden alle Anfragen, die in das unsichere Netz gehen, entgegengenommen und stellvertretend weitergeleitet. Eine Überprüfung der Sicherheit dieses "Herzstücks" der Firewall ist äußerst wichtig.

3.5.7.1 Portscanner

Um einen ersten Überblick zu bekommen, wird wie bei den Paketfiltern ein Portscan durchgeführt. Ein Portscan zeigt die potentielle Angriffsmöglichkeiten auf ein Firewall-System an. Offene Ports sind wie Türen, die man "nur" noch zu öffnen braucht.

Portscans werden auf das Application Gateway direkt durchgeführt. Also ohne dazwischen geschaltete Paketfilter. Die Scans werden einmal auf das Eingangsinterface (IP 141.18.69.250) und auf das Ausgangsinterface (192.168.150.1) durchgeführt.

Die Scans ergaben folgendes Bild:

Scann auf 141.18.69.250 :

Offener Port

Beschreibung

25, SMTP

Transparenter Mail-Proxy (versenden)

110, POP3

Transparenter Mail-Proxy (empfangen)

119, NNTP

Transparente News-Proxy

8021, FTP-Proxy

FTP-Proxy

8080, HTTP-Proxy

HTTP-Proxy

Tabelle 3.4: Portscan auf das zum sicheren Netz gerichtete Interface des Application Gateway

Scann auf 192.168.150.1 :

Offener Port

Beschreibung

25, SMTP

Transparenter Mail-Proxy (versenden)

110, POP3

Transparenter Mail-Proxy (empfangen)

119, NNTP

Transparente News-Proxy

8021, FTP-Proxy

FTP-Proxy

8080, HTTP-Proxy

HTTP-Proxy

Tabelle 3.5: Portscan auf das zum sicheren Netz gerichtete Interface des Application Gateway

Etwas verwunderlich scheint, daß bei den Portscans der Port für DNS, also Port 53, nicht erscheint. Vermutlich ist dies auf eine zu kurze Scanzeit, also die Zeit, in der nach einem Port gesucht wird, oder auf eine schlechte Scanner-Architektur zurückzuführen.

Um das Problem der schlechten Scanner-Architektur auszuschließen, wurden auch Scanner anderer Hersteller verwendet, jedoch ohne Unterschied.

Es ist klar, daß auf dem Application Gateway so viele Ports offen sein müssen. Schließlich schleußt das Application Gateway die Anfragen nicht einfach durch, sondern dient als Stellvertreter.

Erläuterung der offenen Ports:

- Port 25, SMTP. Hier handelt es sich um einen transparenten Proxy, der die Anfragen auf dem gleichen Port entgegen nimmt, wie er sie auch wieder an das unsichere Netz stellt.
- Port 110, POP. Wiederum ein transparenter Proxy,
- Port 119, NNTP. Hierbei handelt es sich auch um einen transparenten Proxy. Jedoch mit dem Unterschied, daß der NNTP-Proxy als "echter" Stellvertreter dient. Der NNTP-Proxy von DeleGate lädt die kompletten Newsgroups auf seine Festplatte und dient dann als eigenständiger Newsserver.
- Port 8021, FTP. Bei dem FTP-Proxy handelt es sich nicht um einen transparenten Proxy. Der FTP-Proxy von DeleGate nimmt Anfragen über den Port 8021 entgegen und schickt seine Anfragen über die Ports 20/21 an das unsichere Netz.
- Port 8080, HTTP. Wiederum ein "Standard"-Proxy, der seine Anfragen über den Port 8080 bekommt und diese dann stellvertretend über den Port 80 in das Internet schickt.

 

3.6.7.2 Nutzung von Außen

Eine sehr wichtige Überprüfung ist die Nutzung von Außen. DeleGate-Proxies sind standardmäßig so konfiguriert, daß sie über jedes Netzwerkinterface angesprochen werden können. Durch den RELIABLE-Befehl wird genau definiert, welche Rechner bzw. welcher IP-Adressbereich überhaupt Zugriff hat.

Die Konfiguration wurde so gewählt, daß nur Rechner mit der IP-Adresse 192.168.150.254 Zugriff auf die Proxies haben. Diese IP-Adresse ist das Interface des zweiten Paketfilters, welches an die DMZ, also an das Application Gateway angeschlossen ist. Es wurde nur eine IP-Adresse und kein IP-Adressbereich gewählt, da auf dem Paketfilter die Maskerading-Funktionalität aktiviert ist.

Um zu überprüfen, ob das Application Gateway auch von Außen genutzt werden kann, wurde zum einen ein Rechner außerhalb der Firewall im unsicheren Netz installiert und zum anderen ein Rechner zwischen Paketfilter 1 und Application Gateway, also in der DMZ.

Die Rechner sind so konfiguriert, wie sie normalerweise im sicheren Netz konfiguriert werden. D.h. die Rechner sind für die Bentutzung der DeleGate-Proxies eingestellt.

Bei beiden Rechnern erschien das selbe Bild:

Es war nicht möglich, die Proxies sowohl vom unsicheren Netz als auch von der DMZ zu benutzen. Es ist also sichergestellt, daß ein Mißbrauch der Proxies von außen nahezu unmöglich ist.

3.5.7.3 Flushing-Angriff

Flushing-Angriffe sind gleich wie bei den Paketfiltern durchzuführen. Jedoch sollte sichergestellt werden, daß sich zwischen dem angreifenden Rechner und dem Application Gateway kein Paketfilter befindet. Alle Tests werden also von der DMZ aus durchgeführt.

Das Application Gateway reagierte auf das Bombardement von UDP- und ICMP-Paketen gleich wie die Paketfilter. Nach kurzer Zeit, also etwa 2-4 Sekunden machte das Application Gateway seine Interfaces dicht. Nach weiteren 2-4 Sekunden wurden die Interfaces wieder geöffnet, um nachzuschauen, ob der Angriff noch andauert, oder ob die "Luft" wieder rein ist.

Also wie bei den Paketfiltern eine gewünschte und durchaus sinnvolle Reaktion.

3.5.7.4 Überwachung während des Betriebes

Das Application Gateway ist die optimale Angriffsfläche für Hacker, Viren und andere Bösewichte. Es ist deshalb unbedingt notwendig, auch während des Betriebes das Application Gateway zu überwachen.

Ein Standardwerkzeug für eine solche Überwachung ist das Programm netstat. netstat kann die aktuellen Verbindungen und die verwendeten Ports aufzeigen. Dazu ist der Befehl:

  netstat a (oder netstat a n für eine numerische Ausgabe)

zu verwenden. netstat liefert dann eine Auflistung aller Verbindungen und der verwendeten Ports. Bei dieser Überwachung sollte überprüft werden, ob das Application Gateway noch andere Ports außer den definierten verwendet. Sollten andere Ports auftauchen, dann zeigt dies eine falsche Konfiguration oder einen Angriff auf. In diesen Fällen ist eine Überprüfung des Sicherheitskonzeptes notwendig.

 

3.5.8 Performance des Firewall-Systems

Ein nicht zu unterschätzender Faktor bei dem Aufbau eines Firewall-Systems ist die Performance. Denn was bringt einem die "schönste" Firewall, wenn sie nicht in der Lage ist, die angeforderten Datenpakete zu bearbeiten ?

Um jedoch eine eindeutige und umfassende Performance-Analyse zu machen, ist eine große Anzahl an Clients notwendig. Es gibt sogar Firmen, die sich nur auf die Analyse der Leistungsfähigkeit eines Firewall-Systems spezialisiert haben. Dies macht deutlich, daß das Messen der Leistungsfähigkeit keine triviale Sache ist.

Im Umfang dieser Diplomarbeit war es nicht möglich, eine umfangreiche Messung der Firewall durchzuführen. Deshalb werden hier nur Zusammenfassungen von verschiedenen Berichten, Erfahrungswerte und Möglichkeiten zur Leistungsanalyse aufgezeigt.

3.5.8.1 Paketfilter:

In einem Firewall-System wird der gesamte Datenverkehr durch einen oder mehrere Paketfilter geschleust. Ein absolutes Leistungsmerkmal für die Beurteilung von Paketfiltern ist also :

  gefilterte Pakete / Sekunde

Um eine Vorstellung zu geben, wie intensiv jedes einzelne Paket behandelt wird, hier ein paar Zahlen:

Auf einem Linux-System mit Kernel 2.2.x werden folgende CPU-Zyklen pro Paket verbraucht [3]:

- IP Pakete an der Netzwerkkarte : 50-100 CPU Zyklen,
- IP Pakete, Filterung nach Quelle und Ziel: 100-200 CPU Zyklen,
- TCP Paket, Filterung nach Port, Quelle und Ziel: 200-400 CPU Zyklen.

Die Zahlen erscheinen hoch. Wenn man aber bedenkt, daß ein heutiges Rechnersystem mit 1 GHz getaktet wird, dann wird für einen CPU-Zyklus lediglich 1ns benötigt. Natürlich ist diese Betrachtung sehr vage. Die Leistungsfähigkeit eines Paketfilter hängt nicht nur von der reinen CPU-Leistung ab. Auch das Betriebssystem spielt eine nicht unwesentliche Rolle. Z.B. war das Linux 2.0 System um den Faktor 2-15 langsamer !

Für verschiedene Anwendungsgebiete ist folgende Hardwareausstattung ausreichend [3][5]:

Anwendungsgebiet

Hardwareausstattung

Paketfilter mit ISDN-Router

80386-33 mit 16 MByte RAM

Paketfilter mit DSL-Router

Pentium 66 mit 16 MByte RAM

Paketfilter für 10 MBit/s Netzwerk

Pentium 166 mit 64 MByte RAM

Paketfilter für 100 MBit/s Netzwerk

Pentium II 300MHz mit 64 MByte RAM

Tabelle 3.6: Hardwareanforderungen bei Paketfiltern

Natürlich sind diese Angaben nur "Daumenwerte" und dienen zur groben Orientierung. Was jedoch auffällt ist, daß für kleinere Netzwerke mit niedrigen Bandbreiten auch ein alter ausrangierter Rechner als Paketfilter dienen kann.

3.5.8.2 Application Gateway:

Die Leistungsfähigkeit eines Application Gateways zu beurteilen ist etwas schwieriger als bei einem Paketfilter. Bei einem Application Gateway zählt nicht allein der reine Datendurchsatz, sondern auch die Reaktionszeiten. Also wie lange der Proxy benötigt, um eine Verbindung aufzubauen. Des weiteren ist auch die Anzahl der parallel möglichen Verbindungen wichtig. Wenn man jedoch bedenkt, daß Linux 2.2 und 2.0 eine Beschränkung auf maximal 1024 Prozesse bzw. maximal 1024 Threads hat, dann stellt dies die "natürliche" Grenze für die Leistungsfähigkeit dar.

Es wird auf einem Application Gateway also genügend CPU-Kapazität benötigt um, schnell neue Prozesse zu starten und Verbindungen aufbauen zu können. Optimal sind hier Maschinen mit mehreren Prozessoren.

Die nächste Grenze ist der Hauptspeicher. Denn jede TCP-Verbindung beansprucht einen Puffer im RAM, der bei Linux je nach verwendeter Version und Prozessortyp schwankt. Als Standardwert kann hier etwas über 32KByte angegeben werden. Es muß jedoch berücksichtigt werden, daß auf einem Application Gateway immer zwei Verbindungen offen gehalten werden müssen. Eine nach innen und eine nach außen.

Beispiel aus [3]:

Absicherung eines WWW-Servers. Bei 50.000 offenen Zugriffen auf den WWW-Server oder die Serverfarm müssen also mind. 100.000 simultane TCP-Verbindungen offen gehalten werden können. Hier ist also eine RAM-Ausstattung von 128 MByte die Untergrenze.

3.5.8.3 Parameter für den Application Gateway:

Bei jedem vernünftigen Proxy können verschiedenste Parameter eingestellt werden. So auch bei DeleGate. Die Parameterliste reicht von maximal zulässigen FTP-Verbindungen über die max. Anzahl von Standby-Prozessen bis zu Timeouts für DNS.

Diese Parameter haben bei DeleGate einen Default-Wert. Diese Default-Werte sollten je nach Umgebung geändert werden. Verfügt das Netzwerk z.B. über einen langsamen DNS-Server, so sind die Timeouts für DNS höher zu setzten. Handelt es sich bei dem Application Gateway um eine leistungsfähige Maschine, so können z.B. mehr parallele Prozesse gestartet werden.

Eine Auflistung von sinnvollen Parametereinstellungen:

Parameter

Wert

Max. Anzahl der parallelen Verbindungen

800-1200

Max. Anzahl der parallelen FTP-Sitzungen

50-75

Timeout für DNS lookup

60 sec.

Timeout für Datentransfer, allgemein

600 sec.

Timeout für Login

60 sec

Tabelle 3.7: Parameter für den Application Gateway

Es ist unbedingt wichtig, daß diese Parameter nicht absolut sind. D.h. während des Betriebes sollte regelmäßig die Auslastung des Systems beobachtet werden und gegebenenfalls die Parameter angeglichen werden. Wenn z.B. regelmäßig ein DNS-Error erscheint, dann sollte der Timout-Wert für DNS lookups schrittweise erhöht werden.

3.5.8.4 Überwachung während des Betriebes:

Um die Leistungsfähigkeit eines Application Gateways beurteilen zu können, und um eine sinnvolle Einstellung der Parameter zu gewährleisten ist eine Überwachung während des Betriebes notwendig.

Wichtige Kriterien für die Überwachung sind folgende:

- CPU-Auslastung in Abhängigkeit der Anzahl der Prozesse,Hiermit wird überprüft, ob die Leistungsfähigkeit der CPU für die Aufgaben ausreichend ist oder nicht.
   
- Freier Arbeitsspeicher in Abhängigkeit der Anzahl der Prozesse,Hiermit kann beurteilt werden, ob der Hauptspeicher seinen Aufgaben gewachsen ist.
   
- Bandbreitenüberprüfung mit z.B. LinkView von Wandel & Goltermann in Abhängigkeit der Anzahl der Prozesse.

Um nun eine Beurteilung der Leistungsfähigkeit vorzunehmen, sollte die Überprüfung mehrmals durchgeführt werden. Es kann damit das dynamische Leistungsverhalten des Application Gateways aufgezeigt werden.

Sollten die Kriterien im "roten" Bereich sein, also die CPU-Auslastung immer über 90% und der Arbeitsspeicher immer zu 90% gefüllt, dann befindet sich die Maschine schon im Höchstlastbereich. Es ist dann zu überlegen, ob eine leistungsfähigere Maschine als Application Gateway einzusetzen ist.

 

3. Firewall konkret

Da nun in den vorherigen Kapiteln ausführlich die Konstellation, Konfiguration und Arbeitsweise von Firewall-Systemen erläutert wurde, wird nun eine konkrete Implementierung für die Fachhochschule Aalen Fachbereich Elektronik/Informatik vorgestellt.

 

Das Sicherheitskonzept und der Netzaufbau der FH-Aalen kann aus Sicherheitsgründen nicht publiziert werden !

 

3.3 Hardware- und Softwareauswahl

3.3.1 Hardwareauswahl

Ein Firewall-System sollte nach Möglichkeit transparent für den Benutzer sein. Unter Transparenz versteht man, daß der Benutzer keine umständlichen und langwierigen Anmeldungen vornehmen muß. Weiter wird unter Transparenz verstanden, daß die Firewall den Anwender nicht in der Bandbreite einschränkt. Um jedoch eine volle Bandbreite zu garantieren, muß die Firewall mit leistungsfähiger Hardware ausgestattet sein.

Für das High-Security-Firewall-System des Fachbereiches Elektronik/Informatik wurde folgende Hardwareausstattung gewählt :

Abbildung 3.4: Hardwareauswahl der High-Security-Firewall

Die beiden Paketfilter haben die gleiche Hardwareausstattung. Sie verfügen jeweils über einen schnellen Pentium III Prozessor, 64 MB Arbeitsspeicher, einer 13 GB Festplatte, einem Grafiksystem und jeweils 2 Netzwerkkarten.

Das Application Gateway ist mit einer leistungsfähigeren Hardware ausgestattet, da er als Stellvertreter fungiert, und somit doppelt so viele Verbindungen offen halten muß wie ein Paketfilter. Es wird über den Application Gateway auch die Identifikation und Authentifikation vorgenommen.

Das Application Gateway hat deshalb auch ein Dual-Motherboard mit 2 Pentium III Prozessoren, 256 MB Arbeitsspeicher, einer 40 GB Festplatte, einem Grafiksystem und 3 Netzwerkkarten spendiert bekommen.

Die Anbindung der einzelnen Komponenten bzw. Rechner erfolgt über 100 MBit/s im Full-Duplex-Betrieb.

3.3.2 Softwareauswahl

Als zu installierende Software wird Linux in der Minimalinstallation verwendet, eine Distribution von SuSE in der Version 6.4.

Linux ist für diese Aufgabe nahezu prädestiniert. Es gibt zwar noch kein Betriebssystem, das hinsichtlich der Kommunikationsanforderungen evaluiert und zertifiziert worden ist, jedoch kann bei einem Open-Source Betriebssystem wie LINUX eine eigene Anpassung erfolgen.

Die Eignung von Linux für ein Firewall-Betriebssystem wird auch durch die Mitteilung des Heise-Tickers vom 14. Januar 2000 deutlich: [1]

"NSA macht Linux zum Firewall-System

Die amerikanische National Security Agency (NSA) läßt ein renommiertes Firewall-Konzept auf Linux portieren. Die Datenschutzbehörde hat der Secure Computing Corporation den Auftrag erteilt, deren patentierte Technik zum Domain Type Enforcement (DTE) auch auf das Betriebssystem Linux zu portieren. DTE ordnet die Netzwerk-Interface von Firewall-Rechnern in getrennte Domains an, die nur durch Proxies miteinander verbunden sind.

Security-Server dieses Konzepts sind unter dem Markennamen Sidewinder bekannt geworden. Bislang verwendeten diese Rechner ein modifiziertes BSD-Unix als Betriebssystem. Der NSA-Auftrag weist aber darauf hin, daß Linux in zunehmendem Maße an Vertrauen gewinnt, so daß es auch für den Einsatz bei Sicherheitssystemen für Industrie und Behörden interessanter wird."

 

3.4 Aufteilung der Subnetze

Das hier vorgestellte und aufgebaute Firewall-System besitzt ein Screened Subnet (siehe 2.4.6 Screened Subnet). Die Vorteile des Screened Subnet wurden bereits in einem vorherigen Kapitel erläutert.

Die interne Netzstruktur, also das zu schützende Netz, besitzt ebenfalls einen privaten IP-Adressbereich.

Die genaue Aufteilung sieht dann wie folgt aus :

Abbildung 3.5: Subnetz Aufteilung der Firewall

 

3.5 Installation und Konfiguration

3.5.1 Paketfilter 1

3.5.1.1 Linux-Installation

Die Installation der SuSE Linux Distribution auf dem Paketfilter 1 geschieht folgendermaßen:

- Linux von CD1 booten,
- Beim Bootprompt "manual" innerhalb der ersten 3 Sekunden eingeben,
- Es wird dann die textorientiere Installation gestartet
- Installation/System starten wählen,
- Installation/Update starten,
- Das Installations- und Konfigurationstool Yast1 wird gestartet,
- Linux neu installieren wählen,

Die Festplatte wie folgt partitionieren :

Geräte-datei

Partitionstyp

Spur, von-bis

Kapazität [MB]

Dateityp

Mount-Point

hda1

Primär

1-26

200

Linux native

/

hda2

erweitert

27-1583

12213

-

-

hda5

logisch

27-52

200

Linux native

/root

hda6

logisch

53-183

1024

Linux native

/usr

hda7

logisch

184-314

1024

Linux native

/var

hda8

logisch

315-331

128

Linux native

/home

hda9

logisch

332-248

128

Linux swap *

-

 

 

 

 

 

 

 


* Der Typ der Swap-Partition muß auf Swap (Typ 83) gesetzt werden.

Tabelle 3.2: Partitionierung der Festplatte des Paketfilters 1

- Konfiguration "SuSE Minimal System" laden,
- Installation starten,
- Im Hauptmenü:

Folgende Einstellungen bei der Installation wählen:

- Standard Kernel,
- Bootdiskette erzeugen (ist immer sinnvoll)
- Lilo konfigurieren: ja
- Append-Zeile für Kernel-Parameter: vga=0c301
- Lilo im Master-Boot-Sektor installieren
- Lilo Wartezeit: 1 Sekunde
- mit F4 neue Boot-Konfiguration mit Namen lin anlegen, dabei Linux booten und bootende Partition /dev/hda1 wählen,
- Zeitzone : MET
- Hardware Uhr: lokale Zeit
- Rechnername: paketfilter1
- Domäne: fbefire1
- TCP/IP: Echtes Netzwerk
- Rechner als DHCP-Client betreiben: Nein
- Typ des Netzwerks: eth0
- IP-Adresse des Rechners: 141.18.253.69
- Netzmask: 255.255.255.0
- Adresse default Gateway: 141.18.253.254
- Inetd starten: ja (vorerst)
- Portmapper starten: nein
- News from-Adresse festlegen: paketfilter1.fbefire1
- Auf Nameserver zugreifen: ja
- Als Nameserver folgende IP-Adressen eintragen: 141.18.1.12 und 141.18.1.12
- Auswahl Netzwerkkarte: 3Com 3c59x/3c90x
- Sendmail Konfiguration: Rechner mit permanenter Netzverbindung (SMTP)
- Passwort für root: *******
- Modem einrichten: nein
- Maus einrichten: ja (PS/2-Maus)
- openssh und sec nachinstallieren: ja

Nach erfolgreicher Installation wird nun die zweite Netzwerkkarte installiert. Um diese zu installieren authentifiziert man sich mit root und gibt dann yast ein.

Yast ist ein Konfigurations- und Installationstool von Suse, welches einem die Administration erleichtert.

Yast meldet sich dann mit folgendem Bildschirm :

Abbildung 3.6: YaST-Hauptmenü

Um die zweite Netzwerkkarte zu installieren wählt man mit den Pfeiltasten das Menü Administration des Systems. Diese Menü mit Return öffnen. Dann den Punkt Netzwerk konfigurieren und abschließend auf Netzwerk Grundkonfiguration.

Abbildung 3.7: YaST-Netzwerk Grundkonfiguration

Nachdem die Netzwerk Grundkonfiguration angewählt wurde, erscheint ein neues Fenster :

Abbildung 3.8: YaST-Netzwerk Konfiguration

Zuerst muß die zweite Netzwerkkarte einen Namen bekommen. Dazu geht man auf die erste Netzwerkkarte (diese hat den Namen eth0 !) und vergibt dann mit F7 den Namen eth1. Mit F6 wird dann folgende IP-Adresse vergeben: 141.18.69.1 Maske 255.255.255.0 und kein Gateway. Mit F4 die Karte aktivieren. Mit F10 die Einstellungen abspeichern.

Linux weiß nun, daß es eine zweite Netzwerkkarte gibt. Jedoch muß für diese Karte noch ein passender Treiber installiert werden. Dies geschieht über das Menü Hardware im System integrieren und nachfolgend auf Netzwerkkarte konfigurieren. Es erscheint dann folgendes Menü:

Abbildung 3.9: YaST-Auswahl der Netzwerk-Karte

Unter Typ des Netzwerkes ist eth1 einzutragen. Die Art der Netzwerk-Karte ist dieselbe wie die erste Netzwerkkarte, nämlich 3COM 3c59x/3c90x. Optionen zum Laden des Moduls werden nicht benötigt. Mit <Weiter> speichern.

Nachdem die zweite Netzwerkkarte installiert ist, wird YaST mit YaST beenden verlassen.

Ein Neustart des Systems mit shutdown r now ist ratsam.

3.5.1.2 Linux-Kernel Konfiguration und Compilierung

Um einen speziell auf einen Paketfilter zugeschnitten Kernel zu haben, muß dieser neu konfiguriert und neu compiliert werden. Dazu startet man YaST und wählt unter Einstellungen zu Installtion den Punkt Installtionsquelle auswählen. YaST gibt dann einige Auswahlmöglichkeiten, wobei hier die Installation von CD-ROM zu wählen ist.

Nachdem YaST nun die CD-ROM gemountet hat, wählt man im YaST Hauptmenü Installation festlegen/starten. Es wird nun ein neuer Bildschirm gezeigt, hier ist Konfiguration ändern/erstellen zu wählen.

Für die Konfiguration und Compilierung des Kernels sind folgende Pakete notwendig :

- lx_suse aus der Serie d,
- make aus der Serie s,

Nachdem die Installation der Pakete abgeschlossen ist, wechselt man mit dem Befehl

 

cd /usr/src/linux

in das Kernel-Verzeichnis. Dort ist folgendes Kommando aufzurufen :

  make menuconfig

Es wird dann das Kernel-Konfigurations-Menü gezeigt :

Abbildung 3.10: YaST-Auswahl zur Kernel Neucompilierung

Folgende Funktionalitäten werden nicht benötigt und sind auf Disable zu setzen :

- Plug & Play support --- > ISA Plug & Play Support,
- SCSI Support,

Eine andere Funktionalität ist zu aktivieren bzw. einzubinden:

- Netzkartentreiber 3C590/3C900,

Als grundlegende Sicherheitseinstellungen für einen Paketfilter sollten folgende Funktionen aktiv sein. Diese gelten nur als allgemeine Richtlinie und können von System zu System variieren. [3]

- loadable module support,
- kernel daemon support,
- networking support,
- network firewalls,
- TCP/IP networking,
- Network firewalls,
- IP: forwarding/gatewaying,
- IP: syn cookies,
- IP: firewall packet logging,
- IP: masquerading,
- ICMP: masquerading,
- IP: accounting,
- IP: drop source routed frames.

Nach der Konfiguration des Kernels ist dieser abzuspeichern. Folgende Kommandos schließen dann die Compilierung ab :

  make dep
  make bzImage
 

lilo

Ob der Kernel erfolgreich konfiguriert und compiliert wurde, läßt sich nach einem weiteren Neustart mit shutdown r now ersehen.

3.5.1.3 Deaktivieren von nicht benötigten Daemonen und Diensten

In der Standard-Installation von Linux sind viele Daemonen und Dienste aktiviert, die es ermöglichen , sich an den Paketfiltern "vorbeizuschmuggeln".

Aus diesem Grund sind folgende Dateien zu editieren, um Änderungen darin vorunehmen :

Die Datei /etc/rc.config :

Bei der /etc/rc.config-Datei handelt es sich um die zentrale Konfigurationsdatei, in der praktisch alles konfiguriert werden kann. Folgende Werte sind zu ändern :

- IP_FORWARD="yes"

  (IP Forwarding ermöglicht ein Weiterleiten von Paketen zwischen mehreren Netzwerkkarten)

- START_INETD="no"

  (Der INET-Daemon ist ein zentraler Daemon, der alle Netzwerkdienste steuert)

- SMTP="no"

  (Es wird sicherlich keiner auf die Idee komme, seine Mails auf einem Paketfilter zu lesen)

- NFS_SERVER="no"

  (Es sollte auch kein NFS >Net File System< laufen)

- START_ROUTED="no"

  (Der Route-Daemon erlaubt eine dynamische Router-Funktionalität, die hier ebenfalls nicht erwünscht ist)

- START_FW="no"

  (FW bedeutet hier die SuSE eigene Firewall. Bei der SuSE Firewall handelt es sich um einen Paketfilter, der über eine zentrale Datei konfiguriert wird. Leider kann die Konfiguration nicht ausführlich genug gemacht werden, deshalb deaktivieren)

Die Datei /etc/inetd.conf :

Ein Datei, in der angegeben werden kann, welche Netzwerkdienste aktiviert werden sollen oder nicht.Zur Sicherheit sind hier alle Einträge mit "#" zu kommentieren und damit zu deaktivieren.

Die Datei /etc/rc.config/firewall.rc.config :

Sollte die SuSE-Firewall bei der Minimal-Installation mitinstalliert worden sein, dann ist auch in dieser Datei sicherheitshalber jeder Eintrag mit "#" zu kommentieren und damit zu deaktivieren.

Anmerkung : Bei der SuSE Linux 6.4 Komplett-Version ist die SuSE-Firewall bei der Minimal-Installation nicht installiert. Im Gegensatz dazu wird die SuSE-Firewall bei der Minimal-Installation von SuSE Linux 6.4 Evaluation Version mitinstalliert.

3.5.1.4 Installation von ipchains

Die Installation des Paketfilter-Programms ipchains wird auch über YaST vorgenommen.

Dazu ist YaST mit YaST aufzurufen, die Installations-CD zu mounten und das Paket ipchains in der Serie sec zu installieren.
ipchains kann so installiert werden, daß es bei jedem Neustart automatisch seine Konfiguration aus einer Konfigurations-Datei liest. Jedoch ist diese Einstellung nicht sinnnvoll.
Die hier beschriebene Lösung eines Paketfilters geht den Weg, daß ipchains über ein Shell-Skript aufgerufen wird. Die Gründe hierfür sind folgende:

Sicherheit:

  Sollte ein Übeltäter einen erfolgreichen Angriff auf das Firewall-System bzw. die Paketfilter ausgeführt haben und die Paketfiltert sind dabei abgestürzt, dann macht es keinen Sinn, die Maschinen einfach neu zu starten. Es sollte auf jeden Fall eine Überprüfung der Filterregeln stattfinden.

Übersichtlichkeit:

  In einem Shell-Skript kann die Konfiguration Schritt für Schritt nachvollzogen bzw. im Falle eines Angriffes kontrolliert und überprüft werden.

 

3.5.1.5 Grundlagen und Funktionsweise von ipchains

Linux 2.2 ipchains ist eine komplette Neuentwicklung des Linux IPv4 Firewall Codes, der hautpsächlich auf den Quellen von BSD 4.4 mit all seinen herausragenden Eigenschaften beruht. Es ist eine Portierung des ipfw Toolkit, welches aus der Feder von Darren Reed stammt, der auch bei den Portierungen auf Solaris 2.5/2.6/2.7 und den BSD Derivaten NetBSD, OpenBSD und FreeBSD mitgewirkt hat. [3]

Der Paketfilter beherrscht in der Standardkonfiguration drei Arten von Regeln. Diese Regeln werden chains genannt und sind : input, output und forward. Wenn ein Paket auf dem Paketfilter-Rechner eintrifft, dann ist dafür die input chain zuständig. Abgehende Datenpakete werden durch die output chain behandelt. Pakete, die von einem Netz-Interface zum nächsten geleitet werden sollen, sind in der forward chain beschrieben.

Eine chain ist eine Liste von Regeln, auch rules genannt. Jede Regel überprüft den Inhalt des Headers des Paketes und entscheidet, was dann zu tun ist. Ob das Paket z.B. abgelehnt oder weitergeleitet wird.

Ein Datenpaket, daß in einer chain ankommt, wird mit jeder Regel dieser chain verglichen und überprüft. Am End der chain angelangt entscheidet der Kernel darüber, welche policy für das Datenpaket zutrifft. policis können folgende sein :

ACCEPT Läßt das Paket in den Paketfilter.
REJECT Schickt ein ICMP Host unreachable reply an den ursprünglichen Sender, läßt dabei das Paket aber nicht in den Paketfilter
DENY Läßt das Paket nicht in den Paketfilter und gibt keine Meldung an den ursprünglichen Sender aus.
MASQ Läßt das Paket in den Paketfilter, maskiert es aber.

Für eine Übersicht aller ipchains-Befehle ist die "IP Chains Quick Reference"-Karte von Scott Bronson zu empfehlen, welche im Postscript-Format dem ipchains-Paket beiliegt.

Weitere Einblicke in ipchains liefert einem auch die Datei /usr/src/linux/net/ipv4/ip_fw.c ausführliche Kenntnisse. Jedoch sollte man über fundierte C-Kenntnisse verfügen.

Die Funktionsweise von den chains und den policies wird anhand der nachfolgenden Diagramme erläutert :

Abbildung 3.11: Schematische Funktionsweise der Input- und Output-Chains

Erklärung zu Abbildung 3.11:

Es handelt sich um eine schematische Darstellung der Input- und Output-Chains.

Jedes abgehende Paket wird durch jede einzelne Regel der Output-Chain geprüft und wenn alle Regeln in Ordnung sind, dann darf das Paket die Netzwerk-Karte passieren.

Die ankommenden Pakete werden durch jede einzelne Regeln der Input-Chain geprüft und dürfen erst dann weiterverarbeitet werden, wenn alle Regeln in Ordnung sind.

Die Forward-Chain funktioniert nach dem selben Prinzip. Die einzelnen Pakete werden durch die Forward-Regeln geprüft und wenn alle Regeln in Ordnung sind, dann wird das Paket "geforwardet", also weitergeleitet.

Abbildung 3.12: Schematische Funktionsweise der Policies

Erklärung zu Abbildung 3.12:

In der Abbildung 3.12 kann man sehr leicht die Funktionsweise der policies erkennen. Jedes IP-Paket wird in den chains überprüft. Wenn eine Regeln nicht zutrifft, dann wird auf die nächste Regel geprüft. Dies wird solange fortgeführt, bis das Ende einer chain erreicht wird.

Am Ende trifft dann die Default-Policy zu.

Wichtig: Immer die erste zutreffende Regel entscheidet über ein Paket. Wenn eine Regel zutrifft, dann werden alle nachfolgenden übergangen. Es ist deshalb besonders wichtig, daß alle Regeln nur einmal definiert werden und daß nachträgliche Regeln an den entsprechenden Stellen eingeführt werden.

 

3.5.1.6 Aufbau der Filterregeln

Für die Aufstellung der Filterregeln benötigt man als erstes eine Liste der notwendigen Ports und deren Umfang, also in welchen Adressbereichen diese Ports gelten (siehe Tabelle 3.1).

Als zweites sollte man sich Gedanken über die voreingestellte Policy machen.

Um die Konfiguration mit einem Shell-Skript zu realisieren ist eine beliebige Text-Datei mit einem Texteditor zu erstellen. In dieser Textdatei werden dann die einzelnen ipchains-Befehle nacheinander eingetragen.

Start des Shell-Skriptes geschieht durch:

  Shell Text-Datei

also z.B.:

  bash paketfilter1.conf

Wichtige Parameter von ipchains:

-A [chain] Hängt die Regel an das Ende der Chain [chain] an.
-I [chain] Fügt die Regel vor den Anfang einer Chain ein.
-i interface Die Netzwerkkarte, für die diese Regel gilt.
-p protokoll IP-Protokoll, für das diese Regel gilt.
-y Das SYN-Flag einer TCP-Nachricht muß gesetzt sein, jedoch darf das ACK-Flag nicht gesetzt sein.
-s adresse[port] Absender-Adresse eines Pakets. Wenn [port] angegeben wurde, dann gilt diese Regel nur für den angegebenen Port.
-d adresse[port] Empfänger-Adresse eines Pakets. Wenn [port] angegeben wurde, dann gilt diese Regel nur für den angegebenen Port.
-j policy Gibt die Polcy dieser Regel an.
-l Jedes mal, wenn diese Regel zutrifft, wird ein Eintrag in /var/log/messages gemacht.
-P [chain] Einstellen der default policy.

Festlegung der Default-Policy:

Die Default-Policy legt fest, was mit einem Paket passieren soll, wenn keine Regel zutrifft.

Eine sinnvolle Einstellung ist, daß alle ankommenden Pakete verworfen werden. Die ipchains-Befehle hierfür sind :

  ipchains P input DENY
  ipchains P ouput ACCEPT
 

ipchains P forward ACCEPT

Sicherheitstechnisch gesehen, kann man auf einem Paketfilter nur alle eingehenden Paketet verschließen. Ein Paketfilter sendet ja keine selbst erzeugten Pakete aus. Genauso mit der Forward-Chain.

Aktivieren des Loopback-Interfaces:

Auf das Loopback-Interface sollte alles zugelassen werden.

 

ipchains A input i lo j ACCEPT

 

ipchains A output i lo j ACCEPT

ICMP-Nachrichten:

ICMP-Nachrichten entstehen als Reaktionen auf bestimmte Fehler oder als Informationsquelle.

Die wichtigsten ICMP-Nachrichtentypen sind:

0 echo-reply Antwort auf ein ping,
3 destination-unreachable Zielhost bzw. Zielnetz ist nicht erreichbar,
4 source-quench Flusskontrolle,
5 redirect Nachricht über Wegstrecken,
8 echo-request Ein abgehendes ping,
11 time-exceeded Nachricht, daß die TTL eines Paketes abgelaufen ist,
12 parameter-problem Der Header des IP-Paketes enthält ungültige Werte

Die Regeln für ICMP-Nachrichten sehen folgender Maßen aus:

- Erlaube Ping (ICMP Typ 0 und 8)
- Erlaube destination-unreachable (ICMP Typ 3)
- Erlaube source-quench (ICMP Typ 4)
- Erlaube time-exceeded (ICMP Typ 11)
- Erlaube parameter-problem (ICMP Typ 12)
- Erlaube keine redirect-Nachrichten (ICMP Typ 5)

Die Variablen $ext_interface und $int_interface bezeichnen die IP-Adressen des Interface zum unsicheren und zu schützenden Netz des Paketfilters.

  # ICMP Echo-Reply
  ipchains -A input -i $ext_interface -s $ext_ip/0 0:0 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 0:0 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 0:0 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 0:0 -p ICMP -j ACCEPT
   
  # ICMP Echo-Request
  ipchains -A input -i $ext_interface -s $ext_ip/0 8:8 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 8:8 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 8:8 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 8:8 -p ICMP -j ACCEPT
   
  # ICMP Destination-Unreachable
  ipchains -A input -i $ext_interface -s $ext_ip/0 3:3 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 3:3 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 3:3 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 3:3 -p ICMP -j ACCEPT
   
  # ICMP Source-Quench
  ipchains -A input -i $ext_interface -s $ext_ip/0 4:4 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 4:4 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 4:4 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 4:4 -p ICMP -j ACCEPT
   
  # ICMP Time-Exceeded
  ipchains -A input -i $ext_interface -s $ext_ip/0 11:11 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 11:11 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 11:11 -p ICMP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 11:11 -p ICMP -j ACCEPT
   
  # ICMP Parameter-Problem
  ipchains -A input -i $ext_interface -s $ext_ip/0 12:12 -p ICMP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 12:12 -p ICMP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 12:12 -p ICMP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/0 12:12 -p ICMP -j ACCEPT

ICMP-Parameter-Problem wird durch die Default-Policy abgefangen.

 

Highports:

Sogenannte Highports, also Ports im Bereich von 1024 bis 65535, werden von verschiedenen Diensten verwendet. Als Beispiele sind FTP, DNS, HTTP und viele weitere zu nennen.

Regel für die High-Ports:

- Erlaube TCP High-Port-Anfragen von überall auf das externe und interne Interface in der input-Chain.
- Erlaube UDP High-Port-Anfragen von überall auf das externe und interne Interface in der input-Chain.

Die Befehle im einzelnen:

  ipchains -A input -i $ext_interface -s $ext_ip/0 1024:65535 -p TCP -j ACCEPT
  ipchains -A input -i $ext_interface -s $ext_ip/0 1024:65535 -p UDP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 1024:65535 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 1024:65535 -p UDP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 1024:65535 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 1024:65535 -p UDP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 1024:65535 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 1024:65535 -p UDP -j ACCEPT

HTTP (Port 80):

HTTP wird für das World Wide Web verwendet. Client und Server bauen dazu ganz normale TCP-Verbindungen auf. Diese geschehen über den TCP Port 80 und TCP Highports.

Die Regel lautet:

- Erlaube TCP Port 80 vom externen Netz über das externe Interface,
- Erlaube TCP Port 80 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 80:80 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 80:80 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 80:80 -p TCP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/0 80:80 -p TCP -j ACCEPT

Der Parameter /0 hinter der IP-Adresse gibt die Zahl der zu maskierenden Bits an. Dabei wird von links, also vom signifikantesten Bit, an gezählt.

SSL (Port 443):

SSL (Secure Socket Layer) dient dem abgesicherten, verschlüsselten Zugang zu WWW-Seiten. Um SSL zuzulassen, lauten die Regeln wie folgt:

- Erlaube TCP Port 443 vom externen Netz über das externe Interface,
- Erlaube TCP Port 443 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 443:443 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 443:443 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 443:443 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 443:443 -p TCP -j ACCEPT

DNS (Port 53):

Der DNS (Domain Name Service) dient zur Umsetzung zwischen IP-Adressen und Rechner-Namen. DNS verwendet sowohl UDP als auch TCP auf Port 53 und auf den Highports.

Die Regeln für DNS lauten :

- Erlaube TCP Port 53 vom FH-Netz über das externe Interface,
- Erlaube TCP Port 53 vom FH-Netz über das interne Interface,
- Erlaube UDP Port 53 vom FH-Netz über das externe Interface,
- Erlaube UDP Port 53 vom FH-Netz über das interne Interface,

Befehle im einzelnen:

  ipchains -A input -i $ext_interface -s $ext_ip/16 53:53 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/16 53:53 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/16 53:53 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/16 53:53 -p TCP -j ACCEPT
   
  ipchains -A input -i $ext_interface -s $ext_ip/16 53:53 -p UDP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/16 53:53 -p UDP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/16 53:53 -p UDP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/16 53:53 -p UDP -j ACCEPT

POP3 (Port 110):

Email braucht fast jeder, deshalb sollten auch für diese Anwendung die Ports geöffnet werden. POP ist ein Protokoll zum Abholen von Mails. POP benutzt ausschließlich TCP-Verbindungen.

Die Regeln für POP lauten:

- Erlaube TCP Port 110 vom externen Netz über das externe Interface,
- Erlaube TCP Port 110 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 110:110 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 110:110 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 110:110 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 110:110 -p TCP -j ACCEPT

SMTP (Port 25):

Das Gegenstück zu POP und IMAP ist SMTP (Simple Mail Transport Protocol). Es dient zum Senden von Mails. Es benutzt ausschließlich TCP-Verbindungen.

Die Regeln für SMTP lauten:

- Erlaube TCP Port 25 vom externen Netz über das externe Interface,
- Erlaube TCP Port 25 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 25:25 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 25:25 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 25:25 -p TCP -j ACCEPT
  ipchains -A output -i $int_interface -d $int_ip/0 250:25 -p TCP -j ACCEPT

NNTP (Port 119):

Das Network News Transfer Protocol, kurz auch News genannt, ist ein technologischer Nachfolger von UUCO. Es ermöglicht das Verteilen, Anfordern, Laden und Verschicken von Artikeln auf der Basis eines zuverlässigen, streamorientierten Übertragungsprotokolls also z.B. TCP.

Die Regeln für NNTP lauten:

- Erlaube TCP Port 119 vom externen Netz über das externe Interface,
- Erlaube TCP Port 119 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 119:119 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 119:119 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 119:119 -p TCP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/0 119:119 -p TCP -j ACCEPT

FTP (Port 20/21):

Das File Transfer Protocol dient zum Transferieren von Daten zwischen einem FTP-Client und einem FTP-Server. FTP benutzt im Gegensatz zum Trivial File Transfer Protocol (TFTP) ausschließlich TCP-Verbindungen. Die Übertragung von Steuersignalen wird mit Hilfe von Telnet-Kommandos abgewickelt.

FTP bereitet jedoch Probleme, wenn es durch eine Firewall benutzt wird. Mehr zu diesem Problem steht im Anhang A 3.

Die Regeln für FTP lauten:

- Erlaube TCP Port 20 und Port 21 vom externen Netz über das externe Interface,
- Erlaube TCP Port 20 und Port 21 vom internen Netz über das interne Interface,

Die Befehle dafür lauten:

  ipchains -A input -i $ext_interface -s $ext_ip/0 20:21 -p TCP -j ACCEPT
  ipchains -A input -i $int_interface -s $int_ip/0 20:21 -p TCP -j ACCEPT
  ipchains -A output -i $ext_interface -d $ext_ip/0 20:21 -p TCP -j ACCEPT
 

ipchains -A output -i $int_interface -d $int_ip/0 20:21 -p TCP -j ACCEPT

Forward-Chain:

Bei der Konfiguration des Paketfilter 1, darf kein Maskerading verwendet werden. Es soll ja von außen auf die DMS zugegriffen werden können.

Es ist dann ein "einfaches" Forwarding möglich.

Die Befehle für das Forwarding im einzelnen :

  ipchains -A forward -i $int_interface -s $int_ip/0 -d $ext_ip/0 -j ACCEPT
 

ipchains -A forward -i $ext_interface -s $ext_ip/0 -d $int_ip/0 -j ACCEPT

Um die Konfiguration abschließen zu können, muß nur noch das Forwarding-Modul im Kernel aktiviert werden.

Dies geschieht durch den Befehl :

 

echo 1 > /proc/sys/net/ipv4/ip_forward

à Die ganze Konfigurationsdatei für den Paketfilter 1steht im Anhang.

 

3.5.2 Paketfilter 2

Das hier vorgestellte Firewall-System besteht aus zwei Paketfiltern. Die Installation und Konfiguration des ersten Paketfilters wurde in den vorherigen Kapiteln bereits ausführlich erläutert und erlärt. Die Installation und Konfiguration des zweiten Paketfilters ist im Prinzip genau gleich wie die des ersten. Es sind aber an einigen Punkten andere Werte bzw. Parameter anzugeben. Einer dieser Parameter sind z.B. die IP-Adressen.

Für den Paketfilter 2 werden folgende IP-Adressen vergeben :

  Netzwerkschnittstelle eth0 192.168.1.254
  Netzwerkschnittstelle eth1 192.168.150.254

Die Netzwerkschnittstelle eth0 ist diejenige, die an das zu schützende Netzwerk angeschlossen wird. Dagegen wird die Netzwerkschnittstelle eth1 an die DMZ bzw. an den Application Gateway angeschlossen.

Die Konfiguration der Filterfunktion unterscheidet sich nur in wenigen Punkten, von der des Paketfilter 1.Es werden deshalb die Filterfunktionen nicht in aller Ausführlichkeit erklärt.

Als erstes sind die Einträge für die Protokolle HTTP, SSL und FTP nicht einzutragen. Für diese Protokolle werden Highports verwendet, die schon abgedeckt sind.

Ein weiterer wichtiger Punkt ist die Maskierung. Paketfilter 2, also jender, der das sicherer Netz mit dem Application Gateway verbindet, muß ein Maskierfunktion haben. Damit wird sichergestellt, daß die Rechner, welche sich im zu schützenden Netz befinden, der Außenwelt verborgen bleiben.

Die Befehle für die Maskierung im einzelnen:

  ipchains -A forward -i $int_interface -s $int_ip/0 -d $ext_ip/0 -j MASQ
  ipchains -A forward -i $ext_interface -s $ext_ip/0 -d $int_ip/0 -j MASQ

Es wurde hier eine Maskierung in beide Richtungen gewählt. Damit wird sichergestellt, daß die Konfiguration der IP-Adressen im zu schützenden Netz unabhängig von der Konfiguration des Application Gateways ist. D.h. bei einer Umstellung der internen IP-Adressen muß lediglich der Paketfilter 2 neu konfiguriert werden.

Nachteil: Es ist damit für das Application Gateway keine Authentifikation anhand der IP-Adresse möglich.

à Auch das Konfigurationsskript für den zweiten Paketfilter steht komplett im Anhang.

3.5.3 Das Application Gateway

Das Application Gateway ist das Herzstück der Firewall. Im Application Gateway werden die Benutzerauthetifikation und die Stellvertretung der einzelnen Protokolle durch Proxies durchgeführt.

3.5.3.1 Installation des Application Gateway

Als Betriebssystem auf dem Application Gateway wird auch Linux verwendet.

Die Installation der SuSE Linux Distribution auf dem Application Gateway geschieht folgendermaßen:

- Linux von CD1 booten,
- Warten, bis die Installationsauswahl erscheint, dann Yast 2 wählen.
- Die Partitionierung von Yast2 automatisch durchführen lassen,
- Minimale Installation wählen.
- Als Kernel ist der SMP-Kernel zu wählen, dieser aktiviert den zweiten Prozessor,
- Lilo im Master-Boot-Record installieren,

Es wird hier die Installation mit dem Yast 2 durchgeführt. Versuche haben gezeigt, daß eine Installation mit dem Yast 1 an verschiedenen, nicht rekonstruierbaren Stellen scheitert. Eine Web-Recherche hatgezeigt, daß der momentan eingesetzte Kernel noch Probleme mit IDE-Festplatte, die größer als 32 GB sind, hat.

Die Grund-Installation mit Yast 2 kann diese Problem umgehen.

Alle weiteren nachträglichen Schritte werden aber dann wieder mit dem Yast1 durchgeführt.Hier nun die Stichpunkte, die nach der Grund-Installation noch mit dem Yast 1 druchzuführen sind:

- Rechnername: proxy
- Domäne: fbefire1
- TCP/IP: Echtes Netzwerk
- Rechner als DHCP-Client betreiben: Nein
- Typ des Netzwerks: eth0
- IP-Adresse des Rechners: 141.18.69.250
- Netzmask: 255.255.255.0
- Adresse default Gateway: 141.18.69.1
- Inetd starten: nein
- Portmapper starten: nein
- News from-Adresse festlegen: proxy.fbefire1
- Auf Nameserver zugreifen: ja
- Als Nameserver folgende IP-Adressen eintragen: 141.18.1.12
- Auswahl Netzwerkkarte: 3Com 3c59x/3c90x
- Sendmail Konfiguration: Rechner mit permanenter Netzverbindung (SMTP)
- Passwort für root: *******
- Modem einrichten: nein
- Maus einrichten: ja (PS/2-Maus)
- openssh und sec nachinstallieren: ja
-  

Es ist weiterhin auch die zweite und dritte Netzwerkkarte zu installieren. Die IP-Konfiguration ist folgende :

Device

IP-Adresse

Subnetmask

Gateway

eth0

141.18.69.250

255.255.255.0

141.18.69.1

eth1

192.168.100.1

255.255.255.0

141.18.69.1

eth2

192.168.150.1

255.255.255.0

141.18.69.1

Tabelle 3.3: IP-Parameter des Application Gateway

 

3.5.3.2 Linux-Kernel Konfiguration und Compilierung

Um einen speziell auf einen Application Gateway zugeschnitten Kernel zu haben, muß dieser neu konfiguriert und neu compiliert werden. Dazu startet man YaST und wählt unter Einstellungen zu Installtion den Punkt Installtionsquelle auswählen. YaST gibt dann einige Auswahlmöglichkeiten, wobei hier die Installation von CD-ROM zu wählen ist.

Nachdem YaST nun die CD-ROM gemountet hat, wählt man im YaST Hauptmenü Installation festlegen/starten. Es wird nun ein neuer Bildschirm gezeigt, hier ist Installation ändern/erstellen zu wählen.

Für die Konfiguration und Compilierung des Kernels sind folgende Pakete notwendig :

- lx_suse aus der Serie d,
- make aus der Serie s,
- linux aus der Serie d,

Nachdem die Installation der Pakete abgeschlossen ist, wechselt man mit dem Befehl

 

cd /usr/src/linux

in das Kernel-Verzeichnis. Dort ist folgendes aufzurufen :

  make menuconfig

Es wird dann das Kernel-Konfigurations-Menü gezeigt :

Abbildung 3.13: YaST-Auswahl zur Kernel Neucompilierung

Folgende Funktionalitäten werden nicht benötigt und sind auf Disable zu setzen :

- ISA Plug & Play Support,
- SCSI Support,

Eine andere Funktionalität ist zu aktivieren bzw. einzubinden:

- Netzkartentreiber 3C590/3C900,

Als grundlegende Sicherheitseinstellungen für einen Application Gateway sollten folgende Funktionen aktiv sein. Diese gelten nur als allgemeine Richtlinie und können von System zu System variieren. [3]

- loadable module support,
- kernel daemon support,
- networking support,
- TCP/IP networking,
- IP: forwarding/gatewaying,
- IP: syn cookies,
- IP: accounting,
- IP: drop source routed frames.

Nach der Konfiguration des Kernels ist diese abzuspeichern. Folgende Kommandos schließen dann die Compilierung ab :

  make dep
  make bzImage
 

lilo

Ob der Kernel erfolgreich konfiguriert und compiliert wurde, läßt sich nach einem weiteren Neustart mit reboot ersehen.

3.5.3.3 Deaktivieren von nicht benötigten Daemonen und Diensten

In der Standard-Installation von Linux sind viele Daemonen und Dienste aktiviert, die es ermöglichen , sich an den Paketfiltern "vorbeizuschmuggeln".

Aus diesem Grund sind folgende Dateien zu editieren, um Änderungen darin vorunehmen :

Die Datei /etc/rc.config :

Bei der /etc/rc.config-Datei handelt es sich um die zentrale Konfigurationsdatei, in der praktisch alles konfiguriert werden kann. Folgende Werte sind zu ändern :

- IP_FORWARD="no"

  (IP Forwarding ermöglicht ein Weiterleiten von Paketen zwischen mehreren Netzwerkkarten)

- START_INETD="yes"

  (Der INET-Daemon ist ein zentraler Daemon, der alle Netzwerkdienste steuert)

- SMTP="no"

  (Es wird sicherlich keiner auf die Idee komme, seine Mails auf einem Paketfilter zu lesen)

- NFS_SERVER="no"

  (Es sollte auch kein NFS >Net File System< laufen)

- START_ROUTED="no"

  (Der Route-Daemon erlaubt eine Router-Funktionalität, die hier ebenfalls nicht erwünscht ist)

- START_FW="no"

  (FW bedeutet hier die SuSE eigene Firewall. Bei der SuSE Firewall handelt es sich um einen Paketfilter, der über eine zentrale Datei konfiguriert wird. Leider kann die Konfiguration nicht ausführlich genug gemacht werden, deshalb deaktivieren)

Die Datei /etc/inetd.conf :

Ein Datei, in der angegeben werden kann, welche Netzwerkdienste aktiviert werden sollen oder nicht.Zur Sicherheit sind hier alle Einträge mit "#" zu kommentieren und damit zu deaktivieren, außer den FTP-Dienst. Der FTP-Dienst wird zur Remote-Administration verwendet.

3.5.3.4 Einstellen der statischen Routen

Das Application Gateway muß genau Bescheid wissen, wie es in welche Netze kommt. Dies wird in der Datei /etc/route.conf eingestellt.

Der Inhalt der Datei sieht folgendermaßen aus:

192.168.150.0 0.0.0.0 255.255.255.0 eth2
192.168.100.0 0.0.0.0 255.255.255.0 eth1
192.168.1.0 192.168.150.254 255.255.255.0 eth2
141.18.69.0 0.0.0.0 255.255.255.0 eth0
default 141.18.69.1    

Man gibt genau das Netz an, welches über ein bestimmtes Interface mit einem bestimmten Gateway zu erreichen ist.

3.5.3.5 Installation von DeleGate

Als Proxy-Software wurde eine Produkt mit dem Namen DeleGate ausgewählt. DeleGate hat eintscheidende Vorteile gegenüber anderen Proxy-Paketen.

DeleGate ist als erstes einmal frei verfügbar (unter http://www.delegate.org). Es ist ein Open-Source-Paket, daß für verschiedenste Platformen verfügbar ist. DeleGate bietet darüber hinaus einen vielzahl an Proxies, die sehr flexibel konfigurierbar sind.

Die aktuellste Version ist unter ftp://ftp.delegate.org/pub verfügbar. Jedoch hat man erst dann Zugriff, wenn man sich als anonymous mit einer exisiterenden Email-Adresse anmeldet.

Um DeleGate auf einer Maschine zum laufen zu bringen, muß es kompiliert werden. Die Entwickler von DeleGate haben es einem so einfach wie nur möglich gemacht, das Paket zu erstellen.

Nach dem entpacken von DeleGate in ein eigenes Verzeichnis ( /delegate ) ist in diesem einfach nur noch make aufzurufen. Der Rest wird dann von selbst erledigt. Um jedoch dieses Paket kompilieren zu können muß vorher das Suse-Paket linux aus der Serie d installiert sein (s.o.).

Nach dem Compilieren erhält man einer Datei unter /delegate/src mit dem Namen delegated. Dies ist das eigentliche Programm.

Das Programm delegated ist der komplette Proxy. Er wird nur mit entsprechenden Parametern aufgerufen.

 

3.5.3.6 Wichtige DeleGate-Parameter

DeleGate verfügt über eine Vielzahl an Parametern, die nahezu keine wünsche offen lassen, was die Konfiguration betrifft. Hier sollen jedoch nur die wichtigsten erläutert werden, die auch bei der Konfiguration verwendet werden.

Eine ganaue Beschreibung alles Parameter wird mit jedem DeleGate-Paket mitgeliefert.

-P[PORT] Dieser Port wird von DeleGate überwacht.
SERVER=prot DeleGate fungiert als Proxy für das angegebene Protokoll.
ADMIN=email Dies ist der Deafult-Administrator, an den auch Emails im Fehlerfall gesendet werden.
ROUTE=[IP] Dies ist der Standard-Gateway für DeleGate. DeleGate erkennt dann anhand der IP-Adresse, über welches etzwerkinterface es seine eigene Anfragen stellt.
RES_NS=[IP] IP-Adresse des Nameservers, den DeleGate verwendet, um Namensauflösungen zu machen.
RELIABLE=[IP] DeleGate nimmt nur Anfragen entgegen, die von dieser IP-Adresse, IP-Adressen oder diesem Adressbereich kommen.
CACHE=[opt] Mit dieser Option kann man DeleGate veranlassen, Daten zu cachen, also zwischenzuspeicher.
MAXIMA=[opt] Damit werden z.B. Default-Zeiten, oder maximale Anzahl an FTP-Sitzungen eingestellt.
DGROOT=[vrz] Das Basis-Directory für alle DeleGate-Dateien.
VARDIR=[vrz] Basis-Directory für Log- und Cache-Dateien.
CACHEDIR=[vrz] Verzeichnis für Cache-Dateien.
LOGDIR=[vrz] Verzeichnis für Log-Dateien.
ERRORLOG=[vrz] Verzeichnis für Fehler-Log-Dateien.
WORKDIR=[vrz] Verzeichnis, indem sich DeleGate befindet.
ACTDIR=[vrz] Verzeichnis für temporäre Dateien.

3.5.3.7 DeleGate HTTP-Proxy

Einen HTTP-Proxy kann man über den Aufruf von folgendem starten. Die angegebenen Parameter werden anschließend erklärt.

 

/delegate/src/delegated P8080 SERVER=http CACHE=do ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

DeleGate hört nun auf Port 8080 nach dem Protokoll http. Der Administrator ist der root-User auf dem Application Gateway. Also Gateway soll DeleGate 141.18.69.1 verwenden. Für Namensauflösungen schaut DeleGate beim 141.18.1.12 nach. Erlaubt sind Zugriffe nur aus dem 192.168.150.0er Netz. Das Basisverzeichnis ist / . Das Verzeichnis für Log-Dateien und Fehler-Log-Dateien ist /var/log. Das Arbeitsverzeichnis, also wo sich DeleGate befindet, ist /delegate. Das temporäre Verzeichnis ist /tmp und das Basisverzeichnis für Logdateien ist /var.

3.5.3.8 DeleGate DNS-Proxy

Ein DNS-Proxy unter DeleGate wird mit folgendem Aufruf gestartet:

 

/delegate/src/delegated P53 SERVER=dns ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

Die Konfiguration eines DNS-Proxies unterscheidet sich nur unwesentlich von der eines HTTP-Proxies. Lediglich der "Lauschport" und der Servertyp wird verändert. Das selbe gilt auch für die nun folgenden drei weiteren Proxies.

3.5.3.9 DeleGate POP-Proxy

Aufruf für einen POP-Proxy :

 

/delegate/src/delegated P110 SERVER=pop ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

3.5.3.10 DeleGate SMTP-Proxy

Aufruf für einen SMTP-Proxy :

 

/delegate/src/delegated P25 SERVER=smtp ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

3.5.3.11 DeleGate NNTP-Proxy

Bei der Konfiguration eines NNTP-Proxies verhält sich DeleGate anders als bei den vorher beschriebenen Proxies. Der NNTP-Proxy von DeleGate ist kein Stellvertreter, der die Anfragen an den Zielserver stellt, sondern es wird die komplette Newsgroup auf dem Proxy-Server gespeichert. Es ist dazu notwendig, daß die zu benutzenden Newsgroups bei der Konfiguration angegeben werden. Die DeleGate.ORG arbeitet daran, daß man auch nachträglich verschiedene Newsgroups über die Remote-Administrations-Funktionalität einbinden kann. Hier eine Beispielkonfiguration mit der DeleGate- und der Microsoft-Newsgroup:

 

/delegate/src/delegated P119 SERVER=nntp MOUNT="= nntp://news.delegate.org" MOUNT="= nntp://msnews.microsoft.com" ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

Die Benutzung mehrerer Newsgroups geschieht durch die Angabe weiterer MOUNT-Parameter.

3.4.3.12 DeleGate FTP-Proxy

Ein FTP-Proxy ist unter DeleGate wie folgt zu konfigurieren. Die Parameter für einen FTP-Proxy unter DeleGate sind:

 

/delegate/src/delegated P8021 SERVER=ftp ADMIN=root@proxy ROUTE=141.18.69.1 RES_NS=141.18.1.12 RELIABLE=192.168.150.0 DGROOT=/ LOGDIR=/var/log ERRORLOG=/var/log WORKDIR=/delegate ACTSIR=/tmp VARDIR=/var

Mögliche Zugangsberechtigungen, wie z.B. schreiben auf einen FTP-Server, sollten bei dem entsprechenden FTP-Server geschehen. Dadurch wird der Umgang mit dem Firewall-System für den Benutzer erleichtert.

3.5.3.13 Umgang mit Konfigurations-Dateien

Bei sehr komplizierten Konfigurationen von DeleGate verliert man schnell den Überblick über die ganzen Parameter. DeleGate bietet deshalb die Möglichkeit, anstatt der Befehlszeilenparameter seine Konfiguration auch aus Dateien zu lesen.

DeleGate wird dann wie folgt aufgerufen:

 

/delegate/src/delegated +=/[PFAD]/[DATEI]

Bei der angegebenen Datei handelt es sich um eine reine Textdatei, die jeden Parameter in einer eigenen Zeile enthält.

Beispiel für eine Konfigurationsdatei für den beschriebenen HTTP-Proxy:

  Datei /delegate/conf/http.conf:
  P8080
  SERVER=http
  CACHE=do
  ADMIN=root@proxy
  ROUTE=141.18.69.1
  RES_NS=141.18.1.12
  RELIABLE=192.168.150.0
  DGROOT=/
  LOGDIR=/var/log
  ERRORLOG=/var/log
  WORKDIR=/delegate
  ACTSIR=/tmp
  VARDIR=/var

Um diesen Proxy mit der Konfigurationsdatei zu starten, ist folgendes einzugeben:

 

/delegate/src/delegated +=/delegate/conf/http.conf

Kommentare können in der Konfigurationsdatei mit # beginnend angegeben werden.Es ist dadruch möglich, sehr verständliche und leicht konfigurierbare Skripte zu schreiben.

3.5.3.14 Remote Administration von DeleGate

DeleGate bietet eine Remote-Administration. Genauer gesagt handelt es sich um eine Abfrage des aktuellen Status.

Die Remote-Administration geschieht über einen beliebigen Webbrowser. Das Kommunikationsinterface ist komplett in HTML gehalten.

Voraussetzungen:

1. Es muß ein User auf dem Application Gateway existieren. Dieser User braucht aber keine besonderen Rechte, wie z.B. root-Rechte zu besitzen.
2. Auf dem Application Gateway muß der FTP-Daemon aktiv sein. DeleGate verwendet für die Authentifikation und Identifikation das FTP-Protokoll. Am einfachsten aktiviert man in der Datei /etc/inetd.conf die Zeile mit FTP.

DeleGate-Parameter:

Die Remote-Administration wird bei DeleGate über nur einen Parameter eingerichtet. Der Parameter hat folgendes Format:

 

AUTH="admin:*:user@Identifikationsmaschine"

Als User ist der unter Linux angelegte User anzugeben. Der Wert für "Identifikations-maschine" ist die IP-Adresse des Rechners, auf dem der Benutzer angelegt wurde.

Web-Aufruf:

Um nun auf die Remote-Administrationsseite von DeleGate zu gelangen, ist folgende URL zu verwenden:

  http://[IP-Adresse von DeleGate]:[Lausch-Port des HTTP-Proxies/-/

Alle weiteren Seiten können über diese zentrale Informationsseite erreicht werden.

So z.B. die "Setup for the client"-Seite und die "Server administration"-Seite.

Beispiel:

1. Anlegen eines neuen Users, der für die Remote-Administration zuständig ist:

Dazu YaST aufrufen, und unter dem Menüpunkt "Administration des Systems" die "Benutzerverwaltung" aufrufen und folgendes eingeben.

Abblidung 3.14: Anlegen eines Users für die Remote-Administration von DeleGate

2. Sicherstellen, daß der FTP-Daemon gestartet ist. In der Datei /etc/inetd.conf muß die Zeile mit FTP aktiviert sein.

3. Den DeleGate-Proxie mit folgendem Parameter aufrufen:

  ... AUTH="admin:*:deleadmin@192.168.1.1"

4. Auf einem beliebigen Browser folgendes eingeben.

 

http://192.168.1.1:8080/-/

Als IP-Adresse kann man auch einen gültigen und eingetragenen DNS-Namen verwenden. Der Wert 8080 gibt den "Lausch"-Port des DeleGate HTTP-Proxies an. DeleGate nimmt nur auf diesem Port HTTP-Anfragen entgegen.

Es erscheint dann folgendes Bild:

Abblidung 3.15: Start-Seite der DeleGate Remote-Administration

Erläuterung der Status-Meldungen:

Version Die verwendete DeleGate-Version.
current-time Natürlich die aktuelle Uhrzeit des Application Gateways.
server-start Die Zeit, zu der der DeleGate-Server gestartet wurde.
server-count Leider keine Angaben (?).
server-alive Die Anzahl der momentan parallel gestarteten HTTP-Proxy-Server.
service-done Wie oft der HTTP-Proxy bisher erfolgreich Anfragen bearbeitet hat.
load_average Die CPU-Auslastung des DeleGate-Rechners.

Erläuterung der Configuration-Meldungen:

DELEGATE Name und "Lausch"-Port des HTTP-Proxies.
SERVER Momentan bearbeitende HTTP-Anfrage (in diesem Fall keine).
EXPIRE Zeit in Sekunden, bis der Cache-Speicher überschrieben wird.
CHARCODE Eingestellter Zeichensatz. DeleGate verfügt über eine Zeichnsatz-Translation, um z.B. japanische Schriftzeichen darstellen zu können.
ADMIN Der Administrator des DeleGate-HTTP-Proxies.

Das Menü "Setup for the Client" wird im folgenden dargestellt und erläutert:

Abblidung 3.16: Client Control von DeleGate-Remote-Administration

Als erstes kann man hier die eigene IP-Adresse und den momentan verwendeten Port erkennen.Des weiteren gibt DeleGate einem Auskunft über das verwendete Betriebssystem und den Browser. Damit ist der Rechner gemeint, von dem die Remote-Administration gemacht wird! Auch weitere Angaben, wie z.B. die verwendete Sprache, welche Dateien man öffnen und betrachten kann und ob ein Pack-Programm installiert ist, erkennt Delegate.

Unter "Current parallel sessions from your host" kann man erkennen, wieviele parallele Proxies DeleGate aufgemacht hat.

Die Angabe "The request number on this connection" gibt an, wie oft man, seit dem Server-Start, diese Seite angewählt hat.

Eine etwas wichtigere Seite ist die "Server administration", die im folgenden dargestellt und erläutert wird:

Abblidung 3.17: Remote-Server-Administration von DeleGate

Auf dieser Seite können Status-Abfragen gemacht werden, die der Öffentlichkeit nicht zugänglich sind.

Alle Menüpunkte auf dieser Seite sind paßwortgeschützt !

Um festzustellen, ob man sich bereits eingeloggt hat, dient die Angabe unter "Callback auth". Wenn nun ein Menüpunkt angewählt wurde, dann erkundigt sich DeleGate nach der Identifikation und Authentifikation, also Benutzername und Paßwort des Remote-Administrators.

 

Abblidung 3.18: Identifikation als Remote-Administrator unter DeleGate

Nachdem die korrekte Benutzerinformationen eingetragen wurden, können z.B. die aktuelle Konfiguration oder das Startup-Logbuch abgefragt werden. Der Server kann auch neu gestartet oder angehalten werden.

In der Zeile "Callback auth" wir nun auch dargestellt, ob man von DeleGate als Remote- Administrator berechtigt wurde oder nicht.

Eine erfolgreiche Identifikation und Authentifikation sieht wie folgt aus:

Abblidung 3.19: Erfolgreiche Identifikation als Remote-Administrator unter DeleGate

Under construction

Die Remote-Administration unter DeleGate befindet sich leider noch im Aufbau. D.h. einige Menüpunkte funktionieren noch nicht oder noch nicht richtig.

Es ist bis jetzt auch nur eine Remote-Administration für den HTTP-Proxy verfügbar. Die Delegate.org ist jedoch dabei, weitere Administrations-Tools zu schreiben.

3.5.4 Client Konfiguration und Benutzung der Proxy-Server

Die Konfiguration der Clients ist relativ einfach, da teilweise transparente Proxies verwendet werden. Transparente Proxies sind Proxies, die keine Port-Translation durchführen. Das bedeutet, daß das Client Programm einfach nur eine neue Serveradresse benötigt. Bei transparenten Proxies wird aber trotzdem die volle Stellvertreterfunktion erfüllt.

Nun aber die Konfiguration im einzelnen.

3.5.4.1 DNS-Server

Der DeleGate DNS-Proxy ist ein transparenter Proxy. Es gibt nahezu kein Betriebssystem, bei dem man für den Namens-Dienst einen anderen Port einstellen kann. Darum hört der DNS-Proxy auf Port 53 und stellt seine Anfragen auch durch Port 53 !

Als DNS-Server ist einfach der DNS-Proxy anzugeben. Die Anfragen werden dann von dem angegebenen DNS-Proxy gestellt und für die Clients präsentiert.

 

 

Bsp.: Microsoft Windows 98

Bsp.: Microsoft Windows NT 4.0

Abblidung 3.20: DNS-Client Konfiguration

Nach dem obligatorischen Neustart von Windows, greift das Betriebssystem nun für Namensauflösungen auf den DNS-Proxy-Server zu.

3.5.4.2 Webbrowser

Bei der Konfiguration des Webbrowsers muß als erstes einmal der Proxy-Server angegeben werden. Dies kann per Name oder IP-Adresse geschehen. Die Porteinstellungen sind im Gegensatz zu der DNS-Konfiguration ebenfalls zu ändern. Der HTTP-Proxy ist kein transparenter Proxy. Er hört auf den Port 8080 und stellt seine Anfragen über den Port 80 an den eigentlichen Webserver.

Bsp.: Microsoft Internet-Explorer 5.5

Bsp.: Opera 4.02

Abblidung 3.21: Konfiguration des Webbrowsers

Die Zugriffssteuerung erfolgt über den Benutzer "anonymous". D.h. der User merkt nichts von einem Proxy-Server.

3.5.4.3 E-Mail-Client

Die Konfiguration des Email-Clients scheint auf den ersten Blick etwas komplexer, jedoch auf den zweiten Blick logisch. Die Problematik die sich dabei stellt ist, woher kennt der Proxy-Server den eigentlichen Mail-Server ? Denn als Mail-Server gibt man ja den Proxy-Server an.

Die Lösung ist der Benutzername. Der DeleGate-Mail-Proxy erwartet als Benutzername folgende Konstellation:

  Benutzername@Mailserver

Somit weiß der Mail-Proxy, welchen Mail-Server man ansprechen möchte. Bei dem Mail-Proxy von DeleGate handelt es sich auch um einen transparenten Proxy. Es gibt immer noch Mail-Clients, bei denen sich die Port-Nummer nicht verstellen läßt. Um auch diese Programme zu verwenden, wurde bei DeleGate ein transparenter Mail-Proxy implementiert.

Sollte der Posteingangsserver ein anderer als der Postausgangsserver sein, so sind weitere Einstellungen notwendig.

 

 

 

Posteingangsserver am Beispiel von Microsoft Outlook Express

Postausgangsserver am Beispiel von Microsoft Outlook Express

Abblidung 3.22: Konfiguration der Email-Cleint-Software

 

3.5.4.4 FTP-Client

Der FTP-Proxy-Server von DeleGate ist ein "echter" Proxy, d.h. es handelt sich hierbei um keinen transparenten Proxy.

Textorientiertes FTP

Um auf den Proxy zu gelangen, gibt man z.B. unter der Eingabeaufforderung von Windows

 

ftp

ein. Es erscheint dann folgendes Bild:

Abblidung 3.23: Der Aufruf von FTP

Um nun auf den DeleGate-FTP-Proxy zu gelangen, ist folgendes einzugeben:

 

open 192.168.150.1 8021

Durch den Befehl open wird eine FTP-Sitzung geöffnet. Daran wird IP-Adresse des Proxy-Servers und die dazugehörende Port Nummer angehängt.

DeleGate meldet sich dann mit folgendem:

Abblidung 3.24: FTP-Proxy-Meldung von DeleGate

Als Anmeldenamen und Paßwort sind diejenigen einzugeben, die für den eigentlichen FTP-Server gelten. Nach der Eingabe erscheint folgendes Bild:

Abblidung 3.25: Authentifikation auf dem DeleGate-FTP-Proxy

Um nun auf den eigentlichen FTP-Server zu kommen, ist folgender Befehl einzugeben:

 

cd //[Remote-Server]

DeleGate nimmt dann selbständig die Verbindung zu dem FTP-Server auf und meldet sich mit den vorher angegebene Benutzereinstellungen an.

CuteFTP

Bei CuteFTP handelt es sich um ein kommerzielles, weit verbreitetes FTP-Programm, daß für die Windows-Plattform erhältlich ist.

Um mit CuteFTP über eine Firewall bzw. einen Proxy-Server arbeiten zu können, muß natürlich auch hier eine etwas andere Anwendung verwendet werden.

Abblidung 3.26: FTP-Zugriff mit CuteFTP

Erläuterung: Als FTP Host Address gibt man den Proxy-Server an. Der Proxy-Server stellt dann für uns die Anfragen an den unter FTP site User Name angegebenen Server. Die Notation hierfür ist wieder das bekannte:

 

User@[Remote-Server]

Als Paßwort wird das entsprechende verwendet.

Ganz wichtig ist auch noch der FTP site connect port Eintrag. Dies ist der Port, auf dem der Proxy-Server auf Anfragen "lauscht". Die Standard FTP-Ports 20 und 21 werden ja von den Paketfiltern blockiert.

LeechFTP

LeechFTP ist ein Freeware FTP-Client, der vor allem wegen seiner Freeware-Eigenschaft in der Beliebtheitsskala weit oben steht.

Auch bei LeechFTP muß nach dem Prinzip user@[Remote-Server] vorgegangen werden.

Abblidung 3.27: Verbindungsaufbau unter LeechFTP

Als Host ist auch hier der Proxy-Server anzugeben. Bei der Portnummer handelt es sich auch hierbei um den "Lausch"-Port des Proxies. Als Username wird wieder das user@[Remote-Server] Format verwendet. Als Paßwort wird das dem entsprechenden User zugeordnete verwendet.

2.5.4.5 News-Client

Die News-Client-Konfiguration wird hier am Beispiel von Microsofts Outlook aufgezeigt. Da die Konfiguration sehr einfach ist, läßt sie sich leicht auf andere News-Programme übertragen.

Die einzigen Unterschiede zur "normalen" News-Konfiguration bestehen darin, daß als News-Server das Application Gateway angegeben wird und daß nur die vorher bei der Proxy-Konfiguration eingebundenen Newsgroups gelesen werden können.

Abblidung 3.28: Konfiguration von Newsgroups

Nach einer Neuübetragung stehen alle eingebundenen Newsgroups zur Verfügung.

3.5.5 Fall-Back-Lösungen

Fall-Back-Lösungen sind sogenannte Notfallpläne, die im Falle eines Ausfalls von Teilsystemen oder des kompletten Systems zum Einsatz kommen. Ausfälle können verschiedene Ursachen haben.

Zum einen können Stromausfälle ein Grund für einen Ausfall sein. Um diesem trivialen Grund vorzubeugen ist auf jeden Fall eine ausreichend dimensionierte USV (Unterbrechungsfreie Stromversorgung) zu empfehlen.

Weitere Gründe können z.B. Hardwaredefekte, Fehlbedienungen, Angriffe oder "Launen" des Betriebssystemes sein.

3.5.5.1 Ausfall des Paketfilter 1

Der Ausfall des Paketfilter 1, also des Paketfilters, der direkt mit dem unsicheren Netz verbunden ist, ist ein großes Sicherheitsrisiko. Durch dessen Ausfall liegt der Application Gateway, also das Herzstück der Firewall, für jedermann offen.

Lösungsansatz für den Ausfall des "äußeren" Paketfilter ist folgender:

· Inneren Paketfilter umkonfigurieren,
  - IP-Adressen anpassen, aus privaten werden offizielle IP-Adressen,
  - DHCP-Server des internen Netz auf die neuen IP-Adressen umstellen,
  - Paketfilterskript anpassen, kein Maskerading, sondern Forwarding.

· Application Gateway umkonfigurieren,
  - Neue IP-Adresse für das Interface, welches bisher zum Paketfilter 2 ging.
  - Proxy-Konfiguration ändern, bisher hatte nur der Paketfilter 2 Zugriff auf die Proxies, nun aber der ganze private IP-Adressbereich (RELIABLE-Variable).

Leider beinhaltet dieser Lödungsansatz einen "Schönheitsfehler". Duch den Wegfall des Paketfilter 2 müssen die IP-Adressen des internen Netzes neu vergeben werden.

3.5.5.2 Ausfall des Paketfilter 2

Ein Ausfall des zweiten Paketfilters, also jener, der das Application Gateway von dem sicheren Netz trennt, stellt kein so schwerwiegendes Sicherheitsrisiko dar. Das Application Gateway ist immer noch komplett vor dem unsicheren Netz geschützt.

Lösungsansatz:

· Application Gateway umkonfigurieren,
  - Neue IP-Adresse für das Interface, welches bisher zum Paketfilter 2 ging.
  - Proxy-Konfiguration ändern, bisher hatte nur der Paketfilter 2 Zugriff auf die Proxies, nun aber der ganze private IP-Adressbereich (RELIABLE-Variable).

3.5.5.3 Ausfall des Application Gateway

Ein Ausfall des Application Gateway stoppt den kompletten Netzverkehr sofort. Es ist auch nicht möglich, ohne eine Umkonfiguration der Clients, nur mit den Paketfiltern zu arbeiten.

Ein Lösungsansatz wäre, einen "Notproxy" auf den Paketfiltern zu installieren. Zu empfehlen ist da der innere, also der zweite, Paketfilter. Der Grund: Die Hilfsproxies bleiben somit vor dem unsicheren Netz geschützt.

Lösungsansatz:

· Umkonfiguration des Paketfilter 2
  - Kernel-Forwarding abschalten (echo 0 > /proc/sys/net/ipv4/ip_forward),
  - ipchains-Funktionalitäten abschalten (ipchains P input ACCEPT, ipchans P output ACCEPT, ipchains P forward ACCEPT, ipchains F ),
  - Eingangsinterface mit neuer offizieller IP-Adresse konfigurieren,
  - Proxy-Skript starten,

Problem:

Die Server, die an das dritte Interface des Application Gateway angeschlossen waren, sind jetzt nicht mehr ansprechbar !

Lösungsmöglichkeit:

Die Server durch einen Switch oder Hub an die DMZ anschließen. Jedoch sind für die Server dann neue IP-Adressen erforderlich.

3.5.5.4 Totalausfall

Ein totaler Ausfall der Firewall stellt das größte Problem da. Als erstes kann auf die Server in der DMZ nicht mehr zugegriffen werden, als zweites können die Clients keinen Netzverkehr mehr mit der Außenwelt herstellen.

Lösungsmöglichkeit 1:

· Komplette Überbrückung der Firewall,
· Neukonfiguration der Clients, z.B. durch neue Images.

Lösungsmöglichkeit 2:

· Ersatzrechner mit DeleGate bereitstellen und vorhandenes Proxy-Skript starten,
· Anschluß der Dienstserver hinter dem Application Gateway,

Bei der zweiten Lösungsmöglichkeit sei jedoch darauf hingewiesen, daß das Application Gateway völlig ungeschützt an das unsichere Netz angeschlossen ist !

3.5.5.5 Anmerkung

Die hier vorgestellten Lösungmöglichkeiten stellen nur einen Lösungsansatz dar. Nach möglichst schnellem Ersatz für das ausgefallene System ist auf jeden Fall zu schauen, da die Sicherheit von dem Zusammenspiel der einzelnen Komponenten abhängt. Ein Ausfall eines Teilsystemes und dessen "Notüberbrückung" stellt ein nicht kalkulierbares Sicherheitsrisiko dar !

Um die Überbrückungszeit so gering wie nur möglich zu halten, sind sogenannte Drive-Images von Vorteil. Diese werden bei einer Ersatzmaschine nur eingespielt und stellen in kürzester Zeit ein System wieder her ohne lästiges Neuinstallieren.

3.5.6 Sicherheitsüberprüfung der Paketfilter

Eine Überprüfung der Sicherheit eines Firewall-Systems muß auf jeden Fall durchgeführt werden. Selbst wenn man beim Aufbau noch so vorsichtig und gewissenhaft vorgeht, schleichen sich immer wieder Sicherheitslücken ein. Diese auszumerzen ist die Aufgabe einer Sicherheitsüberprüfung.

3.5.6.1 Paketfilter mit Einzelpaketen testen.

Das hier verwendete Filtertool ipchains verfügt über einen eigenen Überprüfungsmodus. Ipchains kann seine Filterregeln mit Einzelpaketen testen. Hierzu werden virtuelle Pakete in die Filterchain geschickt und ipchains gibt aus, was mit einem zuvor definierten Paket geschehen wird.

Der Aufruf eines solchen Testpaketes geschieht mit folgender Syntax:

 

ipchains -C [Chain] -i [Interface] -p [Protokoll] -s [Quell IP und Port] -d [Ziel IP und Port]

Ipchains antwortet auf eine solche Anfrage mit der eingestellten Policy. Also accept, reject, deny, masq, redirect oder return.

Beispiel für ein ICMP-Paket:

 

ipchains -C input -i eth0 -p ICMP -s 192.168.1.1 8 -d 192.168.1.254 8

Der Befehl gibt an, es soll die Input-Chain auf dem Interface eth0 getestet werden. Als Protokoll wird ICMP verwendet. Das Paket kommt von der Station 192.168.1.1 und geht an die Station 192.168.1.254. Es handelt sich dabei um den ICMP-Befehl echo request, der mit der 8 angegeben wird.

Ipchains antwortet in unserem aufgebauten Fall mit accepted. D.h. ein Paket, das die angegebenen Parameter enthält, würde von der Input-Chain des Paketfilters angenommen und weitergegeben werden.

Eine komplette Überprüfung der beiden Paketfilter und deren Auswertung steht im Anhang.

3.5.6.2 Allgemeine Tips für die Paketfilter-Entwicklung

Nachfolgend ein paar sinnvolle und vernünftige Tips zur Entwicklung und zum Aufbau eines Paketfilters [5]:

- Regeln immer als vollständiges Skript ausführen. Damit wird im Fall eines Absturzes gewährleistet, daß das System und vor allem die Filterregeln rekonstruierbar sind.
   
- Keine neue Regeln über die Kommandozeile eingeben. Dadurch kann z.B. bei einer Remote-Sitzung die Sitzung komplett abbrechen !
   
- Schrittweise vorgehen. Also immer nur einen Dienst nach dem anderen aktivieren bzw. deaktivieren.
   
- Wichtig: Immer die erste passende Regel gewinnt ! Beim Anfügen von neuen Regeln unbedingt beachten.
   
- Wenn das Skript hängen bleibt, dann benutzt eine Regel vermutlich einen symbolischen Hostnamen statt einer numerischen IP-Adresse. Wenn dann durch Zufall der DNS-Port deaktiviert wurde, kann ipchains keine Namensauflösung mehr machen. Also nach Möglichkeit immer numerische IP-Adressen verwenden.
   
- Sollte ein Dienst nicht funktionieren, dann erst mal mit der Option -l die Protokollierung aktivieren und schauen, was wirklich los ist, als irgendwelche "Verzweiflungstaten" zu tun.
   
-

Bei Forwarding und Masquerading muß die Kernelfunktion IP-Forward aktiviert sein !Am besten nimmt man den Befehl für die Aktivierung in das Skript mit auf !

echo 1 > /proc/sys/net/ipv4/ip_forward

   
- Der Routing-Dämon muß abgeschaltet sein !

 

3.5.6.3 Portscanner

Portscanner sind ein wichtiges Tool, um die Sicherheit eines Systems zu überprüfen. Portscanner arbeiten nach folgendem Prinzip. Sie versuchen, auf allen nur möglichen TCP und UDP-Ports eine Verbindung aufzubauen. Gelingt ihnen ein Aufbau zu einer bestimmten Anwendung auf einem bestimmten Port, dann handelt es sich dabei um eine potentielle Sicherheitslücke.

Portscanner sollten auch beim Aufbau von Paketfiltern als Überprüfungstool eingesetzt werden. Denn was nützen einem die tollsten und aufwendigsten Filterregeln, wenn auf der Maschine der Telnet-Dämon mit anonymous-Rechte läuft ?

Bei der Überprüfung der hier aufgebauten Paketfilter wurde der Port Scanner Super Scan in der Version 2.08 verwendet. Er ist wie viele andere Portscanner frei über das Internet verfügbar, z.B. unter http://members.home.com/rkeir/software.html. Im Internet gibt es eine Vielzahl von Portscannern, für verschiedene Betriebssysteme und mit tausenden Erscheinungsbildern.

Die Überprüfung der hier aufgebauten Paketfilter ergab folgendes Bild :

Ursprungsnetz

Ziel-IP-Adresse

Rechner

Offene Ports

141.18.253.0

141.18.253.69

Paketfilter 1

113 auth

141.18.253.0

141.18.69.1

Paketfilter 1

113 auth

141.18.69.0

141.18.253.69

Paketfilter 1

113 auth

141.18.69.0

141.18.69.1

Paketfilter 1

113 auth

192.168.1.0

192.168.1.254

Paketfilter 2

113 auth

192.168.1.0

192.168.150.254

Paketfilter 2

113 auth

192.168.150.0

192.168.1.254

Paketfilter 2

113 auth

192.168.150.0

192.168.150.254

Paketfilter 2

113 auth

Tabelle 3.4: Portscann-Ergebnis der Paketfilter

Der offene Port auf den Paketfiltern dient dem Ident-Dämon von Linux. Der Ident-Dämon dient zu Identifikation von Benutzer, sowohl lokal als auch per remote. Eine Abschaltung diese Dienstes würde zwar den offenen Port schließen, jedoch auch eine Anmeldung auf der Maschine unmöglich machen.

Da sonst keine anderen Netzwerkdienste, wie etwa Telnet oder FTP laufen, kann man dieses Sicherheitsloch in Kauf nehmen. Schließlich läuft kein anderer Netzwerk-Dienst, der eine Identifikation benötigt.

3.5.6.4 Flushing-Angriff

Unter einem Flushing-Angriff versteht man, das Netzwerkinterface eines Rechners mit Paketen zu überschütten. Nach Möglichkeit mit UDP-Paketen, da diese keine Bestätigung erfordern.

In der Vergangenheit gab es Betriebssysteme und Fehler in solchen, die bei einem Flushing-Angriff abgestürzt sind, oder sich danach in einem unbestimmten Zustand befanden. Bei heutigen Betriebssystemen ist ein solcher Zustand zwar nahezu auschließbar, jedoch sollte trotzdem eine Überprüfung stattfinden, um die Reaktion des Systems zu erfahren. Flushing-Programme wie z.B. ICMP-Bomber oder UDPFlush findet man auch im Internet. Leider sind diese Internetseiten nicht dauerhaft verfügbar oder umgezogen. Jedoch finden die meisten Suchmaschinen diese Programme.

Bei den hier aufgebauten Paketfiltern wurde ein Flushing-Angriff mit UDP- und ICMP-Paketen vollzogen. Als Parameter wurden folgende gewählt :

UDP:

- Port 23 (geschlossen), mit zufälliger Paketgröße und runden 2800 Paketen/s.
- Port 1025 (offen), mit zufälliger Paketgröße und runden 2800 Paketen/s.

ICMP:

- Typ 8 (echo request, offen), mit verschiedenen Paketgrößen (10, 500, 1400, 25000 Bytes) und runden 1900 Paketen/s.
- Typ 5 (redirect, geschlossen), mit verschiedenen Paketgrößen (10, 500, 1400, 25000 Bytes) und runden 1850 Paketen/s.

Der Angriff wurde auf jedes einzelne direkt erreichbare Netzwerkinterface der Paketfilter und auf das gegenüberliegende, also durch die Paketfilter hindurch, gestartet.

Bei allen Angriffen erscheint das gleiche Bild. Die Paketfilter bearbeiteten die ersten 2-4 Sekunden die Anfragen. Lehnten sie ab, oder leiteten sie weiter. Nach den etwa 2-4 Sekunden brach die Verbindung ab. Die Paketfilter hatten den Angriff bemerkt und haben ihre Netzwerkinterfaces geschlossen. Nach etwa weiteren 2 Sekunden wurden die Netzinterfaces wieder geöffnet um nachzuschauen, ob "die Luft rein" ist. Hielt der Angriff an, so wurde alles von vorne wiederholt. Also eine sinnvolle Reaktion der Paketfilter.

3.5.6.5 Resultat

Die Paketfilter habe die Sicherheitsüberprüfung bestanden. Die Reaktionen auf die einzelnen Tests sind als sinnvoll zu bezeichnen.

Jedoch sollte auch während des Betriebes eine regelmäßige Überprüfung der Sicherheit geschehen. Zum einen eine Überprüfung der Log-Dateien und eventuell eine Überprüfung der verwendeten Ports mit dem Tool netstat.

3.5.7 Sicherheitsüberprüfung des Application Gateways

Das Application Gateway ist das Herzstück eines Firewall-Systems. Über das Application Gateway werden alle Anfragen, die in das unsichere Netz gehen, entgegengenommen und stellvertretend weitergeleitet. Eine Überprüfung der Sicherheit dieses "Herzstücks" der Firewall ist äußerst wichtig.

3.5.7.1 Portscanner

Um einen ersten Überblick zu bekommen, wird wie bei den Paketfiltern ein Portscan durchgeführt. Ein Portscan zeigt die potentielle Angriffsmöglichkeiten auf ein Firewall-System an. Offene Ports sind wie Türen, die man "nur" noch zu öffnen braucht.

Portscans werden auf das Application Gateway direkt durchgeführt. Also ohne dazwischen geschaltete Paketfilter. Die Scans werden einmal auf das Eingangsinterface (IP 141.18.69.250) und auf das Ausgangsinterface (192.168.150.1) durchgeführt.

Die Scans ergaben folgendes Bild:

Scann auf 141.18.69.250 :

Offener Port

Beschreibung

25, SMTP

Transparenter Mail-Proxy (versenden)

110, POP3

Transparenter Mail-Proxy (empfangen)

119, NNTP

Transparente News-Proxy

8021, FTP-Proxy

FTP-Proxy

8080, HTTP-Proxy

HTTP-Proxy

Tabelle 3.4: Portscan auf das zum sicheren Netz gerichtete Interface des Application Gateway

Scann auf 192.168.150.1 :

Offener Port

Beschreibung

25, SMTP

Transparenter Mail-Proxy (versenden)

110, POP3

Transparenter Mail-Proxy (empfangen)

119, NNTP

Transparente News-Proxy

8021, FTP-Proxy

FTP-Proxy

8080, HTTP-Proxy

HTTP-Proxy

Tabelle 3.5: Portscan auf das zum sicheren Netz gerichtete Interface des Application Gateway

Etwas verwunderlich scheint, daß bei den Portscans der Port für DNS, also Port 53, nicht erscheint. Vermutlich ist dies auf eine zu kurze Scanzeit, also die Zeit, in der nach einem Port gesucht wird, oder auf eine schlechte Scanner-Architektur zurückzuführen.

Um das Problem der schlechten Scanner-Architektur auszuschließen, wurden auch Scanner anderer Hersteller verwendet, jedoch ohne Unterschied.

Es ist klar, daß auf dem Application Gateway so viele Ports offen sein müssen. Schließlich schleußt das Application Gateway die Anfragen nicht einfach durch, sondern dient als Stellvertreter.

Erläuterung der offenen Ports:

- Port 25, SMTP. Hier handelt es sich um einen transparenten Proxy, der die Anfragen auf dem gleichen Port entgegen nimmt, wie er sie auch wieder an das unsichere Netz stellt.
- Port 110, POP. Wiederum ein transparenter Proxy,
- Port 119, NNTP. Hierbei handelt es sich auch um einen transparenten Proxy. Jedoch mit dem Unterschied, daß der NNTP-Proxy als "echter" Stellvertreter dient. Der NNTP-Proxy von DeleGate lädt die kompletten Newsgroups auf seine Festplatte und dient dann als eigenständiger Newsserver.
- Port 8021, FTP. Bei dem FTP-Proxy handelt es sich nicht um einen transparenten Proxy. Der FTP-Proxy von DeleGate nimmt Anfragen über den Port 8021 entgegen und schickt seine Anfragen über die Ports 20/21 an das unsichere Netz.
- Port 8080, HTTP. Wiederum ein "Standard"-Proxy, der seine Anfragen über den Port 8080 bekommt und diese dann stellvertretend über den Port 80 in das Internet schickt.

 

3.6.7.2 Nutzung von Außen

Eine sehr wichtige Überprüfung ist die Nutzung von Außen. DeleGate-Proxies sind standardmäßig so konfiguriert, daß sie über jedes Netzwerkinterface angesprochen werden können. Durch den RELIABLE-Befehl wird genau definiert, welche Rechner bzw. welcher IP-Adressbereich überhaupt Zugriff hat.

Die Konfiguration wurde so gewählt, daß nur Rechner mit der IP-Adresse 192.168.150.254 Zugriff auf die Proxies haben. Diese IP-Adresse ist das Interface des zweiten Paketfilters, welches an die DMZ, also an das Application Gateway angeschlossen ist. Es wurde nur eine IP-Adresse und kein IP-Adressbereich gewählt, da auf dem Paketfilter die Maskerading-Funktionalität aktiviert ist.

Um zu überprüfen, ob das Application Gateway auch von Außen genutzt werden kann, wurde zum einen ein Rechner außerhalb der Firewall im unsicheren Netz installiert und zum anderen ein Rechner zwischen Paketfilter 1 und Application Gateway, also in der DMZ.

Die Rechner sind so konfiguriert, wie sie normalerweise im sicheren Netz konfiguriert werden. D.h. die Rechner sind für die Bentutzung der DeleGate-Proxies eingestellt.

Bei beiden Rechnern erschien das selbe Bild:

Es war nicht möglich, die Proxies sowohl vom unsicheren Netz als auch von der DMZ zu benutzen. Es ist also sichergestellt, daß ein Mißbrauch der Proxies von außen nahezu unmöglich ist.

3.5.7.3 Flushing-Angriff

Flushing-Angriffe sind gleich wie bei den Paketfiltern durchzuführen. Jedoch sollte sichergestellt werden, daß sich zwischen dem angreifenden Rechner und dem Application Gateway kein Paketfilter befindet. Alle Tests werden also von der DMZ aus durchgeführt.

Das Application Gateway reagierte auf das Bombardement von UDP- und ICMP-Paketen gleich wie die Paketfilter. Nach kurzer Zeit, also etwa 2-4 Sekunden machte das Application Gateway seine Interfaces dicht. Nach weiteren 2-4 Sekunden wurden die Interfaces wieder geöffnet, um nachzuschauen, ob der Angriff noch andauert, oder ob die "Luft" wieder rein ist.

Also wie bei den Paketfiltern eine gewünschte und durchaus sinnvolle Reaktion.

3.5.7.4 Überwachung während des Betriebes

Das Application Gateway ist die optimale Angriffsfläche für Hacker, Viren und andere Bösewichte. Es ist deshalb unbedingt notwendig, auch während des Betriebes das Application Gateway zu überwachen.

Ein Standardwerkzeug für eine solche Überwachung ist das Programm netstat. netstat kann die aktuellen Verbindungen und die verwendeten Ports aufzeigen. Dazu ist der Befehl:

  netstat a (oder netstat a n für eine numerische Ausgabe)

zu verwenden. netstat liefert dann eine Auflistung aller Verbindungen und der verwendeten Ports. Bei dieser Überwachung sollte überprüft werden, ob das Application Gateway noch andere Ports außer den definierten verwendet. Sollten andere Ports auftauchen, dann zeigt dies eine falsche Konfiguration oder einen Angriff auf. In diesen Fällen ist eine Überprüfung des Sicherheitskonzeptes notwendig.

 

3.5.8 Performance des Firewall-Systems

Ein nicht zu unterschätzender Faktor bei dem Aufbau eines Firewall-Systems ist die Performance. Denn was bringt einem die "schönste" Firewall, wenn sie nicht in der Lage ist, die angeforderten Datenpakete zu bearbeiten ?

Um jedoch eine eindeutige und umfassende Performance-Analyse zu machen, ist eine große Anzahl an Clients notwendig. Es gibt sogar Firmen, die sich nur auf die Analyse der Leistungsfähigkeit eines Firewall-Systems spezialisiert haben. Dies macht deutlich, daß das Messen der Leistungsfähigkeit keine triviale Sache ist.

Im Umfang dieser Diplomarbeit war es nicht möglich, eine umfangreiche Messung der Firewall durchzuführen. Deshalb werden hier nur Zusammenfassungen von verschiedenen Berichten, Erfahrungswerte und Möglichkeiten zur Leistungsanalyse aufgezeigt.

3.5.8.1 Paketfilter:

In einem Firewall-System wird der gesamte Datenverkehr durch einen oder mehrere Paketfilter geschleust. Ein absolutes Leistungsmerkmal für die Beurteilung von Paketfiltern ist also :

  gefilterte Pakete / Sekunde

Um eine Vorstellung zu geben, wie intensiv jedes einzelne Paket behandelt wird, hier ein paar Zahlen:

Auf einem Linux-System mit Kernel 2.2.x werden folgende CPU-Zyklen pro Paket verbraucht [3]:

- IP Pakete an der Netzwerkkarte : 50-100 CPU Zyklen,
- IP Pakete, Filterung nach Quelle und Ziel: 100-200 CPU Zyklen,
- TCP Paket, Filterung nach Port, Quelle und Ziel: 200-400 CPU Zyklen.

Die Zahlen erscheinen hoch. Wenn man aber bedenkt, daß ein heutiges Rechnersystem mit 1 GHz getaktet wird, dann wird für einen CPU-Zyklus lediglich 1ns benötigt. Natürlich ist diese Betrachtung sehr vage. Die Leistungsfähigkeit eines Paketfilter hängt nicht nur von der reinen CPU-Leistung ab. Auch das Betriebssystem spielt eine nicht unwesentliche Rolle. Z.B. war das Linux 2.0 System um den Faktor 2-15 langsamer !

Für verschiedene Anwendungsgebiete ist folgende Hardwareausstattung ausreichend [3][5]:

Anwendungsgebiet

Hardwareausstattung

Paketfilter mit ISDN-Router

80386-33 mit 16 MByte RAM

Paketfilter mit DSL-Router

Pentium 66 mit 16 MByte RAM

Paketfilter für 10 MBit/s Netzwerk

Pentium 166 mit 64 MByte RAM

Paketfilter für 100 MBit/s Netzwerk

Pentium II 300MHz mit 64 MByte RAM

Tabelle 3.6: Hardwareanforderungen bei Paketfiltern

Natürlich sind diese Angaben nur "Daumenwerte" und dienen zur groben Orientierung. Was jedoch auffällt ist, daß für kleinere Netzwerke mit niedrigen Bandbreiten auch ein alter ausrangierter Rechner als Paketfilter dienen kann.

3.5.8.2 Application Gateway:

Die Leistungsfähigkeit eines Application Gateways zu beurteilen ist etwas schwieriger als bei einem Paketfilter. Bei einem Application Gateway zählt nicht allein der reine Datendurchsatz, sondern auch die Reaktionszeiten. Also wie lange der Proxy benötigt, um eine Verbindung aufzubauen. Des weiteren ist auch die Anzahl der parallel möglichen Verbindungen wichtig. Wenn man jedoch bedenkt, daß Linux 2.2 und 2.0 eine Beschränkung auf maximal 1024 Prozesse bzw. maximal 1024 Threads hat, dann stellt dies die "natürliche" Grenze für die Leistungsfähigkeit dar.

Es wird auf einem Application Gateway also genügend CPU-Kapazität benötigt um, schnell neue Prozesse zu starten und Verbindungen aufbauen zu können. Optimal sind hier Maschinen mit mehreren Prozessoren.

Die nächste Grenze ist der Hauptspeicher. Denn jede TCP-Verbindung beansprucht einen Puffer im RAM, der bei Linux je nach verwendeter Version und Prozessortyp schwankt. Als Standardwert kann hier etwas über 32KByte angegeben werden. Es muß jedoch berücksichtigt werden, daß auf einem Application Gateway immer zwei Verbindungen offen gehalten werden müssen. Eine nach innen und eine nach außen.

Beispiel aus [3]:

Absicherung eines WWW-Servers. Bei 50.000 offenen Zugriffen auf den WWW-Server oder die Serverfarm müssen also mind. 100.000 simultane TCP-Verbindungen offen gehalten werden können. Hier ist also eine RAM-Ausstattung von 128 MByte die Untergrenze.

3.5.8.3 Parameter für den Application Gateway:

Bei jedem vernünftigen Proxy können verschiedenste Parameter eingestellt werden. So auch bei DeleGate. Die Parameterliste reicht von maximal zulässigen FTP-Verbindungen über die max. Anzahl von Standby-Prozessen bis zu Timeouts für DNS.

Diese Parameter haben bei DeleGate einen Default-Wert. Diese Default-Werte sollten je nach Umgebung geändert werden. Verfügt das Netzwerk z.B. über einen langsamen DNS-Server, so sind die Timeouts für DNS höher zu setzten. Handelt es sich bei dem Application Gateway um eine leistungsfähige Maschine, so können z.B. mehr parallele Prozesse gestartet werden.

Eine Auflistung von sinnvollen Parametereinstellungen:

Parameter

Wert

Max. Anzahl der parallelen Verbindungen

800-1200

Max. Anzahl der parallelen FTP-Sitzungen

50-75

Timeout für DNS lookup

60 sec.

Timeout für Datentransfer, allgemein

600 sec.

Timeout für Login

60 sec

Tabelle 3.7: Parameter für den Application Gateway

Es ist unbedingt wichtig, daß diese Parameter nicht absolut sind. D.h. während des Betriebes sollte regelmäßig die Auslastung des Systems beobachtet werden und gegebenenfalls die Parameter angeglichen werden. Wenn z.B. regelmäßig ein DNS-Error erscheint, dann sollte der Timout-Wert für DNS lookups schrittweise erhöht werden.

3.5.8.4 Überwachung während des Betriebes:

Um die Leistungsfähigkeit eines Application Gateways beurteilen zu können, und um eine sinnvolle Einstellung der Parameter zu gewährleisten ist eine Überwachung während des Betriebes notwendig.

Wichtige Kriterien für die Überwachung sind folgende:

- CPU-Auslastung in Abhängigkeit der Anzahl der Prozesse,Hiermit wird überprüft, ob die Leistungsfähigkeit der CPU für die Aufgaben ausreichend ist oder nicht.
   
- Freier Arbeitsspeicher in Abhängigkeit der Anzahl der Prozesse,Hiermit kann beurteilt werden, ob der Hauptspeicher seinen Aufgaben gewachsen ist.
   
- Bandbreitenüberprüfung mit z.B. LinkView von Wandel & Goltermann in Abhängigkeit der Anzahl der Prozesse.

Um nun eine Beurteilung der Leistungsfähigkeit vorzunehmen, sollte die Überprüfung mehrmals durchgeführt werden. Es kann damit das dynamische Leistungsverhalten des Application Gateways aufgezeigt werden.

Sollten die Kriterien im "roten" Bereich sein, also die CPU-Auslastung immer über 90% und der Arbeitsspeicher immer zu 90% gefüllt, dann befindet sich die Maschine schon im Höchstlastbereich. Es ist dann zu überlegen, ob eine leistungsfähigere Maschine als Application Gateway einzusetzen ist.