Version vom 22. Oktober 2015, 16:14 Uhr

Overlaynetzwerke, der Artikel zum Talk

Dieser Artikel im Nachgang zum Vortrag im 2015er Programm "Overlaynetzwerke - von Überall ins Netz" entstanden.

Die Struktur lehnt sich daher an dem Aufbau des Vortrages an.

Welche Netze

• Eigene Netze

* zu Haus
* Firma
* mit Freunden
* Kundennetze
...

• andere Netze

* Fremde länder
* Darknets 

Motivation und Fokus

Über die Jahre habe ich viele, teils vom Ansatz her grundlegend verschiedene Lösungen kennengelernt. Da einige davon nützliche Helfer im Alltag geworden sind und andere unerlässlich und permanent laufen gibt es darüber nun einen Überblick.

Am Ende soll einem bewusst sein, dass es nicht nur OpenVPN und kommerzielle VPN Lösungen gibt, sondern viele nützliche Tools die sowohl dem Hacker als auch Anwender den Alltag und bei besonderen Herausforderungen dienlich zur Seite stehen.

Motivation und Szenarien

Im Grunde kann man alle Szenarien auf drei Grundbedürfnisse herabbrechen.

* Services anbieten
* Standorte Verbinden/Fernwartungszugriffe
* aus degradierten Netzen Heraustunneln

Das Tafelbild wurde leider nicht abgelichter, daher eine Folie aus dem Draft zum Talk. [szenarien.png]

historisches

In der Fachliteratur wird auch immer über die alten Zeiten erzaehlt, also auch hier. Würde wurden direkt Leitungen zwischen Unternehmensstandorten angemietet (leased lines) oder eigene Verlegt. Für Außendienstmitarbeiter bestand die Möglichkeit sich per Modem über eine DFÜ-Verbindung in die Firma einzuwählen. Hierzu mussten aber entsprechende Leitungen und Farmen an Modems vorgehalten werden. Zudem wurde DFÜ mit dem aufkommen von DSL und (TV)Kabelleitungen unattraktiv weil die sehr langsam sind.

Oder man war einfach vor Ort.

Einwahlverbindungen und leased lines sind aber teuer, ersteres sogar verdammt langsam. Daher wurde aufbauend auf dem vorhandenem Netzwerk (gemeinhin Internet) aufgesetzt und virtuelle Netzwerktechnik entwickelt. Dadurch wird man unabhängiger von Unwetter und Streiks, man kann von quasi Überall in andere nicht öffentliche Netzwerke. Desweiteren führt man idR eh mindestens ein Computer (Telefon), eher mehrere (Telefon, Tablet, Notebook) mit sich.

Problemstellungen

Bevor wir uns verschiedene Techniken anschauen um die in der Motivation/Szenarien abgesteckten Bedrüfnisse sicher zu stellen werden einige Probleme beleuchtet.

Warum kauft man sich nicht einfach genug öffentliche IP Adressen ein und vergibt die an allen Rechnern mit Services?

• Services direkt anbieten

* zu wenig Public (v4) Adressen verfügbar
* simultan dazu v6 Deployment von vielen ISPs mangelhaft bis nicht existent.
* wechselnde/dynamische IP Zuweisungen

* Nicht alle Services sollen (unkontrolliert) nach außen verfügbar sein

• Sicherheit

* viele lesen viel Traffic mit (im öffentlichen Internet, siehe aktuellen Regierungsaffären und Erklärungsnöte)
* komische/ alte Protokolle deployt, die nicht direkt im Internet transportiert werden sollten.

• Compliance/Richtlinien (für Branchen, von Gremien/Verbänden .. etc)

Problemlösungen/Konzepte

Hier stell ich kurz unser Blöcke/Buildingsblocks vor mit denen wir die Probleme lösen können

Netzwerkverbindung zwischen zwei Rechnern via UDP oder TCP. Als Nutzlast/Payload wird dann unsere speziell eingepackten Nutzdaten verschickt.

Ein Datenpaket besteht aus einem IP-Header, Protokoll-Header und Nutzlast. [IP-H.][UDP-Header][Nutzdaten] oder [IP-H.][TCP-H][Nutzdaten]

Sagen wir ein IP kann 1500 Bytes aufnehmen und ein UDP enthält z.b. 2 Byte Quell-Port, 2 Byte Zielport, 2 Byte Längen und 2 Byte Prüfsummen Felder. Das hieße es gehen von unseren 1500 Bytes 8 Bytes ab und es bleiben 'nur' 1492 Bytes für die Datenlast über. In einem TCP-Header werden viel mehr Informationen untergebracht. Wenn da z.b. 30 Byte mehr Informationen untergebracht werden sinkt die transportierbare Datenlast auf nur 1460 bytes. Wer das genauer wissen will, dem seien die Wikipediaseiten zu TCP/IP und UDP oder einschlägige Fachliteratur nahegelegt.

