SSH Tunnel – Virtual Private Networing with SSH

Saturday, 20. November 2010

Auch mit SSH ist es möglich ein VPN aufzuziehen. Dieses Howto versteht sich als Erweiterung zu ISA Firewall/Proxy sucks! -or- How to make it disappear! Es ermöglicht auf das Portforwarding und den OpenVPN Tunnel zu verzichten und das VPN gleich mittels SSH aufzuziehen! (die ssh Verbindung müsste in diesem Falle natürlich zum localhost : 1443 aufgenommen werden auf welchem cntlm lauscht – siehe ISA Firewall/Proxy sucks! -or- How to make it disappear! )

———————————————–

 

Client B (Default Gateway: 10.1.1.1) —> Server A (WAN IP: 1.2.3.4 [myserver.com] SSH Port: 443) Vorbereitung: Auf beiden Maschinen wird das IP forwarding aktiviert:

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
ssh root@myserver.com -p 443 'echo 1 |tee /proc/sys/net/ipv4/ip_forward'
 

Die SSH Daemons müssen über die Datei /etc/ssh/sshd_config so konfiguriert werden, dass ein VPN Tunnel sowie der root Login erlaubt ist:

PermitRootLogin yes
PermitTunnel yes

(Im Optimalfall hat man für weiteres Vorgehen sshd so konfiguriert, dass man ohne Password mit Zertifikat einloggen kann) Jetzt baut man den SSH Tunnel auf. Die folgende Konfiguration sorgt dafür, dass der Tunnel zum Server geschlagen wird, auf dem Client wie auch am Server ein Device namens “tun0” erstellt wird und im gleichen Terminal weitergearbeitet werden kann. Wer sich tatsächlich zum Server verbinden will verzichtet auf N T und f .

sudo ssh -NTCf -w 0:0 root@myserver.com -p 443

Jetzt haben wir zwei unkonfigurierte “virtuelle” Netzwerkinterfaces (tun0) die nun für den Tunnel konfiguriert werden müssen:

local:

sudo ifconfig tun0 10.0.0.222 pointopoint 10.0.0.111

remote:

ssh root@myserver.com -p 443 ifconfig tun0 10.0.0.111 pointopoint 10.0.0.222

zu diesem Zeitpunkt kann man tun0 des Servers (10.0.0.111) bereits pingen (und vice versa). Jetzt binden wird das ganze Netz ein:

sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.222 tun0

Durch diese Anweisung verwendet das 10er Netz das virtuelle Device tun0 als Gateway in die Freiheit.

ssh root@myserver.com -p 443 arp -sD 10.0.0.222 eth0 pub

Dies stellt im Netz des Servers sicher, dass Pakete die für 10.0.0.222 gedacht sind auch an den Server gesendet werden (damit dieser sie forwarden kann) Im letzten Schritt definieren wir für das gesamte 10er netz des Clients tun0 als default Gateway. Damit wird dem SSH Tunnel nicht den Ast absägen auf dem dieser gerade sitzt müssen wir aber zuerst für diese spezielle Verbindung eine eigene Route legen.

sudo route add 1.2.3.4 gw 10.1.1.1 eth0

Jetzt können wir einen neuen default Gateway setzen:

sudo route add default gw 10.0.0.111 tun0
und den alten löschen:
sudo route del default gw 10.1.1.1 eth0

Abschließend muss noch auf beiden Maschinen “masquerading” aktiviert werden

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
ssh root@myserver.com -p 443 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Fertig! Wer sein Werk nun überprüfen will kann testweise mit folgendem Befehl den Verlauf der Pakete über das VPN verfolgen:

tracepath gmx.net

Im übrigen Netz kann man nun die IP des Client B als default Gateway eintragen um auch diese durch den VPN Tunnel zu schleusen.
glhf

Noch einmal alle Shellbefehle auf einem Fleck:

ssh root@myserver.com -p 443 'echo 1 | tee /proc/sys/net/ipv4/ip_forward'
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo ssh -NTCf -w 0:0 root@myserver.com -p 443
sudo ifconfig tun0 10.0.0.222 pointopoint 10.0.0.111
ssh root@myserver.com -p 443 ifconfig tun0 10.0.0.111 pointopoint 10.0.0.222
sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.222 tun0
ssh root@myserver.com -p 443 arp -sD 10.0.0.222 eth0 pub
sudo route add 1.2.3.4 gw 10.1.1.1 eth0
sudo route add default gw 10.0.0.111 tun0
sudo route del default gw 10.1.1.1 eth0
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
ssh root@myserver.com -p 443 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

 

