7 Firewall-Systeme
<< | < | = | > | >>
7.1 Einführung
Ein Firewall-System weist eine unverkennbare Analogie zu einem elektronischen Pförtner und einer elektronischen Brandschutzmauer auf. Sie sichert und kontrolliert den Übergang von einem zu schützenden Netz zu einem unsicheren öffentlichen Netz. Dabei muss ein Firewall-Element grundsätzlich zwei Aspekte erfüllen, um der besagten Analogie gerecht zu werden:
  • Brandschutzmauern

  • Als erstes ist ein Firewall-Element dafür zuständig einen Bereich in einem Netzwerk abzusichern, um eine Schadensbegränzung in einem Notfall einzuräumen. Die eskalierende Seite wird so abgeschottet, dass Schäden nicht auf andere Teile des Netzes überschwappen können. Entsprechend wird das Gebäude einer Organisation in bestimmte Abschnitte unterteilt, damit beim Ausbruch von Feuer in einem Segment nicht andere Teile der Lokation ohne weiteres griffig für Schäden werden können. Auf Kommunikationsnetze bezogen bedeutet dies, dass das Firewall-Element das zu schützende Netz gegen Gefahren aus dem unsicheren Netz abkapselt. Es wird nur ein einziger, sicherer und bewachter Durchgang zwischen den beiden Teilnetzen gewährleistet: Der sogenannte "Common Point of Trust".
     
  • Pförtner

  • Ein Firewall-System hat zudem die Aufgabe als Analogie zum Pförtner den Transfer zu kontrollieren. Möchte ein Besucher das Gebäude der Organisation betreten, so wird er identifiziert und authentisiert. Mitarbeiter werden als Mitarbeiter vermerkt, und Gäste werden als Gäste notiert. Ausserdem wird kontrolliert, welche Gegenstände in das Gebäude eingeführt und ausgeführt werden. All diese Ereignisse werden sorgfältig beim Pförtner protokolliert, zum Beispiel, wann welcher Besucher gekommen und gegangen ist. Ebenso, wen er besucht hat und welche Gegenstände er beim jeweiligen Übertritt des Kontrollpunktes bei sich trug. Eventuell auftretende Unregelmässigkeiten oder verdächtige Aktionen können anhand der Protokollierung im Nachhinein analysiert werden. Das elektronische Äquivalent zum Pförtner ist ein Firewall-Element, das überprüft, wer aus dem unsicheren Netz auf das zu schützende Netz zugreifen darf. Es kontrolliert, über welche Protokolle und Dienste zugegriffen wird und mit welchen Hosts kommuniziert werden darf. In diesem Sinne ist ein Firewall-System also gleichzeitig eine Brandschutzmauer und ein elektronischer Pförtner. Eine Firewall-Lösung und -Implementierung fällt jeweils sehr individuell aus und muss den jeweiligen Ansprüchen angepasst werden. Ausserdem darf nicht ausser Acht gelassen werden, dass ein solcher Knotenpunkt technische, personelle, organisatorische und infrastrukturelle Sicherheitsmechanismen erfordert.
    Voraussetzung für das effiziente Ausnutzen (im positiven Sinne!) der Möglichkeiten eines Firewall-Systems ist ein durchdachtes Sicherheitskonzept. Ähnlich wie beim Pförtner gilt, dass nicht die Firewall etwas sicher macht, sondern mit ihr kann man etwas sicher machen, wenn sie richtig betrieben wird. Das bedeutet, dass ein Unternehmen sich vor dem Angehen an die Implementierung einer proprietären Zwischenlösung an sich an die Ausarbeitung eines Sicherheitskonzeptes machen sollte. In diesem analytischen Zusammentragen muss definiert werden, was vor wem und wer von was geschützt werden soll. Es macht wenig Sinn, sich Hals über Kopf für eine vermeintliche ultimative Lösung zu entscheiden, wenn man sich eigentlich gar nicht über das Problem im Klaren ist. Die Reduzierung des Zugriffs erhöht die Sicherheit und erleichtert die Kontrolle und Administration des Firewall-Systems. Das Fehlen von Überschaubarkeit kann bei einem solchen Projekt zur Achilles-Ferse werden.

    7.1.1 Zielsetzung

    Ein Firewall-System wird quasi als Schranke zwischen das zu schützende und das unsichere Netz geschaltet, so dass der ganze Datenverkehr zwischen den beiden Netzen nur über das Firewall-Element möglich ist. Es stellt also im wahrsten Sinne des Wortes den "Common Point of Trust" für den Übergang zwischen unterschiedlichen Netzen dar. Auf der Firewall werden Mechanismen implementiert, die die ganzen Transaktionen sicher und beherrschbar machen sollen. Dazu analysiert das Firewall-System die Kommunikationsdaten, kontrolliert die Kommunikationsbeziehungen und Kommunikationspartner, reglementiert die Kommunikation nach einer Sicherheitspolitik, protokolliert Ereignisse und alarmiert gegebenenfalls bei bestimmten Verstössen den Security-Administrator. Firewalls werden in erster Linie genutzt, um die Anbindung ans Internet in vielerlei Hinsicht sicherer zu machen. Doch auch das aufteilen in Segmente oder Subnetze macht Sinn; besonders bei grossen Netzwerken. Die Vorteile des "Common Point of Trust" lässt sich auf die geringen Kosten, Umsetzung der Sicherheitspolitik, Möglichkeiten, erhöhte Sicherheit und Überprüfbarkeit aufsummieren.
    7.1.2 Allgemeine Ziele
    Die allgemeinen Ziele von Firewall-Systemen sind folgende:
  • Zugangskontrolle auf Netzwerkebene
  • Zugangskontrolle auf Benutzerebene
  • Zugangskontrolle auf Datenebene
  • Rechteverwaltung
  • Kontrolle auf der Anwendungsebene
  • Entkoppelung von Diensten
  • Beweissicherung und Protokollauswertung
  • Alarmierung
  • Verbergen der internen Netzstruktur
  • Vertraulichkeit von Nachrichten
  • Um diese Ziele in greifbare Nähe rücken zu lassen, muss das Firewall-System selber gewisse Anforderungen erfüllen:
  • Das Firewall-System muss selbst resistent gegen Angriffe sein.
  • Accounting (IP- und benutzerorientiert)
  • NAT - Network Adress Translation (auch IP-Masquerading genannt)
  • 7.2 Paketfilter
    7.2.1 Einführung
    Das aktive Firewall-Element Packet Filter analysiert und kontrolliert die ein- und ausgehenden Paketeauf der Netzzugangs-, der Netzwerk- und der Transportebene. Dazu werden die Pakete, nicht nur TCP/IP-Protokolle, aufgenommen und analysiert. Diese Analyse wird aufwendiger, sobald auch der Inhalt der einzelnen Pakete durchforstet werden soll; daher wird normalerweise nur ein rascher und hastiger Blick auf den Header geworfen. Die beiden Netze werden bei einer solchen Implementierung physikalisch entkoppelt. Ein Paket-Filter verhält sich wie eine normale Bridge und werden transparent in eine Leitung eingefügt.

    Nach der Analyse des Pakets wird verifiziert, ob sie unter eine bestimmte Regel fallen, und dementsprechende Reaktionen ausgeführt. In den Regeln wird vorzugsweise definiert, dass nur die notwendigste Kommunikation erlaubt ist; alle Verstösse werden abgewiesen (engl. deny) oder verworfen (engl. drop). Dadurch können sicherheitskritische Aktionen, wie zum Beispiel IP-Fragmentierung, von vornherein ausgeschlossen werden.
     
    Name Hersteller Homepage
    Axent Eagle Raptor
    Biodata BIGfire Biodata http://www.biodata.com/ch/products/network/bigfire.cphtml
    Biodata BIGfire+ Biodata http://www.biodata.com/ch/products/network/bigfireplus_office.cphtml
    Cisco PIX Firewall Cisco
    Check Point Firewall-1
    Paket-Filter: Stand Februar 2001

    7.2.2 Allgemeine Arbeitsweise
  • Es wird überprüft, von welcher Seite das Paket empfangen wird (Informationen aus dem Einbindungsmodul).
  • Auf der Netzzugangsebene werden die Quell- und Ziel-Adresse und der verwendete Protokoll-Typ kontrolliert.
  • Auf Netzwerkebene wird je nach Protokoll-Typ das Paket anders kontrolliert.
  • IP: die Ziel-, Quell-Adresse, verwendetes Schicht-4-Protokoll, Optionsfeld und Flags
  • ICMP: die ICMP-Kommandos/-Typen
  • IPX: Network und Node
  • OSI-Protokoll: die OSI-Netzwerkadresse
  • Auf Transportebene findet
  • bei UDP und TCP eine Überprüfung der Portnummern (Quell- und Ziel-Port) statt.
  • bei TCP zusätzlich eine Überprüfung der Richtung des Verbindungsaufbaus statt.
  • Zusätzlich kann überprüft werden, ob der Zugriff in einem erlaubten Zeitrahmen geschieht.
  • Die entsprechenden Prüfinformationen werden aus dem Regelwerk (Accessliste und Rechteliste) entnommen und mit den Ergebnissen der jeweiligen Analysen verglichen.
    7.2.3 Dynamische Paketfilter
    Bei verbindungslosen Kommunikationsverbindungen, wie dies zum Beispiel bei UDP der Fall ist, kann nicht grundsätzlich festgelegt werden, von wem ein Verbindungsaufbau durchgeführt wird. Dynamische Paketfilter besitzen in einem solchen Fall die zusätzlich Eigenschaft, sich die Informationen (IP-Adresse und Port) der nach Aussen geschickten UDP-Pakete zu merken und nur die entsprechend passenden Antworten der virtuellen Verbindung zurückzulassen. Das bedeutet genauer, dass nur die Antwortpakete durchgelassen werden, die vom selben  Host und gleichen Port kommen, an den das ursprüngliche UDP-Paket gesendet worden ist und entsprechend zum gleichen System retourniert wird. Der Name rührt also daher, dass die Filter-Regeln intern dynamisch gehandhabt werden. Dienste wie SNMP können über dynamische Paketfilter also viel sicherer angeboten werden.
    7.2.4 Zustandsorientierte Paketfilter
    Der Leistungsumfang von Paketfiltern kann dadurch erweitert werden, indem die Interpretation der Pakete auch auf höheren Kommunikationsebenen durchgeführt wird. In Fall einer solchen "stateful inspection" werden die Pakete auch auf der Anwendungsebene interpretiert und die Informationen bewertet und festgehalten.

    Diese zustandsorientierten Paketfiltern haben die Vorteile von herkömmlichen Packet Filter, können aber zusätzlich die Anwendungen kontrollieren. Einige Risiken bleiben jedoch, weil keine direkte Entkoppelung der Dienste realisiert ist. Ausserdem ist dieses Interpretieren und Festhalten zusätzlicher Kommunikationsdaten dieser veschiedenen Ebenen sehr komplex. Aus diesem Grund findet aus technischen Gründen eine weitaus weniger tiefgründige Analyse statt oder jene sind oft stark fehleranfällig, da eine sehr komplexe und mächtige Software genutzt wird.

    7.2.5 Vorteile von Paketfiltern
  • Transparent für Benutzer und die Rechensysteme. Ausnahmen sind natürlich explizite Authentifizierungen.
  • Einfach erweiterungsfähig für neue Protokolle.
  • Flexibel für neue Dienste.
  • Für andere Protokollfamilien verwendbar (IPX, OSI, DECNET, SNA, ...).
  • Hohe Performance durch optimale Mechanismen (Hardware, Betriebssystem, Treiber, ...).
  • Leicht realisierbar, da geringe Komplexität.
  • 7.2.6 Nachteile von Paket-Filtern
  • Daten, die oberhalb der Transportebene sind, werden in der Regel nicht analysiert.
  • Für die Anwendungen (FTP, HTTP, SMTP, ...) besteht keine Sicherheit.
  • Falsch konfigurierte oder kompromittierte Hosts im internen Netz können für normalerweise nicht erlaubte Kommunikationen zwischen den beiden Netzen missbraucht werden.
  • Protokolldaten werden nur bis zur Transportebene zur Verfügung gestellt.
  • Typische Paketfilter können die Struktur des internen Netzes nicht verbergen (NAT ist kein zwingendes Feature).
  • 7.3 Application-Gateways
    7.3.1 Einführung
    Ein Benutzer, der über ein Application-Gateway kommunizieren möchte, muss sich zuerst beim Firewall-System identifizieren und authentisieren. Es gibt verschiedene Möglichkeiten, wie diese Authentifizierung von Statten gehen kann. Danach wird die Kommunikation für den Anwender transparent weitergeführt: Für ihn sieht es so aus, als würde er einen direkten Datenaustausch mit seinem Ziel abhalten. Damit diese Lösung realisiert werden kann, muss auf dem Application-Gateway ein Dienst laufen, der über einen definierten Port ansprechbar ist. Die Pakete an diesen Port werden analysiert und gegebenenfalls weitergeleitet. Eine solche Software ist in der Regel nur für einen Dienst (HTTP, FTP, SMTP, ...) konzipiert worden und wird als Proxy bbezeichnet. Für jeden Dienst, der über das Application-Gateway ansprechbar und weiterleitbar sein soll, muss ein eigener Proxy vorhanden sein, aber auch keine weitere Software, die diesen Dienst ermöglichen könnte.

    Jeder Proxy auf dem Application-Gateway kann speziell für seinen Dienst, für den er zuständig ist, weitere Sicherheitsdienste anbieten. Auch die Analyse ist auf dieser Kommunikationsebene sehr intensiv möglich, da der Kontext der Anwendungsdaten für den jeweiligen Dienst klar definiert ist. Der Vorteil ist, dass kleine überschaubare Module genutzt werden, und so die Fehleranfälligkeit erfreulich niedrig gehalten werde kann.

    Das Security-Management darf aus sicherheitsgründen nicht auf demselben Rechnersystem laufen oder zumindest nicht zur gleichen Zeit, wie das Application-Gateway. Zudem sollen keine Routing-Funktionen auf dem Host aktiv sein, damit nicht an den Proxies vorbeigeschmuggelt werden kann.

    Da das Application-Gateway bei der Kommunikation jeweils zum Rechnersystem des unsicheren Netzes und zu dem zu schützenden Netzes eine Kommunikationsverbindung hat, bietet es eine "Network Adress Translation". Dabei hat das Application-Gateway für die jeweiligen Interfaces zwei verschiedene IP-Adressen, die auch jeweils nur für die jeweilige Richtung genutzt werden.
     
    Name Hersteller Homepage
    Biodata BIG Application Biodata http://www.biodata.com/ch/products/network/bigapplication.cphtml
    Microsoft ISA Server Microsoft
    Microsoft Proxy 2.0 Microsoft http://www.microsoft.com/germany/backoffice/proxy/
    Squid Squid http://www.squid-cache.org/
    Surfcontrol CSM Enterprise Surfcontrol http://www.csm.co.at/download/products/ep/index.htm
    Application-Gateways: Stand Februar 2001

    7.3.2 Application-Level-Proxies
    Application-Level-Proxies sind für bestimmte Dienste/Anwendungen implementiert. Aus diesem Grund kennen sie die Kommandos der Anwendungsprotokolle und können diese detailliert analysieren und ebenso haargenau kontrollieren. Application-Level-Proxies arbeiten mit der gängigen, unveränderten Clientsoftware für ihre individuellen Dienste. Oft wurde aber zudem eine veränderte Vorgehensweise im Falle einer gewünschten Authentifikation beim Application-Level-Proxy implementiert.
    7.3.3 SMTP-Proxy
    Ein SMTP-Proxy arbeitet nach dem Store-and-Forward-Prinzip, welches in gewissem Masse eine Analogie zum Sammelbriefkasten aufweist. Dabei wird als erstes die komplette Mail vom SMTP-Proxy abgespeichert. Ein Weitersenden wird erst eingeleitet, wenn die erste Phase des Annehmens erfolgreich verlief. Für die Mail-Kommunikation ist also keine end-to-end Beziehung zwischen eigentlichem Sender und seinem nächst direktem Empfänger notwendig.

    Der SMTP-Proxy arbeitet nicht benutzerorientiert und erfordert daher keine Authentifikation. Eine ankommende E-Mail wird standartmässig auf dem TCP-Port25 (SMTP) entgegengenommen und nach der Überprüfung des Absenders auf dem Application-Gateway in einem speziellen Verzeichnis abgelegt. Der SMTP-Daemon prüft periodisch, ob neue Nachrichten eingegangen sind. Der Mail Transfer Agent (MTA) stellt dem Adressaten die elektronische Post direkt oder über einen oder mehrere MTAs zu. Der SMTP-Proxy verhindert damit, dass der MTA direkt mit dem unsicheren Netz kommunizieren kann.

    Der wohl beliebteste MTA ist unbestritten Sendmail. Er wird aufgrund seiner hohen Skalierbarkeit vielerorts eingesetzt. Sendmail ist jedoch auch für seine Vielzahl von Sicherheitslücken und Implementierungsfehlern bekannt. Ein SMTP-Proxy verarbeitet daher nur die folgenden Befehle nach RFC 821 (SMTP - Simple Mail Transfer Protocol), die nicht sicherheitskritisch sind:

  • HELO
  • MAIL
  • RCPT
  • DATA
  • QUIT
  • RSET
  • NOOP.
  • Einige weitere Befehle werden mit Standartantworten quittiert:
  • HELP
  • VRFY
  • EXPN.
  • Bei Nutzen eindeutig sicherheitsrelevanten Befehlen wie
  • DEBUG
  • wird eventuell direkt der Security-Manager mit einer Nachricht informiert. Da die Befehle zuerst den SMTP-Proxy durchlaufen müssen, kann der DEBUG-Befehl einfach ignoriert werden, um den potentiellen Angriff durch eine Suche nach Implementierungsfehlern zu unterbinden. Durch die Verwendung des Store-and-Forward-Prinzips wird eine Entkoppelung des komplexen und fehlerbehafteten MTAs, in diesem und vielen Beispielen Sendmail, erreicht. Sendmail wird nicht direkt mit Befehlen angesprochen, sondern nur die stellvertretende Software des SMTP-Proxies. Der SMTP-Proxy ist überschaubar und damit eine gut testbare Software.

    Im Logbuch des Application-Gateways können durch das SMTP-Proxy die folgenden Protokolldaten für eine spätere Auswertung festgehalten werden:

  • IP-Adresse und Rechnername des Quell-Rechnersystems
  • Uhrzeit und Datum des Verbindungsaufbaus
  • Absender der Nachricht (wie im Mail-Header angegeben)
  • Empfänger der Nachricht (wie im Mail-Header angegeben)
  • Anzahl der übertragenen Bytes
  • Uhrzeit und Datum des Verbindungsabbaus
  • Im Logbuch des Application-Gateways werden durch den Message Transfer Agent die folgenden Protokolldaten für eine spätere Auswertung festgehalten:
  • IP-Adresse und Rechnername des Ziel-Rechnersystems
  • Uhrzeit und Datum des Verbindungsaufbaus
  • Absender der Nachricht (wie im Mail-Header angegeben)
  • Empfänger der Nachricht (wie im Mail-Header angegeben)
  • Anzahl der übertragenen Bytes
  • Uhrzeit und Datum des Verbindungsabbaus
  • 7.3.4 Benutzerorientierte Application-Level-Proxies
    Die folgenden Proxies für Telnet, FTP und HTTP sind benutzerorientierte Proxies, da sie selbst eine Authentifikation mit dem entsprechenden Benutzer durchführen. Im Falle einer erfolgreichen Identifikation und Authentikation des Anwenders beim Proxy gilt diese nur für jenen speziellen Proxy. Für das Nutzen eines anderen Dienstes/Proxies, muss sich der User erneut authentifizieren. Benutzerorientierte Proxies haben den Vorteil, dass die Zuordnung zwischen Benutzer und IP-Adresse und dem gewünschten Dienst eindeutig und lückenlos ist.
    7.3.5 Telnet-Proxy
    Der Telnet-Proxy ist für die kontrollierte Kommunikation über Telnet verantwortlich und stellt entsprechende Sicherheitsfunktionen für diesen Dienst zur Verfügung.

    Der Verbindungsaufbau erfolgt vom Quell-Rechnersystem auf TCP-Port23 (Telnet) des Application-Gateways. An diesem well-known Port für Telnet übernimmt der Telnet-Proxy automatisch die Verbindung. Der Telnet-Proxy kann erkennen, ob an diesem Port ein anderer Dienst aktiviert wurde, so dass der Verbindungsaufbau bei Zuwiderhandlung nicht zustande kommt. Der Benutzer auf dem Clientidentifiziert und authentisiert sich unter der Angabe des Verbindungsziels beim Telnet-Proxy. Wurde diese zweite Phase erfolgreich abgewickelt, wird ein individuelles Benutzerprofil aktiviert, welches sich aus folgenden Punkten zusammensetzt:

  • IP-Adresse des Quell-Rechnersystems, das die Verbindung aufbauen möchte.
  • Benutzername, mit dem die Identifikation und Authentikation erfolgte.
  • IP-Adresse des Ziel-Rechnersystems
  • In der dritten Phase baut der Telnet-Proxy eine zweite Verbindung vom Application-Gateway auf TCP-Port 23 des Ziel-Systems auf. Jetzt kann der Benutzer von seinem Client aus über den Telnet-Proxy mit dem Telnet-Dienst des Ziel-Systems interagieren. Und trotzdem bleibt die Netzstruktur des zu schützenden Netzes verborgen.

    Bei einer über einen Telnet-Proxy geschlauften Telnet-Kommunikation ist es zum Beispiel möglich zu erkennen, ob ein Benutzer unerlaubt vom Quell-Rechnersystems auf ein anderes Rechnersystem als das erlaubte Ziel zugreift. Dieser sogenannte Telnet-Hopping-Angriff ist eine beliebte Methode, um IP-orientierte Authentifikationen zu unterlaufen. Der Control-Monitor überprüft den Datenstrom auf Bytereihenfolgen, die verdächtigen Aktivitäten zugeordnet werden können. Es ist natürlich auch Möglich nach anderen Informationen zu suschen, wie zum Beispiel Steuerzeichen, die nicht verwendet werden sollen (z.B. [CTRL]+[C]).

    Im Logbuch des Application-Gateways werden durch den Message Transfer Agent die folgenden Protokolldaten für eine spätere Auswertung festgehalten:

  • IP-Adresse und Rechnername des Ziel-Rechnersystems
  • Uhrzeit und Datum des Verbindungsaufbaus
  • Absender der Nachricht (wie im Mail-Header angegeben)
  • Empfänger der Nachricht (wie im Mail-Header angegeben)
  • Anzahl der übertragenen Bytes
  • Uhrzeit und Datum des Verbindungsabbaus
  • 7.3.6 FTP-Proxy
    Der FTP-Proxy ist für die kontrollierte Kommunikation über das File Transfer Protocol verantwortlich und stellt entsprechende Sicherheitsfunktionen für diesen Dienst zur Verfügung.

    Der Verbindungsaufbau für den Kommandokanal erfolgt vom Quell-Rechnersystems auf TCP-Port 21 (FTP) des Application-Gateways. Der Benutzer auf dem Client-Systemsidentifiziert und authentisiert sich, unter der Angabe des Verbindungsziels, nun gegenüber dem FTP-Dienst. Nach erfolgreicher Authentifikation wird ein den folgenden Bedingungen entsprechendes individuelles Benutzerprofil aktiviert:

  • IP-Adresse des Quell-Rechnersystems, das die Verbindung aufbauen möchte
  • Benutzername, mit dem die Authentifikation erfolgte
  • IP-Adresse des Ziel-Rechnersystems
  • Nun baut der FTP-Proxy einen zweiten Kommandokanal vom Application-Gateway auf TCP-Port 21 (FTP) des eigentlichen Ziel-Rechnersystems auf.

    Der sogenannte Kommando-Filter analysiert und verifiziert alle vom Benutzer eingegebenen FTP-Kommandos hinsichtlich ihres Eintrags in der zuvor definierten Rechtedatei, die für jeden Anwender individuell ausfallen kann. Für den FTP-Proxy kann zum Beispiel bestimmt werden, welche Befehle verwendet werden dürfen und welche unerwünscht sind. Gibt der Benutzer ein Kommando ein, welches nicht geblockt, verworfen oder geloggt wird, so findet ohne Umschweife ein Verbindungsaufbau statt. Dieser kann von irgendeiner der beiden Seiten initiiert werden, jenachdem, ob eine passive oder aktive FTP-Verbindung gewünscht wurde.

    Ausserdem kann der FTP-Proxy durch einen Datei-Filter eine Namensrestruktierung vornehmen, die übertragen werden dürfen.

    In der Logdatei des Application-Proxies für FTP können die folgenden Protokolleinträge standartmässig vorgenommen werden:

  • IP-Adresse und Rechnername des Quell-Rechnersystems
  • IP-Adresse und Rechnername des Ziel-Rechnersystems
  • Uhrzeit und Datum des Verbindungsaufbaus
  • Name des Benutzers
  • Anzahl der übertragenen Bytes
  • Name der übertragenen Dateien
  • Uhrzeit und Datum des Verbindungsabbaus
  • 7.3.7 HTTP-Proxy
    Der HTTP-Proxy ist für die kontrollierte Kommunikation über das Hypertext Transfer Protocol verantwortlich und stellt entsprechende Sicherheitsfunktionen für diesen Dienst zur Verfügung.

    Der Verbindungsaufbau erfolgt vom Quell-Rechnersystem auf TCP-Port 80 (HTTP) des Application-Gateways. An diesem well-known Port für HTTP übernimmt der HTTP-Proxy automatisch die Verbindung.  Der Benutzer auf dem Clientidentifiziert und authentisiert sich unter der Angabe des Verbindungsziels beim HTTP-Dienst. Wurde diese zweite Phase erfolgreich abgewickelt, wird ein individuelles Benutzerprofil aktiviert, welches sich aus folgenden Punkten zusammensetzt:

  • IP-Adresse des Quell-Rechnersystems, das die Verbindung aufbauen möchte
  • Benutzername, mit dem die Authentifikation erfolgte
  • IP-Adresse des Ziel-Rechnersystems.
  • Nun baut der HTTP-Proxy vom Application-Gateway eine zweite Verbindung zum TCP-Port80 (HTTP) des eigentlichen Ziel-Rechnersystems auf. Jetzt kann der Benutzer mit seinem Browser den Dienst des Ziel-Hosts unter transparenter Einwirkung des Application-Gateways nutzen.

    Da das HTTP-Protokoll nicht session-orientiert arbeitet, ist der HTTP-Proxy dementsprechend auch nicht in der Lage, das Ende einer Sitzung zu erkennen. Bei jeder Anforderung einer WWW-Seite wird eine Verbindung über das Firewall-System aufgebaut, die Dokumente übertragen und die Kommunikationsverbindung wieder abgebaut. Beim ersten Mal wird vor der Übertragung die Authentifikation durchgeführt. Aus diesem Grund wird ein Timer gesetzt, der den Beginn der Session festhält. Nach Ablauf dieses Timers wird der HTTP-Proxy automatisch abgeschaltet. Bei jeder weiteren Kommunikation über den HTTP-Proxy wird der Timer nach erfolgreicher Authentifikation erneut gesetzt.

    Der Kommando-Filter analysiert und überprüft die verwendete Methoden (FTP, HTTP, NNTP, SMTP, ...) und die dafür verwendeten Befehle (z.B. put, get, post). Jeder VVersuch, eine nicht zulässige Anforderung abzusetzen, wird ihm angezeigt und es erfolgt der entsprechende Eintrag in die Protokolldateien. Es können auch spontane Benachrichtigungen vom Security-Management durchgeführt werden, falls grobe Regelverstösse registriert worden sind.

    Mit der Hilfe eines Daten-Filters im HTTP-Proxy können definierte URLs zugelassen oder geblockt werden. So können zum Beispiel nur bestimmte Top-Level-Domains (z.B. ch und de) ansprechbar sein. Durch den Daten-Filter können jedoch auch bekannte, nicht gewünschte Dateien oder HTTP-Seiten durch den Proxy ausgefilter werden.

    Aktive Inhalte innerhalb von HTML-Dokumenten können eine Gefährdung für einen Host darstellen, der das Dokumentiert interpretieren soll. Hier kommt Content-Security ins Spiel, der vor solchen schädlichen Webapplicationen schützen soll. Ein Applet-Filter kann Java, JavaScripts und ActiveX kontrollieren oder ausschliessen. Durch den sogenannten Malware-Filter können korrupter Programmcode (z.B. Viren, trojanische Pferde, Würmer, ...) aufgespürt und ihnen durch externe Lösungen (z.B. Antiviren-Software) eentgegengewirkt werden.

    In der Logdatei des Application-Proxies für HTTP können die folgenden Protokolleinträge standartmässig vorgenommen werden:

  • IP-Adresse und Rechnername des Quell-Rechnersystems
  • IP-Adresse und Rechnername des Ziel-Rechnersystems
  • Uhrzeit und Datum des Verbindungsaufbaus
  • Name des Benutzers
  • Anzahl der übertragenen Bytes
  • Name der übertragenen Dateien oder übertragenen HTML-Seite
  • Uhrzeit und Datum des Verbindungsabbaus
  • 7.3.8 Authentication-Proxy (Global Authentication)
    Das etwas andere Konzept eines Application-Gateways ist, dass der Benutzer die Authentifikation durch einen sogenanten Authentication-Proxy durchführen lässt. Diese Art der Authentifizierung wird auch "Global Authentication" genannt. Dieser spezielle Proxy führt die Rechteverwaltung für die unterschiedlichen Dienste durch.

    Der Vorteil liegt darin, dass keine erneute Authentifizierung des Benutzers durchgeführt werden muss, wenn er den Dienst wechseln möchte.

    Der Nachteil dieser Methode tritt besonders bei Multiuser-Systemen ins Rampenlicht, denn es kann keine eindeutige Verbindung zwischen Dienst und Benutzer erkannt werden. Ausserdem kann während der Zeit der Freischaltung der Verbindung auf dem Application-Gateway und dem Connect des Clients der Dienst von Angreifern benutzt werden.

    7.3.9 Transparent Proxies
    Transparente Proxies haben die Eigenschaft sich komplett transparent dem Benutzer gegenüber zu verhalten. Der Vorteil dieser Lösung besteht darin, dass die Client-Software nicht verändert oder modifiziert werden muss, um den Proxy-Service zu nutzen. Viele ISPs (Internet Service Provider) nutzen transparente Proxies, das beste Beispiel ist AOL (American Online), um eine höhere Performance bei der Netzanbindung gewährleisten zu können.
    7.3.10 Circuit-Level-Proxies
    Da bei Application-Gateways aus sicherheitsgründen kein Routing auf der Netzwerkebene möglich sein darf, können für Dienste, für die keine Proxy-Suite zur Verfügung steht, sogenannte Circuit-Level-Proxies implementiert werden, wenn eine Kommunikation über das Application-Gateway realisiert werden soll. Circuit-Level-Proxies sind eine Art generische Proxies, die für eine Mehrzahl von Diensten mit verschiedenen Protokollen verwendet werden können. Diese Proxy-Art, die auch als generische Proxies, Port-Relays oder Plug-Gateways bezeichnet werden, können in der Regel für TCP- und UDP-Anwendungen Verwendung finden.

    Mit einem Port-Relay wird eine Kommunikation über die Portnummer des Port-Relays adressiert und kann daher nur auf eine definierte IP-Adresse erfolgen. Aus diesem Grund sind Port-Relays immer n:1. Viele Hosts (IP-Adressen) von der einen Seite können auf einen Rechner (eine IP-Adresse) auf der anderen Seite zugreifen - Der umgekehrte Weg ist nicht möglich.

    In der Logdatei des Port-Proxies können die folgenden Protokolleinträge standartmässig vorgenommen werden:

  • IP-Adresse und Rechnername des Quell-Rechnersystems
  • IP-Adresse und Rechnername des Ziel-Rechnersystems
  • Uhrzeit und Datum des Verbindungsaufbaus
  • Anzahl der übertragenen Bytes
  • Uhrzeit und Datum des Verbindungsabbaus
  • 7.3.11 SOCKS
    SOCKS stellt eine standartisierte Umgebung zur transparenten und sicheren Nutzung eines Firewall-Systems zur Verfügung. Um dies zu erreichen, schaltet es sich zwischen die Anwendungs- und Transportebene:
     
    Anwendungsebene
    SOCKS Zwischenebene
    Transportebene
    Netzwerkebene
    Netzzugangsebene

    In dieser Zwischenschicht sitzend fängt SOCKS die TCP- und UDP-Verbindungsanfragen der Applikationen ab und setzt diese auf das SOCKS-Protokoll um. Die Kommunikation findet alsdann in der Form eines sogenannten Tunnels zwischen dem SOCKS-Client und dem SOCKS-Server statt. Die Integration dieser Möglichkeit und der SOCKS-Protokoll-Standart in der Version 5 ist in RFC 1927 definiert.

    SOCKS vereint die Möglichkeiten eines Circuit-Level-Proxies mit denen eines Application-Level-Proxies. Der eindeutige Nachteil des Nutzens von SOCKS ist, dass in jedem Fall Änderungen auf der Client-Seite durchgeführt werden müssen, da es bisher nur sehr wenige Applikationen gibt, die SOCKS direkt unterstützen.

    Die veraltete Version 4 des SOCKS-Protokolls enthielt keinerlei Sicherheitsmassnahmen zur Authentikation und Wahrung der Integrität. Es wurden nur die Kommandos "Bind" und "Connect" unterstützt.

    Die aktuelle Version 5 von SOCKS enthält folgende Merkmale:

  • Standartisierte Schnittstellen zur Integration von starken Authentifikationsmechanismen.
  • Erweitertes Adress-Schema zur Unterstützung von IPv4, IPv6 und Domain-Namen.
  • Unterstützung für TCP und UDP.
  • Verfügbare Implementationen integrieren sich transparent in das Betriebssystem.
  • Allerdings weist auch SOCKS gewisse Nachteile auf:
  • Der Aufbau simultaner und paralleler Verbindungen von einem Server zu einem Client ist nicht ausreichend unterstützt.
  • Die UDP-Implementation bietet keine Unterstützung von Multicasts.
  • Grosser Protokoll-Overhead pro Verbindung.
  • Es existieren keine standartisierten Erweiterungen.
  • Die Skalierbarkeit von SOCKS 5 ist nicht ausreichend.
  • Für die nächste Protokoll-Generation von SOCKS sind folgende Erweiterungen geplant:
  • Major und Minor Version Nummerierung für bessere Rückwärts-Kompatibilität.
  • Standart Mechanismus zur Aushandlung von Protokoll-Erweiterungen.
  • Nutzung eines Kontrollkanals zur Reduzierung des Payloads.
  • TCP: Bind-Kommandoerweiterungen zur Unterstützung von mehreren Verbindungen auf den offenen Port, sowie die Möglichkeit der Vorgabe eines bestimmten Ports durch den Client.
  • UDP: Unterstützung für Multicast.
  • UDP: Wahlmöglichkeit zwischen Senden und Empfangen von Datagrammen.
  • UDP: Möglichkeit der Tunnelung von Datagrammen durch einen zuverlässigen Kanal.
  • 7.3.12 Adaptive Proxies
    Viele Firmen für IT-Security versuchen in dem Namen "Adaptive Proxies" die Vorteile von Paketfiltern und Application-Gateways zu kombinieren. Die Idee hinter diesem Ansatz ist, dass das Firewall-System in einer der Verbindungsaufbauphase wie ein Application-Proxy arbeitet und später in der Datentransferphase wie ein Paketfilter agiert. Die Vorteile dieser Methode liegen auf der Hand: In der ersten Phase wird eine hohe Sicherheit erreicht, danach erst weden die schnellen Tests durchgeführt.
    7.3.13 Angriffe auf Application-Gateways
    Die Gefahr von Implementierungs- und Konfigurations-Fehlern schnellt mit dem Funktionsumfang und der Komplexität in die Höhe.Cisco PIX Firewall Ich möchte nun diese Problematik von Proxy-Elemente bei Application-Gateways an einem historischen Beispiel verdeutlichen: Wie einige andere Firewall-Hersteller implementierte Cisco bei ihrer PIX, ursprünglich ein schlichter Paket-Filter, eine relativ neuartige Technologie, welche den Inhalt von passierenden Paketen für eine Filterung auf dem ISO/OSI-Layer 7 (Anwendungsschicht) analysiert. Im Fall von SMTP können dadurch zum Beisipel nur bestimmte Kommandos aus RFC 821 (SMTP - Simple Mail Transfer Protocol) zugelassen werden: Gefährliche Funktionen wie EXPN und VRFY werden dann im Zweifelsfall schon beim Eintritt ins Netzwerk von der Firewall verworfen (Dank diesen Kommandos werden grossflächige Spam-Attacken oft erst möglich!). Jedoch darf die Filterung der gefährlichen Kommandos natürlich nicht auch für den Body einer Mail gelten: So wird der Filter zwischen dem Befehl DATA und der Escape-Sequenz "<CR><LF><CR><LF>.<CR><LF>" ausser Kraft gesetzt. Durch einen Trick lässt sich nun die Cisco-Firewall überzeugen, dass vermeintliche SMTP-Kommandos angeblich nur für den Mail-Body genutzt werden wollen, in Wirklichkeit jedoch zur Steuerung des SMTP-Relays angewandt werden. Während dem Dialog mit einem SMTP-Server darf das DATA-Kommando erst nach den essentiell wichtigeren Angaben wie "RCPT TO" genutzt werden; andererseits erhält der Client-Rechner die serverseitige Fehlermeldung mit dem Error-Code 503. Die Firewall denkt jedoch nach dieser fehlgeschlagenen Aktion, dass alles in bester Ordnung ist und lässt nun alle Eingaben bis zur besagten Escape-Sequenz zu. Eine solche Session sieht dann in ihren Grundzügen folgendermassen aus:
     
    Welcome to SuSE Linux 7.0 (i386) - Kernel 2.2.16

    prometheus login: mruef
    Password: 
    Last login: Thu Jan 18 13:14:59 on tty1
    Have a lot of phun...
    mruef@prometheus:~ > telnet mail.ubsw.com 25
    mail from: anonymous@computec.ch <mailto:anonymous@computec.ch>
    data (Ab hier ist die Firewall unterlaufen)
    expn guest (Nun können wieder VRFY und EXPN genutzt werden)
    ... [Alle Kommandos, die ich eingeben will]
    quit

    mruef@prometheus:~ > _

    Eine Kompromittierung des SMTP-Proxies der Cisco PIX Firewall.

    Für einige Versionen der Cisco PIX Firewall wurden vom Hersteller Patches realisiert; jedoch nicht für alle. Benutzer dieser Sonderlinge müssen auf Updates zurückgreifen. Mehr Informationen zu dieser Sicherheitslücke findet sich online im Cisco-Advisory: Cisco Secure PIX Firewall Mailguard Vulnerability.

    7.4 Desktop-Firewalls
    7.4.1 Einführung
    Die Gefahr, beim Durchforsten des Internets auf Viren oder korrupten Programmcode zu stossen, egal ob nun in Form eines ActiveX-Elements oder eines Java-Applets, wächst mit der Bedeutung des Internets. Für eine professionelle Lösung muss relativ tief in die Tasche gegriffen werden, um das eigene Netzwerk vor solchen Gefahren hermetisch abzuriegeln. Daher werden auf Software-Ebene sogenannte Desktop-Firewalls realisiert, welche vorzugsweise Windows-Systeme von Normalanwendern vor Gefahren aus dem Internet bewahren sollen.

    Leider ist es so, dass viele auf dem Markt erhältliche Systeme nicht die Anforderungen erfüllen können, die eigentlich an das Objekt in Extremsituationen gestellt werden. Auch die Performance auf dem System nimmt rapide ab, obwohl dies heutzutage bei der eingesetzten Hardware, auch im privaten Bereich, nicht mehr so als negativ ausschlaggebend eingestuft werden muss. Die grösste Angriffsfläche bietet jedoch in den wenigsten Fällen die Private-Firewall selbst, sondern das Betriebssystem, auf dem sie aufsetzt.

    Trotzdem gilt es für Vielsurfer und im Firmennetz als Muss, stets mit on-the-flyAntiviren-Software und PC-Firewall in die Weiten des Internets vorzudringen, da dadurch wenigstens sämtliche TCP/IP-Pakete kontrolliert werden können, die den Rechner erreichen. Auch fungieren einige Desktop-Firewalls automatisch als Viren-Scanner, denn sie überprüfen automatisch das Verhalten von ActiveX- und Java-Elementen, die lokale Daten löschen oder auf dem eigenen Rechner unbemerkt im Hintergrund Daten per FTP an einen entfernten Cracker schickt. Die Software-Firewall schafft um ihren Zweck zu erfüllen, einen Schutzbereich, der so eine Art Quarantäne bildet. Dieser Schutzbereich wird Sandbox genannt, wobei ein Programm, welches innerhalb dieser virtuellen Umgebung ausgeführt wird, nur sehr begrenzten Zugriff auf Ressourcen des Systems gewährt bekommt. Zwar ist der Ansatz dieses Sandbox-Systems sehr gut, doch sind die verschiedenen Umsetzungen noch nicht genug ausgereift, um einen umfassenden Schutz in dieser Hinsicht zu geben.
     

    Name Hersteller Homepage
    Anti-Hack CarbonSoft http://www.carbosoft.com/anti-hack.htm
    AtGuard WRQ http://www.wrq.com/
    Back Protection 2001 JMMG Communications http://www.jmmgc.com/backprotection/index.html
    Black ICE Defender Network ICE Corporation http://www.netice.com/products/blackice_defender.html
    ConSeal PC Firewall Signal 9 http://www.consealfirewall.com/
    Digital Robotics Internet Firewall 2000 Digital Robotics http://www.digitalrobotics.com/IFW2000.htm
    eSafe Desktop Aladdin / eSafe http://www.eSafe.com/
    GNAT Box Light Global Technologies Associates, Inc. http://www.gnatbox.com/Pages/gblight.html
    HackerWacker HackerWacker http://www.hackerwacker.com/hackerwacker/
    HackTracer Sharp Technology /Neoworx http://www.neoworx.com/products/hacktracer/default.asp
    Jammer Agnitum http://www.agnitum.com/products/jammer/
    LockDown 2000 LockDown2000 http://lockdown2000.com/
    Look 'n' Stop Soft4Ever http://www.soft4ever.com/LooknStop/En/decouvrir.htm
    McAfee Internet Guard Dog McAfee http://www.mcafee.com/myapps/firewall/ov_firewall.asp?
    McAfee Personal Firewall McAfee http://www.mcafee.com/myapps/firewall/ov_firewall.asp?
    Neoworx NeoWatch Neoworx http://www.neoworx.com/download/
    NetWatcher 2000 Moonlight Software http://www.moonlight-software.com/netwatcher.htm
    Norman Personal Firewall Norman http://www.norman.no/products_npf.shtml
    Norton Internet Security Symantec http://www.symantec.com/region/de/product/nis/
    NukeNabber Dynamsol http://www.dynamsol.com/puppet/nukenabber.html
    PC Viper Edge Technologies http://www.pcviper.com/
    PGP Network Security Network Associates http://www.nai.com/international/uk/asp_set/about_nai/at_a_glance/intro.asp
    Port Detective Tzolkin http://www.portdetective.com/
    Privatefirewall PrivacyWare http://www.privacyware.com/
    Secure4U Sandbox Security http://www.sandboxsecurity.com/main.htm
    SessionWall-3 AbirNet / Computer Associates http://www.cai.com/solutions/enterprise/etrust/intrusion_detection/
    Sphinx Biodata http://www.sphinxwall.com/
    Sygate Personal Firewall Sygate http://www.sygate.com/
    Tiny Personal Firewall Tiny Software http://www.tinysoftware.com/pwall.php
    Tiny WinRoute Lite Tiny Software http://www.tinysoftware.com/winlite.php
    Tiny WinRoute Professional Tiny Software http://www.tinysoftware.com/winpro.php
    ZoneAlarm ZoneLabs http://www.zonelabs.com/
    Desktop-Firewalls: Stand Februar 2001.
    7.4.2 Vorteile von Desktop-Firewalls
  • Niedrige Kosten.
  • Meist für Normal-Anwender zugeschnitten und daher leicht verständlich.
  • 7.4.3 Nachteile von Desktop-Firewalls
  • Nicht besonders zuverlässig, da schon alleine das Betriebssystem zu viel Angriffsfläche bietet.
  • Viele Anwender können aufgrund fehlender TCP/IP-Kentnisse keine korrekten Filter-Regeln setzen und die Protokollierung auswerten.
  • Performance-Einbussen auf der Workstation.
  • 7.4.4 Angriffe auf Desktop-Firewalls
    Angriffe auf Desktop-Firewalls können grundsätzlich auf drei verschiedene und voneinander unabhängige Angriffspunkte abzielen:

    Fehler im Betriebssystem

    In jedem guten Dokument über Firewalling ist nachzulesen, dass ein Firewall-System grundsätzlich so "schlank" wie möglich programmiert werden soll: Keine überflüssigen Features und keine unnötigen Dienste, denn je mehr Zeilen Programmcode, desto eher schleichen sich Fehler ein. Dieser Grundsatz wird spätesten beim Einsatz von PC-Firewalls auf einem Windows-System über den Haufen geworfen: Windows ist einfach nunmal ein Betriebssystem, das auf einer schwachen Sicherheitsarchitektur aufbaut und einen unstabilen TCP/IP-Stack zu nutzen pflegt. Zwar wird die Messlatte der Sicherheit durch das Nutzen einer Software-Firewall etwas in die Höhe gedrückt, aber niemals können grundlegende Fehler des Betriebssystems von vornherein ausgeschlossen und nachträglich behoben werden.

    Konfigurationsfehler

    Die Sicherheit kann zwar durch das Nutzen einer Personal-Firewall ein bisschen erhöht werden, doch sind wir eigentlich schon beim nächsten Punkt der Kritik angelangt: Ein Grossteil der Windows-Anwender benutzt den Computer für die alltägliche Arbeit. Nur die wenigsten kennen sich mit der Systemarchitektur oder Netzwerken aus. Dementsprechend wird nur eine Hand voll Nutzer die TCP/IP-Fragestellung in der Firewall-Software korrekt beantworten und die Meldungen und Logfiles richtig deuten können. Nicht selten werde ich mit der Frage konfrontiert, warum denn nun mein PC eine Verbindung zur IP x.x.x.x über TCP-Port53 (DNS) machen will. Jeder erfahrene Netzwerk-Administrator wird mit einem Augenzwinkern auf ein TCP/IP-Handbuch und das darin befindliche Kapitel über DNS verweisen...

    Programmier-Fehler

    Man sollte jedoch nicht ausser Acht lassen, dass auch diverse Software-Firewalls direkte Mängel aufweisen, die von einem Angreifer zum eigenen Vorteil ausgenutzt werden können.

    Folgend ein historisches Beispiel: Die PC-FirewallZoneAlarm von ZoneLabs in der Version 2.1.10 wies einen markanten Mangel auf: Es werden grundsätzlich keine Anfragen auf Ports protokolliert, die standartmässig vom Kernel in Anspruch genommen werden. Somit wird das Portscannen einer durch ZoneAlarm geschützten Maschine nicht erkannt, wenn zum Beispiel als Source-PortUDP67 (DHCP) gewählt wurde: Die Desktop-Firewall lässt das Paket ohne weiteres passieren, und informiert keineswegs den User darüber. UDP-Port67 (DHCP) muss geradezu offen gelassen werden, da dieser Port für DHCP (Dynamic Host Configuration Protocol) gebraucht wird. In der früheren Version 2.0.26 wurden auch UDP-Pakete vom Source-Port53 (DNS) durchgelassen. Um einen solchen verdeckten Scan an einem anderen Rechner mit nmap durchzuführen, gibt man in der lokalen Kommandozeile von Linux einfach folgenden Befehl ein: "nmap -g67 -P0 -p135-139 -sU 192.168.0.2". Die Lösung dieses Problems besteht darin, dass ein Update der Software installiert werden muss, da bei den neueren Versionen dieser Bug beseitigt wurde. Die jeweils aktuellste Version von ZoneAlarm kann man online unter http://www.zonelabs.com/download_ZA.htm beziehen.

    7.5 Firewall-Systeme erkennen
    Firewall-Systeme und die darauf befindliche Software ist wie auch ein individuelles Betriebssystem durch diverse Techniken zu erkennen. Mit der Hilfe von Portscans, Firewalking und das Abfangen von Bannern kann ein Angreifer von der Version bis hin zu den gesetzten Filter-Regeln alles für ihn notwendige herausfinden. Firewall-Systeme gelten als die grössten Gegner von Eindringlingen, und sind somit das erste Ziel eines Angreifers: Hat ein Bösewicht erst einmal die Firewall ausgekundschaftet, kann er sich an die Kompromittierung derer machen.

    7.5.1 Portscans

    Die einfachste und auffälligste Technik ist das Abscannen der Firewall nach Standartports. Viele, besonders die bekannten, geben sich nach einem Portscan ohne grosses Zögern bekannt - Man muss lediglich wissen, wonach man sucht. Die CheckPoint Firewall-1 hat standartmässig die TCP-Ports 256 bis 258 offen und der Microsoft Proxy Server die TCP-Ports 1080 und 1745. Mit dem Wissen dieser Default-Ports kann sich ein mit einem Portscanner bewaffneter Angreifer sehr schnell Klarheit über das eingesetzte System verschaffen.

    Mit der Option "-P0" wird bei nmap der ICMP-Ping vor dem Scan weggelassen. Dieser Punkt ist sehr wichtig, da die meisten Firewall-Systeme so konfiguriert werden, dass sie auf ICMP-Pakete nicht reagieren, ja sie gar komplett und lautlos verwerfen.

    7.5.2 Portscans: Gegenmassnahmen
    Die Gegenmassnahmen zu Portscans auf Firewall-Systeme sind in den meisten Punkten mit den in Kapitel 2 (Scanning) besprochenen identisch: Die Netzwerktopologie sollte solche Scans bestmöglich im Sande verlaufen lassen. Dies kann mit geschickt platzierten Routern geschehen.

    Portscans erkennen

    Viele Firewall-Systeme besitzen die Funktionalität eines IDS (Intrusion Detection System): Auffällige Portscans werden so ziemlich schnell entdeckt und gegebenenfalls die definierten Massnahmen eingeleitet. Problematisch sind jedoch verdeckte, langsame oder Scans mit gefälschter Absender-Adresse. Diese werden aufgrund ihrer Eigenarten nur selten (korrekt) Beachtet und es bedarf zu deren Erkennung eine Feinoptimierung der IDS-Module.

    RealSecure für Windows NT und diverse UNIX-Derivate kann mit der folgenden Einstellung darauf getrimmt werden, auch unauffälligere Scans zu erkennen. Hierbei wird der Grenzwert für Einzelportscans verschärft, indem die Parameter der Portscan-Signatur angepasst werden:

  • Wählen Sie die Richtlinie für ihre Netzwerk-Engine und passen Sie diese an.
  • Suchen Sie den Eintrag "Port Scan" und klicken Sie auf die Schaltfläche "Options".
  • Stellen Sie den Wert für Ports auf 5.
  • Ändern Sie Delta auf 60 Sekunden.
  • Für die UNIX-Version der Firewall-1 von CheckPoint gibt es ein Utility von Lance Spitzner, welches zur Erkennung von Portscans am Firewall-System eingesetzt werden kann.

    Vorbeugende Massnahmen

    Um den Erfolg der Erkennung von Standartports einzuschränken, sollten diese Ports geschlossen oder anderweitig unerreichbar, zum Beispiel durch einen Router vor der Firewall, gemacht werden.

    Sollte sich ein Cisco-Router im besagten Einsatz befinden, lohnt es sich die folgende ACL einzuhacken, um die besprochenen Scans abzublocken. Zuerst muss das Cisco-Gerät in den"enable"-Modus versetzt werden, um danach mittels "write" die Schreibberechtigung einzuholen. Danach tippen Sie einfach die gewünschten Zeilen ihrer Umgebung angepasst ein:

    access-list 101 deny tcp any any eq 256 log  ! Firewall-1-Scan blocken
    access-list 101 deny tcp any any eq 257 log  ! Firewall-1-Scan blocken
    access-list 101 deny tcp any any eq 258 log  ! Firewall-1-Scan blocken
    access-list 101 deny tcp any any eq 1080 log  ! SOCKS-Scan blocken
    access-list 101 deny tcp any any eq 1745 log  ! WinSock-Scan blocken

    Zwar lassen sich aufgrund der gefilterten TCP-Ports 256 bis 258 die Cisco-Geräte nicht mehr aus dem Internetadministrieren, doch ist dieses Feature eh meist überflüssig.

    Zusätzlich sollten die Router über eine sogenannte Cleanup-Richtlinie verfügen, welche die gleiche Auswirkung wie eine Blockierung hat. Folgende Zeile übernimmt diese Funktion bei Cisco-Routern:

    access-list 101 deny ip any any log  ! Jedes bis hierhin gelangte Paket abweisen und protokollieren

    7.5.3 Route-Tracing
    Die etwas leisere und subtilere Methode des Auskundschaftens von Firewall-Elementen ist das sogenannte Route-Tracing. Unter UNIX und seinen Derivaten kann man sich des Befehls traceroute (bedarf root-Privilegien!) und unter allen Windows-Versionen tracert.exe bedienen, um die Hops zu einem Ziel ausfindig zu machen. Unter UNIX/Linux verfügt Traceroute über den Parameter "-I", um den Trace anstatt mit der Übermittlung von UDP-Paketen mittels der ICMP-Technik durchzuführen:
     
    MS-DOS-Eingabeaufforderung
    C:\WINDOWS>tracert ubs.ch

    Route-Verfolgung zu ubs.ch [193.134.254.228]

    Über maximal 30 Abschnitte:

      1     1 ms     0 ms     1 ms  gateway.computec.ch [192.168.0.1]
      2    74 ms    14 ms    25 ms  gw.hispeed.ch [62.2.65.254]
      3   290 ms   239 ms   248 ms  rtr1.cablecom.net [62.2.1.1]
      4   285 ms   281 ms   185 ms  fw.ubs.ch [193.134.254.1]
      5   450 ms   495 ms   442 ms  gate.ubs.ch [193.134.254.10]
      6   288 ms   250 ms   248 ms  ubs.ch [193.134.254.228]

    Route-Verfolgung beendet.

    C:\WINDOWS>_

    Ein Traceroute zu ubs.ch, um Firewall-Systeme ausfindig zu machen: Der Hop 4 scheint ein Firewall-Element zu sein.

    Die Chancen stehen sehr gut, dass der Hop direkt vor dem Ziel (gate.ubs.ch mit der IP-Adresse 193.134.245.10) ein Firewall-Element ist; im Besonderen, wenn man die DNS-Auflösung genauer betrachtet: Oft haben solche Hosts den Namen fw, firewall, gw oder gateway.

    Dieses Tracerouting funktioniert nur, wenn alle dazwischenliegenden Router auf TTL-Expired-Pakete reagieren. Oft werden aber aus Performance- und Sicherheitsgründen die Router so eingestellt, dass sie auf keinerlei TTL-Expired-Pakete eingehen: Weder auf welche von ICMP, noch auf solche durch UDP. In einem solchen Szenario fällt die Einsicht für den Angreifer weniger genau aus:
     
    MS-DOS-Eingabeaufforderung
    C:\WINDOWS>tracert ubsw.ch

    Route-Verfolgung zu ubsw.ch [193.84.178.23]

    Über maximal 30 Abschnitte:

      1     1 ms     0 ms     1 ms  gateway.computec.ch [192.168.0.1]
      2    74 ms    14 ms    25 ms  gw.hispeed.ch [62.2.65.254]
      3   290 ms   239 ms   248 ms  rtr1.cablecom.net [62.2.1.1]
      4     *        *        *     Zeitüberschreitung der Anforderung.
      5     *        *        *     Zeitüberschreitung der Anforderung.
      6     *        *        *     Zeitüberschreitung der Anforderung.
      7     *        *        *     Zeitüberschreitung der Anforderung.

    Route-Verfolgung beendet.

    C:\WINDOWS>_

    Ein Traceroute zu ubsw.ch, um Firewall-Systeme ausfindig zu machen: TTL-Expired-Pakete werden ab Hop 4 geblockt.

    Ein Traceroute bei geblockten TTL-Expired-Paketen ist jedoch letztendlich fast genauso aufschlussreich: Ab Hop4 werden die besagten Paketeverworfen, was zu einer Zeitüberschreitung der Anforderung führt. Diese Anomalie deutet auf ein vollwertiges Firewall-Element oder eine Netzwerkstörung hin.

    7.5.4 Route-Tracing: Gegenmassnahmen
    Um das Herumschnüffeln mittels traceroute zu verhindern, muss man alle sicherheitsrelevanten Elemente des Beantwortens von TTL-Expired-Paketen hindern.

    Erkennung

    Route-Tracing vorgehen werden am Einfachsten erkannt, indem man Ausschau nach ICMP- und UDP-Paketen mit einem TTL-Wert von 1 hält und diese gegebenenfalls überwacht. Mit RealSecure für Windows NT und diverse UNIX-Derivate kann diese Aufgabe leicht erfüllt werden, indem die Option "TRACE_ROUTE DECODE NAME" in den Einstellungen aktiviert wird.

    Verhindern

    Um traceroute-Angriffe zu verhindern, müssen alle routenden Elemente so konfiguriert sein, dass sie nicht auf TTL-Expired-Meldungen reagieren, wenn ein Paket mit einem TTL von 0 oder 1 empfangen wird. Eine solche Einstellung wird mittels der folgenden ACL bei Cisco-Routern vorgenommen:

    access-list 101 deny ip any any 10 0 ! tt1-exceeded

    Im Idealfall werden alle unnötigen UDP-Pakete an den Routern ignoriert und verworfen.

    7.5.5 Banner abfangen
    Beim Auskundschaften eines Netzwerk auf der Suche nach Firewall-Systemen können Portscans wichtige Informationen liefern. Die meisten Firewalls haben keine standartmässigen offenen Ports und lassen sich so seltenst ausfindig machen und eindeutig bestimmen. Viele Firewall-Elemente (vor allem aktive Proxies auf Application-Gateways) protzen jedoch wie so mancher Dienst mit einem aussagekräftigen Banner, der bei der ersten Phase einer hergestellten Verbindung zum System dem Anwender zugeworfen wird.

    Um diese Banner abgreifen zu können, bedienen wir uns des Utilitiesnetcat und stellen eine Verbindung zu einem aktiven Dienst eines potentiellen Application-Gateways her:
     
    C:\WINNT\System32\cmd.exe
    Microsoft(R) Windows NT(TM)
    (C) Copyright 1985-1996 Microsoft Corp.

    C:\WINNT>nc -v -n 192.168.0.2 21
    (UNKNOWN) [192.168.0.2] 21 (?) open
    220 Secure Gateway FTP server ready

    C:\WINNT>_

    Ein Verbindungsaufbau mit Netcat zu einem potentiellen Firewall-System.

    Die Status-Meldung "220 Secure Gateway FTP server ready" lässt eine Eagle Raptor vermuten. Ein weiterer Verbindungsaufbau zum gleichen Host auf den TCP-Port23 (Telnet) lässt diesen Verdacht erhärten:
     
    C:\WINNT\System32\cmd.exe
    Microsoft(R) Windows NT(TM)
    (C) Copyright 1985-1996 Microsoft Corp.

    C:\WINNT>nc -v -n 192.168.0.2 21
    (UNKNOWN) [192.168.0.2] 21 (?) open
    220 Secure Gateway FTP server ready

    C:\WINNT>nc -v -n 192.168.0.2 23
    (UNKNOWN) [192.168.0.2] 23 (?) open
    Eagle Secure Gateway
    Hostname:

    Der zweite Versuch deutet faktisch auf eine Eagle Raptor hin.

    Der letzte Versuch mit TCP-Port25 (SMTP) in Kontakt zu treten sollte langsam alle Zweifel bezüglich Host-Funktion beseitigen können:
     
    C:\WINNT\System32\cmd.exe
    Microsoft(R) Windows NT(TM)
    (C) Copyright 1985-1996 Microsoft Corp.

    C:\WINNT>nc -v -n 192.168.0.2 21
    (UNKNOWN) [192.168.0.2] 21 (?) open
    220 Secure Gateway FTP server ready

    C:\WINNT>nc -v -n 192.168.0.2 23
    (UNKNOWN) [192.168.0.2] 23 (?) open
    Eagle Secure Gateway
    Hostname:

    C:\WINNT>nc -v -n 192.168.0.2 25
    (UNKNOWN) [192.168.0.2] 25 (?) open
    421 fw2.ubs.com Sorry, the firewall does not provide mail service to you.

    Der zweite Versuch deutet faktisch auf eine Eagle Raptor hin.

    7.5.6 Banner abfangen: Gegenmassnahmen
    Die Lösung dieses non-paranoiden Umgangs mit solch vertraulichen Informationen ist eine Einschränkung des Publizierens von Banner-Texten. Dies kann entweder durch dazwischengeschaltete und korrekt konfigurierte Router-Elemente oder eine Modifikation der Banner-Ausgaben geschehen.

    Wie sie die Banner-Informationen den eigenen Bedürfnissen anpassen, erfahren Sie aus der mitgelieferten Dokumentation oder direkt vom Hersteller des Produkts. Bei Raptor-Firewalls müssen zum Beispiel die "Message of the Day"-Meldungen in den Dateien ftp.motd und telnet.motd zu diesem Zweck manipuliert werden.

    7.5.7 Ermittlung mit nmap
    Ich persönlich liebe die Arbeit mit nmap, da es sehr schnell und effizient, auch in Firewall-Umgebungen, die gewünschten Informationen bei korrekter Handhabung bereitstellen kann. Wenn ein Host mit nmap nach ansprechbaren Portsgescannt wird, werden nicht nur offene und geschlossene Ports dokumentiert, sondern auch welche, die gefiltert werden.

    Ein blockierterPort bei der Ausgabe von nmap deutet auf einen der folgenden drei Zustände hin:

  • Es wurde kein Paket mit gesetzten SYN- und ACK-Flags empfangen.
  • Es wurde kein Paket mit gesetzten RST- und ACK-Flags empfangen.
  • Eine ICMP-Nachricht des Typs 3 (Ziel unerreichbar) mit dem Code 13 (Communication Administratively Prohibited) wurde empfangen. Mehr Informationen zu diesem "Sonderfall" finden sich in RFC 1812.
  • nmap wertet diese differenten Zustände gleichermassen als gefiltert. Wenn wir zum Beispiel www.ubs.com scannen, erhalten wir ein ICMP-Paket, das auf einen durch ein Firewall-System geschlossenen TCP-Port23 (Telnet) hinweist:
     
    root@prometheus:~ > nmap -p21,22,23,80 -P0 -vv www.ubs.com

    Starting nmap V. 2.54beta by fyodor@insecure.org ( www.insecure.org/nmap/ )
    No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. Use -sP if you really don't want to portscan (and just want to see what hosts are up).
    Initiating TCP connect() scan against www.computec.ch (195.141.76.15)
    Adding TCP port 80 (state Open).
    Adding TCP port 23 (state Firewalled).
    Adding TCP port 21 (state Closed)
    Adding TCP port 22 (state Open).
    The TCP connect scan took 3 seconds to scan 4 ports
    Interesting ports on www.computec.ch (195.141.76.15):
    Port    State        Protocol  Service
    21      closed       tcp        ftp
    22      open         tcp        ssh
    23      firewalled   tcp        telnet
    80      open         tcp        http

    nmap run completed -- 1 IP adress (1 host up) scanned in 3 seconds
    root@prometheus:~ > _

    Ein erweiterter Portscan mittels nmap auf SuSE Linux 7.0, um nach gefilterten Ports Ausschau zu halten.

    Der Status "firewalled" beim Telnet-Dienst (TCP-Port23) besagt, dass ein ICMP-Paket Typ 3 Code 13 (Admin Prohibited Filter) empfangen wurde, wie man bei der tieferen Analyse durch einen Paket-Analyzer (z.B. tcpdump) eindeutig bestimmen könnte.

    Es kann auch sein, dass nmap die Meldung "unfiltered" zurückliefert, welches einen der folgenden Prozeduren vermuten lässt:

    1. Es wurde ein Paket mit gesetzten RST- und ACK-Flags empfangen.
      1. Der Scan kann das Firewall-System durchdringen, erreicht jedoch keinen offenen Port am Ziel-System.
      2. Das Firewall-System antwortet stellvertretend für das Ziel-System mit dessen gespooftenIP-Adresse und gesetzten RST- und ACK-Flags.
    root@prometheus:~ > nmap -sS -p1-300 192.168.0.100

    Starting nmap V. 2.54beta by fyodor@insecure.org ( www.insecure.org/nmap/ )
    Interesting ports on fw4.ubsw.com (192.168.0.100):
    (Not showing ports in state: filtered)

    Port    State        Protocol  Service
    7       unfiltered   tcp       echo
    53      unfiltered   tcp       domain
    256     open         tcp       rap

    nmap run completed -- 1 IP adress (1 host up) scanned in 0 seconds
    root@prometheus:~ > _

    Ein Stealth-Portscan mit nmap auf einem SuSE Linux 7.1.
    7.5.8 Ermittlung mit nmap: Gegenmassnahmen
    Erkennung

    Die Erkennung von nmap-Suchläufen haben wir erstmals in Kapitel 2 (Scanning) besprochen und unterscheiden sich nicht in den mit Firewall-Systemen in Zusammenhang bringbaren Vorgehensweisen.

    Vorbeugende Massnahmen

    Soll ein potentieller Angreifer daran gehindert werden, mit der Hilfe der besagten ICMP-Nachrichten die Rulesets des Firewall-Systemsherauszufinden, unterbinden Sie alle Nachrichten für "IP unerreichbar". Bei Cisco geschieht dies mit der folgenden Filterzeile:

    no ip unreachables

    7.5.9 Ports identifizieren
    Einige Firewall-Systeme reagieren bei einem Verbindungsaufbau mit einem individuellen Fingerabdruck in Form eines Zahlencodes, der zur Erkennung verwendet werden kann. Der folgende Test mittels netcat lässt hinter dem Host mit der IP-Adresse192.168.0.50 eine CheckPoint Firewall-1 vermuten (Im Grunde müsste der offene TCP-Ports 257 einen Angreifer schon hellhörig werden lassen!):
     
    C:\WINNT\System32\cmd.exe
    Microsoft(R) Windows NT(TM)
    (C) Copyright 1985-1996 Microsoft Corp.

    C:\WINNT>nc -v -n 192.168.0.1 257
    (UNKNOWN) [192.168.0.1] 257 (?) open
            30000003

    C:\WINNT>nc -v -n 192.168.0.50 257
    (UNKNOWN) [192.168.0.1] 257 (?) open
            31000000

    C:\WINNT>_

    Ein erweiterter Portscan mittels nmap um nach gefilterten Ports Ausschau zu halten.
    7.5.10 Ports identifizieren: Gegenmassnahmen
    Erkennung

    Ein Verbindungsaufbau kann durch das Tool RealSecure für Windows NT und diverse UNIX-Derivate erkennt und ihm gegebenenfalls mit vordefinierten Aktionen entgegengewirkt werden. Die Einstellung kann anhand der folgenden Schritte vorgenommen werden:

  • Editieren Sie Ihre Richtlinie.
  • Selektieren Sie das Register "Connection Events".
  • Fügen Sie eine Verbindung durch Klick auf "Add Connection" hinzu.
  • Erstellen Sie einen Eintrag für die CheckPoint.
  • Wählen Sie die Scroll-Liste "Destination".
  • Klicken Sie nun auf "Add".
  • Vor dem Klick auf "Ok" muss der Service und Port angegeben werden.
  • Wählen Sie einen neuen Port und klicken Sie erneut auf "Ok".
  • Klicken Sie ein letztes Mal auf "Ok" und wenden Sie die neu erstellte Richtlinie auf die Engine an.
  • Vorbeugende Massnahmen

    Verbindungsanforderungen zu aussagekräftigen Ports sollten schon im Vorfeld unterbunden werden. Eine einfache Cisco-ACL kann einen solchen Angriff effizient unterbinden:

    access-list 101 deny tcp any any eq 257 log  ! Firewall-1-Scans blocken

    7.6 Durch Firewalls scannen
    Eine Firewallabzuscannen mag ja für einen Angreifer als etwas Produktives erscheinen. Viel interessanter ist jedoch für ihn, was sich hinter dem Firewall-System verbirgt. Da kommen einige interessante Techniken ins Spiel, die ich nun gerne vorstellen möchte.

    7.6.1 hping

    Salvatore Sanfilippo publizierte ein erweitertes Ping-Utility, welches TCP-Pakete an einen Ziel-Port zu schicken pflegt, um die Rückantworten einer haargenauen Analyse zu unterziehen. hping wertet jedes Paket, ob empfangen oder nicht, bis ins kleinste Detail aus und kann so viele wichtige Informationen bereitstellen. Durch hping können offene, blockierte, verworfene und zurückgewiesene Pakete erkannt werden.
    7.6.2 hping: Gegenmassnahmen
    hping-Angriffe abzuwehren ist eine Wissenschaft für sich. Die einfachste und zugleich radikalste Möglichkeit ist alle ICMP-Nachrichten des Typs 13 unschädlich zu machen.
    7.6.3 Firewalking
    Firewalk ist ein ausgeklügeltes Tool, welches ähnlich einem Portscanner offene Ports hinter einem Firewall-System erkennen kann. Das von Mike Schiffman (aka. Route) und Dave Goldsmith geschriebene Utilityscannt einen Host auf der entgegenliegenden Seite einer Firewall und meldet die Regeln für den Dialog, ohne das Zielsystem effektiv tangiert zu haben.

    Die Idee hinter Firewalk ist ebenso simpel wie genial: Das Programm bildet Pakete mit einem IP-TTL-Wert, der so berechnet wurde, dass er einen Hop nach der Firewall abläuft. Wird das besagte Paket vom Firewall-System durchgelassen und läuft wie erwartet ab, dann erzeugt es die ICMP-Meldung "TTL expired in transit". Wird das Paket hingegen von einem Firewall-Element blockiert oder verworfen, kommt entweder gar keine Antwort zurück oder die Antwort besteht aus einem ICMP-Paket des Typs 13 (Admin Prohibited Filter).
     
    Welcome to SuSE Linux 7.1 (i386) - Kernel 2.2.17

    prometheus login: root
    Password: 
    Last login: Thu Jan 18 19:16:21 on tty1
    Have a lot of phun...
    root@prometheus:~ > firewalk -pTCP -S135-139 193.134.254.228
    Ramping up hopcounts to binding host...
    probe:  1  TTL:  1 port 32812:  expired from [gw.ubs.com]
    probe:  2  TTL:  2 port 32812:  expired from [fw.ubs.com]
    probe:  3  TTL:  3 port 32812:  Bound scan at 3 hops [fw.ubs.com]
    port 135: open
    port 136: closed
    port 137: closed
    port 138: closed
    port 139: open

    root@prometheus:~ > _

    Firewalking gegen das Firewall-System von ubs.com, um die offenen Ports hinter der Firewall zu erkennen.

    Die Einsichten durch Firewalk sind nicht immer 100%ig kompetent, was damit zusammenhängt, dass viele Firewall-Systeme den Ablauf eines Pakets frühzeitig erkennen und ein ICMP TTL EXPIRED-Paket zurücksenden, bevor die Filter-Regeln zu Rate gezogen worden sind. Ist dies der Fall, so werden fälschlicherweise alle Ports durch das Utility als offen erkannt.

    7.6.4 Firewalking: Gegenmassnahmen
    Als negativer Nebeneffekt zur konstruktiven Blockierung aller ICMP TTL EXPIRED-Pakete bei der externen Schnittstelle sind Einbrüche in der Performance zu verbuchen, da berechtigte Clients beim Verbindungsaufbau nicht vorzeitig wissen können, was mit ihrer Anforderung geschehen wird.
    7.7 Firewall-Systeme austricksen
    Es gibt einige von Angreifern gern genutzte Kniffe, die die Kompetenz eines Firewall-Systems arg ankratzen können. Folgend möchte ich nun gerne einige dieser Standart-Tricks vorstellen.

    7.7.1 Freizügige Filter-Regeln

    Ich verschweige jetzt heimlicherweise die von mir in Erfahrung gebrachte Anzahl Firewall-Systeme mit zu laxen Richtlinien. Aber schon oft durfte ich an ein Firewall-Element heranteten, welches aus Zeitgründen nur schwammig konfiguriert wurde. Beliebt ist zum Beispiel bei gestressten Administratoren die Regeln nur ansatzweise zu setzen: Statt "lasse Aktivitäten des DNS-Servers vom ISP mit der IP-Adresse 62.2.32.5 mit einem Quellport von 53 und einem Zielport von 53 zu" werden oft nur "lasse alle Aktivitäten mit einem Quellport von 53 zu" verwendet. Findet sich diese in ihren Grundzügen zwar korrekte Konfiguration, so könnte ein Angreifer ohne Mühe das gesamte Netzwerk von Aussen abtasten, insofern er bei seinen Aktionen stets den TCP-Port 53 (DNS) als Quelle angibt.

    Übrigens: Ein ähnliches Problem resultierte bei CheckPoint-Firewalls in den Versionen 3.0 und 4.0, die standartmässig mit den für jederman offenen PortsUDP-53 (DNS-Lookup), UDP-53 (DNS-Zonetransfer) und UDP-520 (RIP) ausgeliefert wurden. Gelingt es einem Angreifer den Fortlauf seiner Aktionen durch diese Ports zu schleusen, so kann er die zu schützenden Systeme ohne Protokollierungs-Ängste in aller Ruhe kompromittieren.

    7.7.2 Freizügige Filter-Regeln: Gegenmassnahmen
    Der Administrator sollte genügend Kompetenz aufweisen und die nötige Zeit aufwenden können, um sich in aller Ruhe einer effizienten Filterung anzunehmen. Verwenden Sie in Firewall-Konfigurationen Wildcards und Jokerzeichen so wenig wie möglich, da sonst relativ schnell und ungewollt unliebsamen Gästen Eintritt gewährt werden kann.
    7.7.3 ICMP- und UDP-Tunneling
    Tunneling ist ein Synonym für die Verkapselung von Echtdaten in Paket-Headern. Viele Firewall-Elemente lassen ICMP ECHO REPLY- und UDP-Pakete ohne Einschränkung durch und bieten so eine für einen erfahrenen Eindringling angenehme Angriffsfläche für diese Attacke.

    Jeremy Rauch und Mike D. Schiffmann haben die Tunneling-Hypothese eindrücklich in die Tat umgesetzt und stellen ein auf dem Client-/Server-Prinzip aufgebautes Toolkit zur Verfügung: Wird lokid auf einem Host hinter einer Firewall installiert, die ICMP ECHO- und ICMP ECHO REPLY-Pakete durchlässt, kann der Angreifer mittels dem Client-Teil loki Befehle in ICMP-ECHO-Paketen verpacken und an den Server schicken. Dieser extrahiert die Kommandos und schickt die in ICMP ECHO REPLY-Paketen verkapselten Antworten an den Client zurück.

      Host A            Firewall-Element: Paket-Filter               Host B
     Angreifer                ¦     Erlaubt                  Kompromittiertes System
    loki-Client               ¦ ICMP-Nachrichten                   loki-Daemon
    ,---------.               ¦ ,--------------.                   ,---------.
    |Linux    | ----- Steuerungs-Informationen in ICMP-Paket ----> |Linux    |
    |         | <---- Ausgabe-Informationen in ICMP-Antwort ------ |         |
    `---------'               ¦ |              |                   `---------'
    [_________]               ¦ `--------------'                   [_________]
                              ¦
           Internet           ¦             LAN - Local Area Network
    Das Prinzip von ICMP-Tunneling.

    7.7.4 ICMP- und UDP-Tunneling: Gegenmassnahmen
    Diese Angriffs-Technik kann mit der Deaktivierung des gesamten ICMP-Verkehrs über die Firewall-Systeme unterbunden werden. Folgende Beispiel-ACL für Cisco-Elemente setzt genau dies in die Tat um:

    access-list 101 permit icmp any 192.168.0.0 0.255.255.255 8 ! echo
    access-list 101 permit icmp any 192.168.0.0 0.255.255.255 0 ! echo-reply
    access-list 102 deny   ip   any any         any             ! blocke und logge alles

    Probleme kann es geben, wenn der genutzte ISP die Online-Zeit zur Abrechnung mittels ICMP-Nachrichten herausfinden will. Dieser Umstand war jedoch in der Schweiz noch nie grossflächig Mode.

    7.7.5 Localhost gebrauchen
    Viele auf UNIX-basierenden Proxies sind aufgrund ihrer Komplexität in ihrer Handhabung ziemlich schwerfällig, was schnell die restriktive Konfiguration des lokalen Zugriffs in den Hintergrund rücken lässt: Zugriffe auf ausserhalb liegende Netzwerke werden zwar einer Authentifizierung unterzogen - Lokale Zugriffe sind manchmal aber oft ohne eine solche für jederman möglich.

    Ein Sorgenkind dieser Art ist WWWOffle: Ein komfortabler Proxy für HTTP und FTP. Dessen Konfiguration kann simpel durch einen Webbrowser vorgenommen werden. Ein  Angreifer kann unter Umständen durch die korrekte Anwahl des WWWOffle-Servers mittels Browser die Konfiguration zu seinen Gunsten modifizieren.

    7.7.6 Localhost gebrauchen: Gegenmassnahmen
    Die erfolgreiche Schliessung dieser Sicherheitslücke hängt ausnahmslos mit der Individualität der betroffenen Proxy-Lösungen zusammen. Am besten und falls notwendig sollten localhost-Logins gänzlich unterbunden werden. Wie dies definiert wird, sollte aus der dazugehörigen Dokumentation entnommen werden können.

    Es empfiehlt sich auch die Installation eines TCP-Wrappers auf der UNIX-Firewall, um Verbindungsanforderungen von unauthorisierten Hosts und IP-Adressen einzuschränken.

    7.7.7 Nicht genehmigte Zugriffe ausnutzen
    Ich verbrachte die drei Jahre meiner kaufmännischen Ausbildung im internen Reisebüro der ABB. Über Wochen hinweg brachte ich in Erfahrung, dass über einen Webproxy alle Verbindungen ins Internet gebündelt werden würden. Wie sich herausstellte nahm dieser, auch von meiner Arbeitsstation im Reisebüro ansprechbaren Proxy alle Verbindungen an. Ich muss wohl nicht gross erwähnen, dass ich so manche freie Minute unerlaubt und ebenso unbeobachtet im World Wide Web verbracht habe... Eine solche Fehlkonfiguration ist keine Seltenheit. Gefährlicher wird es jedoch erst, wenn ein Benutzer aus dem Internet den Proxy-Server für zwielichtige Aktionen missbrauchen kann. Es wird ihm so indirekt ein anonymes Treiben im Internet ermöglicht. Die daraus resultierenden Schelten werden sogar eventuell an Sie gerichtet, da die eventuell vom Eindringling gefahrenen Angriffe so aussehen, als würden sie direkt vom Proxy-Element gestartet worden sein.
    7.7.8 Nicht genehmigte Zugriffe ausnutzen: Gegenmassnahmen
    Der Proxy-Zugriff sollte nur authorisierten Personen erlaubt werden und am externen Interface nur bei zwingendem Bedarf Verbindungsanforderungen möglich sein.

    Viele Proxy-Server erlauben zudem die Einführung einer Authentifizierung mit Benutzername und dazugehörigem Passwort, derer sich jeder Nutzer zuerst vor Inbetriebnahme unterziehen muss. Diese Hürde kann einen unerlaubten Eingriff durch Dritte zu unseren Gunsten enorm erschweren.

    Die zur Abschottung nötigen Schritte entnehmen Sie bitte aufgrund ihrer Individualität der mitgelieferten Dokumentation.

    7.8 Zusammenfassung
    Ich hoffe, ich habe niemandem mit diesen niederschmetternden Informationen einen Schrecken eingejagt. Keinesfalls bin ich Firewall-Systemen abgeneigt - Sie sind bei korrektem Einsatz sogar mehr als Gold wert.

    Zugleich soll mit dieser Niederschrift verdeutlicht werden, dass auch die teuerste Firewall kein Allheilmittel darstellt: Firewall-Elemente sind Computer, die von Menschen entwickelt, produziert und gewartet werden. Menschen machen Fehler, und so kommt es nicht selten vor, dass durch falsche Handhabung ein Firewall-System einfach ausgetrickst oder gar kompromittiert werden kann.

    Die Netzwerk-Utilitiestraceroute, nmap, hping und firewalk leisten einem Angreifer beim Auskundschaften gute Dienste und spezifische Schwachstellen sind von einem geübten Cracker schnell gefunden und ausgenutzt. Die aufgezeigten Gegenmassnahmen erschweren jedoch dieses Vorhaben und können es sogar teilweise mit dem Titel Utopie beschmücken.

     
    << | < | = | > | >>