Voorwoord
In deze blogpost zal ik verschillende methodes van het uitbuiten van beveiligingslekken beschrijven. Dit is in geen enkele mate toestemming om deze injecties, uitbuitingen en hacks uit te voeren en dient enkel als voorbeeld om het idee van beveiliging te onderbouwen. Om deze reden ga ik niet heel diep in op de hacking onderdelen en meer in op het idee van beveiliging.
Deze blogpost is de eerste van een vier-delige reeks aan blogposts over de beveiliging van webapplicaties, vanuit het oog van een docent. Veel leesplezier!
Inleiding
Als laatste is het het kopje “Server beveiliging”, waar ik wat generieke onderdelen wil behandelen omtrent het instellen van een (web) server. Ik zal het opstellen van een server niet gaan behandelen, enkel de beveiliging ervan, daarom ga ik meteen door naar het kopje “Beveiliging”.
Beveiliging
Logging
Een heel belangrijke tool voor programmeurs en server beheerders is het gebruik van verschillende logs. Niet alleen voor het opsporen van fouten zijn logs handig, maar ook onder het mom van beveiliging. Access logs zijn logs die laten zien wie er met welk apparaat, browser en eventueel IP adres de website bezoekt op welke URL. Error logs laten vervolgens zien welke fouten er worden gegenereerd. De logs kunnen vervolgens worden gebruikt om patronen te herkennen. Wanneer een website met de TLD “.nl” in een span van een half uur duizend keer wordt bezocht door gebruikers uit Rusland, is dat opvallend. Wanneer deze gebruikers ongebruikelijke URL’s gebruiken (bijvoorbeeld website.nl/admin of website.nl/backend), dan zegt dat al veel. Dit betekent waarschijnlijk mensen pogingen doen om jouw website te hacken en is het misschien tijd om bijvoorbeeld IP adressen te blacklisten (te blokkeren om jouw website te bezoeken) of een extra kijkje te nemen in de beveiligingsinstellingen, om zeker te zijn dat deze goed staan.
Updaten
Een server bevat vaak verschillende functionaliteiten en programma’s (waaronder dus een webserver zoals Apache of Nginx) die zo nu en dan updates hebben. Daarnaast draait de server op een besturingssysteem die ook updates heeft. Het updaten van het systeem, de software en eventueel het gebruikte framework of de gebruikte plugins voor het framework zorgen ervoor dat de nieuw bekende beveiligingslekken worden opgelost voor deze systemen. Derde partijen werken over het algemeen hard om lekken te dichten en brengen deze ontwikkelingen uit middels updates.
Daarom is het belangrijk om regelmatig te updaten en dit proces misschien wel (gedeeltelijk) automatisch te laten gaan.
SSL
Een website wordt getoond via een protocol, waar HTTP en HTTPS het meeste voorkomt. HTTPS is eigenlijk de Secure (veilige) variant van HTTP en om dit protocol aan te bieden aan gebruikers moet er een SSL certificaat aanwezig zijn. Dit certificaat is er in verschillende gradaties en prijzen. Vaak is het zo, dat hoe hoger de prijs van een certificaat is, des te betrouwbaarder de informatie is die met het certificaat mee komt. Een SSL certificaat kan op meerdere manieren worden toegepast, een veelgebruikte methode is via
Let’s Encrypt.
Het genereert een certificaat die door de gebruiker te zien is door op het protocol in de adresbalk te drukken en het certificaat te tonen, zoals in de afbeelding hiernaast te zien is. Het certificaat is hier een maand geldig en wordt via automatisering elke maand ververst.
Gebruikers en permissies
De gemiddelde web server is opgesteld op een linux besturingssysteem. Om die reden zal ik hier enkel het gebruikers en permissies onderdeel behandelen op linux besturingssystemen. Linux werkt op het permissie level met gebruikers en groepen. Gebruikers worden toegewezen aan groepen en groepen krijgen RWX (Read, Write, Execute (lees, schrijf, uitvoer)) permissions per eigenaar, groep en overige. Dit wordt weergegeven met een cijfer, gerekend vanuit binair. Als we kijken naar RWX, kunnen we bij elke letter een 1 of 0 zetten waar er wel of geen permissie is. In een tabel is dit het makkelijkst te tonen:
Stel, de beherende groep die mag lezen en schrijven, maar niet mag uitvoeren. De rechten zien er dan als volgt uit:
| Read |
Write |
eXecute |
| r |
w |
- |
| 1 |
1 |
0 |
Dus, de rechten zijn rw-, wat gelijk staat aan 110 in binair. Omgerekend naar decimaal vormt dat:
110 = 4 + 2 + 0 = 6
Alleen, deze instelling hebben alleen voor de beherende groep. We hebben ook nog de eigenaar van de map en de overige gebruikers. Deze drie onderdelen vormen samen de permissie die een map kan hebben. Stel, we geven de eigenaar alle rechten, we behouden de rechten van de beherende groep zoals hierboven en de andere gebruikers mogen enkel lezen. Dan ziet dit er als volgt uit:
| Type |
Permissie |
Decimale waarde |
| Eigenaar |
rwx |
7 |
| Beherende groep |
rw- |
6 |
| Overig |
r-- |
4 |
In totaal hebben we dus voor deze map de volgende rechten, waar we beginnen met een “d”. Dit geeft aan dat hem om permissies gaat:
drwxrw-r--
In binaire waarde staat dit dus gelijk aan 764. Om deze permissie toe te passen op een map, kunnen we het linux commando “chmod” als volgt gebruiken:
chmod 764 MAPNAAM
Het is dus belangrijk goed na te denken over deze permissies en de gebruikers die je hebt op de webserver. Aangezien de webserver zelf een gebruiker nodig heeft om toegang te krijgen tot bepaalde bestanden, is het goed om een aparte gebruiker te maken voor het proces en deze de juiste rechten te geven. Bij de installatie van een webserver gebeurt dit vaak al (deels) automatisch, maar het is altijd goed om de installatiehandleiding van de webserver door te lezen.
SSH
Om toegang te krijgen tot een webserver zijn er verscheidene manieren. Je logt bij een webserver in met een gebruiker en kunt daarom kiezen om een wachtwoord te gebruiken. Dit is echter niet de meest veilige manier om in een webserver te komen. Vaak wordt er gekozen om SSH te gebruiken, waar je middels een zogenaamde keypairs toegang kunt krijgen. Dit betekent dat je via een SSH programma twee sleutels genereert. Dit zijn gehashte tekstbestanden met een unieke ID die samen jouw identiteit vormen.
De twee sleutels die worden gegenereerd zijn de private en public key. De public key deel je met de instanties waar je SSH verbindingen mee wilt creëren. De private key hou jij voor jezelf en dit is de sleutel die wordt gecontroleerd wanneer jij verbindt met de instantie. Als de aanwezige public key overeenkomt met jouw private key, krijg je toegang.
Lesvoorbereidingsformulier
Lijkt je het leuk om hier een les in geven maar heb je geen idee hoe je moet beginnen? Dan kun je altijd dit lesvoorbereidingsformulier gebruiken die is gemaakt voor 1e jaars studenten van de MBO opleiding Software Development. Al het geschreven materiaal is Open-Source en vrij om te gebruiken.
Lesvoorbereidingsformulier
