Hoppa till innehåll 
Riktade Montering av filsystem-Dessa alternativ förstärker säkerheten på min Linux-server på filsystemnivå och blockerar typiska attacker via tillfälliga sökvägar, setuid-binärer och enhetsfiler. Jag anger tydliga monteringsparametrar som noexec, nosuid och nodev för att fastställa vad som är tillåtet på enskilda partitioner och därmed avsevärt minska risken för privilegieeskalering.
Centrala punkter
Följande huvudpunkter ger en direkt introduktion till hur man konfigurerar monteringsalternativen på ett säkert sätt och visar konkreta åtgärder för Säkerhetsåtgärder för servrar och drift.
- noexec/nosuid/nodev: Viktiga inställningar för att förhindra kodkörning, missbruk av SUID/SGID och enhetsfiler.
- Tillfälliga sökvägar: Begränsa /tmp, /var/tmp och /dev/shm strikt.
- /etc/fstab: Testa och övervaka beständiga poster på ett noggrant sätt.
- Prestandaalternativ: Använd ro, noatime, sync och kvoter på ett målinriktat sätt.
- Tillägg: Kombinera ACL:er, umask, chattr och kryptering.
Varför Mount-alternativ avsevärt förbättrar säkerheten på servrarna
Genom att använda specifika inställningar styr jag vad som får hända på de olika partitionerna och undviker därmed onödiga Attackera ytor. Uppmaningen mount -o rw,noexec,nosuid,nodev förvandlar en vanlig mount till en säker mount som förhindrar kodkörning och setuid-attacker. Särskilt i gemensamt skrivbara kataloger skyddar detta mig mot typiska exploatkedjor från /tmp. Jag planerar vilka åtgärder som verkligen är nödvändiga per partition och begränsar konsekvent allt annat. På så sätt uppnår jag märkbart bättre resultat med liten ansträngning Säkerhet i det dagliga livet.
noexec, nosuid, nodev: de tre tungviktarna i vardagen
Jag ställer in noexec på tillfälliga sökvägar, så att binärfiler som sparas där inte startas direkt. Med nosuid inaktiverar jag SUID/SGID-eskaleringsvägar, framför allt på externa filsystem och nätverksfilsystem. Alternativet nodv förhindrar att någon skapar och missbrukar farliga enhetsfiler. Tillsammans blockerar dessa tre inställningar kodkörning, utökning av behörigheter och åtkomst på låg nivå. Denna kombination minskar risken för behörighetsutökning avsevärt och stärker min Säkerhetsåtgärder för servrar mätbar.
Typiska användningsscenarier och rekommenderade alternativ
För tillfälliga kataloger som /tmp, /var/tmp och /dev/shm anger jag som regel noexec, nosuid och nodev. För /var och /var/log avstår jag från enhetsfiler och SUID/SGID, eftersom inget av dessa fyller något legitimt syfte där. I /home tillåter jag körning vid behov, men blockerar SUID/SGID och enhetsfiler. För /boot ställer jag in nosuid, nodev, noexec, så att endast bootloadern läser och ingenting körs där. Denna tydliga uppdelning per partition ökar Motståndskraft min värd och underlättar felsökningen.
| Monteringspunkt | Rekommenderade alternativ | Kortfattad beskrivning |
|---|---|---|
| /tmp, /var/tmp, /dev/shm | noexec, nosuid, nodev | Ingen körning, inga SUID/SGID, inga enhetsfiler |
| /var, /var/log | nosuid,nodev (valfritt noexec) | Loggfiler och spoolfiler utan SUID/SGID och utan enhetsfiler |
| /home | nosuid,nodev (valfritt noexec) | Användarfiler utan SUID/SGID och utan enhetsfiler |
| /boot | nosuid,nodev,noexec | Endast läsbehörighet för startfiler |
Att använda specialfilsystem och avancerade alternativ på ett effektivt sätt
Jag tar hänsyn till särdragen hos mitt filsystem och anpassar inställningarna därefter. För ext4 gäller följande: data=ordnad (Standard) och commit= en bra balans mellan datakonsistens och skrivfrekvens. För särskilt kritiska partitioner använder jag errors=remount-ro, så att systemet inte fortsätter att fungera obemärkt i händelse av ett fel. På XFS kontrollerar jag om inode64 och kvotvarianter (usrquota, grpquota, prjquota) som används för att hantera stora filstrukturer på ett överskådligt sätt. Alternativ som user_xattr och acl Jag tillåter detta endast i specifika fall när program behöver utökade attribut eller mer detaljerade behörigheter – i övrigt håller jag attackytan liten och håller mig till konservativa standardinställningar.
När det gäller SSD- och molnvolymer väljer jag medvetet mellan kasta bort och regelbundna TRIM-körningar via timern. Online-TRIM (kasta bort) frigör lagringsblock omedelbart, men medför I/O-kostnader. I många konfigurationer är periodisk fstrim mer prestandastark och transparent. Jag väljer tidsstämpelstrategi utifrån arbetsbelastningen: relatime skyddar skivan och är idag en bra kompromiss, ingen tid minimerar skrivåtkomst, men kan orsaka problem för verktyg som är beroende av exakta åtkomsttider. lattid I sin tur buffrar den attributuppdateringar och minskar därmed skrivbelastningen utan att semantik går förlorad – perfekt när jag vill dämpa skriv-IO:er utan att behöva avstå från metadata.
Jag undviker riskfyllda inställningsalternativ om deras effekt inte är helt tydlig: flaggor som nobarrier/återskrivning kan bidra till dataförlust vid strömavbrott. På samma sätt utvärderar jag endast funktioner som DAX om hårdvaran, kärnan och filsystemversionen är kompatibla. Ledordet är fortfarande: testa först isolerat, rulla sedan ut på ett reproducerbart sätt – och alltid med en tydlig återställningsplan.
Att hitta rätt balans mellan prestanda och säkerhet
Jag använder ro där innehållet sällan ändras, så att ingen kan registrera sig obemärkt. Med ingen tid eller relatime sparar jag onödiga skrivåtkomster utan att blint offra viktig metadata. Alternativet synkronisering sparar skrivoperationer omedelbart, vilket visserligen tar tid men gör det svårare att förlora data. Kvoter via usrquota/grpquota håller lagringsslukare i schack och förhindrar avbrott på grund av fulla partitioner. För arbetsbelastningar med ext4 eller XFS testar jag varje alternativ på ett kontrollerat sätt, så att funktionen och Säkerhet passar till användningsområdet.
/etc/fstab: konfigurera permanent och säkert
Jag lägger in de slutgiltiga alternativen i /etc/fstab, så att de klarar varje uppstart. Innan jag startar om kontrollerar jag posterna med mount -a och ladda om tjänsterna med systemctl daemon-reload, för att undvika överraskningar. För rotpartitionen föredrar jag minimala inställningar och flyttar strikta begränsningar till dedikerade monteringspunkter. Exempelrader som UUID=tmp-uuid /tmp ext4 defaults,nosuid,nodev,noexec 0 2 dokumenterar jag noggrant så att framtida granskningar kan genomföras smidigt. Med findmnt --real -o MÅL,ALTERNATIV jämför jag den planerade konfigurationen med den som faktiskt används Alternativ.
systemd-integration: automatisk montering, stabilitet vid uppstart och beroenden
Jag använder systemds Fstab-tillägg för att förbättra tillgängligheten och starttiderna. Med x-systemd.automount Jag laddar in sällan använda sökvägar vid första åtkomsten och minskar därmed uppstartsproblemen. nofail ser till att värden fortsätter att starta trots att sekundära monteringar saknas, medan jag med x-systemd.device-timeout= och x-systemd.mount-timeout= Begränsa hängare. För tjänster definierar jag beroenden med x-systemd.requires-mounts-for=/sökväg, så att applikationerna inte startar förrän lagringsutrymmet verkligen är tillgängligt.
På instabila eller långsamma backend-system lägger jag dessutom x-systemd.idle-timeout= för automatisk montering, så att de avmonteras korrekt efter inaktivitet. På så sätt håller jag antalet öppna deskriptorer lågt, förhindrar ”zombie-monteringar” och säkerställer ett förutsägbart körningsbeteende – vilket är avgörande i stora miljöer med många enheter och lagringsmål.
Kontroll och övervakning av monteringsalternativen under drift
Jag kontrollerar regelbundet med findmnt, om alla partitioner har monterats enligt plan. Avvikelser upptäcker jag omedelbart och åtgärdar dem genom riktade ommonteringar, till exempel mount -o remount,noexec /tmp. För tidskritiska värdar ställer jag in aviseringar om alternativ plötsligt försvinner eller nya monteringar dyker upp. Kontextisolering genom Namnrymder och cgroups kompletterar säkerhetsåtgärderna för filsystemet på ett effektivt sätt. Tillsammans ser jag till att attackvägarna hålls korta, minskar risken för felkonfigurationer och ökar Öppenhet i det dagliga livet.
Säkra pseudofilsystem: /proc, /sys, debugfs och devpts
Jag hanterar pseudofilsystem med samma omsorg som lagringsmedier. För /proc jag sätter bredvid nosuid,nodev,noexec framför allt hidepid=2, för att dölja processdetaljer för andra användare. Om administratörer behöver insyn arbetar jag med en särskild grupp (gid=) och hidepid=1 eller . 2, beroende på vilka synlighetskrav som gäller. /sys Jag håller strikt med nodv och utan onödiga skrivrättigheter; debugfs förblir i princip inte monterad, såvida jag inte behöver den tillfälligt för diagnostiska ändamål – i så fall endast under en kort tid och på testsystem.
För devpts kontrollerar jag lägen och grupprättigheter så att pseudoterminaler är ordentligt isolerade (t.ex. mode=0620,gid=tty). Dessa detaljer förhindrar oönskad korsåtkomst mellan sessioner och minskar risken för att känslig information läser ut. Särskilt i miljöer med flera användare eller i hostingmiljöer är denna finjustering en viktig del av Säkerhetsåtgärder för servrar.
Tmpfs-storlekar och gränsvärden för /tmp och /dev/shm
För system med hög I/O- eller byggbelastning överväger jag /tmp och /dev/shm som tmpfs, noggrant avgränsad och hårt härdad: tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,mode=1777,size=2G 0 0. På så sätt förhindrar jag att tillfälliga filer fyller upp hårddisken och påskyndar åtkomsten till minnet. Jag övervakar dock RAM-användningen och planerar in reserver så att minnesbelastningen inte påverkar andra tjänster negativt. Om enskilda verktyg behöver körbara temporära sökvägar kopplar jag bort dem via dedikerade arbetskataloger och bind-mounts istället för att urvattna globala säkerhetsregler.
Mellan /tmp och /var/tmp Jag gör medvetet följande åtskillnad: /tmp får vara volatil, /var/tmp bör klara omstarter. Därför väljer jag tmpfs snarare för /tmp och låt det vara /var/tmp på disk – även med noexec, nosuid, nodev. För stora arbetsbelastningar med delat minne dimensionerar jag /dev/shm passande (storlek=) och tillämpar konsekvent 1777-rättigheter för att säkerställa avskiljning mellan användare.
Kompletterande säkerhetsåtgärder på filsystemnivå
Jag minskar SUID/SGID-Jag minimerar storleken på binärfilerna och ställer in umask konservativt, till exempel 027 eller 077, så att nya filer skapas med skydd. Jag aktiverar ACL:er selektivt när program behöver mer detaljerade behörigheter och dokumenterar reglerna med getfacl rent. Särskilt känsliga konfigurationer förseglar jag med chattr +i, för att förhindra ändringar. Kvoter stoppar överbelastning av lagringsutrymmet i ett tidigt skede, innan den börjar bromsa tjänsterna. För kraftfull isolering av processerna hänvisar jag dessutom till Jämförelse av processisolering, för att minska riskerna utanför filsystemet.
Kombinera olika isoleringslösningar
Jag kompletterar säkerhetsåtgärderna för filsystemet genom att Filsystemisolering på användarnivå, så att applikationer inte får åtkomst utanför sina gränser. I hostingmiljöer lönar det sig att ha en isolerad miljö, eftersom säkerhetsincidenter orsakar mindre skada. Här är det värt att ta en titt på CageFS-filsystemisolering, som strikt separerar användarmiljöerna. Även containrar och jailer ger fördelar när jag kombinerar dem med restriktiva monteringsalternativ. Denna kombination täpper till luckor som enbart Alternativ för montering inte täcka helt och hållet.
Frekventa hinder och motåtgärder
Jag testar noexec noggrant, eftersom vissa verktyg tillfälligt vill starta binärfiler i /tmp. I sådana fall använder jag istället särskilda arbetskataloger där körning är tillåten. För shell-skript använder jag explicita tolk-anrop som /bin/bash script.sh, så att noexec inte står i vägen. Om enskilda underkataloger kräver undantag använder jag bind-mounts och specifika alternativ. På så sätt håller jag den grundläggande säkerhetskonfigurationen intakt och tillåter endast det som en applikation verkligen krävs.
Bind-mounts, underkataloger och mount-propagering
Jag använder mount --bind, för att endast överföra nödvändiga delträd till målmiljöerna och därigenom begränsa behörigheterna. Med mount -o bind,ro ställer jag in dem som skrivskyddat, och genom en efterföljande mount -o remount,nosuid,nodev,noexec,bind skärper jag säkerhetsgränserna ytterligare. För hela delträd använder jag --rbind, för att ta med alla underordnade monteringar. Det är viktigt att känna till spridningsregeln: Med mount --make-private Jag separerar monteringshändelser mellan värden och chroots/containrar så att inga oönskade monteringar „släpps igenom“.
Där containerorkestrering är aktiverad behåller jag centrala sökvägar som standard privat och öppna endast det som arbetsbelastningarna behöver. Under felsökningsfaserna kan delad kan vara användbart, men i normal drift är det privat/slav Det säkra valet. På så sätt förblir monteringsstrukturerna förutsägbara, och jag förhindrar att privilegierade vägar av misstag dyker upp i gästmiljöer.
Härda fjärr- och utbytbara medier
Externa enheter och nätverksresurser monterar jag alltid med nosuid,nodev och oftast också noexec. För VFAT/NTFS justerar jag ägare och behörigheter (t.ex. uid=1000,gid=1000,umask=027,fmask=137,dmask=027), så att körbara bitar inte blir en säkerhetsrisk. På flyttbara medier finns det inget legitimt behov av SUID/SGID eller enhetsfiler – dessa funktioner inaktiverar jag konsekvent. Om jag bara vill läsa tillkommer dessutom ro används. På så sätt förblir skadlig kod verkningslös och kan inte laddas ned i förbigående.
Även när det gäller NFS/SMB begränsar jag behörigheterna strikt. nosuid,nodev,noexec är standard, medan jag medvetet ställer in tidsgränser och upprepningar (hard/soft,timeo=), så att avbrott inte blockerar hela systemet. För känsliga data planerar jag in integritetsskydd och kryptering på protokollnivå och ser till att klient- och serversidan följer enhetliga riktlinjer. Ju mindre motparten får bestämma över den lokala värden, desto stabilare och mer förutsägbar blir driften.
Steg för steg: Genomföra en exempelkonfiguration på ett säkert sätt
Jag börjar med en inventering via findmnt --real -o MÅL,ALTERNATIV och dokumentera alla aktiva Mounts. Därefter passar jag /etc/fstab till, till exempel med rader för /tmp och /dev/shm inklusive noexec, nosuid, nodev. Därefter testar jag med mount -a och kontrollerar effekten igen med findmnt. Om allt fungerar som det ska sätter jag kvoter där användarkontona växer och aktiverar relatime eller noatime efter behov. Till sist dokumenterar jag ändringarna i min ändringslogg och planerar regelbundna Kontroller.
Driftkontroll, revisioner och säker återställning
Jag fastställer mina monteringsriktlinjer som ett „mål“ och kontrollerar regelbundet om det finns avvikelser. Förutom findmnt och /proc/mounts Jag använder enkla kontroller i Health-skript som slår larm om kritiska vägar saknas noexec, nosuid eller . nodv köras. Ändringar av /etc/fstab Jag dokumenterar versioner av systemd-enheter; innan jag gör riskfyllda justeringar tar jag säkerhetskopior (t.ex. via LVM/btrfs) så att jag snabbt kan återställa systemet i nödfall. För särskilt känsliga system planerar jag underhållsfönster och testar ommonteringar i förväg på identiska staging-värdar.
En praktisk livlina finns alltid till hands: Med mount -o remount,defaults Eller vid riktade motflaggningar återtar jag tillfälligt strikta inställningar om en tjänst oväntat slutar fungera. Därefter isolerar jag orsaken, justerar undantagen för bind-mount och återinför säkerhetsåtgärderna på ett kontrollerat sätt. På så sätt förblir balansen mellan strikta policyer och hög tillgänglighet hanterbar – även under tidspress.
Sammanfattning: Att använda mount-alternativ på ett smart sätt
Jag säkerställer Linux-värdar på ett effektivt sätt genom att noexec, nosuid och nodev placerar jag målmedvetet på rätt partitioner. Tillfälliga sökvägar kapslar jag in ordentligt, medan produktiva dataområden endast tilldelas de behörigheter de verkligen behöver. Prestandainställningar som relatime, ro och kvoter ställer jag in efter situationen, så att både drift och säkerhet fungerar som de ska. Permanenta poster i /etc/fstab och regelbundna kontroller med findmnt säkerställer en pålitlig konfiguration. Kompletterat med ACL:er, umask, chattr och bra isoleringstekniker förblir Attackyta liten och med en överskådlig administration.