PS: Man sollte sich bewusst sein, dass ein Umgehen der Sicherheitsvorkehrungen in den meisten Fällen nicht erwünscht ist und sogar ein Kündigungsgrund sein kann!

ISA Firewall/Proxy sucks! -or- How to make it disappear!

Thursday, 18. November 2010

Wir befinden uns in einem Netzwerk das duch einen Microsoft ISA firewall/proxy Server gesichert ist und uns bis auf http:/ und vielleicht https:/ nicht gestattet mit der Ausserwelt zu kommunizieren.

xmpp, imap, pop3, ftp, ssh, etc. alles zu …. aufgeben? >> Link No Way !!

Die Idee um dieses Problem in den Griff zu bekommen ist folgende: Durch einen http Tunnel wird ein ssh Tunnel aufgebaut. Durch diesen ssh Tunnel wird ein vpn Tunnel aufgebaut. Der gesamte Netzwerktraffic wird durch diesen OpenVPN Tunnel in die Freiheit geroutet.

Wir benötigen:

openssh-server – um genau zu sein einen Server im WeltWeitenNetz der uns gehorcht, dessen ssh Server wir umkonfigurieren können, sodass er auf Port 443 lauscht.

cntlm (cntlm – Fast NTLM authentication proxy with tunneling) http://iitmlug.a.wiki-site.com/index.php/Cntlm

openvpn (openvpn – virtual private network daemon) Der openvpn Server läuft auf der gleichen Maschine wie der ssh Server und lauscht auf Port 1100.

Wir nutzen cntlm um uns am Proxy anzumelden und für ssh einen http Tunnel zum ssh Server zu öffnen. Die anderen Methoden wie zb. proxytunnel (Proxy-Server umgehen – proxytunnel,ssh socks5, proxychains) funktionieren im Falle von NTLMv2 einfach nicht.

Zuerst müssen wir cntlm installieren (sudo apt-get install cntlm) und dann die Konfigurationsdatei bearbeiten (sudo nano /etc/cntlm.conf ) Die wichtigen Parameter sind:

# Cntlm Authentication Proxy Configuration
Username myusername
Domain mydomain.at
Password mypassword
Proxy 10.1.1.1:8080
# This is the port number where Cntlm will listen
Listen 3128
# How to authenticate
Auth LM
# Tunnels mapping local port to a machine behind the proxy
Tunnel 1443:myserver.com:443

Erklärung:

Username, Domain, Passwort – Diese Einstellungen sollte man wissen bzw. schaut man sich am besten von einem Windowsclient ab.
Proxy – Dies ist die IP des ISA Servers
Listen – Hier horcht cntlm als http Proxy am localhost (auch socks5 proxy kann aktviert werden)
Auth – siehe unten
Tunnel – Die wichtigste Einstellung ! hier wird definiert, dass alles was auf localhost:1443 geht durch einen Tunnel an myserver.com:443 geleitet wird.

Jetzt starten wir cntlm mit folgender Zeile:

sudo cntlm -v -M http://google.com

Wir erhalten bei erfolgreicher Anmeldung am ISA Server nun ein wenig Output und kopieren uns die 2 Zeilen “Auth” und “PassNTLMv2” – wir ersetzen nun in der Konfigurationsdatei /etc/cntlm.conf “Auth LM” mit diesen zwei Zeilen.

……. .. ..
config profile 1/11… OK (HTTP code: 301)
—————————-[ Profile 0 ]——————-
Auth NTLMv2
PassNTLMv2 79FDB5B5CD47121A714E133481478CB0

————————————————————–

(nicht aus dem Blog kopieren! Der Hash im HowTo ist ein Beispielhash)

Ist das erledigt kann man cntlm starten (vielleicht zuerst mal mit “sudo cntlm -v” um zu sehen was passiert) Jetzt sollte das Aufbauen eines ssh Tunnels zum Server funktionieren. cntlm horcht, wie in der Konfigurationsdatei definiert, am localhost am Port 1443 um einen solchen zu erstellen.

_____________________________________________

Von diesem Punkt an bieten sich zwei weitere Vorgehensweisen an:

1) Wie geplant OpenVPN durchtunneln  — einfach unten weiterlesen 🙂

2) Mit ssh ein VPN aufziehen SSH Tunnel – Virtual Private Networing with SSH

_____________________________________________

OpenVPN duch den SSH Tunnel routen

sudo ssh -C -L 1100:1.2.3.4:1100 root@localhost -p 1443

