Handleiding Linux server hardening voor mkb

Een VPS die alleen voor een website, webshop of zakelijke applicatie draait, lijkt soms een klein onderdeel van uw IT-omgeving. Toch is deze server vaak rechtstreeks verbonden met klantgegevens, e-mail, bestanden of bedrijfsprocessen. Met een goede handleiding Linux server hardening beperkt u de kans dat een fout wachtwoord, vergeten update of open poort uitgroeit tot een serieus beveiligingsincident.

Hardening betekent niet dat u iedere instelling zo streng mogelijk zet. Het doel is een server die alleen doet wat nodig is, alleen bereikbaar is voor de juiste personen en snel hersteld kan worden als er toch iets gebeurt. Dat vraagt om keuzes die passen bij uw omgeving. Een ontwikkelserver heeft bijvoorbeeld andere toegangsregels nodig dan een productieserver waarop een webshop dag en nacht orders verwerkt.

Begin met overzicht en een herstelplan

Pas geen beveiligingsinstellingen aan zonder eerst vast te leggen wat er op de server draait. Noteer het besturingssysteem, de versie, geïnstalleerde diensten, open poorten, gebruikersaccounts en koppelingen met andere systemen. Denk aan een webserver, database, mailrelay, back-upopslag of externe API. U kunt pas goed beveiligen als duidelijk is welke onderdelen echt nodig zijn.

Maak vervolgens een actuele back-up en controleer of die bruikbaar is. Een back-up die nooit is teruggezet, is een aanname en geen herstelplan. Bewaar minimaal een kopie buiten de server zelf. Bij een VPS is een snapshot handig vóór grotere wijzigingen, maar die vervangt geen zelfstandige back-up. Een snapshot kan immers ook een al besmet systeem bevatten.

Zorg ook voor toegang via de console van uw hostingplatform. Wanneer u SSH verkeerd configureert, kunt u zichzelf buitensluiten. Met consoletoegang kunt u instellingen herstellen zonder afhankelijk te zijn van externe netwerktoegang. Plan wijzigingen bij voorkeur op een rustig moment en voer ze stap voor stap door.

Handleiding Linux server hardening: werk van buiten naar binnen

De meest effectieve aanpak begint bij de netwerkgrens, gevolgd door toegang, software en gegevens. Daarmee verkleint u eerst het aanvalsoppervlak voordat u dieper in de configuratie duikt.

Installeer updates snel en gecontroleerd

Verouderde pakketten vormen een veelvoorkomend risico. Controleer daarom structureel op updates voor het besturingssysteem, de kernel, PHP, databasesoftware en andere gebruikte onderdelen. Op Debian- en Ubuntu-systemen gebruikt u doorgaans `apt update` en `apt upgrade`; op Rocky Linux, AlmaLinux of vergelijkbare distributies is dat vaak `dnf update`.

Automatische beveiligingsupdates zijn voor veel kleine servers een verstandige basis. Wel is controle nodig wanneer uw omgeving afhankelijk is van specifieke versies of maatwerksoftware. Een automatische update die een verouderde plugin of toepassing raakt, kan beschikbaarheid beïnvloeden. Test updates waar mogelijk eerst op een acceptatieomgeving en houd na installatie de belangrijkste diensten in de gaten.

Verwijder bovendien software die niet wordt gebruikt. Een oude FTP-server, testdatabase of vergeten beheerinterface is niet onschuldig omdat deze stil staat. Ieder geïnstalleerd en bereikbaar onderdeel vraagt onderhoud.

Beperk poorten met een firewall

Een server hoeft niet voor het hele internet toegankelijk te zijn. Open alleen de poorten die nodig zijn voor de functie van de server. Voor een publieke website zijn dat meestal HTTP en HTTPS. SSH moet alleen bereikbaar zijn voor beheerders, idealiter vanaf bekende IP-adressen of via een VPN.

Gebruik hiervoor een firewall zoals UFW, nftables of firewalld. Kies één beheerwijze en documenteer de regels. Meerdere tools naast elkaar gebruiken leidt vaak tot onduidelijkheid. Controleer na iedere wijziging vanaf een extern netwerk of de website en beheerverbinding nog werken.

Een praktische basis is: inkomend verkeer standaard weigeren, uitgaand verkeer toestaan en vervolgens alleen noodzakelijke diensten expliciet openen. Heeft een database uitsluitend een lokale webapplicatie nodig, laat de database dan alleen luisteren op `localhost` of op een afgeschermd intern netwerk. Een databasepoort direct op internet openen is zelden nodig.

Maak SSH-toegang streng maar werkbaar

SSH is het beheerluik van uw Linux-server. Dat luik moet goed op slot, zonder dat dagelijks beheer onnodig ingewikkeld wordt. Werk met persoonlijke SSH-sleutels in plaats van alleen wachtwoorden. Een sleutel is moeilijker te raden en u kunt toegang per medewerker intrekken zonder een gedeeld wachtwoord te wijzigen.

Schakel directe root-aanmelding via SSH uit en laat beheerders inloggen met een eigen account dat via `sudo` tijdelijke beheerdersrechten krijgt. Zo is beter te herleiden wie welke actie uitvoerde. Beperk toegang verder met `AllowUsers` of een beheergroep en verwijder accounts van voormalige medewerkers of externe partijen direct.

Voordat u de SSH-configuratie activeert, controleert u deze met `sshd -t`. Houd altijd een bestaande SSH-sessie open terwijl u een tweede sessie gebruikt om de nieuwe instellingen te testen. Pas daarna herstart u de SSH-dienst. Dit kleine ritueel voorkomt veel stress.

