Zum Inhalt springen 
Gezielte Filesystem Mount-Optionen härten meinen Linux-Server an der Dateisystemebene und blockieren typische Angriffe über temporäre Pfade, setuid-Binaries und Geräte-Dateien. Ich lege mit klaren Mount-Parametern wie noexec, nosuid und nodev fest, was auf einzelnen Partitionen zulässig ist und senke so das Risiko für Privilege Escalation deutlich.
Zentrale Punkte
Die folgenden Schwerpunkte führen direkt in die sichere Konfiguration der Mount-Optionen ein und zeigen konkrete Stellhebel für Serverhärtung und Betrieb.
- noexec/nosuid/nodev: Kernoptionen gegen Code-Ausführung, SUID/SGID-Missbrauch und Geräte-Dateien.
- Temporäre Pfade: /tmp, /var/tmp und /dev/shm strikt begrenzen.
- /etc/fstab: Persistente Einträge sauber testen und überwachen.
- Performance-Optionen: ro, noatime, sync und Quotas gezielt nutzen.
- Ergänzungen: ACLs, umask, chattr und Verschlüsselung kombinieren.
Warum Mount-Optionen die Serverhärtung deutlich voranbringen
Ich steuere mit gezielten Optionen auf Partitionen, was dort passieren darf, und schließe so unnötige Angriffsflächen. Der Aufruf mount -o rw,noexec,nosuid,nodev macht aus einem Standard-Mount einen gehärteten Mount, der Code-Ausführung und setuid-Tricks verhindert. Besonders auf gemeinsam beschreibbaren Verzeichnissen schützt mich das vor typischen Exploit-Ketten aus /tmp. Ich plane pro Partition, welche Aktionen wirklich nötig sind, und schränke alles andere konsequent ein. So erreiche ich mit wenig Aufwand spürbar mehr Sicherheit im Alltag.
noexec, nosuid, nodev: die drei Schwergewichte im Alltag
Ich setze noexec auf temporären Pfaden, damit dort abgelegte Binärdateien nicht direkt starten. Mit nosuid schalte ich SUID/SGID-Eskalationspfade aus, vor allem auf externen und Netzwerkdateisystemen. Die Option nodev verhindert, dass jemand gefährliche Gerätedateien anlegt und missbraucht. Zusammen blockieren diese drei Schalter Code-Ausführung, Rechteausweitung und Low-Level-Zugriffe. Dieser Verbund verringert das Risiko von Privilege Escalation deutlich und stärkt meine Serverhärtung messbar.
Typische Einsatzszenarien und empfohlene Optionen
Ich lege für temporäre Bereiche wie /tmp, /var/tmp und /dev/shm grundsätzlich noexec, nosuid und nodev fest. Auf /var und /var/log verzichte ich auf Gerätedateien und SUID/SGID, da beides dort keinen legitimen Zweck erfüllt. In /home erlaube ich Ausführung bei Bedarf, blockiere aber SUID/SGID und Geräte-Dateien. Für /boot setze ich nosuid,nodev,noexec, damit nur der Bootloader liest und nichts dort läuft. Diese klare Trennung pro Partition erhöht die Widerstandskraft meines Hosts und erleichtert das Troubleshooting.
| Mount-Punkt | Empfohlene Optionen | Kurzer Zweck |
|---|---|---|
| /tmp, /var/tmp, /dev/shm | noexec,nosuid,nodev | Keine Ausführung, keine SUID/SGID, keine Geräte-Dateien |
| /var, /var/log | nosuid,nodev (optional noexec) | Logs und Spools ohne SUID/SGID und ohne Gerätedateien |
| /home | nosuid,nodev (optional noexec) | Nutzerdateien ohne SUID/SGID und ohne Gerätedateien |
| /boot | nosuid,nodev,noexec | Nur lesender Zugriff für Bootdateien |
Spezielle Dateisysteme und erweiterte Optionen sinnvoll nutzen
Ich beachte die Eigenheiten meines Dateisystems und stimme Optionen darauf ab. Bei ext4 liefern data=ordered (Standard) und commit= einen guten Ausgleich zwischen Datenkonsistenz und Schreibhäufigkeit. Für besonders kritische Partitionen setze ich errors=remount-ro, damit das System im Fehlerfall nicht unbemerkt weiterarbeitet. Auf XFS prüfe ich, ob inode64 und Quota-Varianten (usrquota, grpquota, prjquota) aktiv sind, um große Dateibäume sauber zu verwalten. Optionen wie user_xattr und acl erlaube ich gezielt, wenn Anwendungen erweiterte Attribute oder feinere Rechte benötigen – andernfalls halte ich die Angriffsfläche klein und bleibe bei konservativen Defaults.
Für SSD- und Cloud-Volumes entscheide ich bewusst zwischen discard und regelmäßigen Trim-Läufen via Timer. Online-TRIM (discard) hält Speicherblöcke unmittelbar frei, kostet aber I/O. In vielen Setups ist periodisches fstrim performanter und transparenter. Die Timestamp-Strategie wähle ich nach Workload: relatime schont die Platte und ist heute ein guter Kompromiss, noatime spart maximal Schreibzugriffe, kann aber Tools irritieren, die auf exakte Zugriffszeiten setzen. lazytime wiederum puffert Attribut-Updates und reduziert so Schreiblast ohne Semantikverlust – ideal, wenn ich Schreib-IOs dämpfen will, ohne auf Metadaten zu verzichten.
Ich halte mich von riskanten Tuning-Optionen fern, wenn ihr Effekt nicht glasklar ist: Flags wie nobarrier/writeback können Datenverlust bei Stromausfall begünstigen. Ebenso evaluiere ich Features wie DAX nur, wenn Hardware, Kernel und Filesystemversion dazu passen. Die Devise bleibt: erst isoliert testen, dann reproduzierbar ausrollen – und immer mit sauberem Rollback-Plan.
Performance und Sicherheit stimmig ausbalancieren
Ich nutze ro dort, wo Inhalte selten wechseln, damit sich niemand unbemerkt einschreibt. Mit noatime oder relatime spare ich unnötige Schreibzugriffe, ohne wichtige Metadaten blind zu opfern. Die Option sync sichert Schreibvorgänge sofort, was zwar Zeit kostet, aber Datenverluste erschwert. Quotas per usrquota/grpquota halten Speicherfresser in Schach und verhindern Ausfälle durch volle Partitionen. Für Workloads mit ext4 oder XFS teste ich jede Option kontrolliert, damit Funktion und Sicherheit zur Anwendung passen.
/etc/fstab: dauerhaft und sicher konfigurieren
Ich hinterlege die finalen Optionen in /etc/fstab, damit sie jeden Boot überstehen. Vor dem Neustart prüfe ich Einträge mit mount -a und lade Dienste neu mit systemctl daemon-reload, um Überraschungen zu vermeiden. Für die Root-Partition halte ich die Optionen minimal und verschiebe harte Einschränkungen auf dedizierte Mounts. Beispielzeilen wie UUID=tmp-uuid /tmp ext4 defaults,nosuid,nodev,noexec 0 2 dokumentiere ich sauber, damit spätere Prüfungen zügig laufen. Mit findmnt --real -o TARGET,OPTIONS vergleiche ich geplantes Setup und real aktive Optionen.
systemd-Integration: Automounts, Boot-Robustheit und Abhängigkeiten
Ich nutze systemds Fstab-Erweiterungen, um Verfügbarkeit und Startzeiten zu verbessern. Mit x-systemd.automount binde ich selten genutzte Pfade bei erstem Zugriff ein und reduziere Boot-Stalls. nofail sorgt dafür, dass der Host trotz fehlender sekundärer Mounts weiter startet, während ich mit x-systemd.device-timeout= und x-systemd.mount-timeout= Hänger begrenze. Für Dienste definiere ich Abhängigkeiten mit x-systemd.requires-mounts-for=/pfad, damit Applikationen erst starten, wenn ihr Storage wirklich bereitsteht.
Auf volatile oder langsame Backends lege ich zusätzlich x-systemd.idle-timeout= für Automounts fest, damit sie nach Inaktivität sauber ausgehängt werden. So halte ich die Zahl offener Deskriptoren klein, verhindere Zombie-Mounts und erhalte ein vorhersehbares Laufzeitverhalten – essenziell in großen Umgebungen mit vielen Units und Storage-Zielen.
Prüfen und Überwachen der Mount-Optionen im Betrieb
Ich kontrolliere regelmäßig mit findmnt, ob alle Partitionen wie geplant eingebunden sind. Abweichungen erkenne ich sofort und korrigiere sie mit gezielten Remounts, etwa mount -o remount,noexec /tmp. Für zeitkritische Hosts setze ich Benachrichtigungen, wenn Optionen plötzlich fehlen oder neue Mounts erscheinen. Kontext-Isolation durch Namespaces und cgroups ergänzt die Dateisystemhärtung wirksam. Zusammen halte ich Angriffswege kurz, reduziere Fehlkonfigurationen und steigere die Transparenz im Alltag.
Pseudo-Dateisysteme absichern: /proc, /sys, debugfs und devpts
Ich behandle Pseudo-Dateisysteme mit derselben Sorgfalt wie Datenträger. Für /proc setze ich neben nosuid,nodev,noexec vor allem hidepid=2, um Prozessdetails anderer Nutzer zu verbergen. Falls Administratoren Einblick benötigen, arbeite ich mit einer dedizierten Gruppe (gid=<proc-gruppe>) und hidepid=1 oder 2, je nach Sichtbarkeitsbedarf. /sys mounte ich strikt mit nodev und ohne unnötige Schreibrechte; debugfs bleibt grundsätzlich ungemountet, es sei denn, ich brauche es temporär zu Diagnosezwecken – dann ausschließlich kurzzeitig und auf Testsystemen.
Für devpts kontrolliere ich Modus und Gruppenrechte, damit Pseudo-Terminals sauber isoliert sind (z. B. mode=0620,gid=tty). Diese Details verhindern ungewollte Querzugriffe zwischen Sessions und reduzieren das Risiko, dass privilegierte Informationen ausgelesen werden. Gerade in Multi-User- oder Hosting-Umgebungen ist dieser Feinschliff ein wichtiger Baustein der Serverhärtung.
Tmpfs-Größen und Limits für /tmp und /dev/shm
Für Systeme mit hohem I/O- oder Build-Anteil erwäge ich /tmp und /dev/shm als tmpfs, sauber limitiert und hart gehärtet: tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,mode=1777,size=2G 0 0. So verhindere ich, dass temporäre Dateien Platten füllen, und beschleunige Zugriffe im Speicher. Ich beobachte aber den RAM-Verbrauch und plane Reserven ein, damit Speicherdruck nicht andere Dienste beeinträchtigt. Benötigen einzelne Tools ausführbare Temp-Pfade, entkopple ich sie über dedizierte Arbeitsverzeichnisse und Bind-Mounts statt globale Sicherheitsregeln aufzuweichen.
Zwischen /tmp und /var/tmp unterscheide ich bewusst: /tmp darf volatil sein, /var/tmp sollte Reboots überstehen. Entsprechend wähle ich tmpfs eher für /tmp und belasse /var/tmp auf Disk – ebenfalls mit noexec,nosuid,nodev. Für große Shared-Memory-Last dimensioniere ich /dev/shm passend (size=) und setze konsequent 1777-Rechte, um Trennung zwischen Nutzern zu gewährleisten.
Ergänzende Härtungsmaßnahmen auf Dateisystemebene
Ich reduziere SUID/SGID-Binaries auf das Minimum und setze umask konservativ, etwa 027 oder 077, damit neue Dateien geschützt starten. ACLs aktiviere ich gezielt, wenn Anwendungen feinere Rechte brauchen, und dokumentiere Regeln mit getfacl sauber. Besonders sensible Konfigurationen versiegle ich mit chattr +i, um Änderungen zu verhindern. Quotas stoppen Speicherexzesse früh, bevor sie Dienste ausbremsen. Für starke Isolation der Prozesse verweise ich zusätzlich auf Prozess-Isolation im Vergleich, um Risiken jenseits des Dateisystems zu verringern.
Isolationskonzepte kombiniert einsetzen
Ich ergänze die Dateisystemhärtung durch Dateisystem-Isolation auf Nutzerebene, damit Anwendungen keinen Zugriff über ihre Grenzen hinaus bekommen. In Hosting-Setups zahlt sich eine gekapselte Umgebung aus, weil Querschläger weniger anrichten. Hier lohnt ein Blick auf CageFS Dateisystem-Isolation, die Nutzerumgebungen strikt trennt. Auch Container und Jails bringen Vorteile, wenn ich sie mit restriktiven Mount-Optionen verknüpfe. Diese Kombination schließt Lücken, die reine Mount-Optionen nicht allein abdecken.
Häufige Stolpersteine und Gegenmaßnahmen
Ich teste noexec gründlich, weil manche Tools temporär Binärdateien in /tmp starten wollen. In solchen Fällen weiche ich auf dedizierte Arbeitsverzeichnisse mit erlaubter Ausführung aus. Für Shell-Skripte nutze ich explizite Interpreteraufrufe wie /bin/bash script.sh, damit noexec nicht im Weg steht. Wenn einzelne Unterverzeichnisse Ausnahmen brauchen, arbeite ich mit Bind-Mounts und spezifischen Optionen. So halte ich die Grundhärtung intakt und erlaube nur das, was eine Anwendung wirklich benötigt.
Bind-Mounts, Unterverzeichnisse und Mount-Propagation
Ich nutze mount --bind, um nur benötigte Teilbäume in Zielumgebungen zu reichen und dabei die Rechte einzuschränken. Mit mount -o bind,ro setze ich sie schreibgeschützt, und über ein anschließendes mount -o remount,nosuid,nodev,noexec,bind ziehe ich die Sicherheitsgrenzen noch enger. Für ganze Unterbäume verwende ich --rbind, um alle Unter-Mounts mitzunehmen. Wichtig ist die Propagationsregel: Mit mount --make-private trenne ich Mount-Ereignisse zwischen Host und Chroots/Containern, damit keine ungewollten Mounts „durchreichen“.
Wo Container-Orchestrierung aktiv ist, halte ich zentrale Pfade standardmäßig private und öffne gezielt nur das, was Workloads brauchen. In Debug-Phasen kann shared nützlich sein, im Regelbetrieb ist private/slave die sichere Wahl. So bleiben die Mount-Topologien berechenbar, und ich verhindere, dass privilegierte Pfade versehentlich in Gastumgebungen auftauchen.
Remote- und Wechselmedien härten
Externe Laufwerke und Netzfreigaben mounte ich grundsätzlich mit nosuid,nodev und meist auch noexec. Für VFAT/NTFS reguliere ich Eigentümer und Masken (z. B. uid=1000,gid=1000,umask=027,fmask=137,dmask=027), damit ausführbare Bits nicht zum Einfallstor werden. Auf wechselbaren Medien gibt es keinen legitimen Bedarf für SUID/SGID oder Gerätedateien – diese Funktionen kappe ich konsequent. Wenn ich nur lesen will, kommt zusätzlich ro zum Einsatz. So bleibt Schadcode wirkungslos und kann nicht im Vorbeigehen nachgeladen werden.
Bei NFS/SMB begrenze ich Privilegien ebenfalls strikt. nosuid,nodev,noexec sind Standard, Timeouts und Wiederholungen setze ich bewusst (hard/soft,timeo=), damit Ausfälle nicht das Gesamtsystem blockieren. Für sensible Daten plane ich Integrität und Verschlüsselung auf Protokollebene ein und achte darauf, dass Client- und Server-Seite konsistente Policies fahren. Je weniger die Gegenseite über den lokalen Host entscheiden darf, desto stabiler und vorhersagbarer bleibt der Betrieb.
Schritt-für-Schritt: Beispielkonfiguration sicher umsetzen
Ich beginne mit einer Inventur via findmnt --real -o TARGET,OPTIONS und dokumentiere alle aktiven Mounts. Danach passe ich /etc/fstab an, etwa mit Zeilen für /tmp und /dev/shm inklusive noexec,nosuid,nodev. Im Anschluss teste ich mit mount -a und prüfe die Wirkung erneut mit findmnt. Läuft alles sauber, setze ich Quotas dort, wo Nutzerkonten wachsen, und aktiviere relatime oder noatime nach Bedarf. Zum Schluss fixiere ich die Änderungen in meinem Änderungsprotokoll und plane regelmäßige Kontrollen.
Driftkontrolle, Audits und sicheres Rollback
Ich halte meine Mount-Policies als „Soll-Zustand“ fest und prüfe regelmäßig auf Abweichungen. Neben findmnt und /proc/mounts nutze ich einfache Checks in Health-Skripten, die Alarm schlagen, wenn kritische Pfade ohne noexec, nosuid oder nodev laufen. Änderungen an /etc/fstab oder systemd-Units dokumentiere ich versioniert; vor riskanten Anpassungen ziehe ich Snapshots (z. B. via LVM/btrfs), damit ich im Notfall schnell zurück kann. Für besonders sensible Systeme plane ich Wartungsfenster und teste Remounts vorab auf baugleichen Staging-Hosts.
Ein pragmatischer Rettungsanker ist stets zur Hand: Mit mount -o remount,defaults oder gezielten Gegen-Flags rolle ich harte Optionen temporär zurück, wenn ein Dienst unvorhergesehen scheitert. Danach isoliere ich die Ursache, passe Bind-Mount-Ausnahmen an und führe die Härtung kontrolliert wieder ein. So bleibt der Spagat zwischen strengen Policies und hoher Verfügbarkeit beherrschbar – auch unter Zeitdruck.
Zusammenfassung: Mount-Optionen clever einsetzen
Ich sichere Linux-Hosts wirksam ab, indem ich noexec, nosuid und nodev gezielt auf die passenden Partitionen lege. Temporäre Pfade kapsle ich hart, produktive Datenbereiche erhalten nur die Rechte, die sie wirklich brauchen. Performance-Optionen wie relatime, ro und Quotas setze ich situationsgerecht, damit Betrieb und Sicherheit stimmen. Persistente Einträge in /etc/fstab und regelmäßige Checks mit findmnt halten die Konfiguration verlässlich. Ergänzt um ACLs, umask, chattr und gute Isolationstechniken bleibt die Angriffsfläche klein und die Administration kalkulierbar.
