Aggiungere l'intestazione HSTS all'endpoint HTTPS che serve Nextcloud

L'avviso "Strict-Transport-Security" di Nextcloud significa che il controllo non ha rilevato un'intestazione HSTS con un valore max-agedi almeno 15552000secondi (180 giorni) nella risposta HTTPS pubblica. Aggiungi l'intestazione sul server web o sul proxy inverso che fornisce HTTPS, quindi testa esattamente quell'URL pubblico. HSTS non è un'impostazione di Nextcloud config.phpe una semplice risposta HTTP non può stabilire una policy HSTS nei browser.

Cosa verificare prima di modificare la configurazione

• Verifica che il sito Nextcloud si carichi correttamente tramite HTTPS e che presenti un certificato valido per il suo nome host.
• Identifica quale servizio termina la connessione TLS: Apache, NGINX, un bilanciatore di carico, un ingresso container o un proxy esterno.
• Verifica se quel servizio ha già impostato Strict-Transport-Security. Invia una policy specifica dall'endpoint TLS pubblico; intestazioni duplicate o in conflitto rendono la verifica complessa.
• Prima di aggiungere , accertati che tutti i sottodomini siano pronti per HTTPS includeSubDomains. Non abilitare questa opzione preloadcome soluzione rapida per eliminare questo avviso.

HSTS indica ai browser che le connessioni future a un hostname devono utilizzare HTTPS. Aiuta a prevenire il downgrade a HTTP dopo che un browser ha ricevuto la policy. Non sostituisce TLS, non corregge un certificato non valido né reindirizza la prima visita HTTP; è necessario configurare anche un reindirizzamento da HTTP a HTTPS separato. Il manuale di amministrazione di Nextcloud 35 identifica il valore minimo di 15552000 secondi e raccomanda di impostare l'intestazione nel server web. Il punto di applicazione effettivo in una distribuzione proxy è il componente che restituisce la risposta al visitatore.

Definire una politica di base

Una politica iniziale prudente per un nome host Nextcloud è la seguente:

Strict-Transport-Security: max-age=15552000

Questo soddisfa i requisiti minimi di durata dei documenti Nextcloud senza applicare automaticamente una policy a ogni sottodominio. Una volta verificato che tutti i sottodomini rilevanti supportino HTTPS in modo continuativo, è possibile valutare l'aggiunta di ; includeSubDomains. Un browser che ha appreso questa direttiva richiederà HTTPS anche per tali sottodomini. Una dashboard interna, un server di posta o un servizio legacy che dipende ancora da HTTP potrebbero diventare irraggiungibili in quel browser fino a quando non vengono migrati o la policy non scade.

Apache

Per un host virtuale Apache TLS, abilita mod_headerse inserisci la direttiva all'interno dell'host virtuale HTTPS, non solo nell'host di reindirizzamento della porta 80:

<VirtualHost *:443>
    ServerName cloud.example.com
    # Keep the existing TLS and Nextcloud configuration here.
    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>
</VirtualHost>

Sostituisci il nome host di esempio e mantieni il certificato e il proxy o la configurazione PHP esistenti. L'esempio di hardening di Apache di Nextcloud utilizza Header always setl'host virtuale HTTPS. Convalida la configurazione di Apache con il comando config-test supportato dalla tua distribuzione, quindi ricarica Apache solo se il test ha esito positivo.

NGINX

In NGINX, aggiungi l'intestazione all'interno del serverblocco che è in ascolto per HTTPS sull'hostname pubblico di Nextcloud:

server {
    listen 443 ssl;
    server_name cloud.example.com;
    # Keep your existing TLS and Nextcloud locations here.
    add_header Strict-Transport-Security "max-age=15552000" always;
}

Non incollare questo codice come sostituzione completa della configurazione esistente del server. L'ereditarietà delle intestazioni NGINX può dipendere dal fatto che una posizione nidificata definisca o meno le proprie add_headerdirettive; esamina la configurazione effettiva e testa risposte rappresentative, inclusi gli endpoint statici e DAV. L'esempio ufficiale di Nextcloud per NGINX include un'impostazione HSTS nella sua configurazione HTTPS e avverte gli amministratori dell'importanza di abilitare il precaricamento.

Proxy inverso o ingresso

Se un bilanciatore di carico, un ingresso o un proxy ospitato termina HTTPS prima di inoltrare il traffico a Nextcloud, imposta HSTS a quel livello TLS pubblico, a meno che la tua architettura non lo aggiunga esplicitamente a un upstream attendibile. Un'intestazione aggiunta solo dal backend potrebbe essere rimossa o sostituita dal proxy. Viceversa, impostarla a entrambi i livelli può produrre valori duplicati. Verifica la configurazione dell'intestazione di risposta del proxy e assicurati che il percorso HTTPS che stai testando sia quello corrispondente. Mantieni le impostazioni del proxy attendibile e dell'URL HTTPS di Nextcloud coerenti con la distribuzione esistente, ma non considerarle un sostituto dell'emissione dell'intestazione.

Convalidare la risposta del pubblico

1. Utilizza lo strumento di verifica della sintassi della piattaforma per la configurazione modificata del server web o del proxy.
2. Ricarica o distribuisci la configurazione convalidata.
3. Richiedi l'indirizzo HTTPS pubblico e ispeziona le intestazioni della risposta: curl -sSI https://cloud.example.com/. Cerca una Strict-Transport-Securityriga il cui valore max-agesia almeno 15552000.
4. Negli strumenti per sviluppatori del browser, esamina la risposta proveniente dallo stesso hostname pubblico. Questo può rivelare la presenza di un proxy che modifica le intestazioni o di un percorso che aggira l'host virtuale previsto.
5. Ricarica la pagina Amministrazione → Panoramica di Nextcloud e attendi che il controllo di sicurezza si aggiorni.

Se curlnon viene visualizzata alcuna intestazione HSTS, verificare che il DNS punti all'endpoint modificato, che la richiesta utilizzi HTTPS e che il proxy non rimuova l'intestazione. Se l'intestazione appare nella home page ma non in altre risposte, esaminare le direttive a livello di posizione di NGINX o le regole dell'intestazione di risposta del proxy. Se la risposta pubblica è corretta ma Nextcloud continua a visualizzare un avviso, verificare che il controllo amministrativo utilizzi lo stesso hostname e schema visibili esternamente, quindi esaminare eventuali livelli di caching o proxy tra il server e il controllo.

Utilizzare il precaricamento solo dopo una revisione a livello di dominio.

Il precaricamento è una scelta separata e di grande impatto. La direttiva di precaricamento non registra di per sé un dominio; gli elenchi di precaricamento dei browser hanno requisiti di invio specifici. Le attuali linee guida dei browser richiedono una lunga max-ageprocedura includeSubDomainsdi registrazione. Nextcloud avverte che la rimozione da un elenco di precaricamento predefinito può richiedere mesi prima di essere visualizzata nei browser installati. Iniziate con la policy di base, inventariate ogni hostname interessato, verificate che HTTPS funzioni su tutto il dominio e consultate i requisiti ufficiali di precaricamento prima di procedere. La maggior parte degli amministratori di Nextcloud può risolvere questo avviso specifico senza optare per il precaricamento.

Riferimenti: Avvisi di sicurezza di Nextcloud 35 , Guida alla protezione di Nextcloud , Configurazione di Nextcloud per NGINX e Riferimento all'intestazione HSTS di MDN .