Access denied on this server: cause e soluzioni

Cosa significa l'errore

Il testo non fa parte di alcuno standard, motivo per cui compare in così tante forme diverse. Apache lo stampa da una regola di directory. ModSecurity e i pannelli di controllo dell'hosting lo stampano quando scatta una regola. Una CDN o un WAF stampa la propria versione con marchio e un numero di riferimento. AWS lo restituisce come un breve documento XML da S3 o CloudFront. Tutti dicono la stessa cosa a livello HTTP: 403, rifiutato, e nessun invito a riprovare con delle credenziali.

Quest'ultimo punto lo distingue dagli errori con cui viene confuso. Un 401 chiede di autenticarsi e si aspetta un nuovo tentativo. Un 404 dice che la risorsa non c'è. Un 403 dice che la risorsa c'è e che non la otterrai, e ripetere la richiesta invariata produrrà la stessa risposta. Lo stato in sé è trattato in 403 Forbidden; questa guida riguarda come capire quale livello ha detto no.

Inizia scoprendo se il problema riguarda solo te o tutti, perché le soluzioni non hanno nulla in comune. Se un collega su un'altra rete carica la pagina senza problemi, sei bloccato tu. Se non riesce a caricarla nessuno, il sito è configurato male.

Perché succede

• Il tuo indirizzo IP è bloccato. Una regola firewall o WAF aggiunta dopo login falliti, uno scraper sulla tua rete, o un blocco manuale che nessuno ha rimosso.
• Rate limiting. Troppe richieste in una finestra temporale breve, facile da attivare con una sessione di debug fatta di ricariche continue o con una connessione di ufficio condivisa.
• Restrizioni geografiche. Siti limitati a un solo paese, o che bloccano intere regioni dopo abusi provenienti da lì.
• Un IP condiviso o segnalato per reputazione. I nodi di uscita VPN, il NAT degli operatori mobili e le fasce di hosting economico vengono spesso bloccati in blocco per ciò che hanno fatto altri utenti.
• Regole anti-bot che leggono il tuo user agent. Strumenti a riga di comando, browser headless e stringhe user agent insolite vengono rifiutati dove un browser normale è ammesso.
• Cookie obsoleti o una sessione rotta. Un token di sessione scaduto può produrre un rifiuto invece di un reindirizzamento alla pagina di login.
• Un'estensione del browser che rimuove o aggiunge header, o un proxy aziendale che riscrive la richiesta.
• Permessi di file e directory. L'utente del web server non può leggere il file o attraversare una directory superiore.
• Nessun file indice, con l'elenco disattivato. Una richiesta di directory senza nulla da servire e Options -Indexes attivo restituisce 403 invece di una pagina vuota.
• Una regola di negazione esplicita. Un Require all denied nella configurazione di Apache o un .htaccess residuo da una finestra di manutenzione.
• Un falso positivo del WAF. ModSecurity e set di regole simili rifiutano richieste legittime che contengono qualcosa che assomiglia a un tentativo di injection, spesso in un campo di form o in una query string.
• Permessi di cloud storage. Una policy del bucket S3 o un'impostazione di origin access di CloudFront che non consente la lettura dell'oggetto.

Se sei il visitatore

1. Conferma il codice di stato invece di fidarti del testo della pagina. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page ti dice se si tratta davvero di un 403 o di un 401 o 429 con un messaggio simile.
2. Apri la pagina in una finestra privata. Elimina cookie e la maggior parte delle estensioni in un solo passaggio. Se funziona lì, la soluzione riguarda il tuo profilo, non il sito.
3. Cancella i cookie specificamente per quel sito invece di cancellare tutto, poi ricarica.
4. Disattiva la VPN o il proxy e riprova. Se allora funziona, era l'indirizzo del nodo di uscita a essere rifiutato, e passare a un'altra regione di solito risolve.
5. Prova una rete diversa, nel modo più semplice un telefono con i dati mobili. È il modo più rapido per dimostrare che è il tuo indirizzo a essere bloccato.
6. Disattiva le estensioni una alla volta, iniziando dagli ad blocker, dagli strumenti per la privacy e da tutto ciò che modifica gli header.
7. Verifica se il blocco è regionale chiedendo a qualcuno in un altro paese, o leggendo la pagina di blocco per un riferimento alla tua posizione.
8. Contatta il sito con il numero di riferimento se la pagina di blocco ne mostra uno. Le pagine WAF di solito stampano un ID incidente che permette all'operatore di trovare in pochi secondi la regola esatta che è scattata.

