403 Zakázané chyby při práci na vašem webu? Firewally, firewally, firewally

Zakázaná chyba 403 se nejčastěji vyskytuje, když naše bezpečnostní systémy chrání váš web. Náš firewall webových aplikací (nazývaný Mod Security nebo modsec) mnohem častěji chrání váš web před automatickými pokusy o hackování.

V některých případech však mohou být legitimní akce nesprávně označeny jako útok a vaše akce bude zablokována. Tomu se říká falešně pozitivní. Zde je několik běžných scénářů, kdy k tomu dojde:

• Při použití libovolného nástroje pro tvorbu webových stránek se nemusí podařit uložit změny
• Pokud používáte téma/tváře Divi pro WordPress, zobrazí se něco jako „Chyba při ukládání stránky“ a poté se zobrazí seznam možných příčin.
• Při přidávání kódu javascript nebo PHP prostřednictvím panelu administrátora vašeho webu (a nikoli pomocí Správce souborů Plesk nebo FTP).

Pokud se vám zobrazuje zakázaná chyba 403, která neodpovídá jedné z výše uvedených akcí, možná budete chtít nejprve prostudovat našeho obecného průvodce odstraňováním chyb 403.

To se může stát zdánlivě z ničeho nic protože naše pravidla brány firewall jsou aktualizována každý týden; potenciálně přidávání nových pravidel každý týden, která by mohla ovlivnit provoz vašeho webu. Pravidla s největší pravděpodobností ovlivní odesílání data na server, například při odesílání formuláře nebo aktualizaci dat v backendu vašeho webu.

Jak najít a interpretovat protokoly brány firewall

Prvním krokem je zkontrolovat protokoly serveru, abyste zjistili, proč poskytuje takovou chybu. Podívejte se na našeho průvodce, jak používat správce souborů Plesk k analýze protokolů vašich webových stránek.

Protože náš firewall webových aplikací pomáhá blokovat běžné útoky, můžete v protokolu vidět mnoho záznamů ModSecurity . Je důležité identifikovat položky protokolu, které přímo korespondují s akcí, kterou provádíte, jinak skončíte oslabením firewallu a zároveň nevyřešíte problém.

Chyby související s firewallem budou vypadat takto:

ModSecurity: Access denied with code 403 (phase 2). 
Pattern match "(asfunction|data|javascript|livescript|mocha|vbscript):" at ARGS:input_5_7_data_canvas. 
[file "/etc/httpd/conf/modsecurity.d/rules/comodo/07_XSS_XSS.conf"] [line "227"] 
[id "212770"] [rev "4"] 
[msg "COMODO WAF: XSS Attack Detected||customerdomain.tld|F|2"] 
[data "Matched Data: data: found within ARGS:input_5_7_data_canvas: data:image/png;base64,{{{{snipped}}}}] 
[severity "CRITICAL"] [hostname "customerdomain.tld"] 
[uri "/specific_uri_requested/"] 

Náš vzorový záznam protokolu výše je falešně pozitivní, ke kterému došlo při odesílání formuláře Gravity Forms s obrázkovou přílohou.

Vytrhli jsme hromadu zbytečných kousků a nahradili jsme je {{{{snipped}}}}, aby to bylo trochu čitelnější. Některé části jsme také označili tučným písmem, abychom označili, co je pro nás nejdůležitější.

Při čtení tučných sekcí v pořadí tato chyba uvádí, že brána firewall nalezla:

• Přístup byl odepřen se zakázanou chybou (kód 403 ) (Poznámka:Pokud nevidíte 'kód 403' nebo 'Přístup odepřen', pak položka protokolu ModSecurity, kterou si prohlížíte, není relevantní:přejděte na další. Některé položky jsou určeny pro ladění nebo obecné informace, nikoli všechny jsou pro blokování.)
• Nějaký druh skriptu (javascript, livescript , atd.)
• Pomocí ID pravidla 212770
• Že to bylo považováno za XSS útok (Skriptování napříč weby)
• Při odesílání obrázku v kódovaném formátu base64 (data:image/png;base64 )
• Szávažností „KRITICKÉ“ (Upozorňujeme, že pokud uvidíte závažnost DEBUG nebo VAROVÁNÍ, pravděpodobně nebudou zodpovědní za viditelnou chybu 403)
• Na URI /specific_uri_requested/

Firewall je z toho pěkně nervózní! Srozumitelné:je to náhodný skript s podivně vypadajícími daty…

Protože víme, že k problému dochází, když legitimní uživatel odešle gravitační formulář a skutečně se jedná o obrázek, jedná se pravděpodobně o legitimní případ použití, a proto je chyba falešně pozitivní.

Pokud potřebujete pomoc s tlumočením, otevřete si lístek! Nezapomeňte uvést záznam protokolu, abychom jej mohli rychle analyzovat.

Níže naleznete dva způsoby, jak tyto chyby obejít:1) deaktivace brány firewall (doporučeno pouze ve vybraných případech) a 2) vyloučení konkrétních pravidel, která generují falešně pozitivní výsledek.

