Vai al contenuto

Sicurezza e HTTPS

Questa pagina raccoglie le impostazioni di sicurezza dell’istanza: HTTPS e certificati, protezione contro i bot (Anubis) e le variabili più sensibili del file .env.

È rivolta a chi amministra l’istanza (SuperAdmin o profilo più tecnico-operativo).

HTTPS e certificati

Farinha funziona dietro Caddy, che gestisce HTTPS automaticamente:

  • Con un indirizzo pubblico configurato (ad esempio, farinha.vostraIstituzione.org): Caddy ottiene e rinnova automaticamente certificati gratuiti.
  • Con certificati propri: metti i file fullchain.pem e privkey.pem nella cartella certs/, nella radice del progetto. Hanno priorità sui certificati automatici.
  • Senza indirizzo pubblico e senza certificati propri (ad esempio, localhost o un IP): la sicurezza viene disattivata, perché i certificati automatici richiederebbero l’installazione di un’autorità di certificazione sui client. In questo caso, è importante configurare un indirizzo pubblico o certificati propri il prima possibile.

Se, per qualsiasi motivo, vuoi comunque disattivare HTTPS, imposta nel .env:

DISABLE_HTTPS=True

Farinha dietro un altro proxy inverso

È comune che l’istituzione collochi Farinha dietro un altro livello di proxy inverso (ad esempio, un proxy perimetrale, un load balancer, un CDN o un pannello proxy come Nginx Proxy Manager). La topologia è questa:

Proxy/CDN esterno
    ↓
Proxy inverso intermedio
    ↓
Caddy (container Farinha)
    ↓
Gunicorn/Django

In questo scenario, è frequente che il proxy intermedio non trasmetta a Caddy le informazioni necessarie per completare la validazione automatica del certificato (ad esempio, il dominio nell’handshake TLS, detto anche SNI). Non riuscendo a ottenere il certificato pubblico, Caddy presenta un certificato interno, emesso dalla propria autorità locale:

Issuer: Caddy Local Authority - ECC Intermediate
Subject Alternative Name: farinha.exemplo.org

Questo certificato è valido per Caddy, ma non è riconosciuto dai proxy a monte né dai browser. Il risultato è di solito uno di questi sintomi:

  • errore di certificato non valido sul proxy/CDN esterno (ad esempio, 526 Invalid SSL Certificate su Cloudflare in modalità strict);
  • 502 Bad Gateway sul proxy intermedio, perché non riesce a completare la connessione HTTPS sicura con Caddy;
  • ciclo di reindirizzamento: il proxy inoltra verso la porta 80, Caddy risponde 308 Permanent Redirect verso HTTPS e il browser continua a passare dall’uno all’altro.

Il problema è lo stesso con qualsiasi proxy; la causa è di solito una di queste due cose:

  1. il proxy non invia il dominio nell’handshake TLS (SNI), quindi Caddy non seleziona il certificato corretto;
  2. il proxy tenta di validare il certificato di Caddy e lo rifiuta, perché è il certificato interno.

Soluzione pratica (esempio con Nginx Proxy Manager):

  1. Nel Proxy Host del dominio, in Details, punta a Farinha via HTTPS sulla porta di Caddy:

  2. Scheme: https

  3. Forward Hostname/IP: IP del container Farinha (es.: 10.0.0.14)
  4. Forward Port: 443

Questo evita il ciclo, perché il proxy non passa più dalla porta 80 (che reindirizza sempre verso HTTPS).

  1. Nella scheda SSL, mantieni il certificato del dominio e Force SSL attivo.

  2. Nella scheda Advanced, invia il dominio nell’handshake e accetta il certificato interno dell’upstream:

proxy_ssl_server_name on;
proxy_ssl_name farinha.exemplo.org;
proxy_ssl_verify off;
  • proxy_ssl_server_name on;: invia lo SNI nell’handshake, consentendo a Caddy di selezionare il certificato corretto per il dominio;
  • proxy_ssl_name farinha.exemplo.org;: definisce quale dominio viene inviato come SNI;
  • proxy_ssl_verify off;: accetta il certificato interno di Caddy sull’upstream.

Su altri proxy, cerca le opzioni equivalenti: abilitare lo SNI/mantenere il nome host sull’upstream e disattivare la verifica del certificato dell’upstream.

Attenzione: disattivare la verifica mantiene la connessione cifrata, ma non valida l’identità del certificato di Caddy. È accettabile come soluzione provvisoria su una rete interna/controllata.

  1. Solo dopo che l’accesso diretto funziona, ripristina la modalità più rigorosa sul proxy/CDN esterno (ad esempio, Full (strict) su Cloudflare).

Soluzioni definitive (preferibili a verify off):

  • Certificato pubblico su Caddy: configurare FARINHA_URL con il dominio e lasciare che completi la sfida ACME, così che Caddy presenti un certificato attendibile e la verifica possa essere riattivata.
  • Certificati propri attendibili: usare certificati di un’autorità riconosciuta dai proxy (opzione certs/).
  • Disattivare HTTPS su Farinha con DISABLE_HTTPS=True e puntare il proxy a http sulla porta 80 del container. Funziona, ma il tratto tra il proxy e Farinha non è più cifrato; valuta il rischio nel tuo ambiente. In questo caso, mantieni HTTPS solo sul bordo (proxy/CDN).

Protezione contro i bot (Anubis)

Farinha può usare Anubis, un firewall che richiede ai visitatori una piccola prova di lavoro per bloccare gli accessi automatizzati (bot), riducendo il carico nei picchi di traffico.

