/Admin Corner: Tunnels graven

Je weet vast wel dat encrypted verbindingen te verkiezen zijn boven plaintext verbindingen, maar je hebt niet altijd de keuze. Vroeg of laat kom je wel eens in een situatie terecht waarin je op het eerste zicht geen encryptie kan gebruiken. De oplossing? Een encrypted tunnel opzetten met OpenSSH of stunnel! Hier volgen enkele praktijkvoorbeelden.

Sommige services hebben een soort management interface die je benadert via een builtin webserver. Uit veiligheidsoverwegingen is die meestal uitsluitend toegankelijk vanaf localhost. Maar wie installeert nou een browser op zijn servers? Helaas is de webinterface openstellen voor buitenaf een stuk makkelijker gezegd dan gedaan. De meeste builtin webservers hebben immers een erg beperkte featureset. Authenticatie is vaak afwezig en SSL-encryptie mag je al helemaal vergeten. Niet bepaald geschikt om rechtstreeks op het internet aan te sluiten dus! Apache met mod_proxy en mod_ssl lost bovenstaande problemen op.

Port forwarding

Maar is dat niet wat veel werk voor iets dat je toch maar sporadisch gebruikt? Je hebt waarschijnlijk al ssh-toegang tot de server, want anders kan je hem moeilijk beheren. Waarom gebruik je dan niet gewoon de local port forwarding-functie van ssh? Bijvoorbeeld:

$ ssh -L 8000:localhost:80 remote-host

 Bovenstaand commando forward connecties op poort 8000 op jouw machine naar poort 80 op ‘localhost’ via een ssh-connectie naar ‘remote-host’. De ‘localhost’ slaat hier dus wel degelijk op de remote machine! De forwarding wordt afgesloten, zodra je de interactieve ssh-sessie sluit. Met de optie ‘-fN’ start je de port forwarding op in de achtergrond, dus zonder shell sessie naar de remote server. De forwarding nadien afbreken doe je bijvoorbeeld met fuser (fuser -k -n tcp 8000).

Ssh laat -wederom uit veiligheidsoverwegingen- enkel connecties toe op de geforwarde port vanaf localhost (jouw machine dus). Wil je andere machines in jouw netwerk via jouw machine toegang geven tot de remote host? Dan laat je ssh luisteren op jouw LAN IP-adres door die als zogenaamde bind interface mee te geven (met * luistert ssh gewoon op alle beschikbare interfaces):

$ ssh -L *:8000:localhost:80 remote-host

Remote forwarding

Port forwarding werkt ook in omgekeerde richting: met -R in plaats van -L zal ssh een poort naar keuze op de remote server forwarden naar een poort op jouw machine:

$ ssh -R 8000:localhost:80 remote-host

In dit geval is ‘localhost’ dus effectief de machine waarop je het port forwarding commando gestart hebt. Ook hier kan je optioneel de bind interface specificeren als je andere machines via de remote host jouw machine wilt laten bereiken. Remote port forwarding komt vooral van pas wanneer jouw pc achter een firewall staat en er geen inkomende verbindingen mogelijk zijn. Dankzij een ommetje via een externe server kan je anderen dan tóch nog toegang geven tot jouw machine. Je hebt daarvoor alleen ssh-toegang nodig tot een server in een minder restrictief netwerk.

Stunnel

Hoewel SSL-ondersteuning intussen wel gemeengoed is geworden, ontbreekt het soms in oudere of kleinere applicaties. Met stunnel voeg je SSL-ondersteuning toe zónder het programma aan te passen. Dat is vooral handig als je twee programma’s met elkaar wilt laten samenwerken en één van beide ondersteunt geen SSL. Stunnel is in feite een extra daemon langs client- of serverkant die plaintext-verbindingen opzet naar de ene applicatie en versleutelde verbindingen naar de andere applicatie. Dit is volledig transparant voor beide applicaties.

Stel dat je een IMAP-client gebruikt die enkel plaintext-verbindingen ondersteunt, terwijl jouw IMAP-server SSL vereist. Op de client luistert stunnel dan op poort 143. De IMAP-client opent nu een plaintext-verbinding met localhost:143 in plaats van met de IMAP-server. Stunnel encrypteert vervolgens alle communicatie alvorens die te forwarden naar de IMAP-server op poort 993. Voor de server lijkt het alsof de client SSL ondersteunt, terwijl de client net denkt dat de server ook plaintext-verbindingen toestaat.

Je kan stunnel met alle vereiste opties via de commandline opstarten, maar het is handiger om een configuratie aan te maken in /etc/stunnel. Dan worden alle tunnels automatisch opgestart bij het booten van je pc en zijn ze steeds beschikbaar. Zo’n configuratie ziet er bijvoorbeeld als volgt uit:

$ cat /etc/stunnel/imap.conf

pid = /stunnel4.pid

debug = mail.5

sslVersion = TLSv1

[remote-imap]

client = yes

accept = 127.0.0.1:143

connect = remoteserver.com:993

Dit artikel van Koen Vervloesem heeft eerder gestaan in Linuxmagazine 3.2014. p45