Insbesondere für die Industriespionage werden Rogue Access Points in Unternehmen verwendet. Sehr leistungsstarke Access Points werden dabei mit der SSID des firmeneigenen Access Points versehen. Damit werden die mittels WLAN angebundenen Endgeräte dazu gebracht, den Roque Hotspot zu verwenden und alle Daten über das System des Angreifers zu leiten.

Es ist insbesondere für nicht sensibilisierte Anwender kaum möglich, einen Rogue Access Point von einem legitimen Access Point zu unterscheiden. Ab 2012 sollen nach den Vorgaben der WiFi Alliance alle Hotspots über erweiterte Sicherheitsfunktionen verfügen, die den Einsatz von Roque Access Points erschweren sollen. Als Anwender kann zudem die Verwendung eines VPN-Tunnels helfen, sensiblen Datenverkehr durch potentiell unsichere Netzwerke zu übertragen. Durch den VPN-Tunnel sind alle übertragenden Daten verschlüsselt und auch am Access Point nicht einsehbar.

ICMP ist spezifiziert für die Version 4 des Internet Protocols (IPv4).  Das Protokoll Internet Control Message Protocol for the Internet Protocol Version 6 (ICMPv6) ist als Gegenstück in IPv6-Umgebungen.

ICMP-Nachrichten werden als Nutzlast in IP-Datagramme eingekapselt. Dabei sind im IP-Header der Servicetyp 0 und die Protokollnummer 1 gesetzt. Im Fall von ICMPv6 lautet die Protokollnummer 58. Um verschiedene Aufgaben und Zustände übermitteln zu können, bietet ICMP verschiedene Typen und Codes.  Zu jedem Typ kann es mehrere Codes geben, die den Typ genauer spezifizieren.

Die nachfolgende Tabelle zeigt die wichtigsten Typen und Codes von ICMP (in Version 4).

Die bekannteste Anwendung von ICMP ist die Applikation “Ping”. Dabei wird ein ICMP-Paket vom Typ 8 Code 0 (Echo Anfrage) an ein entferntes Gerät verschickt. Erhält der Absender ein ICMP-Paket vom Typ 0 Code 0 zurück, ist das entsprechende Gerät auf Netzwerk-Ebene (Layer 3) erreichbar. Bleibt dieses Paket aus, gibt es Probleme in der IP-Kommunikation. Ping wird daher häufig als erstes Hilfsmittel im Debugging von IP-Netzwerken eingesetzt.

Weiterhin stehen unter der Bezeichnung TEST-NET-1/2/3 die Adressbereiche 192.0.2.0/24, 198.51.100.0/24 sowie 203.0.113.0/24 nun für Dokumentationszwecke zur Verfügung. Durch die Freigabe der Adressbereiche erhoffen sich die verwaltenden Stellen eine Verfügbarkeit von IPv4-Adressen bis Mitte 2011. Spätestens dann werden alle verfügbaren Adressen vergeben sein und die Umstellung auf IPv6 erfolgen müssen.

Eine aktuelle Übersicht über die IP-Adressräume von IPv4 und IPv6 gibt es hier.

Die folgende Tabelle stellt die drei Modi gegenüber.

Terminal Monitor

Sofern die Verbindung zwischen dem PC und dem Gerät über den seriellen Anschluss (Console) hergestellt wird, werden alle Debugging-Ausgaben auf dem PC ausgegeben. Erfolgt die Kommunikation jedoch über Telnet oder SSH, werden die Ausgaben des Debuggings nicht direkt ausgegeben. Um die Ausgabe der Meldungen auf den Terminal-Sitzung umzuleiten, wird der Befehl terminal monitor verwendet.

Router#terminal monitor

Dabei ist zu beachten, dass jeweils nur eine Sitzung die Ausgaben empfangen kann. Mehrere parallel arbeitende Administratoren können sich demnach gegenseitig behindern.

Debugging aktivieren

Um das Debugging zu starten, wie der Befehl debug im globalen Modus verwendet. Mittels debug ? kann die Liste der verfügbaren Debuggings aufgerufen werden.

Router#debug ?

Durch die umfangreiche Hierachie kann das Debugging zielführend konfiguriert werden. Die Hierachie entspricht im Wesentlichen dem zur Konfiguration eingesetzten Aufbau.

Debugging von IP-Datenverkehr

Beispielhaft wird hier der gesamte IP-Datenverkehr des Routers analysiert. Dazu sollen ale IP-Pakete analysiert und detailliert dargestellt werden.

Router#debug ip packet detail

Debugging von IP-Datenverkehr mittels ALCs

Mit dem oben vorgestellten Debugging erhält der Administrator eine Vielzahl von Informationen über den IP-Datenverkehr, der auf dem Gerät stattfindet. In der Regel führt dies jedoch nicht zum Ziel, da die Informationen ungefiltert ausgegeben werden. Um das Debugging besser steuern zu können, lassen sich Access Controll Lists (ACLs) definieren. Diese werden zunächst in die Konfiguration geschrieben, ehe sie für das Debugging verwendet werden können. Der grundsätzliche Aufbau einer ACL sieht folgenden Aufbau vor:

access-list <ID> <permit|deny> <Protokoll> <Quelladresse> <Quellnetzmaske (Wildcard)> <Zieladresse> <Zielnetzmaske (Wildcard)