Řešení 1 (dočasné):Vyvíjí se? Zakázat bránu firewall

Pokud právě vyvíjíte web, je nejlepší jednoduše úplně vypnout firewall, protože pravděpodobně narazíte na řadu překážek při odesílání kódu na server přes HTTP (tj. ukládání změny CSS) v rámci WordPress.

Po dokončení úprav webu nezapomeňte znovu povolit bránu firewall, jinak váš web nebude chráněn před velkým počtem běžných útoků.

Zde je návod, jak jej zakázat:

• Ve službě Plesk se vraťte na „Webové stránky a domény“ nebo „Domény“ a klikněte na doménu.
• Klikněte na „Web Application Firewall“.
• V části „Režim brány firewall webové aplikace“ vyberte „Vypnuto“.
  Poznámka:Pokud zvolíte „Pouze detekce“, náš firewall na úrovni TCP bude stále vybírat položky protokolu a zavádět dočasné zákazy. Vypnuto je nejlepší během vývoje.
• Uložte kliknutím na OK nebo Použít.

Až skončíte s vývojem, znovu zapněte bránu firewall provedením stejných kroků, ale vyberte „Zapnuto“ místo „Vypnuto“.

Řešení 2 (trvalé):Vyjma pravidel ModSec

Pokud budou uživatelé vašeho webu pravidelně provádět stejnou akci, jakou jste spouštěli 403, pak úplně deaktivovat firewall prostě nebude fungovat!

Místo toho pojďme do toho a vylučme toto pravidlo z brány firewall pro doménu. V našem příkladu výše jsme identifikovali bezpečnostní pravidlo ID 212770, ale vaše bude jistě jiné. Prohledejte záznam v protokolu, dokud nenajdete ID, bude to vypadat takto:[id „212770“] pak…

• Ve službě Plesk se vraťte na „Webové stránky a domény“
• Klikněte na „Web Application Firewall“.
• V části „Vypnout pravidla zabezpečení“ zadejte ID číslo, které jste našli v protokolu (obvykle jedno na řádek, pokud jich máte více).
• Uložte kliknutím na OK nebo Použít.

Nyní zkuste provést akci, která dříve způsobila problém.

Pokud problém NENÍ vyřešen a stále se vám zobrazuje chyba 403, je pravděpodobné, že akce spustila více pravidla firewallu. Opakujte výše uvedený postup, dokud nenajdete a nevyloučíte všechna ID pravidel způsobující problémy. Upozorňujeme, že pokud tuto chybu způsobuje více ID pravidel, budou pravděpodobně velmi podobná, Při kontrole nejnovějších záznamů protokolu se proto velmi pečlivě dívejte, abyste se ujistili, že se ty, které vidíte, mírně liší od těch, které jste již vyloučili.

Nejvíce jsme museli vyloučit během jednoho sezení 5, takže je velká šance, že to napravíte během pouhých 2 nebo 3 vyloučení.

Odstraňování problémů

Pokud vyloučíte spoustu pravidel, dostanete se k chybě, jako je tato, která nemá přiřazené ID:

ModSecurity: Output filter: Response body too large (over limit of 524288, total not specified).

To znamená, že budete muset tyto limity zvýšit. Pokud máte přístup správce k Plesku, můžete vložit následující pod Nástroje a nastavení> ModSecurity> karta Nastavení> Vlastní direktivy:

SecResponseBodyLimit 546870912
SecRequestBodyInMemoryLimit 546870912

Pokud nemáte administrátorský přístup k Plesku a jste u nás hostováni, otevřete si vstupenku a my se o to postaráme za vás!