Firewall Piercing

Aus UUGRN

Es gibt verschiedene Mittel und Wege, aus einem geschützen Netz heraus Verbindungem am Firewall vorbei bzw. unbemerkt mitten durch den Firewall hindurch Verbindungen zur Außenwelt aufzubauen.

Warnung

Es gibt üblicherweise gute Gründe, warum das jeweilige Netzwerk keine direkte Verbindung zur Außenwelt zulässt. Ein Firewall ist Bestandteil des Sicherheitskonzepts einer Organisation und wenn auf Antrag bei der zuständigen Stelle keine Verbindung erlaubt ist, dann kann das Umgehen der Zugriffsbeschränkungen möglicherweise disziplinarische Konsequenzen haben, i.d.R. hat schon der erfolglose Versuch diese Konsequenzen!
Der Autor / die Autoren dieses Artikels informieren über die Möglichkeiten, die Anwendung oder auch nur das Ausprobieren fällt in den Verantwortungsbereich des Lesers.


SSH als Transportmedium einsetzen[Bearbeiten]

SSH kann nicht nur selbst auf verschiedenen Transportmedien arbeiten, sondern kann auch selbst als Transportmedium dienen. So kann man beispielsweise auf die eine oder andere Weise eine SSH-Verbindung zu einem speziellen Shellserver herstellen und durch die SSH-Verbindung hindurch dann weitere Tunnelmechanismen verwenden.

SSH als SOCKS Proxy einsetzen[Bearbeiten]

OpenSSH kann als SOCKS-Proxy fungieren.

Entweder auf der Kommandozeile: 

# ssh -D localhost:1080 -N user@shell.uugrn.org

oder über die ssh_config(5): 

Host shell.uugrn.org
   [... weitere Optionen ... ]
   DynamicForward localhost:1080
   [... weitere Optionen ... ]

PPP durch SSH[Bearbeiten]

FIXME: Beschreiben, wie eine PPP-Verbindung durch die Terminalverbindung von SSH funktioniert (siehe Diskussionsseite)


IP Tunnel mit SSH[Bearbeiten]

FIXME: Beschreiben, wie man mit Hilfe einer OpenSSH-Sitzung ein tun(4)-Device einrichtet (siehe Diskussionsseite)


SSH-Missbrauch verhindern?[Bearbeiten]

FIXME: Beschreiben, wie man Tunnelmechanismen Client- oder Serverseitig unterbinden kann (siehe Diskussionsseite)


Einen Webproxy als Transportweg verwenden[Bearbeiten]

In komplexeren Firewallsetups gehört ein oder mehrere in Reihe geschaltete Webproxies normalerweise zum Gesamtkonzept, sofern das zu schützende Netz seinen Nutzern den Zugriff auf das World-Wide-Web erlauben will. Der Zugriff auf Webseiten erfolgt überlicherweise über 2 verschiedene Arten, der ungesicherte Zugriff auf tcp Port 80, besser bekannt als http, der durch SSL gesicherte Zugriff auf Webserver auf Port 443, besser bekannt auch als https.

http direkt
Ein (vereinfachter) http-Request auf den URL http://wiki.uugrn.org/index.php?title=Firewall_Piercing vom Client direkt an den Webserver sieht im Klartext so aus:
GET /index.php?title=Firewall_Piercing HTTP/1.1
Host: wiki.uugrn.org
Als Antwort auf diese Anfrage bekommen wir vom Webserver im Klartext:
HTTP/1.1 200 OK
Date: Tue, 25 Mar 2008 11:36:50 GMT
Server: Apache/2.2.8 (FreeBSD) mod_ssl/2.2.8 OpenSSL/0.9.7e-p1 DAV/2
Content-language: de
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

2397
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de" dir="ltr">
        <head>
[...]
</body></html>
 
0
http via Proxy
Der gleiche Request kann auch per Webproxy erfolgen, hier spricht der Webbrowser allerdings nicht mit dem entsprechenden Webserver, sondern nur und ausschließlich mit seinem Webproxy z.B. auf Port 3128/tcp oder 8080/tcp:
GET http://wiki.uugrn.org/index.php?title=Firewall_Piercing HTTP/1.0

