Videre til indhold 
Målrettet Montering af filsystem-Indstillingerne styrker sikkerheden på min Linux-server på filsystemniveau og blokerer typiske angreb via midlertidige stier, setuid-binærfiler og enhedsfiler. Jeg angiver klare mount-parametre som noexec, nosuid og nodev fastlægger, hvad der er tilladt på de enkelte partitioner, og mindsker dermed risikoen for privilegieeskalering betydeligt.
Centrale punkter
De følgende hovedpunkter giver en direkte indføring i sikker konfiguration af mount-indstillingerne og viser konkrete indstillingsmuligheder for Serverhærdning og drift.
- noexec/nosuid/nodev: Vigtige indstillinger til beskyttelse mod kodeudførelse, misbrug af SUID/SGID og enhedsfiler.
- Midlertidige stier: Begræns /tmp, /var/tmp og /dev/shm strengt.
- /etc/fstab: Test og overvåg persistente poster grundigt.
- Ydelsesindstillinger: Målrettet brug af ro, noatime, sync og kvoter.
- Tilføjelser: Kombinere ACL'er, umask, chattr og kryptering.
Hvorfor »mount«-indstillinger bidrager væsentligt til at styrke serversikkerheden
Ved hjælp af målrettede indstillinger styrer jeg, hvad der må ske på de enkelte partitioner, og undgår dermed unødvendige Angreb på overflader. Opfordringen mount -o rw,noexec,nosuid,nodev gør en standard-mount til en sikret mount, der forhindrer udførelse af kode og setuid-udnyttelser. Især på mapper, der kan skrives til af flere brugere, beskytter det mig mod typiske udnyttelseskæder fra /tmp. Jeg planlægger for hver partition, hvilke handlinger der virkelig er nødvendige, og begrænser alt andet konsekvent. På den måde opnår jeg mærkbart mere med minimal indsats Sikkerhed i hverdagen.
noexec, nosuid, nodev: de tre sværvægtere i hverdagen
Jeg sætter noexec på midlertidige stier, så binære filer, der gemmes der, ikke startes direkte. Med nosuid deaktiverer jeg SUID/SGID-eskaleringsveje, især på eksterne og netværksfilsystemer. Indstillingen nodev forhindrer, at nogen opretter og misbruger farlige enhedsfiler. Tilsammen blokerer disse tre indstillinger kodeudførelse, rettighedsudvidelse og adgang på lavt niveau. Denne kombination mindsker risikoen for rettighedsudvidelse betydeligt og styrker min Serverhærdning målbar.
Typiske anvendelsesscenarier og anbefalede muligheder
For midlertidige mapper som /tmp, /var/tmp og /dev/shm indstiller jeg som udgangspunkt noexec, nosuid og nodev. På /var og /var/log undgår jeg enhedsfiler og SUID/SGID, da ingen af delene tjener et legitimt formål der. I /home tillader jeg eksekvering efter behov, men blokerer SUID/SGID og enhedsfiler. For /boot indstiller jeg nosuid, nodev, noexec, så kun bootloaderen læser, og intet kører der. Denne klare adskillelse pr. partition øger Modstandsdygtighed min host og gør fejlfinding nemmere.
| Monteringspunkt | Anbefalede valgmuligheder | Kort beskrivelse af formålet |
|---|---|---|
| /tmp, /var/tmp, /dev/shm | noexec, nosuid, nodev | Ingen udførelse, ingen SUID/SGID, ingen enhedsfiler |
| /var, /var/log | nosuid,nodev (valgfrit: noexec) | Logfiler og spoolfiler uden SUID/SGID og uden enhedsfiler |
| /home | nosuid,nodev (valgfrit: noexec) | Brugerfiler uden SUID/SGID og uden enhedsfiler |
| /boot | nosuid,nodev,noexec | Kun læseadgang til bootfiler |
Effektiv udnyttelse af specielle filsystemer og avancerede indstillinger
Jeg tager højde for mit filsystems særlige egenskaber og tilpasser indstillingerne derefter. I ext4 giver data=ordnet (Standard) og commit= en god balance mellem datakonsistens og skrivehyppighed. Til særligt kritiske partitioner bruger jeg fejl=genmonter-ro, så systemet ikke fortsætter med at køre ubemærket i tilfælde af en fejl. På XFS tjekker jeg, om inode64 og kvotevarianter (usrquota, grpquota, prjquota) er aktive for at kunne administrere store filstrukturer på en overskuelig måde. Indstillinger som user_xattr og acl Jeg giver kun tilladelse i specifikke tilfælde, når programmer har brug for udvidede attributter eller mere detaljerede rettigheder – ellers holder jeg angrebsfladen lille og holder mig til de konservative standardindstillinger.
Når det gælder SSD- og cloud-volumener, vælger jeg bevidst mellem kassér og regelmæssige TRIM-kørsler via timeren. Online-TRIM (kassér) frigør lagerblokke med det samme, men koster I/O. I mange opsætninger er periodisk fstrim mere effektiv og gennemsigtig. Jeg vælger tidsstempelstrategien ud fra arbejdsbelastningen: relatime skåner pladen og er i dag et godt kompromis, Ingen tid minimerer skriveadgang, men kan forstyrre værktøjer, der er afhængige af præcise adgangstidspunkter. dovenskab bufferer igen attributopdateringer og reducerer dermed skrivebelastningen uden tab af semantik – ideelt, når jeg vil dæmpe skrive-IO'er uden at gå på kompromis med metadata.
Jeg holder mig væk fra risikable tuning-indstillinger, hvis deres effekt ikke er krystalklar: Indstillinger som nobarrier/tilbageførsel kan medføre datatab i tilfælde af strømsvigt. Ligeledes evaluerer jeg kun funktioner som DAX, hvis hardware, kerne og filsystemversion passer sammen. Devisen er stadig: først teste isoleret, derefter udrulle på en reproducerbar måde – og altid med en klar plan for tilbageførsel.
At finde den rette balance mellem ydeevne og sikkerhed
Jeg bruger ro der, hvor indholdet sjældent skifter, så ingen kan tilmelde sig ubemærket. Med Ingen tid eller relatime sparer jeg unødvendige skriveadgange, uden at ofre vigtige metadata i blinde. Indstillingen synkronisering sikrer, at skriveoperationer gemmes med det samme, hvilket ganske vist tager tid, men gør det sværere at miste data. Kvoter via usrquota/grpquota holder pladsrøvere i skak og forhindrer nedbrud på grund af fulde partitioner. For arbejdsbelastninger med ext4 eller XFS tester jeg hver enkelt indstilling på en kontrolleret måde, så funktionaliteten og Sikkerhed der passer til anvendelsen.
/etc/fstab: Konfigurer permanent og sikkert
Jeg gemmer de endelige valgmuligheder i /etc/fstab, så de kan klare enhver opstart. Før genstart tjekker jeg indtastningerne med mount -a og genindlæs tjenester med systemctl daemon-reload, for at undgå overraskelser. For root-partitionen foretrækker jeg de minimale indstillinger og flytter strenge begrænsninger over på dedikerede mounts. Eksempler på linjer som UUID=tmp-uuid /tmp ext4 defaults,nosuid,nodev,noexec 0 2 dokumenterer jeg det grundigt, så senere kontroller kan foregå hurtigt. Med findmnt --real -o TARGET,OPTIONS Jeg sammenligner den planlagte opsætning med den faktisk aktive Valgmuligheder.
systemd-integration: Automatisk montering, stabilitet ved opstart og afhængigheder
Jeg bruger systemds’ fstab-udvidelser for at forbedre tilgængeligheden og opstartstiderne. Med x-systemd.automount Jeg integrerer sjældent anvendte stier ved første adgang og reducerer dermed opstartsforsinkelser. nofail sikrer, at værten fortsat starter op, selvom de sekundære mounts mangler, mens jeg med x-systemd.device-timeout= og x-systemd.mount-timeout= Begræns hængere. For tjenester definerer jeg afhængigheder med x-systemd.requires-mounts-for=/sti, så applikationerne først starter, når jeres lagerplads rent faktisk er klar.
På ustabile eller langsomme backends tilføjer jeg desuden x-systemd.idle-timeout= for automatisk montering, så de afmonteres korrekt efter inaktivitet. På den måde holder jeg antallet af åbne deskriptorer lavt, forhindrer »zombie-mounts« og sikrer en forudsigelig kørselsadfærd – hvilket er afgørende i store miljøer med mange enheder og lagringsmål.
Kontrol og overvågning af monteringsindstillingerne under drift
Jeg tjekker regelmæssigt med findmnt, om alle partitioner er monteret som planlagt. Afvigelser opdager jeg straks og retter dem ved hjælp af målrettede genmonteringer, for eksempel mount -o remount,noexec /tmp. For tidsfølsomme værter indstiller jeg notifikationer, hvis indstillinger pludselig forsvinder, eller der dukker nye mounts op. Kontekstisolering gennem Navneområder og cgroups supplerer filsystemets sikkerhed effektivt. Sammen holder jeg angrebsveje korte, reducerer fejlkonfigurationer og øger Gennemsigtighed i hverdagen.
Sikring af pseudofilsystemer: /proc, /sys, debugfs og devpts
Jeg behandler pseudofilsystemer med samme omhu som datamedier. For /proc sætter jeg ved siden af nosuid,nodev,noexec frem for alt hidepid=2, for at skjule andre brugeres procesoplysninger. Hvis administratorer har brug for indsigt, arbejder jeg med en dedikeret gruppe (gid=) og hidepid=1 eller 2, afhængigt af behovet for synlighed. /sys Jeg følger strengt med nodev og uden unødvendige skriverettigheder; debugfs forbliver som udgangspunkt ikke monteret, medmindre jeg har brug for den midlertidigt til diagnostiske formål – i så fald udelukkende i kort tid og på testsystemer.
For devpts kontrollerer jeg tilstand og grupperettigheder, så pseudoterminaler er ordentligt isoleret (f.eks. mode=0620,gid=tty). Disse detaljer forhindrer utilsigtet krydsadgang mellem sessioner og mindsker risikoen for, at fortrolige oplysninger læses ud. Især i miljøer med flere brugere eller hosting-miljøer er denne finjustering en vigtig byggesten i Serverhærdning.
Tmpfs-størrelser og begrænsninger for /tmp og /dev/shm
For systemer med en høj andel af I/O- eller build-opgaver overvejer jeg /tmp og /dev/shm som tmpfs, præcist afgrænset og hårdt hærdet: tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,mode=1777,size=2G 0 0. På den måde forhindrer jeg, at midlertidige filer fylder harddisken, og fremskynder adgangen til data i hukommelsen. Jeg overvåger dog RAM-forbruget og planlægger reserver, så belastningen på hukommelsen ikke påvirker andre tjenester negativt. Hvis enkelte værktøjer har brug for eksekverbare midlertidige stier, adskiller jeg dem via dedikerede arbejdsmapper og bind-mounts i stedet for at svække de globale sikkerhedsregler.
Mellem /tmp og /var/tmp Jeg skelner bevidst mellem: /tmp må være volatil, /var/tmp bør kunne klare genstarter. Derfor vælger jeg tmpfs mere til /tmp og lad det være /var/tmp på disk – ligeledes med noexec, nosuid, nodev. Til store opgaver med delt hukommelse dimensionerer jeg /dev/shm passende (size=) og anvender konsekvent 1777-rettigheder for at sikre adskillelse mellem brugerne.
Supplerende sikkerhedsforanstaltninger på filsystemniveau
Jeg reducerer SUID/SGID-Jeg reducerer binærfilerne til et minimum og indstiller umask konservativt, f.eks. 027 eller 077, så nye filer oprettes med beskyttelse. Jeg aktiverer ACL'er målrettet, når programmer har brug for mere detaljerede rettigheder, og dokumenterer reglerne med getfacl rent. Særligt følsomme konfigurationer forsegler jeg med chattr +i, for at forhindre ændringer. Kvoter sætter en stopper for overdreven lagerbrug i god tid, inden det begynder at bremse tjenesterne. For stærk isolering af processerne henviser jeg desuden til Sammenligning af procesisolering, for at mindske risici uden for filsystemet.
Kombineret anvendelse af isoleringskoncepter
Jeg supplerer sikringen af filsystemet med Filsystemisolering på brugerniveau, så applikationer ikke får adgang ud over deres egne grænser. I hosting-opsætninger er et isoleret miljø en fordel, fordi sikkerhedsbrud forårsager mindre skade. Her er det værd at se nærmere på CageFS-filsystemisolering, der adskiller brugermiljøerne strengt. Også containere og jails giver fordele, når jeg kombinerer dem med restriktive mount-indstillinger. Denne kombination lukker huller, som ren Muligheder for montering ikke dække alene.
Hyppige snublesten og modforanstaltninger
Jeg tester noexec grundigt, fordi nogle værktøjer midlertidigt vil starte binære filer i /tmp. I sådanne tilfælde bruger jeg i stedet dedikerede arbejdsmapper, hvor kørsel er tilladt. Til shell-scripts bruger jeg eksplicitte interpreter-kald som /bin/bash script.sh, så noexec ikke er i vejen. Hvis enkelte undermapper kræver undtagelser, bruger jeg bind-mounts og specifikke indstillinger. På den måde holder jeg den grundlæggende sikkerhed intakt og tillader kun det, som et program virkelig påkrævet.
Bind-mounts, undermapper og mount-propagering
Jeg bruger mount --bind, for kun at videregive de nødvendige deltræer til målmiljøerne og dermed begrænse rettighederne. Med mount -o bind,ro sætter jeg dem til skrivebeskyttet, og derefter via en mount -o remount,nosuid,nodev,noexec,bind strammer jeg sikkerhedsgrænserne endnu mere. For hele undertræer bruger jeg --rbind, for at medtage alle under-mounts. Det er vigtigt at kende udbredelsesreglen: Med mount --make-private Jeg adskiller mount-hændelser mellem værten og chroots/containere, så der ikke „slipper“ uønskede mounts igennem.
Hvor container-orkestrering er aktiveret, opretholder jeg centrale stier som standard privat og åbner målrettet kun det, som arbejdsbelastningerne har brug for. I fejlfindingsfaser kan delt kan være nyttigt, i normal drift er privat/slave det sikre valg. På den måde forbliver mount-topologierne forudsigelige, og jeg forhindrer, at privilegerede stier ved en fejltagelse dukker op i gæstemiljøer.
Hærdning af fjern- og udskiftelige medier
Eksterne drev og netværksdelte mapper monterer jeg som udgangspunkt med nosuid,nodev og som regel også noexec. For VFAT/NTFS justerer jeg ejerskab og masker (f.eks. uid=1000,gid=1000,umask=027,fmask=137,dmask=027), så eksekverbare bits ikke bliver en sikkerhedsrisiko. På udskiftelige medier er der intet legitimt behov for SUID/SGID eller enhedsfiler – disse funktioner deaktiverer jeg konsekvent. Hvis jeg kun vil læse, tilføjes der desuden ro anvendes. På den måde forbliver skadelig kode inaktiv og kan ikke downloades i forbifarten.
Også ved NFS/SMB begrænser jeg rettighederne strengt. nosuid,nodev,noexec er standardindstillinger; jeg indstiller bevidst timeouts og gentagelser (hard/soft,timeo=), så nedbrud ikke blokerer hele systemet. For følsomme data indregner jeg integritet og kryptering på protokolniveau og sørger for, at klient- og serversiden følger ensartede retningslinjer. Jo mindre modparten har indflydelse på den lokale vært, desto mere stabil og forudsigelig forbliver driften.
Trin for trin: Sådan gennemfører du en eksempelkonfiguration på en sikker måde
Jeg begynder med en opgørelse via findmnt --real -o TARGET,OPTIONS og dokumenter alle aktive Ridedyre. Derefter passer jeg /etc/fstab f.eks. med linjer for /tmp og /dev/shm, herunder noexec, nosuid, nodev. Derefter tester jeg med mount -a og kontrollerer effekten igen med findmnt. Hvis alt kører problemfrit, indstiller jeg kvoter der, hvor brugerkonti vokser, og aktiverer relatime eller noatime efter behov. Til sidst registrerer jeg ændringerne i min ændringslog og planlægger regelmæssige Kontroller.
Driftsovervågning, revisioner og sikker tilbageførsel
Jeg fastlægger mine mount-politikker som en „måltilstand“ og kontrollerer regelmæssigt for afvigelser. Ud over findmnt og /proc/mounts Jeg bruger enkle kontroller i Health-scripts, der udløser en alarm, hvis kritiske stier uden noexec, nosuid eller nodev køre. Ændringer til /etc/fstab Jeg dokumenterer versioner af systemd-enheder; inden jeg foretager risikable tilpasninger, tager jeg snapshots (f.eks. via LVM/btrfs), så jeg hurtigt kan rulle tilbage i en nødsituation. For særligt følsomme systemer planlægger jeg vedligeholdelsesvinduer og tester remounts på forhånd på identiske staging-hosts.
Der er altid en pragmatisk redningsplanke ved hånden: Med mount -o remount,defaults Eller ved hjælp af målrettede modflag ruller jeg midlertidigt strenge indstillinger tilbage, hvis en tjeneste uforudset svigter. Derefter isolerer jeg årsagen, tilpasser undtagelser for bind-mounts og genindfører sikkerhedsforanstaltningerne på en kontrolleret måde. På den måde forbliver balancen mellem strenge politikker og høj tilgængelighed håndterbar – også under tidspres.
Resumé: Smart brug af mount-indstillinger
Jeg sikrer Linux-servere effektivt ved at noexec, nosuid og nodev målrettet på de relevante partitioner. Midlertidige stier indkapsler jeg strengt, og produktive dataområder får kun de rettigheder, de virkelig har brug for. Jeg indstiller ydeevneindstillinger som relatime, ro og kvoter efter situationen, så drift og sikkerhed er i balance. Permanente poster i /etc/fstab og regelmæssige kontroller med findmnt sikrer en pålidelig konfiguration. Suppleret med ACL'er, umask, chattr og gode isoleringsteknikker forbliver Angrebsoverflade lille og med en overskuelig administration.
