Gå til innholdet

Cookie-innstillinger

Velg hvilke typer cookies du tillater. Du kan når som helst endre valget via Cookie-innstillinger nederst på hver side. Personvernerklæring

Nødvendige

Alltid på

Trengs for å logge inn, beholde handlekurven og huske valgene dine. Disse er alltid på.

Hvilke cookies?
  • weboke_sessie, weboke_klant, weboke_remember: økten din og at du forblir innlogget
  • weboke_basket: handlekurven din
  • wkBtwIncl: visning av priser med eller uten mva.
  • wok_cookies: cookievalget ditt, 12 måneder

Måler hvilken annonse som fører til et besøk eller en bestilling, slik at vi ikke betaler for annonser som ikke gir noe.

Hvilke cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), opptil 90 dager
  • OpenAI Ads, annonser i ChatGPT
  • wok_aff: hvilken partner som henviste deg til oss (partnerprogram), 60 dager

4,6

Land og språk

Hvert land har sin egen nettside, med priser og mva. for det landet.

Vis

sudo og minimale rettigheter

Modul 3: Brukere, rettigheter og sudo · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du jobbe som vanlig bruker med sudo, legge til en administrator på en trygg måte, endre sudo-innstillingene uten å stenge deg selv ute og forklare hvorfor minimale rettigheter beskytter serveren din.

Nøkkelbegreper: sudo, gruppen sudo, gruppen wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, låse root, sudo-loggen, minimale rettigheter (least privilege), tjenestebruker

Hvorfor ikke bare jobbe som root?

Etter installasjonen logger du ofte inn som root. Det er enkelt: alt er lov. Men det er nettopp det som er problemet:

  • Én skrivefeil er nok. rm -rf / home/anna/oud (legg merke til mellomrommet etter den første skråstreken) sletter hele serveren din som root. Som vanlig bruker får du en feilmelding.
  • Alt kjører som root. Et skript du limer inn fra internett, et program du tester: alt får fulle rettigheter.
  • Ingen spor. Jobber tre personer som root, vet ingen i ettertid hvem som gjorde hva.
  • Root er navnet alle angripere prøver. Innlogging som root bør du helst slå helt av (leksjon 2.2), men det kan du først gjøre når du har en annen vei til administratorrettigheter.

Den andre veien er sudo: du logger inn som deg selv og setter sudo bare foran en kommando som trenger administratorrettigheter.

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 bruker siden versjon 25.10 sudo-rs som standard, en ny implementasjon av sudo. For alt i denne leksjonen fungerer den på samme måte.)

sudo ber om ditt passord, ikke passordet til root. Deretter husker den det i et kvarter som standard, slik at du ikke må skrive det inn for hver kommando. Hver kommando du kjører med sudo, havner i loggen.

Lag en administrator

På Debian og Ubuntu kan alle i gruppen sudo gjøre alt via sudo. Det står i /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Les det slik: medlemmer av gruppen sudo (%) kan på alle maskiner (ALL) som hvilken som helst bruker og gruppe ((ALL:ALL)) kjøre hvilken som helst kommando (ALL).

Å legge til en administrator gjøres altså i to trinn, som root:

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

Legg deretter Annas offentlige nøkkel i /home/anna/.ssh/authorized_keys med riktig eier og riktige rettigheter:

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

Ikke glem chown: når root kopierer filen, eies den av root, og da kan ikke Anna logge inn med nøkkelen sin.

Test nå i et nytt vindu, mens root-økten din fortsatt er åpen:

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

Først når dette fungerer, setter du PermitRootLogin no i SSH-innstillingene (leksjon 2.2). Fra da av logger du alltid inn som Anna.

En ting å huske på: Anna trenger nå et passord for sudo. Lagre det i passordbehandleren din. Innlogging skjer med nøkkelen, sudo med passordet: to forskjellige ting som en inntrenger må ha begge av.

Endre sudo-innstillinger: alltid med visudo

En feil i /etc/sudoers kan føre til at sudo slutter å virke helt. Kan root heller ikke logge inn, sitter du fast. Derfor redigerer du aldri sudo-innstillinger med en vanlig editor, men med visudo. Det åpner en midlertidig kopi og kontrollerer innholdet før det lagrer:

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

Akkurat som med SSH er det bedre å bruke en egen fil i /etc/sudoers.d/ enn hovedfilen. Legg merke til to regler for denne mappen:

  • Filer der navnet inneholder et punktum eller slutter på ~, hoppes over. backup.conf fungerer altså ikke, men backup gjør det. Dette er ment for å ignorere kopier fra editorer, men det overrasker mange.
  • Filen må eies av root og ikke være skrivbar for andre (440 er vanlig; visudo ordner det).

Vil du kontrollere en eksisterende fil uten å redigere den: visudo -c kontrollerer alt.

NOPASSWD: praktisk, men vit hva du gjør

Med NOPASSWD ber sudo ikke lenger om passord:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Noen VPS-images setter dette for standardbrukeren, slik at du er administrator med en gang etter at du har logget inn med en nøkkel. Sjekk med sudo -l hva som gjelder hos deg. Konsekvensen: den som har Annas nøkkel, er root med en gang. Det finnes ingen ekstra lås. For en personlig server kan du velge det, men gjør det bevisst.

