Vai al contenuto 
Mirato Montaggio del filesystem-Le opzioni rafforzano la sicurezza del mio server Linux a livello di file system e bloccano gli attacchi tipici che sfruttano percorsi temporanei, file binari setuid e file di dispositivo. Impostando parametri di mount chiari come noexec, impostando nosuid e nodev per definire cosa è consentito sulle singole partizioni, riducendo così in modo significativo il rischio di escalation dei privilegi.
Punti centrali
I seguenti punti chiave offrono un'introduzione diretta alla configurazione sicura delle opzioni di montaggio e illustrano strumenti concreti per Rafforzamento della sicurezza dei server e il funzionamento.
- noexec/nosuid/nodev: Opzioni principali per impedire l'esecuzione di codice, l'uso improprio dei permessi SUID/SGID e i file di dispositivo.
- Percorsi temporanei: Limitare rigorosamente /tmp, /var/tmp e /dev/shm.
- /etc/fstab: Testare e monitorare accuratamente le voci persistenti.
- Opzioni di prestazione: Utilizzare in modo mirato ro, noatime, sync e le quote.
- Aggiunte: Combinare ACL, umask, chattr e crittografia.
Perché le opzioni di montaggio contribuiscono in modo significativo al rafforzamento della sicurezza dei server
Utilizzo opzioni mirate per controllare cosa può accadere nelle partizioni, evitando così inutili Superfici di attacco. L'appello mount -o rw,noexec,nosuid,nodev trasforma un mount standard in un mount rinforzato, che impedisce l'esecuzione di codice e gli exploit setuid. Soprattutto nelle directory scrivibili in comune, questo mi protegge dalle tipiche catene di exploit provenienti da /tmp. Pianifico per ogni partizione quali azioni sono davvero necessarie e limito sistematicamente tutto il resto. In questo modo ottengo, con poco sforzo, risultati nettamente migliori Sicurezza nella vita quotidiana.
noexec, nosuid, nodev: i tre pilastri dell'uso quotidiano
Ho impostato noexec su percorsi temporanei, in modo che i file binari ivi memorizzati non vengano avviati direttamente. Con nosuid disattivo i percorsi di escalation SUID/SGID, soprattutto sui file system esterni e di rete. L'opzione nodev impedisce che qualcuno crei e utilizzi in modo improprio file di sistema pericolosi. Insieme, questi tre controlli bloccano l'esecuzione del codice, l'escalation dei privilegi e gli accessi di basso livello. Questa combinazione riduce notevolmente il rischio di escalation dei privilegi e rafforza la mia Rafforzamento della sicurezza dei server misurabile.
Scenari di utilizzo tipici e opzioni consigliate
Per le directory temporanee come /tmp, /var/tmp e /dev/shm, di norma imposto noexec, nosuid e nodev. Su /var e /var/log rinuncio ai file di dispositivo e ai permessi SUID/SGID, poiché in quei percorsi non hanno alcuna utilità legittima. In /home consento l’esecuzione se necessario, ma blocco SUID/SGID e i file di dispositivo. Per /boot imposto nosuid, nodev, noexec, in modo che solo il bootloader legga e nulla venga eseguito in quella partizione. Questa chiara separazione per ogni partizione aumenta la Resilienza del mio host e facilita la risoluzione dei problemi.
| Punto di montaggio | Opzioni consigliate | Breve descrizione dello scopo |
|---|---|---|
| /tmp, /var/tmp, /dev/shm | noexec, nosuid, nodev | Nessuna esecuzione, nessun SUID/SGID, nessun file di dispositivo |
| /var, /var/log | nosuid, nodev (opzionale: noexec) | Log e spool senza SUID/SGID e senza file di dispositivo |
| /home | nosuid, nodev (opzionale: noexec) | File utente senza SUID/SGID e senza file di dispositivo |
| /boot | nosuid, nodev, noexec | Solo accesso in lettura per i file di avvio |
Utilizzare in modo efficace i sistemi di file speciali e le opzioni avanzate
Prendo in considerazione le peculiarità del mio file system e adeguo le opzioni di conseguenza. Nel caso di ext4, si ottiene dati=ordinati (Standard) e impegnarsi= un buon equilibrio tra coerenza dei dati e frequenza di scrittura. Per le partizioni particolarmente critiche, utilizzo errori=rimontare in modalità sola lettura, in modo che, in caso di errore, il sistema non continui a funzionare senza che ce ne si accorga. Su XFS verifico se inode64 e varianti di quota (usrquota, grpquota, prjquota) sono utili per gestire in modo ordinato grandi strutture di file. Opzioni come user_xattr e acl Lo consento in modo mirato quando le applicazioni richiedono attributi avanzati o diritti più specifici; in caso contrario, cerco di ridurre al minimo la superficie di attacco e mi attengo alle impostazioni predefinite conservative.
Per i volumi SSD e cloud, scelgo consapevolmente tra scartare e cicli di TRIM regolari tramite timer. TRIM online (scartare) libera immediatamente i blocchi di memoria, ma comporta un costo in termini di I/O. In molte configurazioni, l'esecuzione periodica di fstrim più performante e trasparente. Scelgo la strategia di timestamp in base al carico di lavoro: relatime protegge il piano di lavoro e oggi rappresenta un buon compromesso, noatime riduce al minimo gli accessi in scrittura, ma può creare problemi agli strumenti che si basano su tempi di accesso precisi. pigrizia A sua volta, memorizza temporaneamente gli aggiornamenti degli attributi, riducendo così il carico di scrittura senza perdita di semantica: l'ideale quando voglio attenuare le operazioni di I/O in scrittura senza rinunciare ai metadati.
Mi tengo alla larga dalle opzioni di ottimizzazione rischiose, se il loro effetto non è chiarissimo: flag come nobarrier/writeback possono favorire la perdita di dati in caso di interruzione di corrente. Allo stesso modo, valuto funzionalità come DAX solo se l'hardware, il kernel e la versione del filesystem sono compatibili. Il principio rimane: prima testare in modo isolato, poi implementare in modo riproducibile – e sempre con un piano di rollback ben definito.
Trovare il giusto equilibrio tra prestazioni e sicurezza
Uso ro ladove i contenuti cambiano raramente, in modo che nessuno possa iscriversi senza essere notato. Con noatime oppure con `relatime` evito accessi in scrittura superflui, senza sacrificare alla cieca metadati importanti. L'opzione sincronizzazione salva immediatamente le operazioni di scrittura, il che richiede sì del tempo, ma rende più difficile la perdita di dati. Le quote impostate tramite usrquota/grpquota tengono sotto controllo i processi che consumano molto spazio e prevengono i guasti causati da partizioni piene. Per i carichi di lavoro con ext4 o XFS, sto testando ogni opzione in modo controllato, affinché il funzionamento e Sicurezza adatti all'applicazione.
/etc/fstab: configurazione permanente e sicura
Salvo le opzioni definitive in /etc/fstab, in modo che possano resistere a ogni avvio. Prima di riavviare, controllo le voci con mount -a e ricarica i servizi con systemctl daemon-reload, per evitare sorprese. Per la partizione root ritengo che le opzioni debbano essere ridotte al minimo e rimando le restrizioni più rigide a mount dedicati. Esempi di righe come UUID=tmp-uuid /tmp ext4 defaults,nosuid,nodev,noexec 0 2 lo documento in modo accurato, affinché le successive verifiche possano svolgersi rapidamente. Con findmnt --real -o TARGET,OPTIONS confronto la configurazione prevista con quella effettivamente attiva Opzioni.
Integrazione con systemd: montaggio automatico, affidabilità all'avvio e dipendenze
Utilizzo le estensioni di fstab di systemd per migliorare la disponibilità e i tempi di avvio. Con x-systemd.automount Integro i percorsi utilizzati raramente al primo accesso e riduco i rallentamenti all’avvio. nofail assicura che l'host continui ad avviarsi nonostante la mancanza di mount secondari, mentre io con x-systemd.device-timeout= e x-systemd.mount-timeout= Limita i hanging. Per i servizi definisco le dipendenze con x-systemd.requires-mounts-for=/percorso, in modo che le applicazioni si avviino solo quando lo spazio di archiviazione è effettivamente disponibile.
Su backend instabili o lenti, aggiungo inoltre x-systemd.idle-timeout= per i montaggi automatici, in modo che vengano smontati correttamente dopo un periodo di inattività. In questo modo mantengo basso il numero di descrittori aperti, evito i montaggi "zombie" e ottengo un comportamento di esecuzione prevedibile – essenziale in ambienti di grandi dimensioni con molte unità e destinazioni di archiviazione.
Verifica e monitoraggio delle opzioni di montaggio durante il funzionamento
Controllo regolarmente con findmnt, se tutte le partizioni sono state montate come previsto. Individuo immediatamente eventuali discrepanze e le correggo con operazioni mirate di rimontaggio, ad esempio mount -o remount,noexec /tmp. Per gli host in cui il tempo è un fattore critico, imposto delle notifiche nel caso in cui alcune opzioni vengano improvvisamente a mancare o compaiano nuovi mount. Isolamento del contesto tramite Spazi dei nomi e cgroups integra efficacemente il rafforzamento del file system. Nel complesso, riesco a limitare le vie di attacco, a ridurre gli errori di configurazione e ad aumentare la Trasparenza nella vita quotidiana.
Proteggere i pseudo-sistemi di file: /proc, /sys, debugfs e devpts
Tratto i pseudo-sistemi di file con la stessa cura con cui tratto i supporti di dati. Per /proc lo metto accanto a nosuid, nodev, noexec soprattutto hidepid=2, per nascondere i dettagli dei processi degli altri utenti. Nel caso in cui gli amministratori abbiano bisogno di accedere a tali informazioni, utilizzo un gruppo dedicato (gid=) e hidepid=1 oppure 2, a seconda delle esigenze di visibilità. /sys Lo monto rigorosamente con nodev e senza diritti di scrittura non necessari; debugfs In linea di massima rimane smontato, a meno che non ne abbia bisogno temporaneamente a fini diagnostici – in tal caso, esclusivamente per brevi periodi e su sistemi di prova.
Per devpts Controllo la modalità e i diritti di gruppo in modo che gli pseudo-terminali siano ben isolati (ad es. mode=0620,gid=tty). Questi dettagli impediscono accessi incrociati indesiderati tra le sessioni e riducono il rischio che vengano sottratte informazioni riservate. Soprattutto negli ambienti multiutente o di hosting, questa messa a punto rappresenta un elemento fondamentale della Rafforzamento della sicurezza dei server.
Dimensioni e limiti di Tmpfs per /tmp e /dev/shm
Per i sistemi con un elevato carico di I/O o di build, prenderei in considerazione /tmp e /dev/shm come tmpfs, con limiti ben definiti e altamente temprato: tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,mode=1777,size=2G 0 0. In questo modo evito che i file temporanei riempiano i dischi e accelero gli accessi in memoria. Tuttavia, monitoro l’utilizzo della RAM e prevedo delle riserve, in modo che la pressione sulla memoria non comprometta altri servizi. Se singoli strumenti necessitano di percorsi temporanei per i file eseguibili, li isolo tramite directory di lavoro dedicate e mount bind, invece di allentare le regole di sicurezza globali.
Tra /tmp e /var/tmp distinguo consapevolmente: /tmp può essere volatile, /var/tmp dovrebbe resistere ai riavvii. Di conseguenza, scelgo tmpfs piuttosto per /tmp e lasci /var/tmp su disco – anch’esso con noexec, nosuid, nodev. Per carichi elevati sulla memoria condivisa, dimensiono /dev/shm adatto (size=) e applico rigorosamente i diritti del 1777 per garantire la separazione tra gli utenti.
Misure di protezione aggiuntive a livello di file system
Ridurre SUID/SGID-Riduco i file binari al minimo e imposto un valore conservativo per l'umask, ad esempio 027 o 077, in modo che i nuovi file vengano creati con protezione. Attivo gli ACL in modo mirato quando le applicazioni richiedono diritti più specifici e documento le regole con getfacl pulito. Le configurazioni particolarmente delicate le sigillo con chattr +i, per impedire eventuali modifiche. Le quote bloccano tempestivamente gli eccessi di spazio di archiviazione, prima che rallentino i servizi. Per un isolamento efficace dei processi, rimando inoltre a Confronto tra i metodi di isolamento dei processi, al fine di ridurre i rischi al di fuori del file system.
Utilizzare in modo combinato diverse strategie di isolamento
Completo il rafforzamento della sicurezza del file system tramite Isolamento del file system a livello di utente, in modo che le applicazioni non possano accedere al di fuori dei propri limiti. Nelle configurazioni di hosting, un ambiente isolato è vantaggioso perché riduce al minimo i danni causati da eventi imprevisti. A questo proposito, vale la pena dare un’occhiata a Isolamento del file system CageFS, che separa rigorosamente gli ambienti utente. Anche i container e le jail offrono vantaggi se li abbino a opzioni di montaggio restrittive. Questa combinazione colma le lacune che il semplice Opzioni di montaggio non coprire da solo.
Ostacoli e contromisure frequenti
I test noexec con attenzione, perché alcuni strumenti cercano di avviare temporaneamente file binari in /tmp. In questi casi ricorro a directory di lavoro dedicate in cui è consentita l'esecuzione. Per gli script di shell utilizzo chiamate esplicite all'interprete come /bin/bash script.sh, in modo che noexec non costituisca un ostacolo. Se alcune sottodirectory richiedono delle eccezioni, utilizzo i mount Bind con opzioni specifiche. In questo modo mantengo intatto il livello di sicurezza di base e consento solo ciò di cui un’applicazione ha realmente richiesto.
Bind-mount, sottodirectory e propagazione dei mount
Uso mount --bind, per fornire solo gli alberi parziali necessari negli ambienti di destinazione, limitando al contempo i diritti. Con mount -o bind,ro le imposto come di sola lettura e, tramite un successivo mount -o remount,nosuid,nodev,noexec,bind restringo ulteriormente i limiti di sicurezza. Per interi sottoalberi utilizzo --rbind, per includere tutte le sottomontature. È importante la regola di propagazione: con mount --make-private Separo gli eventi di montaggio tra l'host e i chroot/container, in modo che nessun montaggio indesiderato „passi attraverso“.
Laddove è attiva l'orchestrazione dei container, mantengo i percorsi centrali come impostazione predefinita privato e aprire in modo mirato solo ciò di cui i carichi di lavoro hanno bisogno. Nelle fasi di debug è possibile condiviso può essere utile, durante il funzionamento normale è privato/slave La scelta più sicura. In questo modo le topologie di montaggio rimangono prevedibili ed evito che percorsi privilegiati compaiano accidentalmente negli ambienti guest.
Indurimento dei supporti remoti e rimovibili
Di norma, monto le unità esterne e le condivisioni di rete utilizzando nosuid,nodev e nella maggior parte dei casi anche noexec. Per VFAT/NTFS, modifico i proprietari e le maschere (ad es. uid=1000,gid=1000,umask=027,fmask=137,dmask=027), affinché i bit di esecuzione non diventino una porta d’accesso. Sui supporti rimovibili non vi è alcuna necessità legittima di SUID/SGID o file di dispositivo: disattivo sistematicamente queste funzioni. Se desidero solo leggere, si aggiunge inoltre ro viene utilizzato. In questo modo il codice dannoso rimane inefficace e non può essere scaricato di nascosto.
Anche per NFS/SMB limito rigorosamente i privilegi. nosuid, nodev, noexec sono impostazioni predefinite; i timeout e i tentativi li imposta intenzionalmente (hard/soft,timeo=), in modo che eventuali guasti non blocchino l'intero sistema. Per i dati sensibili prevedo misure di integrità e crittografia a livello di protocollo e mi assicuro che il client e il server applichino politiche coerenti. Minore è il potere decisionale della controparte riguardo all'host locale, più stabile e prevedibile rimane il funzionamento del sistema.
Passo dopo passo: implementare in modo sicuro una configurazione di esempio
Comincio con un inventario tramite findmnt --real -o TARGET,OPTIONS e documenta tutti quelli attivi Montature. Dopodiché mi adatterò /etc/fstab ad esempio con righe per /tmp e /dev/shm che includano noexec, nosuid, nodev. Successivamente eseguo un test con mount -a e verifico nuovamente l'effetto con findmnt. Se tutto funziona correttamente, imposto le quote dove gli account utente stanno crescendo e attivo relatime o noatime a seconda delle necessità. Infine, registro le modifiche nel mio registro delle modifiche e pianifico regolari Controlli.
Controllo della deriva, audit e rollback sicuro
Definisco le mie politiche di montaggio come „stato desiderato“ e verifico regolarmente la presenza di eventuali scostamenti. Oltre a findmnt e /proc/mounts Utilizzo semplici controlli negli script di Health che generano un allarme quando i percorsi critici non noexec, nosuid oppure nodev funzionare. Modifiche a /etc/fstab Documento le unità systemd indicando la versione; prima di apportare modifiche rischiose, creo degli snapshot (ad esempio tramite LVM/btrfs), in modo da poter tornare rapidamente indietro in caso di emergenza. Per i sistemi particolarmente sensibili, pianifico delle finestre di manutenzione e testo in anticipo i rimount su host di staging identici.
C'è sempre un'ancora di salvezza pragmatica a portata di mano: con mount -o remount,defaults oppure, tramite flag di esclusione mirati, annullo temporaneamente le opzioni più restrittive qualora un servizio smetta di funzionare in modo imprevisto. Successivamente, isolo la causa, adeguo le eccezioni relative ai mount Bind e reintroduco il rafforzamento in modo controllato. In questo modo, il compromesso tra politiche rigorose e alta disponibilità rimane gestibile, anche sotto pressione.
Sintesi: Utilizzare le opzioni di montaggio in modo intelligente
Proteggo efficacemente gli host Linux: noexec, imposto in modo mirato i permessi nosuid e nodev sulle partizioni appropriate. Incapsulo rigorosamente i percorsi temporanei, mentre alle aree dati produttive assegno solo i permessi di cui hanno realmente bisogno. Impostiamo le opzioni di prestazione come relatime, ro e le quote in base alla situazione, in modo da garantire il corretto funzionamento e la sicurezza. Le voci persistenti in /etc/fstab e i controlli regolari con findmnt garantiscono l’affidabilità della configurazione. Integrata con ACL, umask, chattr e buone tecniche di isolamento, la Superficie di attacco di piccole dimensioni e con oneri amministrativi prevedibili.
