Bearbeiten von „Firewall Piercing“

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!
<br /> 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.}}


__TOC__

== via SSH ==
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.

=== SOCKS Proxy ===
{{FIXME|Beschreiben, wie man mit einem OpenSSH-Client einen SOCKS-Proxy einrichtet}}

=== PPP over SSH ===
{{FIXME|Beschreiben, wie eine PPP-Verbindung durch die Terminalverbindung von SSH funktioniert}}

=== IP Tunnel ===
{{FIXME|Beschreiben, wie man mit Hilfe einer OpenSSH-Sitzung ein tun(4)-Device einrichtet}}

=== wie verhindern? ===
{{FIXME|Beschreiben, wie man Tunnelmechanismen Client- oder Serverseitig unterbinden kann}}

== via Webproxy ==
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>
 [...]
 <!-- Served in 0.253 secs. --></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>
 [...]
   </div>
 <!-- Served in 0.318 secs. --></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]] ===
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]] ====
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 {{man|freebsd|1|nc}}, auch bekannt unter dem Namen ''netcat''.

;Aus {{man|freebsd|5|ssh_config}}:
:;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]] ====
[[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]] ===
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 [http://openvpn.net/index.php/documentation/howto.html#http OpenVPN HowTo beschreibt die Konfiguration einer Verbindung via http-Proxy].

=== [[httptunnel]] ===
{{FIXME|Beschreibung von [[httptunnel]]}}

=== wie verhindern? ===
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]] 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. [[SSH auf Port 443|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.

=== weiterführende Informationen ===
* 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'''<ref>Johannes Franken: [http://www.jfranken.de/homepages/johannes/vortraege/ssh3_inhalt.de.html OpenSSH Teil 3: Firewalls durchbohren]</ref> beschreibt Johannes Franken sehr detailliert die Funktionsweise von '''OpenSSH via Webproxy'''.

== via SOCKS ==
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}}

=== wie verhindern? ===
{{FIXME|Strategie für den sicheren Betrieb eines SOCKS-Proxys}} 


== via DNS ==
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.  

=== dns2tcp ===
[[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<ref name="dns2tcp">Mehr über [[dns2tcp]] auf der {{Homepage2|www.hsc.fr/ressources/outils/dns2tcp/|dns2tcp}}</ref>.

=== Weblinks ===
* {{Homepage2|www.hsc.fr/ressources/outils/dns2tcp/|dns2tcp}}
* [http://netzhure.de/2007/10/22/127-TCP-over-DNS-mit-dns2tcp.html TCP over DNS mit dns2tcp] von mømø

=== wie verhindern? ===
{{FIXME|Strategie zur Erkennung und Vermeidung von Sicherheitslücken im DNS-Verkehr}}

== via TOR ==
{{FIXME|Beschreiben, wie das TOR Netzwerk funktioniert}}


== siehe auch ==
* [[PuTTY]]
* [[Firewall]]
* [[Proxy]]

== Weblinks ==
<!-- allgemeine Weblinks zum Thema Firewall Piercing -->

== Fußnoten ==
<references />

[[Kategorie:Netzwerk]]
[[Kategorie:Security]]