Direct naar de inhoud

Cookie-instellingen

Kies per soort welke cookies je toestaat. Je kunt je keuze altijd wijzigen via Cookie-instellingen onderaan elke pagina. Privacyverklaring

Noodzakelijk

Altijd aan

Nodig om in te loggen, je winkelwagen te bewaren en je keuzes te onthouden. Deze staan altijd aan.

Welke cookies?
  • weboke_sessie, weboke_klant, weboke_remember: je sessie en ingelogd blijven
  • weboke_basket: je winkelwagen
  • wkBtwIncl: prijzen met of zonder btw tonen
  • wok_cookies: je cookiekeuze, 12 maanden

Meet welke advertentie tot een bezoek of bestelling leidt, zodat we niet betalen voor advertenties die niets doen.

Welke cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), tot 90 dagen
  • OpenAI Ads, advertenties in ChatGPT
  • wok_aff: via welke partner je bij ons kwam (affiliateprogramma), 60 dagen

4,6

Land en taal

Elk land heeft zijn eigen site, met prijzen en btw van dat land.

Bekijken

Module 3 · 3.2

sudo en minimale rechten

Module 3: Gebruikers, rechten en sudo · Leestijd: 11 minuten

Leerdoel: Na deze les kun je werken als gewone gebruiker met sudo, een beheerder veilig toevoegen, de sudo-instellingen wijzigen zonder jezelf buiten te sluiten, en uitleggen waarom minimale rechten je server beschermen.

Kernbegrippen: sudo, groep sudo, groep wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, root vergrendelen, logboek van sudo, minimale rechten (least privilege), dienstgebruiker

Waarom niet gewoon als root werken?

Na de installatie log je vaak in als root. Dat is makkelijk: alles mag. Maar precies dat is het probleem:

  • Eén tikfout is genoeg. rm -rf / home/anna/oud (let op de spatie na de eerste slash) wist als root je hele server. Als gewone gebruiker krijg je een foutmelding.
  • Alles draait als root. Een script dat je van internet plakt, een programma dat je test: alles krijgt volledige rechten.
  • Geen spoor. Werken drie mensen als root, dan weet niemand achteraf wie wat deed.
  • Root is de naam die elke aanvaller probeert. Inloggen als root kun je beter helemaal uitzetten (les 2.2), maar dat kan pas als je een andere weg naar beheerrechten hebt.

Die andere weg is sudo: je logt in als jezelf en zet alleen vóór een commando dat beheerrechten nodig heeft sudo.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Ubuntu gebruikt sinds versie 25.10 standaard sudo-rs, een nieuwe uitvoering van sudo. Voor alles in deze les werkt die hetzelfde.)

sudo vraagt om jouw wachtwoord, niet dat van root. Daarna onthoudt het dat standaard een kwartier, zodat je niet bij elk commando opnieuw hoeft. Elk commando dat je met sudo uitvoert, komt in het logboek.

Een beheerder maken

Op Debian en Ubuntu mag iedereen in de groep sudo alles via sudo. Dat staat in /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Lees dat als: leden van de groep sudo (%) mogen op alle machines (ALL) als elke gebruiker en groep ((ALL:ALL)) elk commando (ALL) uitvoeren.

Een beheerder toevoegen gaat dus in twee stappen, als root:

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

Zet daarna Anna's publieke sleutel in /home/anna/.ssh/authorized_keys met de juiste eigenaar en rechten:

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

Vergeet de chown niet: gekopieerd door root is het bestand van root, en dan kan Anna niet inloggen met haar sleutel.

Test nu, terwijl je root-sessie open blijft, in een tweede venster:

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Pas als dit werkt, zet je in je SSH-instellingen PermitRootLogin no (les 2.2). Vanaf dan log je altijd in als Anna.

Een ding om te onthouden: Anna heeft nu een wachtwoord nodig voor sudo. Bewaar het in je wachtwoordmanager. Inloggen gaat met de sleutel, sudo met het wachtwoord: twee verschillende dingen die een inbreker allebei moet hebben.

sudo-instellingen wijzigen: altijd met visudo

Een fout in /etc/sudoers kan betekenen dat sudo helemaal niet meer werkt. Als root ook niet kan inloggen, zit je vast. Daarom bewerk je sudo-instellingen nooit met een gewone editor, maar met visudo. Dat opent een tijdelijke kopie en controleert de inhoud voordat het opslaat:

root@web1:~# visudo -f /etc/sudoers.d/backup

Gebruik net als bij SSH liever een eigen bestand in /etc/sudoers.d/ dan het hoofdbestand. Let op twee regels van die map:

  • Bestanden waarvan de naam een punt bevat of op ~ eindigt, worden overgeslagen. backup.conf werkt dus niet, backup wel. Dat is bedoeld om kopieën van editors te negeren, maar het verrast veel mensen.
  • Het bestand moet van root zijn en voor anderen niet schrijfbaar (440 is gebruikelijk; visudo regelt dat).

Wil je een bestaand bestand controleren zonder te bewerken: visudo -c controleert alles.

NOPASSWD: handig, maar weet wat je doet

