Hardening e vulnerabilità

Bloccare gli attacchi è metà del lavoro; l'altra metà è chiudere ciò che li ha fatti entrare. Ogni server esegue un controllo di hardening e un audit del software 10 minuti dopo l'avvio dell'agente, poi una volta al giorno. Controlla ora e Controlla il software ora nella scheda Sicurezza del server li eseguono subito.

Il controllo di hardening#

Controlla:

• SSH: login di root, autenticazione con password, porta predefinita, X11 forwarding, numero massimo di tentativi di autenticazione;
• file: i permessi di /etc/shadow, /etc/passwd, sshd_config e degli authorized_keys di root;
• porte: i servizi in ascolto sulla rete pubblica;
• utenti: account con UID 0 diversi da root, account senza password;
• firewall e processi (zombie);
• credenziali: file .env leggibili da tutti, directory .git esposte nelle web root, i permessi delle directory .ssh;
• web server: esposizione della versione, directory listing, il metodo TRACE, protocolli TLS, header di sicurezza, rate limiting, dimensione massima del body delle richieste e impostazioni di prestazioni;
• versioni: sistema operativo a fine vita, kernel, aggiornamenti di sicurezza in sospeso, PHP, MySQL, OpenSSH e il web server.
• PHP: la configurazione di ogni runtime PHP e di ogni pool PHP-FPM (vedi Hardening di PHP più sotto).

Ogni controllo spiega cos'è, perché è importante e come risolverlo.

I controlli SSH leggono la configurazione che sshd usa davvero: sshd -T oppure, quando non può essere eseguito, i file nell'ordine di sshd stesso (agent 1.0.35 o successivo). sshd tiene il primo valore che legge, e sulle distribuzioni attuali sshd_config include i drop-in di /etc/ssh/sshd_config.d/ all'inizio, quindi vince un drop-in: su un server cloud appena creato, il 50-cloud-init.conf di cloud-init spesso riattiva il login con password. Il risultato indica il file e la riga che impostano il valore, per esempio /etc/ssh/sshd_config.d/50-cloud-init.conf:1: modificalo lì.

Quanti controlli riceve un server dipende dal server: da 40 a 50 sulla maggior parte. I controlli del web server dipendono da quali sono installati, nginx, Apache o entrambi, e i controlli PHP (da sei a nove) si ripetono per ogni runtime PHP e ogni pool PHP-FPM, quindi un server con molti pool ne riceve di più.

Correzioni con un clic#

Dieci controlli si possono risolvere con Correggi automaticamente:

InfraFence scrive ogni modifica in un file a parte (/etc/ssh/sshd_config.d/00-infrafence-hardening.conf, oppure zz-infrafence-hardening.conf per nginx e Apache), verifica la configurazione (sshd -t, nginx -t, apachectl configtest) e ricarica il servizio: le sessioni e le connessioni aperte non vengono interrotte. Annulla la correzione la toglie.

Alcuni controlli non sono mai automatici, perché se fatti male potrebbero chiuderti fuori o cambiare il comportamento dei tuoi siti: login di root, autenticazione con password, porta SSH, directory listing, protocolli TLS e header di sicurezza. La loro pagina spiega come risolverli a mano. Su un server la cui configurazione è gestita da un pannello di hosting o da uno strumento di gestione della configurazione, sono automatiche solo le correzioni dei permessi.

Hardening di PHP#

Il controllo legge la configurazione effettiva di ogni runtime PHP del server: il PHP della distribuzione, ondrej, remi, cPanel EA4, Plesk e CloudLinux alt-php. Segue php.ini e la cartella di scansione nello stesso ordine di PHP, e controlla ogni pool PHP-FPM con le sue sostituzioni php_value e php_admin_value. Il PHP da riga di comando non viene controllato.

"Con approvazione" richiede l'autenticazione a due fattori. Le correzioni di cgi.fix_pathinfo e disable_functions le applica solo un proprietario o un admin con accesso tramite autenticazione a due fattori: con Rivedi e applica nella scheda Sicurezza del server, oppure in Approvazioni quando lo chiede AutoMode. Senza 2FA la dashboard non le applica. Attivala in Impostazioni › Sicurezza.

Ogni segnalazione indica il runtime, il pool, il valore e il file e la riga da cui viene. Prima di approvare una correzione di disable_functions, la dashboard elenca i file dei siti che chiamano quelle funzioni (fino a 20).

Le correzioni vanno in un file di InfraFence, zz-infrafence-hardening.ini nella cartella di scansione del runtime; php.ini e i file dei tuoi pool non vengono mai modificati. Quando un pool imposta il valore nel proprio file, un drop-in non può sostituirlo: la segnalazione indica allora la riga esatta da cambiare a mano in quel file. L'agent verifica la configurazione (php-fpm -t), controlla che il nuovo valore sia quello effettivo, ricarica PHP-FPM senza interruzioni (mai un riavvio) ed esegue lo stesso controllo dei siti delle altre correzioni: se un sito smette di rispondere, la modifica viene annullata. Una correzione nel file del runtime vale per ogni pool di quel runtime che non imposta il valore da sé.

L'agent sorveglia anche questi file. Quando viene attivato allow_url_include o display_errors, l'evento Comparsa un'impostazione PHP rischiosa indica il file, una volta per modifica. Se qualcun altro modifica il file di InfraFence (un pannello, un pacchetto, una persona), ricevi un evento anche per questo.

Su cPanel, Plesk e CloudLinux la configurazione di PHP viene segnalata, mai modificata, e i file per sito (il php.ini di Plesk, il .user.ini di cPanel) vengono solo segnalati.

È hardening e sorveglianza della configurazione. In PHP non viene caricato nulla e non ferma un attacco dentro la tua applicazione: di questo si occupano il web firewall e lo scanner malware.

Verifica e annullamento#

Prima di una correzione l'agente annota quali porte SSH accettano connessioni e quali siti rispondono senza errori del server, in HTTP e HTTPS (fino a 20 siti). Dopo il reload li ricontrolla per un massimo di 20 secondi. Se uno smette di rispondere, annulla la modifica da solo e il risultato riporta Annullata dal server. Le correzioni dei permessi non hanno annullamento automatico: un permesso più restrittivo non rompe un servizio.

La stessa verifica protegge la chiusura delle porte, i blocchi in uscita e le patch virtuali.

Vulnerabilità (CVE)#

L'audit del software invia l'elenco dei pacchetti installati alla dashboard, che lo confronta con il database OSV. Funziona su Debian, Ubuntu, AlmaLinux e Rocky Linux. Il pannello Vulnerabilità (CVE) elenca i pacchetti per cui è disponibile una correzione e segnala quelli presenti nella lista CISA delle vulnerabilità sfruttate attivamente (Sfruttata attivamente (CISA KEV)): aggiorna prima quelli.

Aggiornamenti di sicurezza#

Aggiorna tutti o Aggiorna questo pacchetto installa le versioni corrette. L'agente aggiorna solo quei pacchetti (non installa né rimuove nient'altro), mantiene i tuoi file di configurazione, si rifiuta di partire mentre è in corso un'altra operazione sui pacchetti e non riavvia mai il server. L'aggiornamento di un pacchetto può riavviare per un momento il suo servizio. Quando serve un riavvio, o un servizio sta ancora eseguendo il vecchio codice, il risultato lo segnala.

Punteggio di sicurezza#

I risultati alimentano il punteggio di sicurezza del server, da 0 a 100, con le correzioni principali in cima. Vedi Server.