I servizi di un server Linux protetti a livello di sistema: ecco il security hardening di systemd
Sapevate che systemd, oltre ad essere il PID 1 dei moderni sistemi Linux, offre anche la possibilità di proteggere i servizi? In questa mini guida illustreremo come effettuare una rapida revisione della sicurezza dei servizi e come migliorare la sicurezza.
Il principio della funzionalità di analisi di systemd è quello dell’accesso al kernel Linux, che può filtrare e limitare l’accesso a file system, alle reti, ai dispositivi, alle chiamate di sistema e altro ancora.
Una nota importante: lo strumento di revisione della sicurezza del servizio systemd è stato aggiunto dalla versione 240, ed è questa la minima versione che serve per seguire questa guida. Se avete per esempio Fedora 33, potrete verificare tutto.
systemd-analyze
Eseguendo il comando systemd-analyze security si ottiene un audit di sicurezza di tutti i servizi di systemd:
$ systemd-analyze security --no-pager UNIT EXPOSURE PREDICATE HAPPY ModemManager.service 5.8 MEDIUM 😐 NetworkManager.service 7.8 EXPOSED 🙁 systemd-journald.service 4.4 OK 🙂 ... httpd.service 9.2 UNSAFE 😨 ...
Nell’elenco troviamo tutte le unit di systemd con associato un punteggio di sicurezza, da 0 a 10. Punteggi bassi significano servizi più sicuri. Il punteggio di sicurezza si basa sull’utilizzo da parte di un servizio delle funzionalità di sicurezza fornite da systemd.
Nota: questo audit non considera le funzionalità di sicurezza integrate nel servizio stesso o altri controlli tipo SELinux e non valuta i fattori di rischio di un programma o la sua configurazione.
Dal risultato vediamo che il servizio httpd (Apache HTTP Server) rispetto agli altri ha un punteggio superiore (quindi è più insicuro). Questo perché Fedora Linux, dove è stato effettuato il test, fornisce una unit di servizio httpd con alcune direttive di systemd, che toccano l’aspetto sicurezza, abilitate in maniera predefinita.
Ecco quindi come rivedere le direttive sulla sicurezza di un servizio.
Analisi del servizio specifico
Eseguendo il comando systemd-analyze security httpd.service otteniamo un report delle direttive di sicurezza applicate alla unit httpd.service, riassunto in questo schema:
Possiamo notare che Apache HTTP Server è limitato alla propria directory temporanea e che non ha accesso alla directory system /tmp. Questa è una politica predefinita per httpd su Fedora Linux. Chiaramente i risultati potrebbero essere diversi a seconda della distribuzione Linux utilizzata.
I risultati di audit ci mostrano come ci sia molto spazio per migliorare, a seconda della configurazione del server Apache. Ad esempio, potrebbe non necessitare dell’accesso in scrittura alla maggior parte delle posizioni nella gerarchia di file.
Vediamo quindi come rafforzare sicurezza di httpd.service.
Unit hardening
Eseguendo il comando systemctl edit httpd.service sarà possibile aggiungere delle override alla unit di servizio httpd in maniera istantanea e dinamica, ma è possibile anche modificare le unit con il proprio editor di testo preferito. I path delle stesse si possono ottenere con questo comando:
$ systemd-analyze unit-paths /etc/systemd/system.control /run/systemd/system.control /run/systemd/transient /run/systemd/generator.early /etc/systemd/system /etc/systemd/system.attached /run/systemd/system /run/systemd/system.attached /run/systemd/generator /usr/local/lib/systemd/system /usr/lib/systemd/system /run/systemd/generator.late
Sotto riportiamo come dovrà apparire l’override della unit httpd con la lista dei parametri da applicare alla unit httpd che risolve alcuni dei punti identificati nell’audit di sopra. Sarà possibile far riferimento alla pagina man systemd.exec per avere un’ampia documentazione per ogni direttiva:
$ cat /etc/systemd/system/httpd.service.d/override.conf [Service] PrivateDevices=true ProtectControlGroups=true ProtectHome=true ProtectKernelTunables=true ProtectSystem=full RestrictSUIDSGID=true
Una volta salvate quindi le modifiche, basterà eseguire il comando systemctl daemon-reload per rendere systemd consapevole delle aggiunte e lanciare systemctl restart httpd.service per renderle effettive.
A questo punto una nuova analisi dimostrerà come le modifiche apportate abbiano migliorato lo stato del servizio:
$ systemd-analyze security --no-pager | grep httpd httpd.service 9.2 EXPOSED 🙁
Ben lungi dall’essere ottimale, ma certamente un netto miglioramento.
Conclusioni
systemd consente di proteggere i servizi che gestisce, compensando i limiti delle installazioni di default presenti nelle distribuzioni, forniti in alcuni casi con poca o nessuna protezione. Le esigenze di sicurezza variano da installazione a installazione, quindi spetta all’amministratore di sistema abilitare le protezioni di sicurezza necessarie.
Non sarà quindi sempre necessario applicare tutte le direttive di sicurezza offerte da systemd, così come raggiungere un valore basso per ogni servizio potrebbe risultare proibitivo. Come sempre vale la regola del buonsenso: le giuste precauzioni per i giusti ambiti.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
![[Guida] Cron e Anacron: programmare job periodici su GNU/Linux](;https://www.lffl.org/wp-content/uploads/2020/03/cron-anacron-crontab.png "[Guida] Cron e Anacron: programmare job periodici su GNU/Linux 5")
