Access denied on this server: příčiny a řešení

Co chyba znamená

Toto znění není součástí žádného standardu, a proto se objevuje v tolika různých podobách. Apache ho vypíše z pravidla pro adresář. ModSecurity a hostingové administrační panely ho vypíší, když zafunguje pravidlo. CDN nebo WAF vypíše vlastní brandovanou verzi s referenčním číslem. AWS ho vrátí jako krátký XML dokument z S3 nebo CloudFront. Všechny na úrovni HTTP říkají totéž: 403, odmítnuto, a žádné pozvání zkusit to znovu s přihlašovacími údaji.

Právě tahle poslední část ji odlišuje od chyb, se kterými se plete. 401 vás žádá o autentizaci a počítá s tím, že to zkusíte znovu. 404 říká, že prostředek neexistuje. 403 říká, že prostředek existuje a vy ho nedostanete, a opakování stejného požadavku přinese stejnou odpověď. Samotnému stavu se věnuje návod 403 Forbidden; tento návod řeší, jak zjistit, která vrstva řekla ne.

Nejdřív zjistěte, jestli jde o vás, nebo o všechny, protože řešení nemají nic společného. Pokud kolegovi na jiné síti se stránka načte bez problémů, blokovaní jste vy. Pokud ji nedokáže načíst nikdo, web je špatně nakonfigurovaný.

Proč se to stává

• Vaše IP adresa je zablokovaná. Pravidlo firewallu nebo WAF přidané po neúspěšných přihlášeních, scraper na vaší síti, nebo ruční blokace, kterou nikdo neodstranil.
• Rate limiting. Příliš mnoho požadavků v krátkém okně, což se snadno spustí session s hodně refreshováním při ladění nebo sdíleným kancelářským připojením.
• Geografická omezení. Weby omezené na jednu zemi, nebo blokující celý region hromadně po zneužití z něj.
• Sdílená IP nebo IP se špatnou reputací. Výstupní uzly VPN, NAT mobilních operátorů a levné hostingové rozsahy bývají blokované jako celek za to, co provedli jiní uživatelé.
• Pravidla proti botům čtoucí váš user agent. Nástroje pro příkazovou řádku, headless prohlížeče a neobvyklé řetězce user agent bývají odmítnuty tam, kde běžný prohlížeč projde.
• Zastaralé cookies nebo rozbitá session. Vypršelý session token může vyvolat odmítnutí místo přesměrování na přihlašovací stránku.
• Rozšíření prohlížeče, které odstraňuje nebo přidává hlavičky, nebo firemní proxy přepisující požadavek.
• Oprávnění souborů a adresářů. Uživatel, pod kterým běží webový server, nemůže soubor přečíst nebo projít nadřazený adresář.
• Chybějící index soubor a vypnutý výpis obsahu. Požadavek na adresář bez ničeho k obsloužení a s aktivním Options -Indexes vrátí 403 místo prázdné stránky.
• Explicitní pravidlo pro zamítnutí. Require all denied v konfiguraci Apache nebo pozůstatek souboru .htaccess z okna údržby.
• Falešně pozitivní zásah WAF. ModSecurity a podobné sady pravidel odmítají legitimní požadavky, které obsahují něco připomínajícího pokus o injekci, často v poli formuláře nebo v query stringu.
• Oprávnění cloudového úložiště. Zásada bucketu S3 nebo nastavení přístupu k originu CloudFront, které neumožňuje objekt přečíst.

Pokud jste návštěvník

1. Ověřte stavový kód místo spoléhání na text stránky. curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page vám řekne, jestli jde skutečně o 403, nebo o 401 či 429 v podobném převleku.
2. Otevřete stránku v anonymním okně. Tím jedním krokem odpadnou cookies i většina rozšíření. Pokud tam projde, oprava se týká vašeho profilu, ne webu.
3. Smažte cookies konkrétně pro daný web místo mazání všeho, a pak stránku načtěte znovu.
4. Vypněte VPN nebo proxy a zkuste to znovu. Pokud pak funguje, odmítnutá byla adresa výstupního uzlu, a přepnutí na jiný region to obvykle vyřeší.
5. Zkuste jinou síť, nejjednodušeji telefon na mobilních datech. Tohle je nejrychlejší způsob, jak dokázat, že blokovaná je právě vaše adresa.
6. Vypínejte rozšíření jedno po druhém, začněte blokátory reklam, nástroji na ochranu soukromí a čímkoli, co upravuje hlavičky.
7. Zjistěte, jestli je blokace regionální, zeptejte se někoho v jiné zemi, nebo si na blokovací stránce přečtěte, jestli nezmiňuje vaši lokalitu.
8. Kontaktujte provozovatele webu s referenčním číslem, pokud ho blokovací stránka zobrazuje. Stránky WAF obvykle vypíšou ID incidentu, podle kterého provozovatel za pár vteřin najde přesné pravidlo, které zafungovalo.