Met NOPASSWD vraagt sudo geen wachtwoord meer:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Sommige VPS-images zetten dit voor de standaardgebruiker, zodat je na het inloggen met een sleutel meteen beheerder bent. Kijk met sudo -l wat er bij jou geldt. Het gevolg: wie Anna's sleutel heeft, is meteen root. Er zit geen tweede slot meer op. Voor een persoonlijke server kun je daarvoor kiezen, maar doe het bewust.

Veel beter is NOPASSWD alleen voor één bepaald commando, bijvoorbeeld voor een back-upscript dat automatisch moet kunnen draaien:

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

De gebruiker backup mag dan precies dat ene script als root draaien, zonder wachtwoord, en verder niets. Twee valkuilen:

  • Gebruik altijd het volledige pad. Met alleen maak-backup kan iemand een eigen programma met die naam vooraan in zijn pad zetten.
  • Het script zelf mag niet schrijfbaar zijn voor die gebruiker. Anders past hij het aan en draait dan willekeurige commando's als root. Hetzelfde geldt voor commando's die zelf een shell kunnen openen, zoals een editor (vim, nano) of less: wie die via sudo mag starten, kan vanuit het programma een rootshell openen. Geef zulke commando's nooit los via sudo.

Wat er gelogd wordt

Elke keer dat iemand sudo gebruikt, komt er een regel in de journal (en op systemen met rsyslog ook in /var/log/auth.log):

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Je ziet wie, waar, als wie en welk commando. Dat is een van de redenen om niet met meerdere mensen als root te werken. Mislukte sudo-pogingen ("incorrect password attempts") van een account dat jij niet bent, zijn een alarmsignaal.

Minimale rechten in het groot

sudo is één toepassing van een algemeen principe: minimale rechten (least privilege). Elke gebruiker en elke dienst krijgt precies de rechten die nodig zijn, en niet meer. Op een server betekent dat onder andere:

  • je werkt als gewone gebruiker en gebruikt sudo alleen als het nodig is;
  • elke dienst draait onder een eigen gebruiker zonder shell (les 3.1), niet als root;
  • een webapplicatie krijgt een databasegebruiker die alleen zijn eigen database mag gebruiken, niet de beheerder van de databaseserver;
  • een back-upscript mag alleen het ene commando dat het nodig heeft (NOPASSWD met volledig pad);
  • een collega die alleen de website bijwerkt, krijgt schrijfrecht op /var/www/example.com via een groep, niet sudo.

Het idee: gaat er iets mis (een lek in een plugin, een gestolen sleutel), dan blijft de schade beperkt tot die ene gebruiker of dienst. In de CIS-principes en de hardeningles (10.1) komt dit steeds terug.

Op AlmaLinux en Rocky Linux

Daar heet de beheerdersgroep wheel in plaats van sudo: usermod -aG wheel anna. De regel in /etc/sudoers is %wheel ALL=(ALL) ALL. visudo en /etc/sudoers.d werken hetzelfde. Sudo-meldingen staan daar ook in /var/log/secure.

Samenvatting

  • Werk als gewone gebruiker en gebruik sudo voor beheer; sudo vraagt je eigen wachtwoord en logt elk commando.
  • Een beheerder maken: adduser anna, adduser anna sudo (wheel op RHEL-achtigen), sleutel met juiste eigenaar en rechten, testen in een tweede venster, pas dan root-login uit.
  • Bewerk sudo-regels alleen met visudo, liefst in een eigen bestand in /etc/sudoers.d/ zonder punt in de naam.
  • NOPASSWD voor alles haalt een slot weg; gebruik het liever alleen voor één commando met volledig pad dat de gebruiker niet kan wijzigen.
  • Minimale rechten: elke gebruiker en dienst krijgt precies wat nodig is, zodat een fout of lek klein blijft.

Quiz

1. Om welk wachtwoord vraagt sudo standaard als Anna sudo apt update typt?



2. Je maakt het bestand /etc/sudoers.d/backup.conf met een geldige regel, maar hij werkt niet. Waarom?



3. Waarom bewerk je sudo-regels met visudo?



4. Welke regel geeft een back-upgebruiker het kleinste risico?



5. In welke volgorde zet je root-login uit zonder jezelf buiten te sluiten?



Opdracht

Opdracht O3.2: Een beheerder met sudo. Maak op je server een gewone beheerder (bijvoorbeeld anna), zet je sleutel goed, test inloggen en sudo -l in een tweede venster, en zet daarna root-login via SSH uit (PermitRootLogin no). Vink de stappen af, plak de uitvoer van id (alleen naam en groepen) en beantwoord de vragen: welke regel geeft je beheerder rechten, staat er ergens NOPASSWD, en hoe kom je binnen als je je wachtwoord vergeet?

Opdracht O3.2: Een beheerder met sudo

Deze opdracht doe je zelf; niemand kijkt hem na. Vink af wat je gedaan hebt en markeer de opdracht als gedaan.




Je vinkjes en aantekeningen blijven alleen in deze browser; we sturen ze nergens heen. Ben je aangemeld, dan bewaren we in Mijn cursussen alleen dat je de opdracht gedaan hebt.

Verder lezen

De stappen in deze artikelen gelden voor de VPS'en van WebOké; bij andere aanbieders werkt het vergelijkbaar.

Even geduld…

Stel je domeinen in

Regel per domein de nameservers, de koppeling aan je hosting en wie de eigenaar wordt.

Je domeinen laden…