Es gibt verschiedene Gründe warum Du Deine Daten nicht für jeden lesbar und ohne Authentifizierung auch für jeden veränderbar durch ein Netzwerk schicken möchtest. Wenn Du in einem als unsicher eingestuften Netz hängst und mal kurz z.B. Deine Mails checken möchtest, aber das Pech hast, dass Dein E-Mail Server kein SSL unterstützt, dann hast Du immer noch ne Chance Deinen Traffic zu verschlüsseln und die Verbindung zu authentifizieren. Ich stelle hier zwei verschiedene Möglichkeiten vor Tunnel auf zu bauen: SSH und Stunnel (über OpenSSL).

Um sicher zu gehen, dass Du keiner Man-in-the-middle Attacke zum Opfer fällst, solltest Du vorher ein X.509 Zertifikat des Verbindungspartners im Gepäck haben.

Noch schöner wär es, wenn Du die IP des entfernten Rechners in der /etc/hosts stehen hast und die MAC Adresse des internen Gateways kennst, sie statisch in Deinen ARP Cache schreibst und auch nur Pakete zu dieser MAC Adresse routest.

Wie schon erwähnt: Besorge Dir die IP und ein Zertifikat von Deinem Verbindungspartner am besten indem Du Dich aus einem vertrauenswürdigen Netz über eine SSL gesicherte Verbindung zu diesem connectest und das Zertifikat bis zu seinem Verfallsdatum akzeptierst und speicherst.

Falls Du eine Verbindung das erste Mal aus einem unsicheren Netz öffnest, könntest Du schon Opfer einer Man-in-the-middle Attacke geworden sein und der Angreifer schiebt Dir sein Zertifikat unter, welches Du fälschlicher Weise als vertrauenswürdig akzeptieren könntest. .oO( Zuviel Konjunktiv ) Wenn Du das Zertifikat vorher schon gesichert hattest und eine Fehlermeldung bekommst, dass es sich geändert hat, brich entweder sofort die Verbindung ab oder schmeiss nen Sniffer an und schau Dir den Traffic Deiner Verbindung an! Achte dabei z.B. auf DNS Spoofing Attacken:

tcpdump host dns-server and port 53

Wenn Du zwei DNS Responses vom "DNS Server" für einen Request bekommst, dann is wohl offensichtlich was faul.

Deshalb solltest Du die IP auch vorher zusammen mit dem DNS Eintrag in die /etc/hosts eintragen. Das schützt Dich schon mal vor DNS Spoofing Attacken zu diesem Rechner, weil /etc/hosts immer vor dem DNS Server nach der IP befragt wird.

Es gibt bei SSH Verbindungen auch die Möglichkeit, dass Du bisher immer über SSH2 mit einem Rechner verbunden warst und somit nur seinen DSA Key von dem entfernten Rechner kennst.

Ein Angreifer könnte z.B. über ARP Poisoning die Verbindung auf einen von ihm kontrollierten SSH Server, der nur Protocol Version 1 spricht, umleiten und so versuchen Dir einen neuen Public Key unter zu schieben. Für mehr Informationen über diesen Angriff lies am besten mal den Artikel über SSHarp im Phrack Magazin 59.

Deshalb stell die Protokoll Version ein mit der Du Dich connecten willst, falls Du einen Tunnel über SSH auf baust und achte auf jeden Fall auf ARP Poisoning Attacken:

tcpdump arp

Sollte ein bestimmter Rechner Dir alle paar Sekunden mitteilen, dass er eine bestimmte MAC Adresse hat, dann sperre kurz mit IPtables sämtliche Packete der IP und überprüfe manuell, ob die IP auch wirklich zu dieser MAC Adresse gehört:

iptables -A INPUT -m mac --mac-source fragliche-mac -j DROP
arp -d fragliche-mac
ping -c 1 ip-zu-fraglicher-mac
arp -a

Wenn die Werte übereinstimmen, kannst Du die Iptables Regel wieder löschen (iptables -F).

Außerdem könnte Dir jemand mit einem gespooften ICMP Paket einen anderen Standard Gateway in die Routing Tabelle haun. Damit Du keine Pakete an diesen falschen Router schickst, solltest Du folgende Iptables Regel implementieren:

iptables -A INPUT -p icmp -j DROP

Dann musst Du zwar selbst raus bekommen, wenn der Verbindungspartner offline ist bzw. manche Dienste funktionieren vielleicht auch nicht ohne ICMP, aber ein Angreifer kann Dir weder einen anderen Gateway eintragen noch die Verbindung über ICMP Redirect Pakete umlenken.