Mye bedre er NOPASSWD bare for én bestemt kommando, for eksempel et sikkerhetskopiskript som skal kunne kjøre automatisk:

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

Brukeren backup kan da kjøre akkurat det ene skriptet som root, uten passord, og ingenting annet. To fallgruver:

  • Bruk alltid den fullstendige stien. Med bare maak-backup kan noen legge et eget program med det navnet først i stien sin.
  • Selve skriptet må ikke være skrivbart for den brukeren. Ellers kan han endre det og deretter kjøre vilkårlige kommandoer som root. Det samme gjelder kommandoer som selv kan åpne et skall, som en editor (vim, nano) eller less: den som kan starte dem via sudo, kan åpne et root-skall fra programmet. Gi aldri slike kommandoer enkeltvis via sudo.

Hva som logges

Hver gang noen bruker sudo, havner det en linje i journalen (og på systemer med rsyslog også i /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

Du ser hvem, hvor, som hvem og hvilken kommando. Det er en av grunnene til ikke å jobbe flere personer som root. Mislykkede sudo-forsøk ("incorrect password attempts", altså feil passord) fra en konto som ikke er din, er et varseltegn.

Minimale rettigheter i større skala

sudo er én anvendelse av et generelt prinsipp: minimale rettigheter (least privilege). Hver bruker og hver tjeneste får akkurat de rettighetene som trengs, og ikke mer. På en server betyr det blant annet:

  • du jobber som vanlig bruker og bruker sudo bare når det trengs;
  • hver tjeneste kjører under en egen bruker uten skall (leksjon 3.1), ikke som root;
  • en webapplikasjon får en databasebruker som bare kan bruke sin egen database, ikke administratoren av databaseserveren;
  • et sikkerhetskopiskript får bare den ene kommandoen det trenger (NOPASSWD med fullstendig sti);
  • en kollega som bare oppdaterer nettstedet, får skriverett til /var/www/example.com via en gruppe, ikke sudo.

Tanken er: går noe galt (et sikkerhetshull i en plugin, en stjålet nøkkel), begrenses skaden til den ene brukeren eller tjenesten. I CIS-prinsippene og hardening-leksjonen (10.1) kommer dette stadig tilbake.

På AlmaLinux og Rocky Linux

Der heter administratorgruppen wheel i stedet for sudo: usermod -aG wheel anna. Linjen i /etc/sudoers er %wheel ALL=(ALL) ALL. visudo og /etc/sudoers.d fungerer på samme måte. Sudo-meldinger står der også i /var/log/secure.

Oppsummering

  • Jobb som vanlig bruker og bruk sudo til administrasjon; sudo ber om ditt eget passord og logger hver kommando.
  • Lag en administrator: adduser anna, adduser anna sudo (wheel på RHEL-lignende systemer), nøkkel med riktig eier og rettigheter, test i et nytt vindu, og slå først deretter av root-innlogging.
  • Rediger sudo-regler bare med visudo, helst i en egen fil i /etc/sudoers.d/ uten punktum i navnet.
  • NOPASSWD for alt fjerner en lås; bruk det heller bare for én kommando med fullstendig sti som brukeren ikke kan endre.
  • Minimale rettigheter: hver bruker og tjeneste får akkurat det som trengs, slik at en feil eller et sikkerhetshull forblir lite.

Quiz

1. Hvilket passord ber sudo om som standard når Anna skriver sudo apt update?



2. Du lager filen /etc/sudoers.d/backup.conf med en gyldig regel, men den fungerer ikke. Hvorfor?



3. Hvorfor redigerer du sudo-regler med visudo?



4. Hvilken regel gir en sikkerhetskopibruker minst risiko?



5. I hvilken rekkefølge slår du av root-innlogging uten å stenge deg selv ute?



Oppgave

Oppgave O3.2: En administrator med sudo. Lag en vanlig administrator på serveren din (for eksempel anna), legg inn nøkkelen din riktig, test innlogging og sudo -l i et nytt vindu, og slå deretter av root-innlogging via SSH (PermitRootLogin no). Kryss av trinnene, lim inn utdataene fra id (bare navn og grupper) og svar på spørsmålene: hvilken regel gir administratoren din rettigheter, står det NOPASSWD noe sted, og hvordan kommer du inn hvis du glemmer passordet ditt?

Oppgave O3.2: En administrator med sudo

Denne oppgaven gjør du selv; ingen kontrollerer den. Kryss av det du har gjort, og merk oppgaven som fullført.




Avkrysningene og notatene dine blir kun i denne nettleseren; vi sender dem ikke noe sted. Er du logget inn, lagrer vi kun i Mine kurs at du har gjort oppgaven.

Les mer

Trinnene i disse artiklene gjelder for VPS-ene til WebOké; hos andre leverandører fungerer det på lignende måte.

Et øyeblikk …

Sett opp domenene dine

Ordne for hvert domene navnetjenerne, koblingen til hostingen din og hvem som blir innehaver.

Laster inn domenene dine…