Diese Zeile baut dank “cntlm” einen ssh Tunnel zu “myserver.com:443” auf und leitet gleichzeitig alles was am localhost:1100 landet auf den Server auf Port 1100 (1.2.3.4 ist hier die IP von “myserver.com” sprich: des ssh Servers, welcher auch gleichzeitig der openvpn Server ist ). -C komprimiert den Netzwerktraffic. SuperUserRechte (sudo) werden hier benötigt!

Wir müssen nun den openvpn Client so konfigurieren, dass er sich zu “localhost:1100” verbindet. Dieser wird dann automatisch an die remote IP geleitet.

Siehe Redirect network traffic through OpenVPN tunnel

(Dieser Artikel beschreibt den letzten notwendigen Schritt um den gesamten Netzwerktraffic durch die Tunnel zu routen. Lediglich die “remote” Adresse muss auf “localhost” geändert werden.)

! OpenVPN muss als tcp-server bzw. tcp-client konfiguriert werden, sonst funktioniert das Tunneln nicht !

glhf !

🙂

——————————————————————–

Gedanken:

(Möglicherweise wäre es machbar openvpn auf Port 443 zu legen und gleich durch cntlm zu tunneln – ohne ssh Tunnel. in einem schnellen Versuch konnte die Verbindung nicht aufgebaut werden. Ich sehe aber keinen Grund warum das nicht gehen sollte. Je nachdem wie restriktiv der ISA Server konfiguriert ist, könnte es auch drin sein sich direkt per OpenVPN am Proxy anzumelden (openvpn bietet eine Möglichkeit dafür)

Ich bin für Anregungen diese Lösung effizienter zu machen sehr dankbar und werde dieses HowTo beizeiten auch noch nachbessern!

Redirect network traffic through OpenVPN tunnel

Saturday, 6. November 2010

  • Der Server auf dem openVPN läuft hat die IP 88.88.88.88
  • Das lokale Subnet ist ein 10.0.0.0 und der Client der zum openVPN Server die Verbindung aufbauen wird hat die IP 10.0.0.1
  • Beim Start des openVPN Servers wird das virtuelle Device “tap0” am Server erstellt und erhält die IP 10.10.10.250
  • Beim Start des openVPN Clients am Rechner mit der IP 10.0.0.1 wird ebenfalls ein virtuelles Device “tap0” erstellt und erhält die IP 10.10.10.1

Wir haben also zwei verschiedene Netze 10.0.0.0 und 10.10.10.0 die von OpenVPN durch Routing automatisch verbunden werden. (Somit ist keine bridge und kein anpassen der beiden Netze aneinander nötig)

Die Konfigurationsdateien für Server und Client sehen wie folgt aus:

~# cat /etc/openvpn/Server.conf

####### OpenVPN Server Config #########

port 1100
mode server
dev tap0
client-to-client
tls-server
proto tcp-server

server-bridge 10.10.10.250  255.255.255.0 10.10.10.1 10.10.10.199
ifconfig 10.10.10.250 255.255.255.0

chroot /etc/openvpn

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem

keepalive 10 60
verb 5
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-tun
persist-key
comp-lzo
comp-noadapt

~$ cat /etc/openvpn/client.conf

####### OpenVPN Client Config #########

port 1100
remote 88.88.88.88
ifconfig 10.10.10.1 255.255.255.0

dev tap
tls-client
proto tcp-client
redirect-gateway
route-gateway 10.10.10.250

ca /etc/openvpn/keys/ca.crt
key /etc/openvpn/keys/client1.key
cert /etc/openvpn/keys/client1.crt

ns-cert-type server
keepalive 10 60

tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-tun
persist-key
comp-lzo
comp-noadapt
route-delay 10

Die Zertifikate müssen im Vorraus erstellt und ausgetauscht worden sein. Hierbei helfen die Skripte im Verz.: /usr/share/doc/openvpn/examples/easy-rsa/2.0/

(Anleitungen zur Erstellung und dem Umgang mit den Zertifikaten findet man über die Suchmschine seiner Wahl (HowTo folgt eventuell noch^^)

Nach dem erfolgreichen Start des VPN wird mit dieser Konfiguration sämtlicher Traffic des VPN Clients über den VPN Tunnel geleitet und kommt erst bei der IP 88.88.88.88 im Netz zum Vorschein. (Dies könnte auch dazu genutzt werden um Internet TV und andere Dienste zu nutzen die mit der eigenen IP nicht zugängig sind. Diesen Trick erlauben uns die Optionen

redirect-gateway
route-gateway 10.10.10.250

welche dafür sorgen, dass sämtliche Vorkehrungen automatisch getroffen werden um das Tunneln zu ermöglichen.  Möchte man nun das gesamte Netz des VPN Client über diesen Gateway schleifen so muss auf diesem Internetforwarding aktivert werden und die IP 10.0.0.1 bei allen anderen Clients im Netz als Default Gateway eingetragen werden.

Siehe auch > Internet Forwarding aus der Konsole aktivieren

Am OpenVPN Client:

sudo iptables -A POSTROUTING -t nat -j MASQUERADE
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

Auf den übrigen Clients im Netz:

sudo route add default gw 10.0.0.1

glhf 🙂

Internetforwarding aus der Konsole aktivieren

Saturday, 6. November 2010

Das Internetfähige Handy ist angeschlossen, der Laptop ist über dieses online!

ppp0 hat die IP 55.66.77.88 erhalten

eth0 hängt am Switch an dem auch alle anderen PCs im Netz hängen und hat die IP 10.0.0.1


Folgende 2 iptables Regeln werden laut UbuntuWiki emfohlen sind aber nur bedingt notwendig:

sudo iptables -A FORWARD -i eth0 -o ppp0 -s 10.0.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Masquerading und ip forwarding aktiveren:

sudo iptables -A POSTROUTING -t nat -j MASQUERADE
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

Jetzt noch auf den Clients den Laptop als default Gateway eintragen und fertig:

sudo route add default gw 10.0.0.1

Anstelle von ppp0 kann auch wlan0 oder eth1 stehen. Es geht nur darum dass dieses das Interface mit dem Zugang nach draussen ist. Die ersten beiden iptables Regeln werden zwar empfohlen, es funktioniert aber auch ohne wie ein kurzer Test ergeben hat.

Die iptables Regeln kann man übrigens sichern und wieder rückspielen:

sudo iptables-save | sudo tee /etc/iptables.sav
iptables-restore < /etc/iptables.sav

Proxy-Server umgehen – proxytunnel,ssh socks5, proxychains

Thursday, 4. November 2010

Sitzt man hinter einem ISA oder einem anderen Firewall/Proxy-Server, so sind meist die wichtigen Ports für SSH, IMAP oder FTP geschlossen und somit die Nutzung dieser Dienste unmöglich. Hat man Zugriff auf einen SSH Server irgendwo im freien Internet kann man folgendes Szenario anwenden um diese Restriktion zu umgehen.

Kurzzusammenfassung:

  1. Der openssh-server wird so konfiguriert, dass er über einen erlaubten Port ansprechbar wird. zB.SSL:  443 (Welcher zumeist offen ist! Falls der SSL Port zu ist und am Server kein Apache läuft kann man auch Port 80 missbrauchen)
  2. proxytunnel wird verwendet um über den ISA einen HTTP Tunnel aufzubauen und SSH durchzuschleifen.
  3. ssh wird verwendet um einen socks5 proxy zu erstellen und einen tunnel zum openssh-server aufzubauen.
  4. proxychains wird konfiguriert sämtlichen traffic über den socks5 proxy zu leiten.

ad 1) am server sshd_config editieren und den Port auf dem der openssh-server lauscht auf 443 stellen:

sudo nano /etc/ssh/sshd_config
Port 443

ad 2) am client proxytunnel installieren und ssh so konfigurieren, dass es beim Aufruf des Hosts “foobar” diesen verwendet.

sudo apt-get install proxytunnel
nano ~/.ssh/config
Host foobar
ProtocolKeepAlives 30
ProxyCommand /usr/bin/proxytunnel -p proxy.server.at:8080 -u user -s password -d xapient.net:443
foobar The symbolic name of the host you want to connect to
proxy.customer.com The host name of the proxy you want to connect through
8080 The port number where the proxy software listens to
user Your proxy userid
password Your proxy password
xapient.net The hostname of the box you want to connect to (ultimately)
443 The port number of the SSH daemon on mybox.athome.nl

Falls der Proxy keinen Benutzernamen und kein Passwort benötigt kann man diese Optionen weglassen. Gibt man nur -u an so wird man nach dem Passwort gefragt. Es kann auch notwendig sein die Domäne mitanzugeben. Hierfür ist der Parameter -t (zB. -t mydomain)

ad 3) ssh socks5 auf Port 1080 und tunnel zum openssh-server aufbauen

ssh -D 1080 root@foobar -p 443

ad 4) proxychains.conf editieren, sicherstellen dass strict_chain und proxy_dns auskommentiert sind und den lokalen SOCKS5 der [ProxyList] hinzufügen.

sudo nano /etc/proxychains.conf
socks5  127.0.0.1 1080

Nun kann man zb. Dolphin starten um über FTP auf den Server zu zugreifen:

proxychains dolphin