Dneska si ukážeme jak vypadá přetížený webhosting na kterém jede WordPress a jak mu můžeme pomoct, abychom nemuseli přecházet na vyšší variantu anebo hledat jiný.
Problém má tentokrát přímo tento blog flyer.cz. Je tu 91 článků, které píšu něco přes dva roky. Pravidelné viditelné imprese činní zhruba 81 lidí za den (měřeno z 60 denního průměru). Nejlepší dny tu mám něco kolem 140 impresí. Cachované stránky se vygenerují do 100ms a kompletně zobrazí do půl vteřiny. U většiny mi Pingdom hlásí rychlejší než 97% zbytku internetu. Tedy nic s čím by mohl mít problém výkonný webhosting Ebola Basic. Tak jde je problém?
Jak poznat přetížený webhosting
Základem je služba na monitorování dostupnosti. Já používám uptimerobot.com, která každých 5 minut kontroluje zdali se něco neděje. Ačkoliv je určená hlavně na měření dostupnosti stránek pozná i přetížený webhosting. Konkrétně na ní uvidíte takové minivýpadky, které nemusí být moc časté.
Datum a čas Stav Délka
Down 13.04.2016 17:54:08 Connection Timeout 0 hrs, 1 mins
Down 13.04.2016 17:47:38 Service Unavailable 0 hrs, 1 mins
Down 08.04.2016 09:21:02 Connection Timeout 0 hrs, 0 mins
Down 08.04.2016 09:14:31 Service Unavailable 0 hrs, 1 mins
Down 06.02.2016 11:28:17 Connection Timeout 0 hrs, 6 mins
Down 06.02.2016 11:17:22 Service Unavailable 0 hrs, 5 mins
Down 05.02.2016 13:15:55 Service Unavailable 0 hrs, 1 mins
Down 05.02.2016 12:53:01 Service Unavailable 0 hrs, 5 mins
Down 05.02.2016 12:03:07 Service Unavailable 0 hrs, 1 mins
Down 04.02.2016 11:31:26 Service Unavailable 0 hrs, 1 mins
Down 01.02.2016 03:53:10 Connection Timeout 0 hrs, 1 mins
Down 01.02.2016 03:46:40 Service Unavailable 0 hrs, 1 mins
Down 22.01.2016 03:42:33 Connection Timeout 0 hrs, 1 mins
Down 02.12.2015 16:12:43 Connection Timeout 0 hrs, 4 mins
Down 01.10.2015 14:44:38 Connection Timeout 0 hrs, 3 mins
Down 30.07.2015 15:25:07 Connection Timeout 1 hrs, 33 mins
Down 04.07.2015 13:20:23 Connection Timeout 0 hrs, 11 mins
Down 04.07.2015 13:12:11 Connection Timeout 0 hrs, 2 mins
Down 04.03.2015 18:30:55 Connection Timeout 0 hrs, 3 mins- Service Unavailable znamená, že došlo k chybě 5XX, konkrétně u Ebola se zobrazí 508, ale je to 503.
- Connection Timeout je spojení vypršelo, zde se může jednat také o přetížení, výpadek anebo se aktivovala nějaká ochrana na hostingu. Například odřízli zahraniční provoz. To se používá u DDoS útoků.
Samozřejmě pro výše uvedené problémy může existovat i vysvětlení na straně webu. Například špatně nakonfigurovaný skript, který se snaží někam připojovat vyčerpá přidělené prostředky. Ale já tady nemám affiliate katalog ani nesynchronizuji více RSS na jednom místě. Tedy správně byste měli tohle jako možnost vyřadit z dat v access log či error log (zaměřit se na dlouho běžící skripty). Prostě vezmeme v úvahu, že problém teď není na straně WordPress, který něco provádí na pozadí a nevíme o tom.
Vraťme se ale k monitorování dostupnosti. Že je webhosting přetížený poznáme i podle grafu odezvy (response time).
Na grafu jsou vidět podivné špičky, které přesahují i 6 vteřin. Samozřejmě i zde může být důvodem nějaký problém na trase, tedy mezi serverem na měřením dostupnosti a webserverem.
Co webhosting přetěžuje
Na každé vygenerování stránky jsou potřeba serverové prostředky. Pokud máte čistě sdílený webhosting, tak vás bude limitovat pouze to, kolik stránek můžete za jakou dobu vygenerovat. Zjednodušeně řečeno. například pokud můžete mít rozjetých maximálně 5 vláken na generování PHP, tak se musíte postarat o to, aby těchto 5 vláken vše stíhalo. Protože když budete mít 7 návštěv za vteřinu a stránka se bude generovat 1 vteřinu, tak 2 návštěvníci budou čekat ve frontě. Tady právě bývá problém s různým stahováním RSS feedů, které mohou zabrat jednotlivá vlákna na desítky vteřin a pak vám pro návštěvníky nic nezbude.
Ok ale zpět k tématu. Pro analýzu použijeme access log z Ebola, který je zdarma. Soubor najdete v adresáři logs a ten můj za 24 hodin má velikost 1,4 MB. Na každém řádku najdeme informaci kdo, kdy, jak, co požadoval a zdali mu bylo vyhověno. Celkem server obdržel 5548 požadavků.
Například:
crawl-66-249-78-41.googlebot.com - - [04/May/2016:08:vps1.biltron.es - - [04/May/2016:10:15:02 +0200] "GET //wp-xmlrpc.php HTTP/1.1" 503 299 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"01:58 +0200] "GET /kontaktni-formular/ HTTP/1.1" 200 26252 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"Z adresy crawl-66-249-78-41.googlebot.com v 8:01:58 4.5.2016 požádal přes metodu GET obsah /kontaktni-formular/. Server mu to poskytl – stavový kód 200. Celkem stránka měla 26252 bajtů. Ten někdo o sobě ještě tvrdil že má prohlížeč Googlebot/2.1.
Takže se zaměříme na období, kdy se objevují chyby 503.
Útoky
První 503 najdeme na řádku 895 v 10:15. Z URL vps1.biltron.es jde během dvou minut 178 požadavků na administraci, neexistující pluginy anebo xml-rpc. Prostě skenování zranitelností. Například:
vps1.biltron.es - - [04/May/2016:10:15:02 +0200] "GET //wp-xmlrpc.php HTTP/1.1" 503 299 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" vps1.biltron.es - - [04/May/2016:10:15:43 +0200] "GET /wp-content/plugins/revslider/temp/update_extract/revslider/polahi.php HTTP/1.1" 404 131466 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
anebo
ip184-39.ethernet.wplus.ru - - [05/May/2016:00:03:19 +0200] "POST /wp-login.php HTTP/1.0" 503 299 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36"
Většina z nich nejde na cachované stránky. Takže se s tím WordPress musí vypořádat bez cache, což může trvat i více jak vteřinu. Proto se také objeví 503.
Tohle všechno jsou útoky, které přetěžují webhosting. Mimochodem za celých 24 hodin bylo pokusů o POST na wp-login celkem 259. Což není málo. Například tento:
a170786571.example.com - - [04/May/2016:19:23:05 +0200] "POST /wp-login.php HTTP/1.1" 200 5382 "http://www.flyer.cz/wp-login.php" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; 125LA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"
To zkoušel 172x a posílal to tam každou vteřinu.
Roboti
Na web vám chodí každý den desítky i stovky robotů, kteří pořád něco stahují a kontrolují. Přitom pro vás nemají žádný význam. Většina provozovatelů hostingů je rovnou blokuje na firewall anebo řeší přes IPS/IDS ochranu.
Například tady narazil robot služby ahrefs na ochranu od Ebola
orbit002.ahrefs.com - - [04/May/2016:12:36:36 +0200] "GET /robots.txt HTTP/1.1" 503 299 "-" "Mozilla/5.0 (compatible; AhrefsBot/5.1; +http://ahrefs.com/robot/)"
Tak a tady máme robota, který se pokouší poslat komentář
84.94.90.197.cable.012.net.il - - [04/May/2016:12:58:09 +0200] "POST /wp-comments-post.php HTTP/1.0" 200 3407 "http://www.flyer.cz/chyby-a-problemy/problemy-s-pluginem-yoast-seo/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36"
Samozřejmě jej zastavil antispamový plugin, ale nějaké prostředky to stálo.
Řešit budeme jen roboty
V tomto konkrétním případě jsou problémy jen s roboty. Normálních lidí se tu nikdy nesejde tolik, aby způsobili přetížený webhosting. Takže stačí omezit jejich aktivitu.
Přístup do adresáře s administrací (/wp-admin/) kompletně odříznu z .hraccess pouze na IP adresu, kterou používám. Respektive se to u mě mění, tak použiji rozsah mého provozovatele.
order deny,allow
deny from all
allow from 84.42.145Tím se podstatně sníží zatížení serveru, protože ten pro kohokoliv jiného hodí vygeneruje chybu 403. WordPress se načte jen mě. Nezapomeňte si tam dát svou IP adresu. Doporučuji pak vždy otestovat přes proxy jestli to funguje. Jestliže na stejnou IP adresu nemůžete spoléhat, protože například cestujete kolem světa zkuste WordFence anebo jiný bezpečnostní plugin pro WordPress a omezete počet přihlášení/přístupů do adresáře /wp-admin/
Útoky mimo administraci jdou také omezit, ale zde je problém, že skripty komunikují na dálku a takto byste je mohli v podstatě znefunkčnit.
Ohledně škodlivých robotů, to nechám na Ebola. Většinu jich blokují autoamticky. Pokud by byl nějaký moc aktivní, tak by bylo nutné jej identifikovat (název, IP) a dát přímo na blacklist do .htaccess v hlavním adresáři. Na robots.txt zapomeňte, ten většinou ignorují.
Závěr
A zabralo to? Omezení v .htaccess bylo nasazeno při psaní článku, od té doby uběhly tři hodiny. Na grafu odezvy to vypadá po dlouhé době na klid. No posuďte sami.
Útoky na WordPress vytěžují webhosting poměrně znatelně. Daleko více než běžná návštěvnost, protože směřují na necachované části. Skenování zranitelností, bruteforce, to všechno jede prakticky nonstop klidně i desítky minut v kuse. Co vteřina to pokus. Na počítadle návštěvnosti to samozřejmě neuvidíte. V dnešní ukázce jsme odřízli pouze útoky na administraci a to ještě za cenu obětování admin-ajax.php, kterému bychom ve skriptu měli správně dát výjimku.
PS: výjimka na admin-ajax.php by měla vypadat následovně:
<Files admin-ajax.php>
Order allow,deny
Allow from all
Satisfy any
</Files>