Naar hoofdinhoud springen

Handleidingen / Oplossen: handleidingen voor veelvoorkomende foutmeldingen

Access denied on this server: oorzaken en oplossingen

"Access denied on this server" betekent dat de server uw verzoek ontving, begreep, en weigerde het te bedienen. De pagina bestaat en de machine draait. Iets tussen het verzoek en het bestand besliste dat u het niet mag hebben, en dat draagt vrijwel altijd HTTP-status 403.

Wat de fout betekent

De formulering maakt deel uit van geen enkele standaard, wat verklaart waarom hij in zoveel verschillende vormen opduikt. Apache drukt hem af vanuit een directoryregel. ModSecurity en hostingcontrolepanelen drukken hem af wanneer een regel afgaat. Een CDN of WAF drukt zijn eigen gebrandmerkte versie af met een referentienummer. AWS geeft hem terug als een kort XML-document vanuit S3 of CloudFront. Ze zeggen allemaal hetzelfde op HTTP-niveau: 403, geweigerd, en geen uitnodiging om het opnieuw te proberen met inloggegevens.

Dat laatste onderscheidt hem van de fouten waarmee hij wordt verward. Een 401 vraagt u zich te authenticeren en verwacht een nieuwe poging. Een 404 zegt dat de resource er niet is. Een 403 zegt dat de resource er wel is en dat u hem niet krijgt, en het onveranderd herhalen van het verzoek levert hetzelfde antwoord op. De status zelf staat behandeld in 403 Forbidden; deze handleiding gaat over uitzoeken welke laag nee zei.

Begin met uitzoeken of het u treft of iedereen, want de oplossingen hebben niets met elkaar gemeen. Als een collega op een ander netwerk de pagina wel gewoon laadt, bent u geblokkeerd. Als niemand hem kan laden, is de site verkeerd geconfigureerd.

Waarom het gebeurt

  • Uw IP-adres is geblokkeerd. Een firewall- of WAF-regel toegevoegd na mislukte inlogpogingen, een scraper op uw netwerk, of een handmatige blokkade die niemand heeft verwijderd.
  • Rate limiting. Te veel verzoeken in een kort tijdsvenster, wat makkelijk te triggeren is met een debugsessie vol herladen of een gedeelde kantoorverbinding.
  • Geografische beperkingen. Sites die tot één land beperkt zijn, of die een regio in zijn geheel blokkeren na misbruik ervandaan.
  • Een gedeeld of als verdacht gemarkeerd IP. VPN-uitgangsknooppunten, mobiele NAT van providers en goedkope hostingreeksen worden vaak als groep geblokkeerd om wat andere gebruikers deden.
  • Botregels die uw user agent lezen. Commandoregeltools, headless browsers en ongebruikelijke user-agentstrings worden geweigerd waar een normale browser wordt toegelaten.
  • Verouderde cookies of een kapotte sessie. Een verlopen sessietoken kan een weigering opleveren in plaats van een doorverwijzing naar de inlogpagina.
  • Een browserextensie die headers verwijdert of toevoegt, of een bedrijfsproxy die het verzoek herschrijft.
  • Bestands- en directoryrechten. De webservergebruiker kan het bestand niet lezen of een bovenliggende directory niet doorlopen.
  • Geen indexbestand, met listings uitgeschakeld. Een directoryverzoek met niets om te tonen en Options -Indexes in werking geeft 403 in plaats van een lege pagina.
  • Een expliciete deny-regel. Een Require all denied in de Apache-configuratie of een achtergebleven .htaccess uit een onderhoudsvenster.
  • Een vals positief van de WAF. ModSecurity en vergelijkbare regelsets weigeren legitieme verzoeken die iets bevatten dat op een injectiepoging lijkt, vaak in een formulierveld of een querystring.
  • Rechten in cloudopslag. Een S3-bucketbeleid of een CloudFront-origin-access-instelling die niet toestaat dat het object gelezen wordt.

Als u de bezoeker bent

  1. Bevestig de statuscode in plaats van op de paginatekst te vertrouwen. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page vertelt u of dit echt een 403 is of een 401 of 429 met een vergelijkbaar bericht.
  2. Open de pagina in een privévenster. Dat laat cookies en de meeste extensies in één stap vallen. Werkt het daar wel, dan zit de oplossing in uw profiel, niet in de site.
  3. Wis cookies specifiek voor die site in plaats van alles te wissen, en herlaad dan.
  4. Schakel de VPN of proxy uit en probeer opnieuw. Werkt het dan wel, dan was het adres van het uitgangsknooppunt wat geweigerd werd, en overschakelen naar een andere regio lost dat meestal op.
  5. Probeer een ander netwerk, het makkelijkst een telefoon op mobiele data. Dit is de snelste manier om te bewijzen dat uw adres het geblokkeerde ding is.
  6. Schakel extensies één voor één uit, te beginnen met advertentieblokkers, privacytools en alles wat headers wijzigt.
  7. Controleer of de blokkade regionaal is door iemand in een ander land te vragen, of door de blokkeerpagina te lezen op een vermelding van uw locatie.
  8. Neem contact op met de site met het referentienummer als de blokkeerpagina er een toont. WAF-pagina's drukken meestal een incident-ID af waarmee de beheerder binnen enkele seconden de exacte regel vindt die afging.

