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 Trasport vermöglichen.

==== [[OpenSSH]] ====
{{FIXME|Perlscript und Configanleitung für OpenSSH-Client}}

==== [[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? ===
{{FIXME|Strategie zur Vermeidung oder Aufspüren ungewollter Zugriffe über den Webproxy}}

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

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

=== Weblinks ===
* [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}}

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