Sicurezza Avanzata WordPress: Risolvere SELinux, Regole POSIX ACL e Ripristino Backup

Gestire un server dedicato o una VPS per WordPress richiede competenze specifiche. A volte i normali permessi Unix (chmod e chown) non bastano. Se riscontri errori nel caricamento dei media, consulta prima la nostra guida principale sui problemi di upload. In questa guida analizziamo i controlli di sicurezza avanzati wordpress per sistemi Linux enterprise come RHEL, AlmaLinux, Rocky Linux e Debian.

Quando il web server riceve un errore di tipo Access Denied, la causa può risiedere nei moduli di sicurezza del kernel. Sistemi come SELinux o le liste di controllo degli accessi (POSIX ACL) impongono barriere invisibili. Imparare a configurare questi parametri protegge il sito e garantisce la corretta esecuzione di ogni script PHP.

Comprendere SELinux e i blocchi di scrittura su WordPress

Cos’è SELinux e perché blocca la cartella wp-content

Security-Enhanced Linux (SELinux) è un’estensione del kernel che implementa il controllo degli accessi obbligatorio (MAC). Il sistema associa a ogni file, directory e processo un’etichetta di sicurezza. Anche se assegni la proprietà a www-data o apache con permessi 775, SELinux può impedire la scrittura.

Il server web gira normalmente con un contesto limitato, come httpd_t. Se la directory uploads possiede un contesto non compatibile, il demone PHP non potrà inserire immagini o creare sottocartelle. Questo accade spesso dopo una migrazione manuale o un download via SSH.

Diagnosi rapida con ausearch e audit2allow

Per confermare che il problema derivi da SELinux, controlla i log del server. Il file principale risiede in /var/log/audit/audit.log. Puoi filtrare i messaggi di diniego con un comando specifico:

  • Esegui: ausearch -m avc -ts recent per individuare i blocchi recenti.
  • Usa grep "denied" /var/log/audit/audit.log per esaminare l’elenco cronologico.
  • Lancia audit2allow -w -a per visualizzare una spiegazione umana dell’errore.

Se visualizzi un rifiuto sul processo php-fpm o httpd verso la cartella uploads, la causa è accertata. Non disabilitare mai SELinux a livello globale. Esiste una soluzione corretta e sicura per ripristinare il flusso di lavoro.

Configurare correttamente i contesti SELinux per uploads

Assegnare il contesto httpd_sys_rw_content_t con semanage

La directory wp-content/uploads deve consentire operazioni di lettura e scrittura da parte dei processi web. Il tipo di contesto standard da applicare è httpd_sys_rw_content_t. Questo tipo autorizza Nginx, Apache e PHP-FPM a creare e modificare file.

Per applicare la regola in modo persistente ai riavvii, usa il comando semanage:

  1. Installa gli strumenti di policy: dnf install policycoreutils-python-utils.
  2. Definisci la regola per uploads: semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/wp-content/uploads(/.*)?".
  3. Se utilizzi una cartella personalizzata, adatta il percorso assoluto specificato nel comando.

Applicare le modifiche con il comando restorecon

La modifica con semanage salva la regola nel database di sicurezza, ma non modifica i file esistenti. Per forzare il ricalcolo immediato dei contesti, devi usare restorecon. Questo strumento legge le policy registrate e le impone al file system.

Lancia nel terminale il seguente comando con privilegi di root:

  • restorecon -Rv /var/www/html/wp-content/uploads

Il parametro -R applica l’operazione in maniera ricorsiva a tutte le sottocartelle annuali e mensili. Il parametro -v stampa a schermo i dettagli di ogni file modificato. In questo modo puoi verificare immediatamente l’aggiornamento dell’etichetta SELinux.

Avviso di sicurezza: Evita l’impostazione setenforce 0 se non per una brevissima sessione di debug. Disattivare SELinux espone l’intero server a compromissioni gravi in caso di vulnerabilità nei plugin installati.

Impostare i Boolean di sistema per il web server

In molte configurazioni, WordPress deve contattare servizi esterni o inviare email tramite script locali. SELinux vincola queste azioni tramite variabili booleane dedicate. Puoi verificare i valori correnti con il comando getsebool.

Ecco i flag consigliati per un’infrastruttura WordPress solida:

  • setsebool -P httpd_can_network_connect 1 (permette connessioni HTTP esterne come API e webhook).
  • setsebool -P httpd_can_sendmail 1 (consente l’invio di notifiche tramite sendmail o Postfix).
  • setsebool -P httpd_unified 0 (isola le directory scrivibili da quelle a sola lettura).

L’argomento -P rende l’impostazione permanente tra i riavvii della macchina. Una gestione meticolosa garantisce standard operativi identici a quelli dei provider enterprise.

Gestione avanzata dei permessi con le POSIX ACL

Perché i permessi standard non bastano

I permessi tradizionali proprietario-gruppo-altri mostrano evidenti limiti in ambienti multi-utente. Spesso un operatore deve gestire i file via SFTP con un utente personale. Al contempo, il demone web (ad esempio www-data) deve mantenere il pieno accesso in scrittura.

Se modifichi il proprietario in favore dell’utente SFTP, WordPress non potrà più caricare file. Se lasci la proprietà a www-data, il tuo utente SFTP non potrà editare i temi. Le Access Control Lists (POSIX ACL) risolvono questo conflitto alla radice.