Um beispielsweise den Datenverkehr von Netz 10.0.0.0/24 zum Host 10.1.1.4 zu analysieren, wird die folgende ACL in die Konfiguration des Routers geschrieben:

Router(config)#access-list 101 permit ip 10.0.0.0 0.0.0.255 host 10.1.1.4

Nach dem ACL angelegt ist, kann das Debug-Kommando um die ID der ACL ergänzt werden:

Router#debug ip packet detail 101

Nun werden lediglich die IP-Pakete analysiert, die der ACL entsprechen. So kann durch den Einsatz geeigneter Access Controll Lists die Anzahl der Pakete im Debugging drastisch reduziert werden. Dies erleichert dem Adminstrator die Analyse und vermindert die Auslastung des Systems. Die Access Controll Lists können auch über einen ACL-Generator erzeugt werden.

Debugging deaktivieren

Um das Debugging einer einzelnen Funktion zu beenden, wird der zu Aktivierung verwendet Ausdruck verwendet. Jedoch wird debug durch undebug ersetzt. Sollen alle Debugging-Vorgänge beendet werden, kann der Befehl undebug all genutzt werden.

Router#undebug ip packet detail 101

1. Voraussetzungen

Für das folgende Szenario wird ein Linux-Server benötigt, auf dem admistrative Berechtigungen bestehen. Weiterhin müssen in der Firewall die Ports 3128 (Squid-Proxy) und 22 (SSH) freigegeben werden.

2. Installation des Proxy-Servers

Zunächst wird der Proxy-Server Squid, einer der meistverbreitesten seiner Art, installiert. In der Regel kann Squid über den Paketverwaltungsdienst installiert werden (bspw. apt-get install squid). Unbedingt beachtet werden sollten die Hinweise des BSI zur Sicherheitsuntersuchung der Squid Proxy-Servers. Hier werden wichtige Hinweise zur Absicherung des Servers gegeben. Weitere Konfigurationen sind nicht notwendig.

3. Konfiguration von PuTTY

Das Programm PuTTY ist ein freier SSH/Telnet-Client, der kostenfrei bezogen werden kann. Es steht für alle gängigen Betriebssysteme zur Verfügung.
Nach dem Ausführen erscheint zunächst eine Eingabemaske, in der die IP-Adresse und der SSH-Port des Servers eingegeben werden muss. Über das Menü Connection > SSH > Tunnels kann die Tunnel-Konfiguration erreicht werden. Der lokale Source-Port kann entsprechend der Richtlinien zur Portvergabe frei gewählt werden. Jeder Datenverkehr, der das lokale System auf diesem Port erreicht, wird von nun an über den SSH-Tunnel an den Server übertragen. Als Destination-Adress dient die Kombination der Server-Adresse und des Squid-Ports, in der Regel Port 3128. Nachdem diese Einstellungen gespeichert wurden, kann die Verbindung zum Server nun aufgebaut werden.

Konfiguration eines SSH-Tunnels mittels PuTTY - 1

Konfiguration eines SSH-Tunnels mittels PuTTY - 2

Wichtig: PuTTY bzw. die Verbindung zum Server darf keinesfalls beendet werden, sonst ist ein verschlüsselter Internet-Zugriff nicht möglich!

4. Konfiguration der Internetverbindung

Nachdem der Server nun als Proxy-Server arbeitet und ein SSH-Tunnel zwischen dem lokalen System und der Server aufgebaut ist, muss nun der Internet-Datenverkehr in diesen SSH-Tunnel geleitet werden. Dazu muss in den Internetoptionen lediglich die Option Proxy-Server aktiviert werden. Als Server-Adresse wird localhost verwendet, als Port der im Abschnitt 3 definierte lokale Source-Port.

5. Funktionstest

Um zu prüfen, ob auch wirklich der gesamte HTTP-Datenverkehr verschlüsselt über den SSH-Tunnel bis zum Proxy-Server transportiert wird, kann mit Hilfe eines Sniffers (bspw. Wireshark) der Paketfluss analysiert werden. Während der Sniffer analysiert, können beliebige Internetseiten aufgerufen werden. Dabei sollten keine HTTP-Verbindungen im Sniffer erkennbar sein. Sofern lediglich SSH- und TCP-Pakete sichtbar sind, ist die Kommunikation korrekt verschlüsselt.

Die folgende Tabelle stellt wichtige Befehle beider Systeme gegenüber.

Routing-Tabellen

(Quelle: Juniper)

Jeder Hersteller definiert die Standardwerte selbstständig, sodass es Abweichungen geben kann. Aus diesem Grunde können die administrativen Distanzen manuell editiert werden.

Im Folgenden sind die administrative Distanzen der Hersteller Cisco und Juniper dargestellt.

Cisco

(Quelle: Cisco)

Juniper

(Quelle: Juniper)

Alle wichtigen Parameter können eingegeben werden, natürlich bietet die ACL-Syntax wesentlich mehr Funktionen, jedoch werden die meistgebrauchten Regeln bereits abgedeckt.

Gerne nehme ich Kritik und Anregungen auf, was noch verbessert bzw. ergänzt werden sollte.

Cisco ACL-Generator