Met SSH en TELNET kunt u beide verbinding maken met externe netwerkcomputers en deze gebruiken alsof u er zelf voor zit. Dus wat is het verschil tussen deze twee eerbiedwaardige protocollen, en is er echt altijd een voordeel aan het gebruik van SSH boven TELNET?
TELNET en SSH: het oorsprongsverhaal
Noodzaak is de moeder van de vindingrijkheid. Systeembeheerders hadden een manier nodig om toegang te krijgen tot en computers te beheren die zich fysiek elders bevonden. Als het voor de beheerder onpraktisch of onhandig was om voor de computer te gaan staan, hadden ze een manier nodig om toegang te krijgen tot de externe computer waarmee ze opdrachten konden geven alsof ze die in die computer typten.
TELNET, afkorting van teltyp voorbij nettowerkprotocol, werd in 1969 ontwikkeld als antwoord op dat probleem. Zolang de externe computer via het netwerk toegankelijk was, kon de beheerder of een andere geautoriseerde persoon er verbinding mee maken en deze gebruiken alsof ze fysiek op de toetsen van het externe toetsenbord drukten.
SSH is pas veel later ontstaan - in 1995 – als directe reactie op Telnet en andere soortgelijke oplossingen. De noodzaak deze keer was beveiliging. TELNET, rlogin, FTP en andere protocollen uit die tijd zijn ontworpen zonder enige aandacht voor, of waargenomen behoefte aan, beveiliging.
SSH staat voor Sveilig schell, zodat u kunt zien dat beveiliging vanaf het begin een leidend principe was. Tegenwoordig heeft SSH bijna volledig TELNET vervangen.
TELNET is een beveiligingsnachtmerrie in platte tekst
Het grote probleem met TELNET is dat het platte tekst gebruikt. Het versleutelt geen van zijn verkeer, inclusief gebruikersnamen en wachtwoorden. Alles wat het over het netwerk verzendt, kan met het grootste gemak worden opgevangen door packet sniffing en gelezen. Dit is zelfs op een lokaal netwerk een beveiligingsrisico, tenzij u de enige gebruiker bent. Elke gebruiker kan TELNET-verkeer onderscheppen en inloggegevens verkrijgen waar hij geen recht op heeft.
Als de externe computer zich op een externe locatie bevindt en er een verbinding via internet nodig is om deze te bereiken, wordt het probleem enorm vergroot. TELNET was een product van zijn tijd, en om eerlijk te zijn, hadden de auteurs vrijwel zeker niet verwacht dat mensen het meer dan vijftig jaar later zouden gebruiken, in het totaal andere IT-landschap van vandaag.
Hoewel TELNET zijn plaats verdient op de lijst van belangrijke programma’s die ons collectief hebben geholpen om te komen waar we nu zijn, is het niet iets dat we nog steeds zouden moeten gebruiken in de wereld van vandaag.
Hoe verschilt SSH van TELNET?
Op het eerste gezicht zijn TELNET en SSH twee antwoorden op hetzelfde probleem. Ze geven je allebei toegang tot een terminalvenster op een externe computer en geven er opdrachten aan. Maar omdat SSH zoveel later werd ontwikkeld dan TELNET, werd het probleem grondiger begrepen en was het antwoord beter ontwikkeld.
TELNET is ontworpen met privaat netwerken in gedachten, maar SSH is ontworpen om ermee om te gaan openbaar netwerken en de noodzaak om privacy en veiligheid te behouden bij het overdragen van gegevens en het maken van verbindingen op afstand.
TELNET gebruikt poort 23 en dat poortnummer kan niet worden gewijzigd. SSH gebruikt standaard poort 22, maar dit kan worden geconfigureerd en gewijzigd. Het configureren van SSH om een niet voor de hand liggend poortnummer te gebruiken, maakt het moeilijker voor aanvallers om de SSH-poort te identificeren. Als de SSH-poort kan worden geïdentificeerd, is het een triviale zaak om een brute-force-aanval uit te voeren waarbij duizenden wachtwoorden die zijn verkregen uit datalekken beurtelings worden uitgeprobeerd door geautomatiseerde software.
Sterker nog, SSH kan helemaal afzien van wachtwoorden. Het kan codering met openbare sleutels gebruiken om zich te authenticeren bij externe computers. Wachtwoorden worden helemaal nooit verzonden, omdat het niet nodig is om ze naar de externe computer te sturen. Dankzij de gegevensversleuteling en SSH-sleutelauthenticatie kan SSH veilige verbindingen en communicatie leveren via onveilige netwerken zoals internet.
SSH kan zelfs worden gebruikt om te authenticeren met verschillende services, niet alleen externe computers met een SSH-server. U kunt bijvoorbeeld toegang krijgen tot de door GitHub, GitLab en BitBucket gehoste Git-opslagplaatsen met behulp van SSH in plaats van wachtwoorden.
Een ander voordeel van het gebruik van SSH boven TELNET is dat SSH reverse SSH-tunneling kan uitvoeren. Hiervoor moet de server een verbinding tot stand brengen met de clientcomputer. Totdat de lokale gebruiker een verbinding met de server wil maken, wordt de verbinding genegeerd.
Wanneer de client verbinding wil maken met de server, brengt de gebruiker een SSH-verbinding tot stand met zijn eigen computer. SSH stuurt de verbinding via de reeds tot stand gebrachte verbinding naar de server. Dit zorgt voor een privétunnel binnen de reeds versleutelde verbinding van de server naar de client.
De enige winst voor TELNET is dat het minder bandbreedte gebruikt. Maar dit is niet het jaar 1969 waarin bandbreedte schaars was, en SSH is ook niet bepaald een bandbreedtevreter.
SSH heeft ook zijn problemen gehad
Hoewel SSH TELNET overtreft als het gaat om beveiliging, moeten we niet vergeten dat het nog steeds software is en dat software bugs kan bevatten. Die bugs kunnen leiden tot kwetsbaarheden die kunnen worden uitgebuit door cybercriminelen. Ook veranderen coderingsstandaarden en algoritmen in de loop van de tijd en worden ze vervangen. Zoals alle op codering gebaseerde software, kunnen oudere SSH-versies minder veilig worden. Daarom is het belangrijk om ervoor te zorgen dat je de laatste versie van SSH gebruikt.
De versie van SSH die op de meeste Linux-computers wordt gebruikt, is OpenSSH, een implementatie van SSH die voortbouwt op de OpenSSL-toolkit en bibliotheken. In 2012 introduceerde de OpenSSL-bibliotheek per ongeluk een bug waardoor een aanvaller een antwoord van de SSL-server kon vragen en kon specificeren hoeveel gegevens het antwoord moest bevatten.
Ze zouden een antwoord van (zeg maar) 64 KB kunnen vragen, terwijl het werkelijke antwoord niet meer dan 64 bytes nodig zou hebben gehad. De eerste reeks bytes in die gegevens zou het echte, verwachte antwoord zijn, gevolgd door wat er toevallig in het geheugen zat dat onlangs door OpenSSL werd gebruikt. Wat er in die gegevens stond, was geluk, maar het kon gevoelige informatie bevatten, zoals sessiecookies en wachtwoorden, of andere informatie waarmee een aanvaller bijvoorbeeld privésleutels kon bemachtigen.
Nadat het in 2014 was ontdekt, werd het beveiligingslek bekend als Heartbleed. Het was snel opgelost in de software. De kwetsbaarheid verdwijnt op dat moment echter niet. De kwetsbaarheid is pas volledig opgeheven als op alle computers waarop de kwetsbare software draait de vaste versie is geïnstalleerd. Met andere woorden, wanneer de computers zijn geweest gepatcht. Omdat veel beheerders traag reageerden, verliep de acceptatie van de vaste software traag.
Ook verontrustend zijn de twee jaar tussen 2012 toen de bug werd geïntroduceerd en 2014 toen deze werd ontdekt en verholpen. Gedurende die twee jaar liep elke SSH-server met de kwetsbare versie van OpenSSL gevaar.
Om eerlijk te zijn, dat gebeurde bijna tien jaar geleden en sindsdien zijn er veel releases, verbeteringen, bugfixes en codereviews geweest.
Moet u SSH of TELNET gebruiken?
Het is moeilijk om een reden te bedenken waarom u vandaag TELNET zou moeten gebruiken. Dat is niet hetzelfde als zeggen dat er een scenario is waarin het veilig is om TELNET te gebruiken. In een op zichzelf staand netwerk dat niet is verbonden met de buitenwereld, en je weet zeker dat niemand je verkeer gaat opsnuiven, zou je TELNET kunnen gebruiken. Maar daar is geen reden toe. De veiligheidsafweging kan niet worden gerechtvaardigd.
SSH is veiliger en flexibeler – dat is het voordeel van het gebruik van SSH boven TELNET. De OpenSSH-implementatie is gratis voor alle toepassingen, inclusief commercieel, en is beschikbaar voor alle populaire besturingssystemen.