Een afwijkende SSH-poort kan geautomatiseerde scans verminderen, maar is geen volwaardige beveiligingsmaatregel. Zie het als ruisreductie, niet als slot op de deur. Sleutels, beperkte bron-IP’s en waar passend multifactor-authenticatie leveren veel meer bescherming op.

Bescherm accounts, rechten en geheimen

Geef gebruikers alleen de rechten die zij voor hun werk nodig hebben. Een webapplicatie heeft bijvoorbeeld geen rootrechten nodig en een ontwikkelaar hoeft niet automatisch toegang te hebben tot productiegegevens. Dit principe van minimale rechten beperkt schade als een account of toepassing wordt misbruikt.

Controleer bestandsrechten van webdirectories, configuratiebestanden en privésleutels. Configuraties met databasewachtwoorden of API-sleutels mogen niet leesbaar zijn voor alle lokale gebruikers. Plaats geheimen niet in broncode, openbare webmappen of shellgeschiedenis. Gebruik waar mogelijk omgevingsvariabelen of een passend secrets-beheerproces.

Sterke, unieke wachtwoorden blijven nodig voor diensten die geen sleutelaanmelding ondersteunen. Bewaar ze in een wachtwoordmanager en vervang inloggegevens onmiddellijk als een medewerker vertrekt, een laptop verloren gaat of er twijfel bestaat over misbruik.

Beveilig de diensten die u werkelijk gebruikt

De basis van serverhardening zit niet alleen in Linux zelf. Een bijgewerkte server blijft kwetsbaar wanneer de webapplicatie, het CMS of de database slecht is ingesteld. Houd WordPress, plugins, thema’s en andere applicaties actueel. Verwijder ongebruikte extensies en testaccounts, vooral als die beheerdersrechten hebben.

Gebruik HTTPS voor publieke diensten en vernieuw certificaten op tijd. Stel voor webapplicaties beveiligingsheaders in waar dat past en voorkom dat directory listings, foutmeldingen of beheerpagina’s onnodige informatie prijsgeven. Laat PHP of andere runtimes niet meer rechten krijgen dan noodzakelijk.

Bij databases geldt hetzelfde uitgangspunt: gebruik aparte accounts per toepassing, geef alleen vereiste rechten en sta externe verbindingen uitsluitend toe wanneer daar een duidelijke reden voor is. Een account dat alleen gegevens uit één database hoeft te lezen, hoeft geen databases te kunnen verwijderen of nieuwe gebruikers te kunnen aanmaken.

Detecteer problemen voordat ze schade veroorzaken

Hardening is geen eenmalige klus. Nieuwe kwetsbaarheden, gewijzigde toepassingen en nieuwe medewerkers veranderen uw risico voortdurend. Monitoring en logcontrole horen daarom bij de dagelijkse praktijk, zeker bij systemen die omzet of bereikbaarheid ondersteunen.

Controleer minimaal de beschikbare schijfruimte, belasting van CPU en geheugen, back-upstatus, mislukte inlogpogingen en bereikbaarheid van cruciale diensten. Te weinig schijfruimte kan databases, logging en back-ups tegelijk verstoren. Een plotselinge piek in uitgaand verkeer kan wijzen op misbruik, maar soms ook op een legitieme campagne. Context blijft nodig.

Tools zoals Fail2ban kunnen herhaalde mislukte inlogpogingen tijdelijk blokkeren. Dat helpt tegen eenvoudige brute-force-aanvallen, maar vervangt geen goede toegangsinstellingen. Bewaar logs lang genoeg voor onderzoek en zorg dat een aanvaller ze niet eenvoudig kan verwijderen door logbestanden naar een externe locatie of centrale logging te sturen.

Leg ook vast wie gebeld of geïnformeerd wordt bij een storing of beveiligingsmelding. Voor een zzp’er kan dat één persoon zijn; voor een mkb-team zijn duidelijke verantwoordelijkheden nodig. Techniek werkt beter wanneer eigenaarschap vooraf geregeld is.

Test herstel, niet alleen beveiliging

De vraag is niet alleen of een aanval wordt tegengehouden, maar ook hoe snel u weer operationeel bent als dat niet lukt. Oefen daarom ten minste periodiek het terugzetten van bestanden, databases en een volledige serverback-up. Controleer daarna of de applicatie functioneert, gebruikers kunnen inloggen en gegevens actueel zijn.

Bij een webshop kan een herstelpunt van gisteren technisch correct zijn, maar toch betekenen dat recente bestellingen of voorraadwijzigingen opnieuw moeten worden verwerkt. Bepaal daarom vooraf hoeveel dataverlies acceptabel is en hoe lang uitval mag duren. Die afspraken bepalen hoe vaak u back-upt, hoeveel kopieën u bewaart en of hoge beschikbaarheid nodig is.

Wie geen interne beheerder heeft, hoeft deze controles niet zelf tussen andere werkzaamheden door te doen. DeltaServ kan helpen met beheerde VPS-omgevingen, monitoring, back-ups en een vast technisch aanspreekpunt dat uw omgeving kent. Zo blijft beveiliging geen losse taak op een lange actielijst, maar een onderdeel van continuïteit.

De beste volgende stap is eenvoudig: kies deze week één server, maak een actuele inventarisatie en controleer toegang, updates en herstelbaarheid. Daarmee maakt u direct zichtbaar waar uw grootste risico zit – en waar gerichte aandacht het meeste oplevert.