![[Georges Tarbouriech]](../../common/images/Georges-Tarbouriech.jpg)
original in en Georges Tarbouriech
en to en Lorne Bailey
en to nl G.H. Snijders
Georges is reeds lang een Unix gebruiker (commercieel en vrij). Hij is
zeer ge�nteresseerd in beveiliging en wil de Free software community danken
voor het fantastische werk dat is gebeurd op dit gebied.
SSH, (Secure SHell), is een goed commercieel
produkt. Er zijn echter ook diverse goede vrije implementaties van ssh clients en
servers beschikbaar voor Unix (commercieel of vrij) en voor andere OS'es.
De bekenste is OpenSSH, beschikbaar op http://www.openssh.org/. Op deze website zijn
alternatieven te vinden voor Unix systemen, windos, Mac... Voor sommige produkten
zoals Windos heb je alleen vrije clients.
In dit artikel zullen we een paar voorbeelden laten zien van hoe je ssh kunt
gebruiken om data van/naar externe applicaties te tunnelen. VPN (Virtual Private
Network) lijkt op ssh maar op een andere manier, veel uitgebreider dan waar we hier
op in gaan. Een andere geavanceerde oplossing is om
VTun. te gebruiken.
Aansluitend, laten we tunneling zien als een eenvoudige en simpele manier om data
te versleutelen in een heterogeen netwerk, om te voorkomen dat het wordt afgeluisterd.
Het moge duidelijk zijn dat dit toe te passen is op zowel locale als remote netwerken.
Echer, hou in gedachten dat ssh alleen maar data versleuteld, het maakt je netwerk
op zich niet veilig...
Je bent gewaarschuwd!
SSH is een vervanging voor telnet of rsh, rlogin, zoals reeds genoemd in een eerder artikel.
Ook al zijn er recent beveilings problemen gevonden in SSH, het blijft een goede tool
voor het versleutelen van data. Tussen haakjes, bovengenoemde beveilings probleem behelst
een probleem met wachtwoorden: het wordt sterk aangeraden passphrases (zinnen) te
gebruiken in plaats van RSA sleutels! Het gebruik van SSH sluit het gebruik van
andere beveiligings tools niet uit, zoals tcpwrappers.
Het is heel eenvoudig om data die door een netwerk circuleert, af te luisteren met
standaard tools als tcpdump en snoop. Je kunt dit testen op een netwerk waar twee
machines data uitwisselen met, bijvoorbeeld, telnet. Op een derde machine, waar
(bijvoorbeeld) Linux op draait, start je tcpdump (als root, natuurlijk) en kijk je wat
er gebeurt. Je kunt alle data lezen! (noot van redactie: de 3 computers zullen verbonden
moeten zijn door middel van een hub om dit te testen). Het zal niet werken als je een
switch gebruikt, maar het punt is geldig.
Natuurlijk is de display te snel om van het scherm af te lezen, maar niet houdt je tegen
om de output om te leiden naar een bestand, en dat vervolgens onder het genot van een
kop koffie te lezen. Als dit geldt voor de data, geldt het ook voor je wachtwoord: dat
is, de deur staat wijd open voor de crackers, je geeft ze de sleutel tot je huis.
Stel je een voor dat de rondgaande data vertrouwelijk is... Als jij de systeembeheerder
bent, ben ik bang dat je baas je zal vragen een andere baan te gaan zoeken.
De remote commando's rsh, rcp, rlogin zijn ook gevaarlijk, daar de data ook niet
versleuteld wordt. Als SSH een goede vervanging is voor rlogin of rsh, er wordt een
tool meegeleverd, scp, welke een goede vervangin is voor rcp. Dat wil zeggen, je hebt
geen remote commando's of telnet meer nodig als je SSH gebruikt, of tenminste, je zou
ze niet langer moeten gebruiken.
De installatie van SSH, het genereren van priv� en publieke sleutels... vallen buiten
het bereik van dit artikel. Alles wat je nodig hebt kun je vinden in het SSH archief
dat je downloadt of door het lezen van de documentatie die beschikbaar is op
het Linux Documentatie Project.
Daar vandaag de dag het gebruik van een computer bijna altijd het verplaatsen van data
op een of manier betekend, zou SSH verplicht moeten zijn... wel, het is aan jou.
Echter, SSH kan veel meer dan telnet of de remote commando's vervangen.
Het kan gebruikt worden om data te versleutelen tussen externe applicaties en uiteraard,
tussen verschillende OS'en. Het kan deze data ook comprimeren. Het wordt vaak gebruikt
met protocollen als pop, ftp, http... of het nu voor compressie is of versleuteling.
Dit is zeer bruikbaar als je een systeembeheerder bent, om bijvoorbeeld een verbinding
van huis naar het werk op te zetten of vice versa.
Daar het een client/server applicatie is, heeft SSH duidelijk beide nodig: Je hebt een
machine nodig die een ssh server draait en een machine die een ssh client draait (ik
hoop dat je merkt hoe slim ik ben!)
Waarom ik de nadruk leg op dit overduidelijke feit? Omdat, daar we het hebben over vrije
software, vele OS'en anders dan Unix, hebben geen vrije servers. Dat betekend dat je
soms niet in staat zult zijn om het voor de hand liggende te doen, je zult het probleem
moeten omdraaien: de sleutel wordt ook wel forwarding (doorsturen) genoemd. Later meer
hierover. Dat betekend dat het bebruik van OS'en als Mac OS of Windos met zich meebrengt
dat je geen vrije servers hebt, zodat je het zult moeten doen met alleen clients. Hoe dat
in z'n werk gaat ligt niet altijd even voor de hand. Laten we een paar echte voorbeelden
aanhalen.
Als je VNC niet kent, mis je een van de mooiste tools ooit. Je kunt hier een blik
op werpen om er meer over te lezen.
Op de VNC website (
http://www.uk.research.att.com/vnc/docs.html) is zeer veel documentatie
beschikbaar voor waar we het over hebben. Je kunt er bijvoorbeeld vinden hoe je
VNC over SSH kunt gebruiken, tussen een Windos SSH client en een Unix SSH server.
Aansluitend, ik zal niet proberen Frank Stajano's fantastische werk niet herschrijven,
vooral omdat het een stuk beter is dan wat ik zou doen.
Ok, laten we eens kijken hoe dit werkt.
Allereerst moeten we een vrije Windos client uitkiezen. Voor dit voorbeeld, zullen
we gebruik maken van Teraterm Pro met zijn ITssh uitbreiding. Je kunt deze vinden
op
http://hp.vector.co.jp/authors/VA002416/teraterm.html.
Het is genaamd ITssf, daar het een versie is, die is toegestaan in Frankrijk.
(De dingen veranderen, maar tijdens het schrijven van dit artikel, staan veel
landen versleuteling niet toe. Check op deze URL om te zien hoe de situatie
in jouw land is:
http://www2.epic.org/reports/crypto2000/countries.html.)
Nu, stel dat je een ssh server op een Unix machine gestart hebt. Op dezelfde machine,
kun je ook een vncserver draaien. Als die 2 servers draaien, kun je een verbinding
opzetten vanaf een NT machine naar een Unix server met behulp van Ttssh. Dat betekend
dat je nu een versleutelde verbinding hebt tussen 2 machines. Maar dit staat je nog
niet toe om een versleutelde vncviewer (vncclient) te starten op die NT machine. Om
dat te doen, moet je ssh de juiste poort door te sturen (forwarden, daar zijn we
dan!)
De Unix machine die de vnc server draait, is genaamd "bandit" en gebruikt poort
5901 omdat het display nummer 1 is, daar de default X display voor deze machine 0 is.
De normale manier zou zijn om een commando "vncviewer bandit:1" te gebruiken.
Dit zal werken, uiteraard, maar zonder dat de data versleuteld is. In plaats daarvan,
kun je de NT "shell" gebruiken (de DOS interface, om zo te zeggen), om het commando
"/ssh-L5902:bandit:5901" zonder spaties, te gebruiken. Dit betekent dat je een
lokale poort 5902 cre�ert. Nu zal een commando als "vncviewer localhost:2" een
versleutelde verbinding starten met het VNC protocol op je NT machine. Dit kan
gedaan worden zonder gebruik te maken van de opdracht regel, daar Ttssh een
graphische interface heeft. Merk op dat deze syntax alleen voor Ttssh geldt.
Hetzelfde commando op een Unix machine zou er zo uitzien: "ssh
-L 5902:bandit:5901 bandit".
Dit is uiteraard een basis voorbeeld: je kunt veel complexere dingen doen.
Check de documentatie, beschikbaar op de VNC website, en dan vooral die van
Frank Stajano.
MySQL is vermoedelijk een van de meest
gebruikte DBMS'en, vooral op het Internet. Nogmaals, de beveiliging van MySQL
valt buiten het bereik van dit artikel. Echter, het versleutelen van de data
die wordt uitgewisseld tussen een MySQL server en een MySQL client maakt de
verbinding een stuk veiliger. SSH staat je toe om dat te doen, op dezelfde
manier als met VNC, met behulp van port forwarding.
Ons voorbeeld gaat over een Intranet. De MySQL server is een Linux box en
de meeste van de clients zijn NT machines. Ook hier zullen we een Ttssh client
gebruiken op de Windos machines.
Het standaard MySQL poort nummer is 3306. We zullen diezelfde poort (3306)
forwarden.
Je kunt zowel lokaal als remote forwarden.
Een lokale forward ziet er ongeveer uit als "/ssh-L3306:localhost:3306" op de
NT machine of "ssh -L 3306:localhost:3306" op een Unix machine. Door gebruik
te maken van "localhost" kun je data door de loopback interface sturen in plaats
van de host interface.
Een remote forward zou "/ssh-R3306:bandit:3306" voor NT zijn, en "ssh -R
3306:bandit:3306" voor Unix.
Dit betreft alleen de connectie zelf. Om in te loggen op de DBM, heb je
natuurlijk je hostname en je gebruikersnaam voor de MySQL server nodig,
waarschijnlijk verschillen deze van de login naam van je machine. Lees de SSH
man pages over de optie "-l".
Uiteraard, zal dit alleen werken als je een MySQL client hebt op je NT machine.
Als je die niet hebt, kun je gebruik maken van een ODBC applicatie zoals bijv.
Sybase. Start deze applicatie en gebruik de ODBC driver om het linken met
MySQL. Nu kun je een verbinding opzetten naar de localhost, niet de MySQL server,
om de MySQL server te benaderen. Het dataverkeer dat plaatsvindt tussen client en
server wordt nu versleuteld. Je kunt dit controleren met snoop of tcpdump.
Dat was voorbeeld met een lokaal netwerk. Als je er meer voor voelt dergelijke
dingen over WAN's te doen, wordt het iets complexer als je achter een firewall
zit. Dit kan een manier zijn om wat werk op afstand te doen vanaf thuis als je
de systeembeheerder bent, maar je kunt bijna niet zo'n manier verwachten als
een manier om een DBM op een website te benaderen. In dat geval zul je moeten
kijken naar een nog geavanceerdere oplossing, een vpn bijvoorbeeld, maar dit
is het idee.
Hoe dan ook, geloof niet dat het genoeg is om een veilige DBM server op te zetten,
belast met beheren van vertrouwelijke data zoals credit card nummers!
En, tussen haakjes, wie gelooft het werkelijk als iemand zegt dat hij een heel
veilige server heeft, die in staat is om dit soort data te beheren zonder enig
risico? Ik niet!!!
Wat wil dit zeggen, daar we reeds terminal emulatie gebruiken?
Stle dat je een oude Cobol applicatie draait op een Unix server.
De clients zijn, alweer, NT machines. Om contact te kunnen maken hebben ze
een gevanceerdere terminal emulatie dan vt100, vt220 of vt320 nodig om de
juiste gebruikersinterface te bieden. Dat wil zeggen, accenten, tabellen...
Een standaard terminal emulatie tot 8bit zal niet werken. Wat je dan krijgt
is onbruikbaar. Aansluitend, daar het een nogal oud produkt is, gebruik je
"oude" terminal emulatie software.
Na een lang gevecht om de juiste emulatie te krijgen, ontdek je dat "ibm3151"
het beste resultaat geeft. Zo ver gaat het goed!
Maar, daar de gebruikte software vele jaren geleden ontwikkeld is, weet het
niks van beveiliging. De verbinding gebruikt telnet! En erger, de data die
verstuurd wordt is nogal vertrouwelijk... Nou en? Je zult een manier moeten
vinden om, op z'n minst, de data te versleutelen. Ook hier kan SSH een
uitweg bieden.
Nogmaals, Er Is Meer Dan Een Manier Om Het Te Doen...
Ofwel je redirect (omleiding) telnet naar poort 22 (SSH) of je stuurt de
poort van de terminal emulatie door. Maar... Ik ben bang dat de server het
niet accepteerd als een gewone gebruiker de telnet poort omleidt (standaard
is dit 23): Je zult root moeten zijn om zoiets te doen (tenminste, dat hoop
ik!). Wat betreft de terminal applicatie, dit kan gedaan worden door
verschillende gebruikers tegelijk, en dus verschillende poorten voor elke
connectie, 10 gebruikers=10 poorten dus.
Dat begint een beetje lastig te worden, niet?
Eerst moet op de applicatieserver dus de SSH server draaien en luisteren
op poort 22.
>Vanaf een NT client, zetje een verbinding op naar de app server, met Ttssh
of vanaf de commando regel. Je zet dus een beveiligde verbinding op tussen de
server en de client als een gewone gebruiker. In de Ttssh opties kun je de
lokale poort 50000 doorsturen naar poort 23 (telnet) op de server. Vanaf de
commando regel zou dit ongeveer zo gaan: "ssh-L50000:servername:23".
Nu kun je je terminal emulatie vertellen om verbinding te makne via poort 50000
in plaats van poort 23. De data zal nu circuleren via een beveiligd kanaal,
dat wil zeggen, versleuteld. Je kunt dit controleren met snoop of tcpdump.
Uiteraard zou je hetzelfde kunnen doen voor iedere client die is toegestaan om
contact te maken met de applicatie, door de doorgestuurde poort te veranderen.
Je zou bijvoorbeeld 50001, 50002, 50003, etc kunnen gebruiken.
...
Nu, zou je kunnen vragen, waarom zulke hoge poorten? Het antwoord is: om
vele redenen!
Serieus, de belangrijkste reden is dat je hoge poorten kunt "manipuleren" zonder
root te zijn.
De tweede reden is dat de geselecteerde poort nog niet in gbruik mag zijn op
beide machines. Voorbeeld: als de server Solaris draait, worden veel hoge
poorten gebruikt voor de draaiende services. Dus zouden poort 50000 en hoger
moeten werken. Dit betekend dat je de poorten zult moeten checken voor je ze
omleidt.
Natuurlijk, dit zou moeten werken voor vele andere OS'en die in staat zijn
om SSH clients te gebruiken.
Wat betreft de manier om het proces te automatiseren op de client machines,
dat is helemaal aan jou. Je kunt een "normale" gebruiker niet vragen om dit
allemaal te doen alvorens een verbinding op zetten, wel? Wel, dat laten we
open als oefening voor de lezers...
Deze paar voorbeelden laten wat van de talrijke toepassingen van SSH zien. Je kunt
veel meer doen met veel applicaties en SSH. Het hangt af van wat nodig hebt.
Echter de "filosofie" is altijd hetzelfde: port forwarding (poorten doorsturen).
Niettemin, wees voorzichtig als je meer complexe forwarding gaat gebruiken.
Bijvoorbeeld, als je doorstuurd door een derde-partij-machine, zal de data
die ciruleert in het midden niet versleuteld worden.
Een ander nadeel gaat over het gebruik van Windos clients als Ttssh. De
connectie om door te sturen, is afhankelijk van IP adressen, net als remote
commando's doen, en is dus gevoelig voor spoof aanvallen. Vandaar de noodzaak
andere tools, zoals tcpwrappers, naast SSH te gebruiken.
Onderzoek de "literatuur" over SSH, je kunt er een hoop van leren. Je fantasie
zal de rest doen.
Beveiliging zou een zorg van iedereen moeten zijn, maar dat is het niet!
SSH is alleen een van de beveiligings hulpmiddelen die je iedere dag kunt
gebruiken. Het is een best wel goede, als je bedenkt wat het is, dus dat het
een versleutel- en compressie tool is.
Op zichzelf is SSH bijna onbruikbaar, daar het niet de vele "gaten" oplost die
je in een machine of netwerk kunt hebben. Een host of zelfs een netwerk beveiligen
is veel werk, en tools doen niet alles, zelfs als zelf goed zijn.
De basis taken liggen voor de hand wanneer het over beveiliging gaat. Vergeet niet
alle ongebruikte services te verwijderen, controleer de SUID root programma's,
schakel de "gevaarlijke" programma's uit... Er is veel te doen en het zal nooit
genoeg zijn. Je kunt alle beschikbare beveiligings tools installeren, het zal
nutteloos zijn als je een of meer achterdeurtjes wijd open laat. Natuurlijk, dit
is een ander verhaal, maar vergeet niet het voor de hand liggende.
Terug naar SSh, laten we stellen dat dit een tool is waar je niet zonder kunt,
zodra je het goed gebruikt, en voor wat het is gemaakt. Nogmaals, gebruik het
met passphrases (wachtzinnen) en RSA keys, geen wachtwoorden. Controleer de
permissies van de verschillende bestanden in de .ssh directory en natuurlijk
de permissies van de directory zelf. En weer en weer, gebruik tenminste de
wrappers!
Onthou echter dat je de meeste bestaande protocollen door SSH kunt tunnelen.
Dit kan heel bruikbaar zijn om connecties een beetje veiliger te maken.
Er is andere toepassing waar SSH veel voor gebruikt wordt, en waar we het nog
niet over hebben gehad, x sessie forwarding. Daar dit het draaien van X op
verschillende OS'en impliceert, hebben we het in de eerste instantie achterwege
gelaten. Maar het valt zeker onder het tunnelen van protocollen. X is misschien
niet zo heel erg veilig, SSH kan het een en ander verbeteren.
Voor gevanceerder gebruik zal SSH niet voldoende zijn. Zoals we al eerder zeiden,
check VPN's of tools als VTun, ze kunnen wellicht helpen.
Ten slotte, controleer de encryptie situatie in jouw land. Het zou jammer zijn
om als spion achter de trailies te verdwijnen, alleen maar door het gebruik
van software als SSH.
Zo ligt het...
Hoe dan ook, we leven in een fantastische tijd!