Obiger Request würde ein Proxy beispielsweise so beantworten: 

HTTP/1.0 200 OK
Date: Tue, 25 Mar 2008 11:40:45 GMT
Server: Apache/2.2.8 (FreeBSD) mod_ssl/2.2.8 OpenSSL/0.9.7e-p1 DAV/2
Content-Language: de
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Content-Type: text/html; charset=utf-8
X-Cache: MISS from proxy.example.com
Via: 1.0 proxy.example.com:3128 (squid/2.6.STABLE17)
Proxy-Connection: close

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de" dir="ltr">
       <head>
[...]

</body></html>
https direkt
Anders als bei einfachem http spricht der Client mit dem Webserver über eine SSL verschlüsselte Verbindung, d.h. alle http-Aufrufe laufen verschlüsselt ab. Server und Client haben nicht nur eine verschlüsselte Verbindung, sondern darüber hinaus auch eine Prüfung von Zertifikaten, um die Vertrauenswürdigkeit (i.d.R. des Servers durch den Client) zu prüfen. Die HTTP-Methodenaufrufe innerhalb der SSL-Verbindung sehen aus wie bei normalem http, auf TCP-Ebene sieht man nur verschlüsselten Datenverkehr.
https via Proxy
Der Client hat keine Möglichkeit, auf IP-Ebene eine direkte Verbindung mit dem Webserver herzustellen, er muss dafür seinen Proxy-Server verwenden, der den Verbindungsaufbau zu Port 443 des Webservers vornimmt. Der Webbrowser spricht dafür i.d.R. den Proxy an, der für https konfiguriert ist, üblicherweise ist das der gleiche Proxy auf dem gleichen Port wie bei http. Der Verbindungsaufbau durch den Client erfolgt dabei wie folgt:
CONNECT shell.uugrn.org:443 HTTP/1.0
Die Antwort des Proxy-Servers ist die folgende Zeile, gefolgt von einer Leerzeile.
HTTP/1.0 200 Connection established
Der gesamte darauf folgende Traffic ist 1:1 vom Server, in diesem Beispiel ist es nicht ganz https, sondern die Klartext-Antwort des sshd von shell.uugrn.org
SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110
Wichtig zu wissen ist
Der Webproxy stellt auf die Anfrage CONNECT hin die Verbindung zum gewünschten Server auf dem gewünschten Port her und antwortet einzeilig mit der Nachricht, dass die Verbindung hergestellt wurde. Nach einer weiteren Leerzeile erscheint auf der Verbindung dann bitsauber der Datenverkehr des jeweiligen Remotehosts. Bitsauber beudetet, dass SSL fehlerfrei funktioniert, aber auch jedes andere Protokoll, welches auf eine bitgenaue, d.h. nicht zeilenbasierte Übermittlung der Daten angewiesen ist.

SSH über Webproxy[Bearbeiten]

Das SSH-Protokoll erlaubt es neben einer Terminalsitzung auch weitere Daten zu übertragen. Das kann von SSH basierten Anwendungen über einfaches Portforwarding und SOCKS-Proxy Fähigkeiten bis hin zu gerouteten IP-Verbindungen (OpenSSH) gehen. Wichtig für die Anwendung ist, dass die SSH-Verbindung irgendwie zustande kommt. Mögliche Transportwege für SSH sind neben einer direkten TCP-Verbindung auch Verbindungen via SOCKS-Proxy oder eben Webproxy oder alle andere Möglicheiten, die einen bitsauberen Transport ermöglichen.

OpenSSH über Webproxy[Bearbeiten]

OpenSSH kennt die ProxyCommand-Direktive. Hiermit ist es möglich, ein externes Hilfsprogramm einzubinden, welches die Kommunikation zum Proxy-Server übernimmt. Das folgende Beispiel verwendet das bei *BSD mitgelieferte Programm nc(1), auch bekannt unter dem Namen netcat.

Aus ssh_config(5)
ProxyCommand
This directive is useful in conjunction with nc(1) and its proxy
support. For example, the following directive would connect via
an HTTP proxy at 192.0.2.0:
ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p

