{"id":20292,"date":"2026-08-03T15:05:08","date_gmt":"2026-08-03T13:05:08","guid":{"rendered":"https:\/\/webhosting.de\/filesystem-mount-options-linux-serverhaertung-securefs\/"},"modified":"2026-08-03T15:05:08","modified_gmt":"2026-08-03T13:05:08","slug":"opzioni-di-montaggio-del-filesystem-hardening-del-server-linux-securefs","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/filesystem-mount-options-linux-serverhaertung-securefs\/","title":{"rendered":"Opzioni di montaggio del filesystem per il rafforzamento della sicurezza del server: configurare correttamente la sicurezza del server in Linux"},"content":{"rendered":"<p>Mirato <strong>Montaggio del filesystem<\/strong>-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 <strong>noexec<\/strong>, impostando nosuid e nodev per definire cosa \u00e8 consentito sulle singole partizioni, riducendo cos\u00ec in modo significativo il rischio di escalation dei privilegi.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>I seguenti punti chiave offrono un'introduzione diretta alla configurazione sicura delle opzioni di montaggio e illustrano strumenti concreti per <strong>Rafforzamento della sicurezza dei server<\/strong> e il funzionamento.<\/p>\n<ul>\n  <li><strong>noexec\/nosuid\/nodev<\/strong>: Opzioni principali per impedire l'esecuzione di codice, l'uso improprio dei permessi SUID\/SGID e i file di dispositivo.<\/li>\n  <li><strong>Percorsi temporanei<\/strong>: Limitare rigorosamente \/tmp, \/var\/tmp e \/dev\/shm.<\/li>\n  <li><strong>\/etc\/fstab<\/strong>: Testare e monitorare accuratamente le voci persistenti.<\/li>\n  <li><strong>Opzioni di prestazione<\/strong>: Utilizzare in modo mirato ro, noatime, sync e le quote.<\/li>\n  <li><strong>Aggiunte<\/strong>: Combinare ACL, umask, chattr e crittografia.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-server-sicherheit-4123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perch\u00e9 le opzioni di montaggio contribuiscono in modo significativo al rafforzamento della sicurezza dei server<\/h2>\n<p>Utilizzo opzioni mirate per controllare cosa pu\u00f2 accadere nelle partizioni, evitando cos\u00ec inutili <strong>Superfici di attacco<\/strong>. L'appello <code>mount -o rw,noexec,nosuid,nodev<\/code> 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 <strong>Sicurezza<\/strong> nella vita quotidiana.<\/p>\n\n<h2>noexec, nosuid, nodev: i tre pilastri dell'uso quotidiano<\/h2>\n<p>Ho impostato <strong>noexec<\/strong> su percorsi temporanei, in modo che i file binari ivi memorizzati non vengano avviati direttamente. Con <strong>nosuid<\/strong> disattivo i percorsi di escalation SUID\/SGID, soprattutto sui file system esterni e di rete. L'opzione <strong>nodev<\/strong> 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 <strong>Rafforzamento della sicurezza dei server<\/strong> misurabile.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/ServerSicherheitLinux4578.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Scenari di utilizzo tipici e opzioni consigliate<\/h2>\n<p>Per le directory temporanee come \/tmp, \/var\/tmp e \/dev\/shm, di norma imposto <strong>noexec<\/strong>, nosuid e nodev. Su \/var e \/var\/log rinuncio ai file di dispositivo e ai permessi SUID\/SGID, poich\u00e9 in quei percorsi non hanno alcuna utilit\u00e0 legittima. In \/home consento l\u2019esecuzione 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 <strong>Resilienza<\/strong> del mio host e facilita la risoluzione dei problemi.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Punto di montaggio<\/th>\n      <th>Opzioni consigliate<\/th>\n      <th>Breve descrizione dello scopo<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>\/tmp, \/var\/tmp, \/dev\/shm<\/td>\n      <td>noexec, nosuid, nodev<\/td>\n      <td>Nessuna esecuzione, nessun SUID\/SGID, nessun file di dispositivo<\/td>\n    <\/tr>\n    <tr>\n      <td>\/var, \/var\/log<\/td>\n      <td>nosuid, nodev (opzionale: noexec)<\/td>\n      <td>Log e spool senza SUID\/SGID e senza file di dispositivo<\/td>\n    <\/tr>\n    <tr>\n      <td>\/home<\/td>\n      <td>nosuid, nodev (opzionale: noexec)<\/td>\n      <td>File utente senza SUID\/SGID e senza file di dispositivo<\/td>\n    <\/tr>\n    <tr>\n      <td>\/boot<\/td>\n      <td>nosuid, nodev, noexec<\/td>\n      <td>Solo accesso in lettura per i file di avvio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Utilizzare in modo efficace i sistemi di file speciali e le opzioni avanzate<\/h2>\n<p>Prendo in considerazione le peculiarit\u00e0 del mio file system e adeguo le opzioni di conseguenza. Nel caso di ext4, si ottiene <code>dati=ordinati<\/code> (Standard) e <code>impegnarsi=<\/code> un buon equilibrio tra coerenza dei dati e frequenza di scrittura. Per le partizioni particolarmente critiche, utilizzo <code>errori=rimontare in modalit\u00e0 sola lettura<\/code>, in modo che, in caso di errore, il sistema non continui a funzionare senza che ce ne si accorga. Su XFS verifico se <code>inode64<\/code> e varianti di quota (<code>usrquota<\/code>, <code>grpquota<\/code>, <code>prjquota<\/code>) sono utili per gestire in modo ordinato grandi strutture di file. Opzioni come <code>user_xattr<\/code> e <code>acl<\/code> Lo consento in modo mirato quando le applicazioni richiedono attributi avanzati o diritti pi\u00f9 specifici; in caso contrario, cerco di ridurre al minimo la superficie di attacco e mi attengo alle impostazioni predefinite conservative.<\/p>\n<p>Per i volumi SSD e cloud, scelgo consapevolmente tra <code>scartare<\/code> e cicli di TRIM regolari tramite timer. TRIM online (<code>scartare<\/code>) libera immediatamente i blocchi di memoria, ma comporta un costo in termini di I\/O. In molte configurazioni, l'esecuzione periodica di <em>fstrim<\/em> pi\u00f9 performante e trasparente. Scelgo la strategia di timestamp in base al carico di lavoro: <code>relatime<\/code> protegge il piano di lavoro e oggi rappresenta un buon compromesso, <code>noatime<\/code> riduce al minimo gli accessi in scrittura, ma pu\u00f2 creare problemi agli strumenti che si basano su tempi di accesso precisi. <code>pigrizia<\/code> A sua volta, memorizza temporaneamente gli aggiornamenti degli attributi, riducendo cos\u00ec il carico di scrittura senza perdita di semantica: l'ideale quando voglio attenuare le operazioni di I\/O in scrittura senza rinunciare ai metadati.<\/p>\n<p>Mi tengo alla larga dalle opzioni di ottimizzazione rischiose, se il loro effetto non \u00e8 chiarissimo: flag come <code>nobarrier<\/code>\/<code>writeback<\/code> possono favorire la perdita di dati in caso di interruzione di corrente. Allo stesso modo, valuto funzionalit\u00e0 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 \u2013 e sempre con un piano di rollback ben definito.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-server-security-config-4005.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Trovare il giusto equilibrio tra prestazioni e sicurezza<\/h2>\n<p>Uso <strong>ro<\/strong> ladove i contenuti cambiano raramente, in modo che nessuno possa iscriversi senza essere notato. Con <strong>noatime<\/strong> oppure con `relatime` evito accessi in scrittura superflui, senza sacrificare alla cieca metadati importanti. L'opzione <strong>sincronizzazione<\/strong> salva immediatamente le operazioni di scrittura, il che richiede s\u00ec del tempo, ma rende pi\u00f9 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\u00e9 il funzionamento e <strong>Sicurezza<\/strong> adatti all'applicazione.<\/p>\n\n<h2>\/etc\/fstab: configurazione permanente e sicura<\/h2>\n<p>Salvo le opzioni definitive in <strong>\/etc\/fstab<\/strong>, in modo che possano resistere a ogni avvio. Prima di riavviare, controllo le voci con <code>mount -a<\/code> e ricarica i servizi con <code>systemctl daemon-reload<\/code>, per evitare sorprese. Per la partizione root ritengo che le opzioni debbano essere ridotte al minimo e rimando le restrizioni pi\u00f9 rigide a mount dedicati. Esempi di righe come <code>UUID=tmp-uuid \/tmp ext4 defaults,nosuid,nodev,noexec 0 2<\/code> lo documento in modo accurato, affinch\u00e9 le successive verifiche possano svolgersi rapidamente. Con <code>findmnt --real -o TARGET,OPTIONS<\/code> confronto la configurazione prevista con quella effettivamente attiva <strong>Opzioni<\/strong>.<\/p>\n\n<h2>Integrazione con systemd: montaggio automatico, affidabilit\u00e0 all'avvio e dipendenze<\/h2>\n<p>Utilizzo le estensioni di fstab di systemd per migliorare la disponibilit\u00e0 e i tempi di avvio. Con <code>x-systemd.automount<\/code> Integro i percorsi utilizzati raramente al primo accesso e riduco i rallentamenti all\u2019avvio. <code>nofail<\/code> assicura che l'host continui ad avviarsi nonostante la mancanza di mount secondari, mentre io con <code>x-systemd.device-timeout=<\/code> e <code>x-systemd.mount-timeout=<\/code> Limita i hanging. Per i servizi definisco le dipendenze con <code>x-systemd.requires-mounts-for=\/percorso<\/code>, in modo che le applicazioni si avviino solo quando lo spazio di archiviazione \u00e8 effettivamente disponibile.<\/p>\n<p>Su backend instabili o lenti, aggiungo inoltre <code>x-systemd.idle-timeout=<\/code> per i montaggi automatici, in modo che vengano smontati correttamente dopo un periodo di inattivit\u00e0. In questo modo mantengo basso il numero di descrittori aperti, evito i montaggi \"zombie\" e ottengo un comportamento di esecuzione prevedibile \u2013 essenziale in ambienti di grandi dimensioni con molte unit\u00e0 e destinazioni di archiviazione.<\/p>\n\n<h2>Verifica e monitoraggio delle opzioni di montaggio durante il funzionamento<\/h2>\n<p>Controllo regolarmente con <strong>findmnt<\/strong>, se tutte le partizioni sono state montate come previsto. Individuo immediatamente eventuali discrepanze e le correggo con operazioni mirate di rimontaggio, ad esempio <code>mount -o remount,noexec \/tmp<\/code>. Per gli host in cui il tempo \u00e8 un fattore critico, imposto delle notifiche nel caso in cui alcune opzioni vengano improvvisamente a mancare o compaiano nuovi mount. Isolamento del contesto tramite <a href=\"https:\/\/webhosting.de\/it\/contesto-server-isolamento-spazi-dei-nomi-cgroups-hosting-sicurezza\/\">Spazi dei nomi e cgroups<\/a> 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 <strong>Trasparenza<\/strong> nella vita quotidiana.<\/p>\n\n<h2>Proteggere i pseudo-sistemi di file: \/proc, \/sys, debugfs e devpts<\/h2>\n<p>Tratto i pseudo-sistemi di file con la stessa cura con cui tratto i supporti di dati. Per <code>\/proc<\/code> lo metto accanto a <code>nosuid, nodev, noexec<\/code> soprattutto <code>hidepid=2<\/code>, 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 (<code>gid=<\/code>) e <code>hidepid=1<\/code> oppure <code>2<\/code>, a seconda delle esigenze di visibilit\u00e0. <code>\/sys<\/code> Lo monto rigorosamente con <code>nodev<\/code> e senza diritti di scrittura non necessari; <code>debugfs<\/code> In linea di massima rimane smontato, a meno che non ne abbia bisogno temporaneamente a fini diagnostici \u2013 in tal caso, esclusivamente per brevi periodi e su sistemi di prova.<\/p>\n<p>Per <code>devpts<\/code> Controllo la modalit\u00e0 e i diritti di gruppo in modo che gli pseudo-terminali siano ben isolati (ad es. <code>mode=0620,gid=tty<\/code>). 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 <strong>Rafforzamento della sicurezza dei server<\/strong>.<\/p>\n\n<h2>Dimensioni e limiti di Tmpfs per \/tmp e \/dev\/shm<\/h2>\n<p>Per i sistemi con un elevato carico di I\/O o di build, prenderei in considerazione <code>\/tmp<\/code> e <code>\/dev\/shm<\/code> come <code>tmpfs<\/code>, con limiti ben definiti e altamente temprato: <code>tmpfs \/tmp tmpfs rw,nosuid,nodev,noexec,mode=1777,size=2G 0 0<\/code>. In questo modo evito che i file temporanei riempiano i dischi e accelero gli accessi in memoria. Tuttavia, monitoro l\u2019utilizzo 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.<\/p>\n<p>Tra <code>\/tmp<\/code> e <code>\/var\/tmp<\/code> distinguo consapevolmente: <code>\/tmp<\/code> pu\u00f2 essere volatile, <code>\/var\/tmp<\/code> dovrebbe resistere ai riavvii. Di conseguenza, scelgo <code>tmpfs<\/code> piuttosto per <code>\/tmp<\/code> e lasci <code>\/var\/tmp<\/code> su disco \u2013 anch\u2019esso con <code>noexec, nosuid, nodev<\/code>. Per carichi elevati sulla memoria condivisa, dimensiono <code>\/dev\/shm<\/code> adatto (<code>size=<\/code>) e applico rigorosamente i diritti del 1777 per garantire la separazione tra gli utenti.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/Server-Konfiguration1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Misure di protezione aggiuntive a livello di file system<\/h2>\n<p>Ridurre <strong>SUID\/SGID<\/strong>-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\u00f9 specifici e documento le regole con <code>getfacl<\/code> pulito. Le configurazioni particolarmente delicate le sigillo con <code>chattr +i<\/code>, 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 <a href=\"https:\/\/webhosting.de\/it\/processo-isolamento-hosting-chroot-cagefs-container-jails-sicurezza-confronto\/\">Confronto tra i metodi di isolamento dei processi<\/a>, al fine di ridurre i rischi al di fuori del file system.<\/p>\n\n<h2>Utilizzare in modo combinato diverse strategie di isolamento<\/h2>\n<p>Completo il rafforzamento della sicurezza del file system tramite <strong>Isolamento del file system<\/strong> 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 \u00e8 vantaggioso perch\u00e9 riduce al minimo i danni causati da eventi imprevisti. A questo proposito, vale la pena dare un\u2019occhiata a <a href=\"https:\/\/webhosting.de\/it\/cloudlinux-cagefs-isolamento-del-file-system-sicurezza-hostingshield\/\">Isolamento del file system CageFS<\/a>, 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 <strong>Opzioni di montaggio<\/strong> non coprire da solo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/Linux_Server_Haertung_5203.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ostacoli e contromisure frequenti<\/h2>\n<p>I test <strong>noexec<\/strong> con attenzione, perch\u00e9 alcuni strumenti cercano di avviare temporaneamente file binari in \/tmp. In questi casi ricorro a directory di lavoro dedicate in cui \u00e8 consentita l'esecuzione. Per gli script di shell utilizzo chiamate esplicite all'interprete come <code>\/bin\/bash script.sh<\/code>, 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\u00f2 di cui un\u2019applicazione ha realmente <strong>richiesto<\/strong>.<\/p>\n\n<h2>Bind-mount, sottodirectory e propagazione dei mount<\/h2>\n<p>Uso <code>mount --bind<\/code>, per fornire solo gli alberi parziali necessari negli ambienti di destinazione, limitando al contempo i diritti. Con <code>mount -o bind,ro<\/code> le imposto come di sola lettura e, tramite un successivo <code>mount -o remount,nosuid,nodev,noexec,bind<\/code> restringo ulteriormente i limiti di sicurezza. Per interi sottoalberi utilizzo <code>--rbind<\/code>, per includere tutte le sottomontature. \u00c8 importante la regola di propagazione: con <code>mount --make-private<\/code> Separo gli eventi di montaggio tra l'host e i chroot\/container, in modo che nessun montaggio indesiderato \u201epassi attraverso\u201c.<\/p>\n<p>Laddove \u00e8 attiva l'orchestrazione dei container, mantengo i percorsi centrali come impostazione predefinita <em>privato<\/em> e aprire in modo mirato solo ci\u00f2 di cui i carichi di lavoro hanno bisogno. Nelle fasi di debug \u00e8 possibile <em>condiviso<\/em> pu\u00f2 essere utile, durante il funzionamento normale \u00e8 <em>privato\/slave<\/em> La scelta pi\u00f9 sicura. In questo modo le topologie di montaggio rimangono prevedibili ed evito che percorsi privilegiati compaiano accidentalmente negli ambienti guest.<\/p>\n\n<h2>Indurimento dei supporti remoti e rimovibili<\/h2>\n<p>Di norma, monto le unit\u00e0 esterne e le condivisioni di rete utilizzando <code>nosuid,nodev<\/code> e nella maggior parte dei casi anche <code>noexec<\/code>. Per VFAT\/NTFS, modifico i proprietari e le maschere (ad es. <code>uid=1000,gid=1000,umask=027,fmask=137,dmask=027<\/code>), affinch\u00e9 i bit di esecuzione non diventino una porta d\u2019accesso. Sui supporti rimovibili non vi \u00e8 alcuna necessit\u00e0 legittima di SUID\/SGID o file di dispositivo: disattivo sistematicamente queste funzioni. Se desidero solo leggere, si aggiunge inoltre <code>ro<\/code> viene utilizzato. In questo modo il codice dannoso rimane inefficace e non pu\u00f2 essere scaricato di nascosto.<\/p>\n<p>Anche per NFS\/SMB limito rigorosamente i privilegi. <code>nosuid, nodev, noexec<\/code> sono impostazioni predefinite; i timeout e i tentativi li imposta intenzionalmente (<code>hard\/soft,timeo=<\/code>), in modo che eventuali guasti non blocchino l'intero sistema. Per i dati sensibili prevedo misure di integrit\u00e0 e crittografia a livello di protocollo e mi assicuro che il client e il server applichino politiche coerenti. Minore \u00e8 il potere decisionale della controparte riguardo all'host locale, pi\u00f9 stabile e prevedibile rimane il funzionamento del sistema.<\/p>\n\n<h2>Passo dopo passo: implementare in modo sicuro una configurazione di esempio<\/h2>\n<p>Comincio con un inventario tramite <code>findmnt --real -o TARGET,OPTIONS<\/code> e documenta tutti quelli attivi <strong>Montature<\/strong>. Dopodich\u00e9 mi adatter\u00f2 <code>\/etc\/fstab<\/code> ad esempio con righe per \/tmp e \/dev\/shm che includano noexec, nosuid, nodev. Successivamente eseguo un test con <code>mount -a<\/code> 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\u00e0. Infine, registro le modifiche nel mio registro delle modifiche e pianifico regolari <strong>Controlli<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverconfig-raum-8394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Controllo della deriva, audit e rollback sicuro<\/h2>\n<p>Definisco le mie politiche di montaggio come \u201estato desiderato\u201c e verifico regolarmente la presenza di eventuali scostamenti. Oltre a <code>findmnt<\/code> e <code>\/proc\/mounts<\/code> Utilizzo semplici controlli negli script di Health che generano un allarme quando i percorsi critici non <code>noexec<\/code>, <code>nosuid<\/code> oppure <code>nodev<\/code> funzionare. Modifiche a <code>\/etc\/fstab<\/code> Documento le unit\u00e0 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.<\/p>\n<p>C'\u00e8 sempre un'ancora di salvezza pragmatica a portata di mano: con <code>mount -o remount,defaults<\/code> oppure, tramite flag di esclusione mirati, annullo temporaneamente le opzioni pi\u00f9 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\u00e0 rimane gestibile, anche sotto pressione.<\/p>\n\n<h2>Sintesi: Utilizzare le opzioni di montaggio in modo intelligente<\/h2>\n<p>Proteggo efficacemente gli host Linux: <strong>noexec<\/strong>, 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\u2019affidabilit\u00e0 della configurazione. Integrata con ACL, umask, chattr e buone tecniche di isolamento, la <strong>Superficie di attacco<\/strong> di piccole dimensioni e con oneri amministrativi prevedibili.<\/p>","protected":false},"excerpt":{"rendered":"<p>Questo articolo illustra come ottimizzare la sicurezza e il rafforzamento del tuo server Linux utilizzando opzioni di montaggio sicure del filesystem e come impiegare correttamente noexec, nosuid e nodev.<\/p>","protected":false},"author":1,"featured_media":20285,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20292","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"114","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Filesystem Mount","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20285","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20292","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=20292"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20292\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20285"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20292"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20292"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20292"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}