Als u de eigenaar van de site bent

  1. Lees eerst het foutenlogboek. Het noemt de oorzaak rechtstreeks, en elke stap hierna is giswerk zonder dat:
    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 logt een rechtenprobleem als "client denied by server configuration" of "Permission denied". nginx logt "directory index of ... is forbidden" of "open() ... failed (13: Permission denied)". Die drie berichten dekken de meeste gevallen.
  2. Controleer de rechten over het hele pad, inclusief elke bovenliggende directory. Een directory waar de webserver niet in kan, weigert alles eronder, hoe correct het bestand zelf er ook uitziet:
    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. Zoek naar een deny-regel in de vhost en in elke .htaccess onder de documentroot. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html vindt ze in één keer.
  4. Voeg een indexbestand toe of schakel listing in als het verzoek voor een directory is. 403 tonen voor een kale directory is de standaard, geen fout.
  5. Controleer SELinux op systemen uit de Red Hat-familie, waar correcte Unix-rechten alleen nog niet genoeg zijn: ls -Z /var/www/html, en dan sudo restorecon -Rv /var/www/html.
  6. Zoek uit welke WAF-regel afging en corrigeer ofwel het verzoek, ofwel voeg een nauwe uitzondering toe voor die regel en dat pad. De hele regelset uitzetten om de fout te laten verdwijnen ruilt één probleem in voor een erger.
  7. Bekijk de blokkeerlijst op reeksen die tijdens een incident zijn toegevoegd. Tijdelijke blokkades die nooit een vervaldatum kregen, zijn een veelvoorkomende oorzaak van klachten weken later.
  8. Voor S3 of CloudFront, controleer het bucketbeleid en de origin-access-configuratie. De XML-body noemt de bewerking die geweigerd werd, wat naar de specifiek te verlenen toestemming wijst.

Controleer het van buitenaf

Een weigering gericht op één adres ziet er precies uit als een sitebrede storing vanaf dat adres, en u kunt de twee niet uit elkaar houden vanaf de machine die geweigerd wordt. Vraag het ergens anders vandaan.

De responseheaders noemen meestal de laag die antwoordde. Kijk naar Server, en naar leverancierheaders zoals CF-Ray of X-Amz-Cf-Id, die u vertellen of de weigering van uw origin kwam of van een edge die hem nooit bereikte:

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

Als het tweede commando 200 teruggeeft waar het eerste 403 gaf, zit de blokkade op de user agent en is er niets mis met uw rechten. Voer dan de HTTP-check uit tegen dezelfde URL vanaf meetpunten in meerdere landen tegelijk. Een 403 vanaf elke locatie is een configuratieprobleem op de site. Een 403 vanuit twee landen en 200 vanuit de rest is een geografische regel of een regionale blokkeerlijst, een conclusie die u niet kunt trekken met één curl vanaf één bureau.

Een niet-bedoelde 403 betrappen

Toegangsregels breken op manieren die aan uw kant geen fout opleveren. Een WAF-regelset wordt bijgewerkt, een script voor certificaatvernieuwing herschrijft een config, een tijdelijke blokkade wordt vergeten, en de site blijft u 200 tonen terwijl hij een deel van de echte bezoekers weigert. Niets in uw eigen logs ziet er alarmerend uit, want een 403 is een normale, geslaagde weigering wat de server betreft. Een geplande check die de statuscode leest vanaf 300+ meetpunten in 158 steden betrapt de dag waarop een regio geweigerd begint te worden, en waarschuwt per e-mail, sms, spraakoproep, Slack, Telegram en meer. De andere handleidingen hier staan in het onderdeel oplossen, en de statuscode achter dit bericht heeft zijn eigen referentie in 403 Forbidden.

Nu controleren

Voer de gratis check uit op je eigen site, zonder account.

HTTP check

Dit permanent monitoren

Ontvang een melding zodra er iets misgaat: HostTracker controleert vanaf meer dan 300 locaties en waarschuwt je via e-mail, sms, Slack, Telegram en meer.

HostTracker-functies

Meer in dit onderdeel: Oplossen: handleidingen voor veelvoorkomende foutmeldingen