PuTTY über Webproxy[Bearbeiten]

PuTTY kann neben direkten TCP-Verbindungen auf Port 22 auch über verschiedene andere Wege mit dem SSH-Server kommunizieren, dazu gehören:

  • Webproxy, auch mit Authentifizierung
  • SOCKS Proxy
  • Telnet-Proxy

PuTTY selbst bietet neben der üblichen Terminal-Sitzung auch Portforwarding an:

  • Local Portforwarding: einen (oder mehrere) bestimmten Port eines Remote-Servers auf einen beliebigen Port auf localhost bzw. 127.0.0.1 oder [[::1]] binden
  • Remote Portforwarding: einen lokalen Port auf einem Remote-Server verfügbar machen, dort idR nur via localhost bzw. 127.0.0.1/::1 zugreifbar
  • Dynamic Portforwarding: Stellt auf einem lokalen Port, z.B. tcp/1080 einen SOCKS-Proxy zur Verfügung. Verbindungen über diesen Proxy werden zum SSH-Server (verschlüsselt) durchgetunnelt und von dort aus (unverschlüsselt) zum Zielsystem, z.B. ein IMAP-Server oder auh einenanderen SSH-Server weitergereicht.

Die Anwendung und Konfigurationsbeispiele befinden sich im Artikel PuTTY.

OpenVPN über Webproxy[Bearbeiten]

OpenVPN ist ein Tunnelprotokoll. Durch eine OpenVPN-Verbindung lassen sich IP-Verbindungen, je nach Tunneltyp sogar Ethernet-Bridges realisieren. OpenVPN selbst arbeitet standardmäßig auf UDP Port 1194, kann aber auch auf anderen Ports oder TCP-Verbindungen, sogar durch Proxyverbindungen hindurch arbeiten.

Das OpenVPN HowTo beschreibt die Konfiguration einer Verbindung via http-Proxy.

httptunnel über Webproxy[Bearbeiten]

FIXME: Beschreibung von httptunnel (siehe Diskussionsseite)


Verbindungen über Webproxies erkennen und verhindern[Bearbeiten]

Web-Proxies sollten die CONNECT-Methode nur auf "echte" HTTP-SSL Ports erlauben. Überlicherweise ist dies der Port 443. Der Zugriff insbesondere auf Ports < 1024 sollte mit CONNECT darüber hinaus nicht möglich sein.

squid absichern[Bearbeiten]

squid liefert eine squid.conf mit, die folgende acls enthält: 

acl SSL_ports port 443

acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http

# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports

Mit dieser Voreinstellung ist der erforderliche CONNECT ("https-Methode") nur auf Port 443 möglich.

Einschränkung
Die vorige Methode unterbindet zwar wirkungsvoll den CONNECT auf Port 22 (!Safe_ports), ist aber wirkungslos bei SSH auf Port 443. Ein Firewall müsste in den Verbindungsaufbau reinlauschen und den Protokollheader von SSH erkennen bzw. abfangen, der im Klartext erscheint, z.B. shell.uugrn.org:443:
SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110

Squid schreibt nach Verbindungsabbau eine Zeile in das access.log, in dem der CONNECT und die Menge der übertragenen Daten protokolliert werden: 

1209763269.836   5325 10.11.12.13 TCP_MISS/200 158155 CONNECT www.example.com:443 - DIRECT/208.77.188.166 -

Durch konsequente Auswertung dieses Logfiles kann auch nachträglich der Zugriff auf "berüchtigte" Ports erkannt und über eine Blacklist im Firewall künftig unterbunden werden. Etwas radikaler wäre, Zugriffe auf HTTP-SSL auf bekannte Webseiten zuzulassen, d.h. über eine Whitelist.

Mehr zum Thema Webproxy[Bearbeiten]

  • Durch die Verwendung eines oder mehrerer offenener Proxies im Internet können Verbindungen "umgeleitet" werden. Die Verwendung fremder (offener) Proxys ist üblicherweise nicht legal.
  • In seinem Vortrag OpenSSH Teil 3: Firewalls durchbohren[1] beschreibt Johannes Franken sehr detailliert die Funktionsweise von OpenSSH via Webproxy.

