Jak chránit WordPress před DDoS útoky.

Proč WordPress přitahuje DDoS útoky

WordPress pohání velkou část webu a právě tahle popularita je problém: útočník váš web nikdy nemusí zkoumat. Každá instalace má stejné rozložení souborů, stejnou přihlašovací URL, stejný REST jmenný prostor i stejné drahé endpointy. Jeden skript napsaný proti WordPressu funguje na miliony cílů — včetně vašeho.

Druhým důvodem je cena jednoho požadavku. Statický soubor se přečte z paměti a je hotovo výrazně pod jednou milisekundou. Necachovaná stránka WordPressu znamená PHP workera, bootstrap WordPressu, kód šablony a pluginů a několik databázových dotazů — často 200–600 ms práce. Útočník vydá jeden levný HTTP požadavek, vy tisícinásobek. To je nákladová asymetrie za každým útokem na vrstvě 7 a WordPress ji útočníkům dává rovnou z krabice.

Třetí důvod je to, co ve skutečnosti dojde. Weby na WordPressu skoro nikdy neumírají na vyčerpané pásmo. Umírají proto, že je plně obsazený pool workerů PHP-FPM — typicky někde mezi 5 a 50 procesy — takže každý další návštěvník stojí ve frontě za záplavou a nakonec dostane 502 nebo 504. Stačí pár set požadavků za sekundu na necachovatelnou cestu. K výpadku nepotřebujete útok z titulků novin, stačí znuděný člověk se skriptem.

Endpointy, na které útočníci skutečně míří

Proč bezpečnostní plugin DDoS útok nezastaví

Bezpečnostní plugin pro WordPress žije uvnitř toho, co je pod útokem. Projděte si cestu požadavku: záplava dorazí na váš server, webový server přijme spojení, worker PHP-FPM ho převezme, WordPress nabootuje, načtou se pluginy — a teprve pak se plugin rozhodne požadavek zablokovat. To už jste utratili přesně ten zdroj, který se útočník snaží vyčerpat. Při pár tisících požadavcích za sekundu vás „zablokovat požadavek" stojí skoro totéž co „obsloužit požadavek".

Není to kritika pluginů, jen popis toho, kde sedí. Zamykání účtů po neúspěšných přihlášeních, skenování malwaru, kontrola integrity souborů i dvoufaktorové ověření mají skutečnou hodnotu — a ani jedno není obranou proti objemu. Totéž, byť mírněji, platí pro pravidla v .htaccess a firewally na úrovni serveru: blokovat v nginxu je mnohem levnější než v PHP, ale pořád to je vaše linka, vaše CPU a vaše tabulka spojení, které útok pohlcují.

Mitigace musí proběhnout dřív, než požadavek dorazí k PHP — a ideálně dřív, než vůbec dorazí na váš server. To je celý argument pro filtrování na edge, rozebraný v článku co je DDoS mitigace.

Krok 1 — Zavřete zesilovače, které WordPress přináší

• XML-RPC. Pokud ho nepotřebujete pro vzdálené publikování nebo plugin, který ho stále vyžaduje, /xmlrpc.php rovnou zablokujte. Přijímá mnoho pokusů o autentizaci v jediném požadavku, což z něj dělá nejefektivnější plochu pro brute force na celé platformě.
• WP-Cron. WordPress ve výchozím stavu kontroluje plán úloh při načtení stránky, takže se z útoku stane způsob, jak vám nepřetržitě spouštět cron. Dejte do wp-config.php define('DISABLE_WP_CRON', true); a volejte wp-cron.php ze skutečného systémového cronu každých pár minut.
• Pingbacky a trackbacky. Vypněte je v Nastavení → Diskuse. Existují proto, aby cizí servery mohly nechat pracovat ten váš.
• Výčet autorů. Pokud nepublikujete archivy autorů, zablokujte přesměrování ?author= a cestu wp-json/wp/v2/users. Výčet uživatelů je průzkumný krok, který teprve zefektivní následný útok na hesla.
• Nepoužívané REST cesty. Headless nebo málo využívané REST API má být dostupné jen tam, kde ho skutečně potřebujete.

Oficiální průvodce zabezpečením WordPressu pokrývá zbytek základů — aktualizace, práva souborů, databázové uživatele s minimem oprávnění. Nic z toho záplavu nezastaví a všechno by mělo platit tak jako tak.

Krok 2 — Udělejte z běžného případu nulové náklady

Plné cachování stránek na edge je pro web na WordPressu nejúčinnější dostupná obrana proti DDoS, protože pro anonymní návštěvníky odstraní PHP z cesty požadavku úplně.

• Cachujte HTML pro anonymní provoz a obcházejte cache, když je přítomná cookie wordpress_logged_in_ nebo cookie košíku WooCommerce. Přihlášení dostanou dynamické stránky, záplava ne.
• Ignorujte neznámé query stringy v klíči cache, aby ?utm_source=… i ?x=8462 ukazovaly na tentýž objekt. Jinak vám parametry na obejití cache projdou rovnou do PHP.
• Při chybě originu servírujte zastaralý obsah (stale-while-revalidate, stale-if-error). Když origin přece jen podlehne, návštěvníci dál vidí web, ne 502.
• Statická aktiva cachujte agresivně s dlouhými TTL a otisky ve jménech souborů.