Jetzt solltest Du die grösst mögliche Sicherheit geschaffen haben, um einen Tunnel zu Deinem Verbindungspartner sicher aufbauen zu können.

Wenn Du Deine Verbindung über SSH tunneln möchtest, dann brauchst Du einen Account und einen offenen SSH Port auf der Maschine, zu der Du einen Tunnel aufbauen willst.

ssh -L 5555:remote-machine:25 user@remote-machine

Das verbindet den lokalen Port 5555 mit dem entfernten port 25 und nutzt SSH als Proxy.

[local]-[5555]-->[ssh]----->[remote]-[ssh]--->[25]

Jetzt kannst Du Dich lokal auf den Port 5555 verbinden und wirst transparent auf die entfernte Maschine zu Port 25 weiter geleitet. telnet localhost 5555.

Auf diese Weise kannst Du Dich auch zu einem SMTP (oder was auch immer) Server connecten, der nicht zwingenderweise auf dem Kasten laufen muss, der Dir SSH zur Verfügung stellt.

ssh -L 5555:smtp.remote.com:25 user@ssh-remote

[local]-[5555]-->[ssh]------>[ssh-remote]-[ssh]---->[smtp-remote]-[smtp]

Aber Du solltest beachten, dass der Traffic nur zwischen den beiden Rechner verschlüsselt ist!

Wenn jemand auf der lokalen oder einer entfernten Maschine einen Sniffer laufen hat, dann kann er immer noch alles mitlesen...

Bisher hast Du den Port (Socket) immer auf dem lokalen Rechner auf gemacht, man kann ihn aber ebenso gut auf dem entfernten Rechner öffnen indem man -R statt -L verwendet.

ssh -R 5555:localhost:25 user@remote

Man muss sich halt nur im Klaren sein von wo aus die Verbindung aufgemacht werden soll.

Wenn der Client auf dem lokalen Rechner läuft, dann benutzt Du -L für lokales Port Forwarding und wenn er auf dem entfernten Kasten läuft -R für Remote Port Forwarding.

Remote Port Forwarding kann aber auch verwendet werden, um eine Firewall von intern bzw. aus einer DMZ zu umgehen.

[inside]-[blocked_port]-->[ssh]------->[firewall]----->[outside]-[5555]

Wenn die Firewall keine SSH Zugriffe von extern zu lässt, dann muss man den SSH Server halt auf nem Port lauschen lassen, den die Firewall für in Ordnung hält...

Aber was machst Du, wenn Du keinen SSH Server auf den Rechnern findest, zwischen denen Du eine getunnelte Verbindung aufmachen möchtest? Keine Panik! ;)

Du bekommst schon noch Deine sichere Verbindung! Die Lösung heisst Stunnel. Auf dem Kasten zu dem Du Dich connecten willst führst Du folgendes aus:

stunnel -d 5555 -r 25

Das bindet den Port 5555 an den Port 25. Auf dem lokalen Kasten machst Du dann die Verbidnung auf:

stunnel -c -d 2323 -r remote-host:5555

Jetzt kannst Du Dich lokal auf den Port 2323 verbinden und wirst wieder transparent zu der entfernten Maschine auf Port 25 weiter geleitet.

[local]-[2323]------->[remote]-[5555]-->[25]

Stunnel verwendet SSL/TLS also muss eine SSL Bibliothek wie z.B. OpenSSL installiert sein.

Wenn das Tool schon SSL verwendet, dann kann man aber auch gleich noch Zertifikate nutzen, damit sich die beiden Rechner auch ausweisen können. Dazu verwendet man einfach den Parameter -v ssl-version. Vorher muss man natürlich ein Zertifikat generieren: openssl req -new

Wie man Zertifikate mit OpenSSL erstellt, kann man z.B. hier nachlesen. Das schützt Dich aber immer noch nicht unbedingt gegen Hijacking (Man-in-the-middle) Attacken aus dem lokalen Netz.

Du solltest auf jeden Fall die Augen offen halten nach merkwürdigen oder unbekannten Zertifikaten.

OK. Jetzt kannst mit oder ohne SSH Deinen Traffic zwischen zwei Rechnern verschlüsseln und authentifizieren, aber was machst Du, wenn Du Dich zu einem SSL verschlüsselten Service verbinden willst, aber Dein Client unterstützt gar kein SSL?? Das ist easy!

stunnel -d 2323 -r remote-host:ssl-port

Oder verwende SSL-Proxy... Happy tunneling out there in the galaxy! ;)