La protezione è controllata da due impostazioni dell’applicazione, nel pannello interno di amministrazione (Django Admin):

  • Webapp -> Impostazioni dell'applicazione -> "Anubis habilitado?"
  • Webapp -> Impostazioni dell'applicazione -> "Dificuldade do Desafio Anubis" (Muito leve (1), Leve (3), Padrão (4) e Forte (10))

Elenco delle impostazioni dell’applicazione con mappa e Anubis

Le impostazioni dell’applicazione includono la mappa del portale e la protezione contro i bot (Anubis).

Punti importanti:

  • La modifica di Anubis (attivazione/disattivazione o difficoltà) ha effetto dopo il riavvio di Farinha. Al salvataggio, il pannello avvisa di questo.
  • Il run (script run.sh/run.bat) legge queste impostazioni dal database e le applica all’avvio dell’istanza.
  • La difficoltà "Padrão (4)" è un buon punto di partenza. Valori alti rendono la sfida più pesante e possono infastidire gli utenti; valori troppo bassi riducono la protezione.
  • Se la sfida non compare per i visitatori, verifica che "Anubis habilitado?" sia selezionato e riavvia Farinha.

Vedi anche: Portale.

Variabili sensibili del .env

Il file .env (creato da .env-sample alla prima esecuzione) raccoglie le impostazioni dell’istanza. Le più rilevanti per la sicurezza:

  • FARINHA_URL: dominio/i o IP di accesso, separati da virgole (senza https://). Con un dominio pubblico, HTTPS viene attivato automaticamente.
  • ADMIN_PATH: percorso del pannello interno di amministrazione. Predefinito: admin/. Vedi Utente SuperAdmin.
  • SECRET_KEY: chiave che protegge i dati sensibili. È obbligatoria: senza di essa Farinha non si avvia. È generata automaticamente da run.sh/run.bat; se la crei manualmente, non usare il carattere $ (Docker Compose lo interpreterebbe come variabile d’ambiente).
  • SECURE_HSTS_SECONDS: HSTS. Mantieni 0 (disattivato) finché non sei sicuro che HTTPS funzioni, perché HSTS può rendere il sito irraggiungibile se i certificati non sono corretti. Attivalo solo se sai quello che stai facendo.
  • SECURE_HSTS_INCLUDE_SUBDOMAINS: include i sottodomini nell’HSTS.
  • SECURE_PROXY_SSL_HEADER e SECURE_PROXY_SSL_HEADER_VALUE: indicano a Django che la richiesta originale è sicura quando c’è un proxy davanti (già configurato per impostazione predefinita per Caddy).
  • SECURE_CONTENT_TYPE_NOSNIFF: impedisce ai browser di indovinare il tipo di file.
  • DEBUG: in produzione, mantieni False (valore predefinito di .env-sample).
  • SQLITE_BUSY_TIMEOUT_MS: tempo di attesa del database quando è occupato.

Precauzioni:

  • Non pubblicare mai il file .env o la SECRET_KEY (non inviarli via e-mail, chat o issue).
  • Quando modifichi variabili, ferma e riavvia l’istanza (./down.sh && ./run.sh su Linux; .\down.bat e .\run.bat su Windows).

Buone pratiche

  • Mantieni permessi restrittivi sul .env; contiene la SECRET_KEY.
  • Genera una SECRET_KEY propria ed esclusiva per ogni istanza (il run lo fa già automaticamente). Non riutilizzare mai la chiave di un’altra installazione.
  • Prima di attivare HSTS (SECURE_HSTS_SECONDS), conferma che HTTPS funzioni su tutti i domini e sottodomini usati. HSTS è difficile da annullare lato client.
  • In produzione, mantieni DEBUG=False.
  • Se cambi il percorso del pannello con ADMIN_PATH, condividi il nuovo indirizzo con il gruppo di lavoro ed evita percorsi ovvi come admin/ o pannello/.
  • Mantieni un backup del database (db/) e dei certificati propri (certs/), se li usi.
  • Se usi un altro proxy inverso davanti a Farinha, preferisci la soluzione definitiva (certificato pubblico o proprio attendibile) invece di mantenere la verifica del certificato disattivata sull’upstream a lungo.

Problemi comuni

  • Farinha non si avvia: verifica che SECRET_KEY esista nel .env e non contenga $. L’errore compare nei log del container.
  • Avviso di certificato non valido nel browser: può essere il certificato interno di Caddy, perché il dominio non è configurato correttamente in FARINHA_URL, o perché la validazione automatica non è riuscita. Controlla anche la sottosezione sul proxy sopra.
  • Errore di certificato (526) o 502 su proxy/CDN: vedi la sottosezione Farinha dietro un altro proxy inverso; di solito è l’upstream HTTPS senza SNI e con la verifica del certificato attiva.
  • Ciclo di reindirizzamento: il proxy punta alla porta 80 di Caddy, che reindirizza sempre verso HTTPS. Usa https sulla porta 443 o disattiva HTTPS su Farinha.
  • La sfida di Anubis non compare: conferma che "Anubis habilitado?" sia selezionato nelle Impostazioni dell'applicazione e riavvia Farinha.
  • Ho modificato l’impostazione di Anubis e non è cambiato nulla: le modifiche hanno effetto solo dopo il riavvio di Farinha (l’avviso compare nel pannello al salvataggio).
  • La sfida di Anubis ostacola le integrazioni interne: valuta di disattivare la protezione o ridurre la difficoltà, ricordando il riavvio necessario.