Als Quintessenz kann man sich merken, wenn man Netzwerkpakete einpackt, sind Zwangsläufig die transportierbate Nutzdatenlast.

Originalpaket
[IP-Header ][TCP o. UDP Header ][Nutzlast                                    ]
eingepacktes paket
[IP-Header'][TCP o. UDP Header'][IP-Header][TCP o. UDP header][Nutzdatenlast ]

Um einen sicheren Transportkanal zu haben, wird eine TLSverbindung aufgebaut. Mit TLS 1.2 steht einem dann ein sicherer Kanal für Nutzdaten zur verfügung. Von SSL und TLS1.0 sollte man inzwischen aber absehen. Promintestes Beispiel für so ein Konstrukt ist HTTPS. Dafür wird statt über Port 80 zu Port 443 die Verbindung aufgebaut und die eigentlichen HTTP Daten werden in TLS Nachrichten gewrapt. Am Zielrechner werden die wieder ausgepackt und zum eigentlichen Dienst weitergeleitet.

%beispiel grafik

Werkzeuge

Folgend werden einige Werkzeuge vorgestellt. Als fiktive IP hat der Rechner dem ich sitze die IP 14 . tunnelbox hat die IP 25

= SSH

Der klassiker sind SOCKS-tunnel

ssh -ND user@tunnelbox

wieistmeineip.de zeigt die 25 als

Portbasierte Weiterleitung

ssh -L 9001:bralug.de:80 user@tunnelbox

auf localhost:9001 wird die Website bralug.de erreicht

Wenn man nicht nur einzelne Ports weiterleiten will oder das Programm keine Unterstützung für Sockstunnel mitbringt kann man zum einen tsocks ausprobieren oder sshuttle.

tsocks selbst beschrieben als: tsocks is a wrapper between the tsocks library and the application what you would like to run socksified.

Über LD_PREALOAD wird der Anwendung der Sockstunnel untergeschoben. Aufgerufen wird das z.B. mit:

tsocks nc wieistmeineip.de 80

sshuttle basiert auf SSH, bringt aber gleichzeitig Iptablesregeln mit, mit derer Hilfe Datenpaketen für ganze Netze über den SSH-Tunnel transportiert werden. Für den Client also transparent und ganz ohne Konfiguration von Socks oder ähnliches.

Statt sshuttle lässt sich vielleicht auch autossh benutze, um SSH session automatisch nach abbruch zu erneuern. http://www.harding.motd.ca/autossh/

Single Port geschichten / Services exponieren

mit socat kann man über diverse Transportprotokolle Daten verschicken. Als Server z.b. socat UDP-LISTEN:1337,fork,reuseaddr stdio lauscht Port 1337 und gibt nach STDIO aus.

Der Client: socat READLINE UDP:127.0.0.1:1337 nimmt Eingaben von der standardinput mit Readline-support auf und schickt es per UDP nach 127.0.0.1 auf port 1337.

Anstatt UDP können auch IPv6 Datagrams,Socks, SCTP etc verwenden werden.

Ich nutz das ganz gerne um z.b. größere Daten im internern Netz zu verschicken. Z.b. eine Festplatte per dd auslesen und zu einen Rechner mit viel Speicher schicken. Dafür nutz ich keine Crypto und will möglichst viel Nutzlast pro Paket unter bekommen!

stunnel wird gerne benutzt wenn man für einen Dienst einen TLS-Tunnel brauch, aber die Software das nicht selbst anbieten kann. Z.b. kann ich mit in TCL ein Script schreiben was Sensordaten ausliest und per HTTP-Befehle abrufbar macht. HTTPS will oder kann ich aber nicht in TCL machen und nutze daher stunnel. Dann kann ich das mit einem beliebigen Client der HTTPS kann anfragen.

Zentralisierte VPN

= OpenVPN

OpenVPN eignet sich hervorragend für Master-Client Setups. Z.b. um Außendienstmitarbeiter anzubinden oder wenn man mit seinen Mobilgeräten nur in das Heimnetz zu Hause will.

Zwei Standorte können auch Site-to-Site verbunden werden. Bei mehreren Standorten müssen aber welche als Hop benutzt werden oder n*n-1 Verbindungen konfiguriert werden.

MeshVPN

Das Problem mit den vielen Konfigurationen wird durch sogenannte Meshing VPNs gelöst. In diesen Ansatz sind alle Knoten weitestgehend gleich wertig, ohne Masterinstanz und die Verbdinungen werden dynamisch untereinander gehändelt. Wie in einem Maschennetz.

= tinc

Als MeshVPN benutz ich tinc. Das hat sich als robust genug erwiesen.

Allgemeine Anmerkungen, Nebenbedingungen

DNS im Zweifel auch durchtunneln. Es ist recht dämlich die DNS Anfrage über die direkte Leitung zu schicken, wenn man danach die kritischen Daten über abgesicherte Verbindung anfragt und verschleiern will was man da für Daten hat.