IBA Verklaart ssh

Al sinds de beginjaren van het internet werden er applicaties gemaakt om in te kunnen loggen op andere computers vanaf je eigen computer. Neem bijvoorbeeld programma’s zoals telnet en rsh (als deze programma’s je niks zeggen, wees gerust, we zullen ze niet behandelen). Echter, de bestaande programma’s hadden niet genoeg beveiliging en waren vatbaar voor bijvoorbeeld wachtwoordsniffers. Daarom besloot Tatu Ylönen in 1995 om een beter programma te maken voor het inloggen op andere computers en hij doopte het programma ‘ssh’ (secure shell). Al vanaf het begin bleek ssh populair en tegenwoordig is het niet meer weg te denken in de wereld van Linux en Macs en wordt het gebruikt om veilig bestanden over te sturen, applicaties op een andere computer te draaien en nog veel meer. Windowsgebruikers moeten zich nog wenden tot andere applicaties om hetzelfde doel te bereiken (denk bijvoorbeeld aan PuTTY) maar Microsoft heeft in 2015 aangekondigd dat het ssh in toekomstige generaties van Windows gaat integreren.

Hoe werkt ssh dan precies, vraag je je misschien af. Laten we eens gaan kijken wat er allemaal gebeurt als je een ssh-connectie probeert op te zetten. Het eerste wat je doet is verbinding maken met de ssh-poort op de ssh-server (meestal poort 22). Op dit moment krijgt de client (dat is de computer vanaf waar je connectie maakt) twee dingen toegestuurd: de protocolversie en de ssh-versie van de server. Als de client het protocol ondersteunt, kunnen ze verder. Op dit moment gaan zowel de client als de server over op een Binair Package Protocol, dat betekent dat de pakketjes die overgestuurd worden nu 32 bits groot zijn. De server stuurt nu zijn publieke sleutel (het publieke deel van de asymmetrische versleuteling, maar dat is weer een verhaal voor een andere keer), 8 willekeurige bits die de client moet terugsturen als antwoord en tenslotte alle soorten encryptie die ondersteund worden. Nu maakt de client een symmetrische sleutel aan en stuurt deze sleutel ook naar de server. Deze sleutel wordt gebruikt om de data die over de ssh gestuurd wordt te versleutelen. Merk natuurlijk wel op dat deze sleutel eerst versleuteld wordt met de publieke sleutel van de server. Ook geeft de client op dit moment aan welke versleutelingsmethode hij gebruikt voor het versleutelen van de data. Als laatste stap wacht de client op een bevestiging van de server. Deze bevestiging is uiteraard versleuteld met de symmetrische sleutel die de client heeft aangemaakt en is belangrijk voor de client; dit is namelijk nu de enige manier om te weten of de client met dezelfde server praat als waar hij net mee heeft gecommuniceerd, dit om zeker te zijn dat er niet iemand is die met alles loopt te rommelen om zo je geheime data te achterhalen. Als dit allemaal goed is gegaan kunnen de client en de server versleuteld en veilig met elkaar babbelen en kan je gaan inloggen op de server.

Dit is natuurlijk een hoop informatie om in 1 keer te bevatten, dus we gaan nu kijken wat er gebeurt als je vanaf thuis bij \aesnaam gaat inloggen. Je probeert dan dus vanaf thuis met poort 22 op de A-Eskwadraatserver te verbinden. Het eerste wat je tegenkomt is de router. De router zorgt voor poortforwarding. Dat houdt in dat de router een lijstje heeft staan met welke poortverbinding hij moet doorsturen naar welke poort op welke machine. Daar staat bijvoorbeeld dat als je op poort 22 probeert te verbinden, de router je doorstuurt naar poort 22 op de ssh-extern-machine van A-Eskwadraat, paul. Vervolgens maak je dus verbinding met poort 22 op paul en treedt het standaard ssh-protocol in werking. In de router staan echter nog meer regels, zo kan je bijvoorbeeld verbinding maken met poort 32022 om op de workstation dennis uit te komen. Probeer het zelf ook eens uit, Linux- en Mac-gebruikers kunnen het commando ssh gebruiken:

ssh [username]@a-eskwadraat.nl -p 32022

Windowsgebruikers kunnen als ze putty gebruiken in putty selecteren met welke poort ze verbinding willen maken.
Natuurlijk wordt de poortforwarding voor veel meer gebruikt dan alleen ssh, denk aan mail of een http-request, maar dat is een verhaal voor een andere keer!

IBA Verklaart Router

Naast de verschillende servers en workstations die A-Eskwadraat heeft is er nog een cruciaal onderdeel binnen het netwerk, de router. De router is de spin in ons netwerk. Hij bepaalt welke diensten beschikbaar zijn en hoe je die kunt benaderen.

