PuTTY
PuTTY ist eine freie Implementierung von SSH und Telnet. Das PuTTY-Projekt wurde von Simon Tatham ins Leben gerufen. Mittlerweile stehen auch Tools für den vollen Funktionsumfang SSHs zur Verfügung wie z.B. SCP. Das PuTTY-Projekt beschäftigt sicht primär mit der Win32 Plattform, es gibt aber auch eine Portierung für UNIX, welche auch unter Linux und BSD laufähig ist.
Anwendung[Bearbeiten]
Die Hauptanwendung ist putty.exe. Hier werden Sessions angelegt, konfiguriert und gestartet.
Hilfreiche Zusatzanwendungen sind:
- Pageant
- Ermöglicht die Verwendung von SSH-Keys / Agent forwarding
- PuTTYgen
- Erstellen und Verwalten von mit OpenSSH kompatiblen Schlüsseln. Schlüssel müssen in Pageant geladen werden, bevor man sie nutzen kann.
Aufruf, Verknüpfung[Bearbeiten]
Auf dem Desktop oder in Menüs können einzelne Sessions direkt aufgerufen werden, indem Verknüpfungen zu putty.exe wie folgt erstellt werden:
C:\Programme\PuTTY\putty.exe @shell.uugrn.org
Eine Verknüpfung wie diese ruft das Profil shell.uugrn.org auf.
Tunnel[Bearbeiten]
PuTTY kann über eine SSH-Verbindung beliebiges Portforwarding, es können entweder lokale remote durchgereicht werden, aber auch remote-Ports nach lokal. Außerdem implementiert PuTTY selbst einen SOCKS-Proxy, wenn man ein dynamic Portforwarding einrichtet.
Proxy[Bearbeiten]
PuTTY kann seine Verbindungen entweder direkt, aber auch via Socks- oder HTTPS-Proxy aufbauen, vorausgesetzt der entsprechende Proxy ist dafür konfiguriert, d.h. erlaubt de CONNECT-Methode auf Port 22. Leider ist das häufig eher nicht der Fall. Abhilfe ist hier auf dem Zielsystem den sshd zusätzlich zu Port 22 auch noch Port 443 zu konfigurieren, welches i.d.R. für HTTPS verwendet wird, standardmäßig erlauben Web-Proxies einen CONNECT auf Port 443.
- /etc/ssh/sshd_config
Port 22 Port 443 [...]
Der sshd auf shell.uugrn.org läuft zusätzlich auch auf Port 443 und kann durch Vereinsmitglieder entsprechend verwendet werden, Details unter SSH auf Port 443.
Durch Kombination dieser Fähigkeiten kann man auch aus relativ restriktiven Netzwerkumgebungen, z.B. Firmennetz oder Campus-Netz "ausbrechen": Man konfiguriert eine SSH-Verbindung von intern nach extern via HTTP-Proxy und konfiguriert außerdem noch eine "dynamische" Portweiterleitung aka SOCKS-Proxy z.B. auf localhost:1080.
Viele Programme unterstützen die Verwendung von SOCKS-Proxy anstelle einer direkten Netzwerkverbindung, z.B. Chat/Messenger, FTP-Clients, Mailprogramme (z.B. Thunderbird). Darüberhinaus kann man über diese SOCKS-Verbindug auch weitere PuTTY-Verbindungen aufbauen, ohne zusätzliche Einträge im Logfile des Web-Proxies zu hinterlassen (idR erst beim Abbau der Verbindung.)
Heimserver verwenden[Bearbeiten]
Verfügt man über keinen Server mit sshd auf Port 443, kann man dieses über den Permanent am Netz laufenden Heim-Server einrichten. Hierzu ist es jedoch erforderlich einen DynDNS-Eintrag zu haben, da beim Zugriff auf die IP-Adresse, die man zudem oft nicht kennt, jedesmal ein neues Host:Fingerprint-Pärchen gespeichert wird. Beispielsweise bietet sich dyndns.org an, wo man sich Hostnamen wie etwa blablubb.homeip.net eintragen kann. Hängt der Heimserver hinter einen NAT-Router, so muss hier entsprechend eine Portweiterleitung für 22 und 443 nach innen eingerichtet werden.
Web-Proxy[Bearbeiten]
Will man darüber hinaus nicht nur "unbefugtes" SSH nach Hause machen, sondern darüber auch im Web surfen, ohne im Proxy-Server der Firma Spuren zu hinterlassen, so installiert und konfiguriert man sich zu Hause einen eigenen squid-Server auf Port 3128. Der sichere Zugriff darauf erfolgt durch den SSH-Tunnel, der bereits schon den SOCKS-Proxy implementiert: zusätzlich konfiguriert man ein Local-Portforwarding von 3128 auf 127.0.0.1:3128.
- ACHTUNG! Nicht localhost verwenden, da dieses auf der Gegenstelle durch sshd möglicherweise auf IPv6 mit ::1 aufgelöst wird. Squid ist jedoch nur via IPv4 erreichbar, was zuweilen Grund für bizarre Fehlersuchen sein kann.
Verbindet man sich nun mit der entsprechend erweiterten PuTTY-Session auf den Heimserver, kann man lokal auf Port 3128 (oder den Port, den man lokal konfiguriert hat transparent auf den Heim-Proxy zugreifen. Der Proxy zu Hause sieht die Zugriffe von 127.0.0.1 kommen, während man selbst (unter Windows) auch auf 127.0.0.1 zugreift.
Will man nur bei bestimmten URLs oder zu bestimmten Servern über den privaten Proxy gehen, empfiehlt sich das Add-on FoxyProxy von Firefox. Hier kann man basierend auf Wildcards oder Regular Expressions verschiedene Proxies verwenden.
Gegenmittel[Bearbeiten]
Wenn man selbst Admin und verantwortlich für die Sicherheit des Firmennetzes ist, sollte man diese "Gefahr" kennen. Es ist allerdings nicht trivial einen Ausbruch mittels SSH zu unterbinden, wenn gleichzeitig HTTPS (SSL) erlaubt sein soll.
Denkbar wären (neben disziplinarischen Maßnahmen) folgende technische Möglichkeiten:
- Blacklists
- alle dyndns-Domains (ca 30-40), vermutlich gibt es hier fertige ACL. Nachteil: Das Verfahren geht auch ohne die Verwendung von DynDNS-Services.
- alle HTTPS-Server, die kein gültiges SSL-Zertifikat haben (etwas komplizierter). Dies führt darüberhinaus dazu, dass Webbrowser nicht auf kompromittierte https-Server zugreifen können
- Content-Prüfung
Prüfen des Verbindungsaufbaus beim CONNECT: Bei einem sshd erscheint direkt nach dem Öffnen der TCP-Verbindung zunächst im Klartext folgender String noch bevor der SSH-Client Daten sendet:
SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110
Bei einem normalen HTTPS-Server sendet zuerst der Client Daten an den Server und beginnt damit den SSL-Handshake.
Entweder unterstützt der Proxy direkt entsprechende Content-Filter auf CONNECT oder man läßt den Firewall ausgehende Verbindungen auf Port 443 entsprechend überwachen und nötigenfalls Verbindungen blockieren, wenn diese nach SSH und nicht nach SSL aussehen.
Nachträglich lässt sich auch anhand der geloggten CONNECT-Verbindungen im Proxy-Log eine systematische Prüfung per Script durchführen und kann sich eine eigene Blacklist generieren, das ist relativ trivial mit nc (netcat) zu erledigen:
$ nc -w 2 up.uugrn.org 443 | grep -i ssh >/dev/null 2>&1 && echo "SSH" || echo "kein SSH" SSH $ nc -w 2 www.uugrn.org 443 | grep -i ssh >/dev/null 2>&1 && echo "SSH" || echo "kein SSH" kein SSH $ nc -w 2 shell.uugrn.org 443 | grep -i ssh >/dev/null 2>&1 && echo "SSH" || echo "kein SSH" SSH