Uso di setfacl e getfacl su wp-content

Le ACL consentono di assegnare diritti di lettura, scrittura ed esecuzione a più utenti o gruppi simultaneamente. Non è necessario modificare il proprietario principale della cartella. Prima di tutto, verifica lo stato attuale con getfacl:

  • getfacl /var/www/html/wp-content/uploads

Per autorizzare sia il server web sia un utente sviluppatore (es. “deployer”), usa il comando setfacl:

  1. Assegna permessi al server web: setfacl -m u:www-data:rwx /var/www/html/wp-content/uploads.
  2. Assegna permessi all’utente deployer: setfacl -m u:deployer:rwx /var/www/html/wp-content/uploads.
  3. Verifica nuovamente con getfacl per visualizzare le nuove voci create.

Impostare l’ereditarietà con le Default ACL

Quando WordPress crea una nuova cartella per il mese corrente, applica i permessi definiti dal processo PHP. Senza una regola esplicita, le ACL appena impostate andrebbero perse per i nuovi contenuti. Le Default ACL risolvono definitivamente questo problema.

Imposta le regole predefinite con il flag -d:

  • setfacl -d -m u:www-data:rwx /var/www/html/wp-content/uploads
  • setfacl -d -m u:deployer:rwx /var/www/html/wp-content/uploads
  • setfacl -d -m g::rx /var/www/html/wp-content/uploads
  • setfacl -d -m o::r /var/www/html/wp-content/uploads

D’ora in poi, qualsiasi cartella o file generato da WordPress erediterà automaticamente questi permessi. Nessun aggiornamento o upload futuro perderà l’accesso da parte dei tuoi utenti autorizzati.

Ripristino da backup preservando metadati di sicurezza

Comando tar con preservazione di ACL e SELinux

Un backup standard eseguito con opzioni generiche ignora i contesti SELinux e le tabelle ACL. Quando ripristini un archivio simile, i caricamenti smetteranno di funzionare. I controlli di sicurezza avanzati wordpress devono essere inclusi sin dalla fase di salvataggio dell’archivio compresso.

Usa i flag corretti quando crei il tuo backup con tar:

  • tar --acls --selinux --xattrs -czpf backup-wordpress.tar.gz /var/www/html

Durante il restore su un nuovo server o dopo un guasto, specifica nuovamente i medesimi parametri:

  • tar --acls --selinux --xattrs -xzpf backup-wordpress.tar.gz -C /

In questo modo l’intero albero di file manterrà intatti permessi speciali, attributi estesi e ruoli di sicurezza.

Sincronizzazione professionale con rsync

Se utilizzi rsync per sincronizzare i file verso un server di staging o di backup, adotta i flag per gli attributi estesi. Il classico flag -av non include i metadati di sicurezza.

Esegui il comando di sincronizzazione in questo modo:

  • rsync -aAXv /var/www/html/ /backup/wordpress/html/

Il parametro -A istruisce rsync a trasferire le regole ACL. Il parametro -X preserva gli attributi estesi, inclusi i contesti SELinux. In assenza di questi flag, il ripristino richiederà una riconfigurazione manuale da riga di comando.

Best practice e monitoraggio nel tempo

Automazione e verifiche periodiche

I server di produzione evolvono continuamente nel corso del tempo. Un aggiornamento di sistema o un cambio di permessi errato può alterare le policy stabilite. Un piano di manutenzione periodico deve includere i controlli di sicurezza avanzati wordpress.

Crea uno script cron settimanale che verifichi l’integrità dei contesti e segnali eventuali discrepanze:

  1. Esegui una verifica di conformità con restorecon -nv /var/www/html/wp-content/uploads.
  2. Invia l’output via email agli amministratori se vengono rilevate deviazioni dallo standard.
  3. Monitora i log di audit per prevenire falsi positivi causati da nuovi plugin installati.

Con questa architettura scalabile, il tuo CMS rimane blindato contro attacchi esterni senza sacrificare le normali funzionalità operative quotidiane.

Domande frequenti (FAQ)

Come verifico rapidamente se SELinux è attivo sul mio server?

Puoi digitare il comando sestatus nel terminale del tuo server. L’output mostrerà lo stato operativo corrente (enabled o disabled) e la modalità attiva (enforcing o permissive). La modalità enforcing blocca attivamente le violazioni delle regole, mentre la permissive genera solo segnalazioni di registro.

Cosa succede se un plugin modifica autonomamente i permessi delle cartelle?

Molti plugin provano a forzare permessi standard come 0755 o 0777 tramite istruzioni PHP chmod. Le impostazioni POSIX ACL predefinite sul filesystem hanno priorità e mantengono l’accesso per gli utenti definiti nelle tabelle di sicurezza. Controlla comunque che il plugin non rimuova l’ereditarietà delle directory.

Perché applicare i controlli di sicurezza avanzati wordpress invece di un semplice chmod 777?

Il comando chmod 777 concede a qualunque utente o processo locale il pieno controllo sui tuoi file. In caso di codice malevolo o vulnerabilità in un plugin, un attaccante potrebbe sovrascrivere file di sistema cruciali. I meccanismi come SELinux e ACL limitano rigorosamente i privilegi solo ai processi che ne hanno effettivo bisogno operativo.

Articoli simili