Door de tunnel

ArticleCategory: [Choose a category for your article]

System Administration

AuthorImage:[Here we need a little image form you]

[Georges Tarbouriech]

TranslationInfo:[Author and translation history]

original in en Georges Tarbouriech

en to en Lorne Bailey

en to nl G.H. Snijders

AboutTheAuthor:[A small biography about the author]

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.

Abstract:[Here you write a little summary]

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!

ArticleIllustration:[This is the title picture for your article]

Illustratie

ArticleBody:[The article body]

Waarom SSH gebruiken?

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.

SSH en VNC

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.

SSH en MySQL

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!!!

SSH en terminal emulatie

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...

Waarheen vanaf hier?

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.

Eindelijk, dat was het!

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!