Ten výpočet stojí za to říct nahlas: s TTL 60 sekund na edge vyprodukuje záplava 5 000 požadavků za sekundu na vaši homepage jediný dotaz na origin za minutu. Všechno ostatní obslouží edge — a proto je CDN pancířem, ne jen nástrojem na rychlost.

Krok 3 — Postavte bránu před přihlášení a administraci

wp-login.php se nedá cachovat, míří na něj útoky nepřetržitě a každý zásah nabootuje celý stack. Dejte mu vlastní režim: přísný rate limit na klienta, výzvu pro anonymní klienty a — pokud se váš tým hlásí ze známých míst — omezení /wp-admin/ podle země nebo IP. Přidejte dvoufaktorové ověření a přestaňte používat účet jménem admin. Credential stuffing a záplava na vrstvě 7 jsou tentýž provozní vzorec s jiným cílem a stejná brána zvládne obojí.

Krok 4 — Omezte drahé dynamické cesty

Vyhledávání, AJAX a e-shopové endpointy jsou místa, kde malý objem požadavků nakoupí velké množství práce databáze.

• Omezte /?s= na klienta a úspěšná vyhledávání krátce cachujte; prázdné a absurdně dlouhé dotazy rovnou odmítejte.
• Omezte admin-ajax.php — právě tam kód pluginů, který jste nepsali, dělá neohraničenou práci.
• Ve WooCommerce chraňte ?add-to-cart=, /cart a /checkout limity na klienta, ne cachováním — musí zůstat dynamické, takže je místo toho ohraničte.
• Postavte před databázi objektovou cache (Redis nebo Memcached), aby opakované dotazy přestaly být opakovanou prací.

Krok 5 — Zajistěte, aby edge nešlo obejít

Nic z toho nepomůže, pokud je skutečná IP adresa vašeho serveru stále dostupná. Útočníci vytáhnou historii DNS, prohlédnou logy transparentnosti certifikátů a proklepnou neproxované subdomény jako mail. nebo cpanel. — a záplavu pošlou přímo mimo vaši filtrační vrstvu. Nastavte firewall originu tak, aby přijímal HTTP jen z vaší ochranné sítě. Celý postup najdete v článku jak skrýt IP adresu originu.

Krok 6 — Nadimenzujte origin na to, co přece jen projde

Nastavte max_children u PHP-FPM na to, co vaše RAM opravdu unese, ne na optimistické číslo — přetížení pak degraduje místo toho, aby server odešel do swapu. Přidejte v nginxu mírný limit_req jako pojistku. Omezte čas pomalých dotazů. Samy o sobě útok nepřežijí — rozhodují o tom, jestli ta část, která k vám dorazí, způsobí zpomalení, nebo pád.

Pokud tohle čtete proto, že je váš web právě teď dole, projděte nejdřív jak zastavit DDoS útok a k zabezpečení se vraťte potom.

Jak Itnetic chrání weby na WordPressu

Itnetic stojí před WordPressem jako reverzní proxy, kterou zapnete dvěma DNS záznamy — žádný plugin k instalaci, žádné zásahy do serveru a nic, co by se udržovalo uvnitř WordPressu, kde by vás požadavky útočníka už stály workera.

Anonymní provoz narazí na edge na neviditelnou výzvu: skutečné prohlížeče projdou bez CAPTCHY a skriptované záplavy mířené na wp-login.php a xmlrpc.php se k vašemu PHP poolu vůbec nedostanou. Behaviorální signatury a filtrace podle reputace IP odhalí klienty, kteří předstírají prohlížeč, a pravidla WAF vám dovolí povolit, zablokovat nebo vyzvat podle cesty, metody, země či fingerprintu klienta — tak zamknete /wp-admin/ na svou zemi zhruba za minutu. Cache na edge obslouží anonymní stránky bez dotyku s originem a rate limity ohraničí cesty, které musí zůstat dynamické: vyhledávání, admin-ajax.php, košík a pokladnu. Pokud provozujete WordPress headless, dají se cesty wp-json označit jako API zóna, aby strojoví klienti dostali 429 místo výzvy, kterou nedokážou vyřešit.

Každý verdikt skončí v logu jednotlivých požadavků a analytice, takže po incidentu ukážete přesně, co bylo zablokováno a proč. Útočný provoz se nikdy nepočítá do vašeho limitu přenosu — z útoku nemá vzniknout faktura — a DDoS ochrana je součástí každého tarifu, včetně toho bezplatného.

DDoS ochrana od Itnetic je živá zhruba za pět minut. Pokud chcete nejdřív kontext, začněte tím, co je DDoS mitigace.