Besturingssysteem

Tot voor kort draaide de router binnen ons netwerk op OpenBSD. Hoewel er voordelen zijn om OpenBSD te draaien op een router, te noemen makkelijke firewall configuratie en veiligheid, zijn er ook nadelen. De nadelen zijn onder andere de lastige manier van updaten, wat voor een router van zeer groot belang is. Doordat updaten zeer lastig is komt de veiligheid in het geding, vooral met de vele beveiligingslekken in onder andere SSL de laatste tijd. Daarom zijn we als sysop al langere tijd bezig met een vervangend systeem, dat goed aansluit bij de andere systemen die we gebruiken en dus ook CentOS draait.

Firewall

Binnen besturingssystemen zitten firewalls, deze zijn er om de veiligheid van een netwerk te bewaren. Daarbij is de router de eerste beveiliging tussen de grote boze buitenwereld en het interne netwerk van A-Eskwadraat. OpenBSD heeft een zeer mooie manier om een firewall te configureren, waarbij de configuratie leesbaar is voor de beheerders (pf). Iedere regel beschrijft zeer duidelijk wat er gebeurt. Bij andere systemen is dit over het algemeen lastiger te lezen. Zo ook bij een GNU/Linux systeem, daarbij zijn er vele mogelijkheden om je firewall te configureren. Deze vertalen echter altijd naar regels in iptables die het systeem uitleggen wat er wel en niet door mag naar het interne netwerk. Met het nieuwe systeem maken we gebruik van shorewall (wat voor de oud-sysoppers bekend zou moeten zijn, omdat deze ook op de oude server max gebruikt werd).

Reverse Webproxy

Naast dat het besturingssysteem een probleem begon te worden, waren er ook al langer problemen met enkele van de programma’s die we gebruikten op de router. Een van de belangrijke programma’s op de router is een zogenaamde ‘Reverse Webproxy’, dit is te vergelijken met een webserver die webpagina’s beschikbaar maakt. Hierbij worden de webpagina’s echter niet op de router gemaakt, maar wordt het werk uitbesteed naar andere webservers. Dit heeft als voordeel dat er gebruik gemaakt kan worden van veel verschillende webservers die allemaal hun eigen afgezonderde taak hebben. Bij OpenBSD hadden we voor de Reverse Webproxy een programma genaamd squid. Squid is speciaal ontwikkeld voor gebruik als proxy en heeft als extra optie de mogelijkheid tot reverse proxy. Deze heeft nagenoeg altijd zijn functie goed gedaan, maar door de grote en ingewikkelde configuratie die we gebruikten werd het steeds ingewikkelder om aanpassingen aan de configuratie te doen. Aanpassingen zijn nodig als er een nieuwe website of feature toegevoegd moest worden. Daarnaast begon de beveiliging ook een steeds groter probleem te worden. Hierdoor zijn we voor het nieuwe systeem overgegaan op Nginx, dit is een volwaardige webserver die zeer geschikt is voor gebruik als reverse webproxy. De configuratie heeft ook voordelen, doordat iedere site in zijn eigen bestand opgeslagen kan worden.

15 april 2015

Binnen sysop hadden we besloten dat het tijd werd om het router-migratie-project, wat al langere tijd nagenoeg klaar was, tot een einde te brengen. De router stond al langere tijd klaar om operationeel te gaan, en de voorganger te vervangen. 15 april was het dan eindelijk zo ver en zou de router overgezet worden. Echter zoals vele projecten gaat er wel eens wat mis. Naast de grote hoeveelheid testen die we hebben gedraaid waren er toch nog enkele grote problemen toen we daadwerkelijk het systeem gingen overzetten. Enkele cruciale functies van de firewall werkten niet naar behoren terwijl die tijdens het testen wel werkten. Daardoor is op het laatste moment besloten om alle wijzigingen terug te draaien en de problemen op een later tijdstip op te lossen.

The day after

Een dag later zijn er testen gedaan met een andere manier van firewall configureren. Deze werkte naar behoren waarop besloten werd om nogmaals (vanaf thuis) de router over te zetten. Naast dat dit vanaf thuis een riskante bezigheid is, je zit namelijk van buiten het netwerk het netwerk aan te passen, verliep de overzetting zeer goed. Er waren nog enkele problemen die binnen zeer korte tijd op te lossen waren. Daardoor draait nu het A-Eskwadraat netwerk met de nieuwe router-configuratie en zijn de voordelen zeer duidelijk zichtbaar. Een van de belangrijkere voordelen zijn de betere https-veiligheid (zie bug #5577) en de integratie met de andere sysop-systemen.

*update Technische uitleg te vinden op de A-Eskwadraat wiki