Come installare OSSN in modo sicuro sul tuo server

OSSN funziona bene solo se il contesto attorno è sobrio: un web server esposto il minimo necessario, PHP senza moduli inutili, database dedicato, directory scrivibili solo dove serve e aggiornamenti gestiti come change controllato. L’errore tipico è trattarlo come un CMS “da provare” e lasciarlo con permessi larghi, installazione accessibile a chiunque e backup improvvisati. In produzione questo si traduce quasi sempre in problemi di sicurezza o in un ripristino doloroso al primo guasto.

Qui l’obiettivo è installarlo in modo difendibile: ridurre la superficie d’attacco, separare i privilegi, verificare i prerequisiti prima di lanciare il setup e chiudere subito i punti deboli dopo il primo avvio. Se manca un dato del tuo stack, non indovino: il punto da chiudere è il binomio web server/PHP, perché OSSN cambia parecchio tra Apache e Nginx e tra PHP-FPM e mod_php.

Scelta architetturale: cosa va isolato prima di toccare il pacchetto

OSSN non richiede un’infrastruttura complessa, ma richiede disciplina. La configurazione minima sensata è: un vhost dedicato, un database dedicato, un utente DB dedicato, PHP-FPM con pool separato se il server ospita altro, TLS obbligatorio e una root web che punti solo ai file pubblici. Se il server è condiviso con altri siti, la regola pratica è non far condividere né utente di sistema né directory di upload tra applicazioni diverse.

Il primo controllo da fare è banale ma decisivo: il sito deve rispondere in HTTPS e il virtual host deve essere quello giusto. Se il certificato è ancora da emettere, fallo prima dell’installazione, non dopo. Un wizard esposto in chiaro, anche per pochi minuti, è un errore evitabile.

Prerogative minime: sistema, PHP e database

OSSN gira su stack LAMP/LEMP classico. La parte più delicata non è il CMS in sé, ma la compatibilità PHP e il set di estensioni. Prima di installare, verifica la versione effettiva di PHP usata dal web server e non solo quella da CLI, perché spesso non coincidono.

Controlli utili:

php -v

Atteso: una versione supportata dalla build di OSSN che stai usando. Se la CLI mostra una versione diversa dal pool FPM o dal modulo Apache, il dato da chiudere è nel file di configurazione del vhost o del service PHP-FPM, non nel binario CLI.

Verifica anche le estensioni più comuni:

php -m | egrep 'mysqli|pdo_mysql|gd|curl|mbstring|xml|zip|openssl|json'

Se una di queste manca, il setup può fallire in fase di upload o nella gestione media. La falsificazione è immediata: se il modulo non compare, installalo dal repository della distro o abilitalo nel file `php.ini`/`conf.d` corretto e riavvia il servizio PHP-FPM.

Per il database, crea un utente dedicato con privilegi limitati al solo database applicativo. Non usare root, nemmeno temporaneamente. Il principio è semplice: se il CMS venisse compromesso, il movimento laterale deve fermarsi lì.

mysql -u root -p

CREATE DATABASE ossn CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'ossn_user'@'localhost' IDENTIFIED BY 'PASSWORD_FORTE';
GRANT ALL PRIVILEGES ON ossn.* TO 'ossn_user'@'localhost';
FLUSH PRIVILEGES;

La password in chiaro non va salvata in note operative. Mettila in un password manager, in un secret store o in un file di provisioning con accesso ristretto, poi ruotala se il processo di installazione è stato eseguito in modo non controllato.

Installazione pulita su Apache con PHP-FPM

Apache resta la via più lineare quando vuoi ridurre gli errori operativi. Con PHP-FPM ottieni separazione migliore rispetto a mod_php e puoi tenere il virtual host più pulito. Il punto chiave è non lasciare la document root puntata troppo in alto rispetto ai file pubblici dell’applicazione.

Schema consigliato: scarica OSSN in una directory di staging, verifica integrità e solo dopo spostalo nella root del sito. Se hai un sistema di gestione config, versiona il vhost prima di toccarlo.

cd /var/www
wget https://example.org/ossn-latest.zip
unzip ossn-latest.zip -d ossn-staging

Il link sopra è un segnaposto: la fonte reale va presa dal progetto ufficiale o dal repository che usi internamente. Il dato mancante da chiudere è sempre l’URL di release attendibile, non un mirror casuale.

Dopo l’estrazione, assegna ownership coerente con l’utente del web server, ma senza allargare i permessi oltre il necessario. In genere la root dell’app può essere leggibile dal web server, mentre le directory di upload e cache devono essere scrivibili solo dal processo PHP.

chown -R www-data:www-data /var/www/ossn-staging
find /var/www/ossn-staging -type d -exec chmod 755 {} \
;
find /var/www/ossn-staging -type f -exec chmod 644 {} \
;

Se il tuo server usa un utente diverso da `www-data`, adatta il comando. Il controllo successivo è verificare che le directory scrivibili da OSSN siano quelle previste dalla documentazione dell’app, non l’intero albero web.

Esempio di vhost minimale con HTTPS forzato:

<VirtualHost *:80> ServerName social.example.com Redirect permanent / https://social.example.com/
</VirtualHost> <VirtualHost *:443> ServerName social.example.com DocumentRoot /var/www/ossn/public SSLEngine on SSLCertificateFile /etc/letsencrypt/live/social.example.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/social.example.com/privkey.pem <Directory /var/www/ossn/public> AllowOverride All Require all granted </Directory>
</VirtualHost>