Se possiedi il sito

1. Leggi prima il log degli errori. Indica direttamente la causa, e ogni passo successivo è un'ipotesi senza di esso:

   sudo tail -50 /var/log/apache2/error.log
   sudo tail -50 /var/log/nginx/error.log
   sudo grep -i modsecurity /var/log/apache2/error.log | tail -20

   Apache registra un problema di permessi come "client denied by server configuration" o "Permission denied". nginx registra "directory index of ... is forbidden" oppure "open() ... failed (13: Permission denied)". Questi tre messaggi coprono la maggior parte dei casi.
2. Controlla i permessi lungo tutto il percorso, incluse tutte le directory superiori. Una directory che il web server non può attraversare rifiuta tutto ciò che sta sotto, per quanto corretto possa sembrare il file stesso:

   namei -l /var/www/html/index.html
   sudo chmod 755 /var/www/html
   sudo chmod 644 /var/www/html/index.html
   sudo chown -R www-data:www-data /var/www/html

3. Cerca una regola di negazione nel vhost e in ogni .htaccess sotto la document root. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html li trova in un solo passaggio.
4. Aggiungi un file indice o abilita l'elenco se la richiesta riguarda una directory. Servire 403 per una directory nuda è il comportamento predefinito, non un difetto.
5. Controlla SELinux sui sistemi della famiglia Red Hat, dove i permessi Unix corretti da soli non bastano ancora: ls -Z /var/www/html, poi sudo restorecon -Rv /var/www/html.
6. Trova la regola WAF che è scattata e correggi la richiesta oppure aggiungi un'eccezione ristretta per quella regola e quel percorso. Disattivare interamente il set di regole per far sparire l'errore scambia un problema con uno peggiore.
7. Rivedi la lista di blocco alla ricerca di intervalli aggiunti durante un incidente. I blocchi temporanei a cui non è mai stata data una scadenza sono una causa comune di lamentele settimane dopo.
8. Per S3 o CloudFront, controlla la policy del bucket e la configurazione di origin access. Il corpo XML indica l'operazione che è stata rifiutata, il che punta al permesso specifico da concedere.

Controllalo dall'esterno

Un rifiuto rivolto a un solo indirizzo appare esattamente come un'interruzione dell'intero sito vista da quell'indirizzo, e non puoi distinguere le due situazioni dalla macchina a cui viene rifiutato l'accesso. Chiedi da un altro posto.

Gli header di risposta di solito indicano il livello che ha risposto. Guarda Server, e gli header specifici del fornitore come CF-Ray o X-Amz-Cf-Id, che ti dicono se il rifiuto è arrivato dalla tua origine o da un edge che non l'ha mai raggiunta:

curl -sS -D - -o /dev/null https://example.com/page
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://example.com/page

Se il secondo comando restituisce 200 dove il primo restituiva 403, il blocco è sullo user agent e non c'è nulla che non va nei tuoi permessi. Poi esegui il controllo HTTP sullo stesso URL da postazioni in più paesi contemporaneamente. Un 403 da ogni postazione è un problema di configurazione del sito. Un 403 da due paesi e 200 dal resto è una regola geografica o una lista di blocco regionale, una conclusione a cui non puoi arrivare con un solo curl dalla tua scrivania.

Intercettare un 403 non intenzionale

Le regole di accesso si rompono in modi che non producono alcun errore dalla tua parte. Un set di regole WAF si aggiorna, uno script di rinnovo del certificato riscrive una configurazione, un blocco temporaneo viene dimenticato, e il sito continua a restituirti 200 mentre rifiuta una fetta di visitatori reali. Niente nei tuoi log appare allarmante, perché un 403 è un rifiuto normale e riuscito dal punto di vista del server. Un controllo pianificato che legge il codice di stato da oltre 300 postazioni in 158 città intercetta il giorno in cui una regione inizia a essere rifiutata, e avvisa via email, SMS, chiamata vocale, Slack, Telegram e altro. Le altre guide qui sono nel cluster risolvere, e il codice di stato dietro questo messaggio ha il proprio riferimento in 403 Forbidden.