Pokud je web váš

1. Nejdřív si přečtěte chybový log. Přímo pojmenuje příčinu a bez něj je každý další krok jen hádání:

   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 loguje problém s oprávněním jako "client denied by server configuration" nebo "Permission denied". nginx loguje "directory index of ... is forbidden" nebo "open() ... failed (13: Permission denied)". Tyto tři hlášky pokrývají většinu případů.
2. Zkontrolujte oprávnění po celé cestě, včetně každého nadřazeného adresáře. Adresář, do kterého webový server nemůže vstoupit, odmítne všechno pod ním, ať už samotný soubor vypadá sebelépe:

   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. Hledejte pravidlo pro zamítnutí ve vhostu a v každém souboru .htaccess pod kořenem dokumentů. sudo grep -rn "Require\|Deny from" /etc/apache2/sites-enabled /var/www/html je najde na jeden průchod.
4. Přidejte index soubor nebo povolte výpis, pokud jde o požadavek na adresář. Vracet 403 na holý adresář je výchozí chování, ne chyba.
5. Zkontrolujte SELinux na systémech rodiny Red Hat, kde na samotná správná unixová oprávnění nemusí stačit: ls -Z /var/www/html, pak sudo restorecon -Rv /var/www/html.
6. Najděte pravidlo WAF, které zafungovalo, a buď opravte požadavek, nebo pro dané pravidlo a danou cestu přidejte úzkou výjimku. Vypnutí celé sady pravidel, aby chyba zmizela, jen vymění jeden problém za horší.
7. Projděte si blokovací seznam a hledejte rozsahy přidané během incidentu. Dočasné blokace, kterým nikdo nenastavil expiraci, bývají běžnou příčinou stížností o týdny později.
8. U S3 nebo CloudFront zkontrolujte zásadu bucketu a konfiguraci přístupu k originu. Tělo XML pojmenovává operaci, která byla odmítnuta, a to ukáže přesně na oprávnění, které je potřeba udělit.

Ověřte to zvenčí

Odmítnutí namířené na jednu adresu vypadá úplně stejně jako výpadek celého webu, když se díváte z tohoto stroje, a z něj to jedno od druhého nerozeznáte. Zeptejte se odjinud.

Hlavičky odpovědi obvykle prozradí vrstvu, která odpověděla. Podívejte se na Server a na hlavičky konkrétních poskytovatelů jako CF-Ray nebo X-Amz-Cf-Id, které řeknou, jestli odmítnutí přišlo od vašeho originu, nebo od edge uzlu, který se k němu vůbec nedostal:

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

Pokud druhý příkaz vrátí 200 tam, kde první vrátil 403, blokace je na user agentu a s vašimi oprávněními není nic v nepořádku. Pak spusťte HTTP kontrolu na stejnou URL z kontrolních bodů ve více zemích najednou. 403 z každé lokality je problém konfigurace webu. 403 ze dvou zemí a 200 ze zbytku je geografické pravidlo nebo regionální blokovací seznam, což je závěr, ke kterému se jedním curl z jednoho stolu nedostanete.

Jak zachytit 403, kterou jste nechtěli

Pravidla přístupu se lámou způsoby, které na vaší straně nevyvolají žádnou chybu. Sada pravidel WAF se aktualizuje, skript pro obnovu certifikátu přepíše konfiguraci, dočasná blokace se zapomene odstranit, a web vám dál vrací 200, zatímco odmítá část skutečných návštěvníků. Ve vašich vlastních lozích nevypadá nic alarmujícího, protože 403 je ze serverového pohledu normální, úspěšné odmítnutí. Naplánovaná kontrola, která čte stavový kód z více než 300 kontrolních bodů ve 158 městech, zachytí den, kdy určitý region začne dostávat odmítnutí, a upozorní e-mailem, SMS, hlasovým hovorem, přes Slack, Telegram a další kanály. Další návody najdete v clusteru oprav a stavový kód za touto zprávou má vlastní samostatný návod v 403 Forbidden.