Se il progetto richiede rewrite o regole specifiche, abilita solo i moduli strettamente necessari. Su Apache il check utile è:

apachectl -M | egrep 'rewrite|ssl|headers|proxy_fcgi'

Se un modulo non serve, non caricarlo. Meno superficie, meno sorprese.

Installazione su Nginx: più controllo, più attenzione ai dettagli

Con Nginx il vantaggio è la chiarezza del routing; lo svantaggio è che un errore nel `try_files` o nel passaggio a PHP-FPM si traduce subito in pagina bianca o 404 strani. Qui la regola è testare il blocco server prima di esporlo.

nginx -t

Se il test passa, controlla il socket o la porta del pool FPM:

ss -ltnp | grep php-fpm

Un esempio di blocco base:

server { listen 443 ssl http2; server_name social.example.com; root /var/www/ossn/public; index index.php; ssl_certificate /etc/letsencrypt/live/social.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/social.example.com/privkey.pem; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }
}

Il socket va adattato al tuo sistema. Il punto critico non è la sintassi del blocco, ma la coerenza tra root, path reale e permessi del processo PHP. Se la root punta a un livello sbagliato, OSSN può installarsi ma poi fallire su asset, upload o routing.

Wizard di installazione: cosa controllare prima di cliccare avanti

Prima di eseguire il wizard, entra nel server e verifica che la directory di installazione non sia già pubblicamente modificabile più del necessario. Se il setup crea file di configurazione, assicurati che il solo processo web possa scriverli durante l’installazione e che poi i permessi vengano stretti subito dopo.

Le tre verifiche che contano davvero sono queste:

Se una di queste tre non è vera, fermati. Andare avanti “per vedere cosa succede” complica la diagnosi e spesso sporca il setup con file parziali o tabelle incomplete.

Durante il wizard, usa un account amministrativo iniziale con una password lunga e unica. Subito dopo il primo login, valuta se il software offre impostazioni per MFA, restrizioni di sessione o controllo delle notifiche email. Se manca l’autenticazione forte, il dato da chiudere è esterno all’app: almeno proteggi l’accesso amministrativo con IP allowlist, VPN o reverse proxy con autenticazione aggiuntiva.

Hardening immediato dopo il primo avvio

La fase più importante non è il deploy ma il post-deploy. Appena OSSN è operativo, riduci la finestra di esposizione dell’installer, blocca la scrittura dove non serve e verifica i permessi delle directory sensibili. Se il progetto prevede un file di configurazione generato dal wizard, controlla che non sia world-writable.

Le azioni da fare subito sono queste:

Per controllare i permessi reali:

find /var/www/ossn -perm -0002 -type f -o -perm -0002 -type d

Se il comando restituisce oggetti scrivibili da tutti, quello è un problema da correggere prima di esporre il sito a traffico normale. Il rollback, in questo caso, è ripristinare i permessi precedenti solo se li hai versionati; altrimenti correggi con modifiche incrementali e verifica dopo ogni step.

Logging e diagnosi: dove guardare quando qualcosa non torna

La diagnosi utile parte dai log del web server e di PHP-FPM, poi passa ai log applicativi se OSSN li espone. Non serve aprire dieci file a caso: serve capire se l’errore è di routing, permessi, DB o codice PHP.

Controlli rapidi:

tail -n 100 /var/log/apache2/error.log
journalctl -u php-fpm -n 100 --no-pager
journalctl -u nginx -n 100 --no-pager

Su distribuzioni diverse i path cambiano, ma il pattern resta identico: errori 500 con riferimento a `permission denied` indicano permessi o ownership; errori su `PHP Fatal error` indicano estensioni mancanti o versione non compatibile; errori di connessione al DB indicano credenziali, host o socket sbagliati.

Se trovi una pagina bianca, non assumere che sia “solo tema”. Guarda prima i log PHP e il `display_errors` deve restare spento in produzione. Per il debug temporaneo usa log file, non output a schermo.

Backup e rollback: il punto che evita di improvvisare

Prima di qualsiasi modifica strutturale, salva tre cose: database, directory di upload e configurazione del web server. Senza questo, il rollback non esiste: esiste solo il tentativo di ricostruire a mano.

mysqldump -u ossn_user -p ossn > /root/backup/ossn.sql
rsync -a /var/www/ossn/uploads/ /root/backup/ossn-uploads/
cp /etc/apache2/sites-available/social.example.com.conf /root/backup/

Se usi Nginx, salva il file del server block. Se usi un pannello hosting, esporta lo snippet o annota il percorso esatto nel repository di configurazione del pannello. Il rollback corretto è: ripristino DB, ripristino file, reload del web server e verifica login. Non fare restore parziali senza capire la coerenza tra schema e file.

Check finale di sicurezza prima di aprire il traffico

Ultimo passaggio: apri il sito da un client esterno e verifica il comportamento reale, non solo il localhost. Il controllo minimo è che il sito risponda in HTTPS, che il redirect da HTTP sia attivo e che il login funzioni senza errori nei log.

Checklist finale:

Se vuoi alzare ancora il livello, aggiungi rate limiting sul reverse proxy, header di sicurezza coerenti e un controllo periodico degli aggiornamenti. Non sono decorazioni: su una piattaforma sociale il rischio principale è la combinazione tra account admin esposto, plugin non verificati e permessi troppo larghi.

Assunzione operativa: il server è Linux recente con Apache o Nginx, PHP-FPM e MySQL/MariaDB; se il tuo stack differisce, il punto da chiudere è la compatibilità tra web server, versione PHP e percorso della root pubblica.