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.
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.
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 (siehe Diskussionsseite)
PPP over SSH
FIXME: Beschreiben, wie eine PPP-Verbindung durch die Terminalverbindung von SSH funktioniert (siehe Diskussionsseite)
IP Tunnel
FIXME: Beschreiben, wie man mit Hilfe einer OpenSSH-Sitzung ein tun(4)-Device einrichtet (siehe Diskussionsseite)
wie verhindern?
FIXME: Beschreiben, wie man Tunnelmechanismen Client- oder Serverseitig unterbinden kann (siehe Diskussionsseite)
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> [...] </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
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 (siehe Diskussionsseite)
PuTTY
FIXME: Beschreibung und/oder Screenshots für Putty (siehe Diskussionsseite)
OpenVPN
FIXME: Beschreibung aus dem Handbuch von OpenVPN (siehe Diskussionsseite)
httptunnel
FIXME: Beschreibung von httptunnel (siehe Diskussionsseite)
wie verhindern?
FIXME: Strategie zur Vermeidung oder Aufspüren ungewollter Zugriffe über den Webproxy (siehe Diskussionsseite)
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 (siehe Diskussionsseite)
wie verhindern?
FIXME: Strategie für den sicheren Betrieb eines SOCKS-Proxys (siehe Diskussionsseite)
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. FIXME: Beschreiben, mit welcher Software man soetwas einrichten kann (siehe Diskussionsseite)
wie verhindern?
FIXME: Strategie zur Erkennung und Vermeidung von Sicherheitslücken im DNS-Verkehr (siehe Diskussionsseite)