SOCKS Proxy als Transportmedium nutzen[Bearbeiten]

Manche Firewallsysteme bieten für Applikationen einen SOCKS-Proxy an. Sehr viele Applikationen, die per TCP kommunizieren können auch via SOCKS-Proxy kommunizieren, zum Beispiel auch SSH, aber auch Messenger, Tauschbörsen, Mailclients. FIXME: Beschreiben, wie man einen SOCKS-Proxy nutzt (siehe Diskussionsseite)


OpenSSH über SOCKS Proxy[Bearbeiten]

OpenSSH kann mit Hilfe von nc(1) bzw. netcat einen Verbindungsaufbau über einen SOCKS-Proxy herstellen. Ähnlich wie bei OpenSSH-via-HTTP-Proxy geht es hier leicht abgewandelt auch mit 2 SOCKS-Versionen:

SOCKS4
ProxyCommand /usr/bin/nc -X 4 -x 10.11.12.13:1080 %h %p
SOCKS5
ProxyCommand /usr/bin/nc -X 5 -x 10.11.12.13:1080 %h %p

PuTTY über SOCKS Proxy[Bearbeiten]

PuTTY kann von Haus aus über verschiedene Proxies arbeiten, das Proxy-Protokoll ist hier nur eine einfache Auswahl im Setup-Dialog. Details dazu stehen unter PuTTY#Proxy.

Missbrauch eines SOCKS-Proxys verhindern?[Bearbeiten]

Der Betrieb eines SOCKS-Proxies sollte genau geplant sein. Zugriffsberechtigungen sollten über Firewalls oder Zugangskontrollen geregelt werden.

FIXME: Strategien für den sicheren Betrieb eines SOCKS-Proxys (siehe Diskussionsseite)


DNS als Transportmedium nutzen[Bearbeiten]

DNS ist üblicherweise auch in stark abgeschirmten Netzwerken möglich. Selbst wenn es keine direkte Route zwischen den Netzwerken gibt kann man davon ausgehen, dass innerhalb des Sicherheitskonzepts innere DNS-Server über externe DNS-Server weitergeleitet werden. Ein speziell präparierter Client kann über standardkonforme DNS-Requests Verbindungen zu einem speziellen DNS-Server herstellen, der Nutzdaten wie z.B. einzelne IP-Pakete per Request vom Client erhält und per Response dem Client zurückschickt.

TCP Portforwarding mit dns2tcp[Bearbeiten]

dns2tcp ist ein Netzwerktool zum Vermitteln von TCP Verbindungen über DNS-Datenverkehr. Die Datenkapselung findet auf TCP-Ebene statt, das bedeutet dass kein TUN oder TAP Treiber benötigt werden und dementsprechend auch keine besonderen Systemrechte erforderlich sind. Dns2tcp besteht aus 2 Teilen, einem Server und einem Client. Serverseitig sind verschiedene Ressourcen in einer Konfigurationsdatei hinterlegt, entweder als lokaler oder remote Dienst für TCP Verbindungen. Der Client nimmt auf einem vordefinierten Port TCP Verbindungen an und leitet ("tunnelt") diese durch die DNS-Verbindung zum eigentlichen Ziel[2].

Weiterführende Informationen zu DNS[Bearbeiten]

Mißbrauch des DNS-Serves erkennen und verhindern?[Bearbeiten]

FIXME: Strategie zur Erkennung und Vermeidung von Sicherheitslücken im DNS-Verkehr (siehe Diskussionsseite)


TOR Netzwerk als Transportmedium nutzen[Bearbeiten]

FIXME: Beschreiben, wie das TOR Netzwerk funktioniert (siehe Diskussionsseite)


siehe auch[Bearbeiten]

Weblinks zum Thema FirewallPiercing[Bearbeiten]

Fußnoten[Bearbeiten]

  1. ↑ Johannes Franken: OpenSSH Teil 3: Firewalls durchbohren
  2. ↑ Mehr über dns2tcp auf der Offizielle Webpräsenz „dns2tcp”
Abgerufen von „https://wiki.uugrn.org/index.php?title=Firewall_Piercing&oldid=9810“