Úvod
Tento článek není určen pro koncové zákazníky a majitele e-shopů.
Článek je odborného charakteru a je určen pro programátory.
Nebudeme zacházet úplně do detailů a vysvětlování, ale vezmeme to pokud možno stručně a včetně praktických možností minimalizace škod z útoku DDoS.
Dále je nutno říci, že zde budeme pracovat s běžnými přístupy, které by měl každý mít, tedy FTP. Neřešíme situaci, kdy máme přístup na server (ssh) a jsme schopni detekovat pomocí jiných nástrojů (htop, apache status, apod.) a dále mitigovat (zmírňovat) útok na úrovni serveru. My se budeme zabývat detekcí a zmírněním útoku na úrovni webu jako takového.
Co je to DDoS?
DDoS je útok mířený na určitý web/eshop/server s cílem vyřadit jej z činnosti nebo jej alespoň zpomalit, či omezit díky krokům, které musí administrátoři/programátoři podniknout.
Typů útoku DDoS je mnoho, mají různé formy i obměny. My budeme brát v potaz nejběžnější z útoků na webserver (apache) a další napojené služby (php/mysql). S tím, že primární útok míří na apache.
Podstata DDoSu je v tom, že je posíláno většinou malé/běžné množství požadavků ovšem z obrovského množství IP adres. (řádově tisíce a více)
A to právě proto, aby nedošlo k odbavení například před firewall a pro administrátora/programátora je pak velmi složité útok kompletně odfiltrovat bez jiných škod. Dá se říci, že takový útok spolehlivě přímo odfiltrovat nejde, vždy je tam nějaká škoda, ale my se tyto škody pokusíme minimalizovat.
Detailní info o DDoS -> https://en.wikipedia.org/wiki/Denial-of-service_attack
Jak minimalizovat škody z útoku DDoS?
Záměrně neuvádíme slovní spojení typu „jak odrazit DDoS“, či „jak odfiltrovat DDoS“ apod. Viz odstavec výše. Lze minimalizovat škody.
1) Základ je detekovat typ útoku, či problému, abychom věděli, že se opravdu jedná o DDoS (nejlehčím poznávacím znakem je velmi rychle se plnící apache log – např. 1000 násobně rychle oproti jiným dnům a velké množství různých zahraničních IP adres), ale dá se očekávat, že Váš hosting to detekuje dříve než Vy a bude muset podniknout kroky za Vás (ale ne vždy to je pravidlem). Buďto Váš webhosting web vypne rovnou a nebo ho nějak omezí (individuální dle hostingu – každý hosting k tomu přistupuje jinak a jde i o to, o jaký útok se jedná atd – více proměnných).
Obecně hostingy jednají vždy v zájmu většiny, pokud tedy bude e-shop pod velkým útokem, hostingy většinou web vypnou a poté můžou nastat 2 základní scénáře:
– vypnou to a snaží se najít řešení
– vypnou to a informují zákazníka, aby si „vyřešil“ nebo aby odešel apod.
OpenServis hosting jde tou variantou více prozákaznickou, snažíme se útok analyzovat a poté postupně aplikovat různá pravidla (např. i pravidla z tohoto článku), aby byly škody pro náš hosting i zákazníka minimální. Zákazník tedy ve většina případů nemusí činit žádné kroky. Útok DDoS ale není běžnou záležitostí (viz „Závěr“ tohoto blog postu)
2) Po detekci, kdy již víme, že se jedná o DDoS, je nutno web odstavit, aby nedocházelo ke kumulaci útoku a nárustu škod. Jak web odstavit, 2 nejlehčí základní možnosti:
A) přihlasit se na FTP a přejmenovat index.php
B) přihlásit se na FTP a přejmenovat celou složku s webem
3) Po odstavení webu si zapneme web pouze pro nás, abychom se tam dostali (může se někdy hodit a zároveň tím zjistíme, jestli je útok úspěšně odfiltrován a web běží). Toto učiníme na FTP přes .htaccess:
# Apache 2.4
<IfModule !mod_authz_core.c>
Order Deny,allow
allow from VASE_IP
</IfModule>
# Apache 2.2
<IfModule mod_authz_core.c>
Require all denied
Require ip VASE_IP
</IfModule>
Tato pravidla výše uvedená pravidla .htaccess po aplikaci bodu „5“ zakomentujeme/smažeme.
4) Nyní jsme ve stavu, kdy již o útoku víme, je odfiltrován kompletně, ale s tím i celý provoz e-shopu (zákazníci). Jediný kdo má přístup bude povolená IP adresa. Co s tím dále?
5) Více možností se nabízí, jak omezit škody z DDoSu, vyjmenujme si je:
A) 1. možnost obrany: úprava .htaccess
v .htaccess zablokovat všechny HTTP/1.0 a HTTP/1.1 požadavky (99% DDoS útoků jde právě přes tento protokol), nevýhoda je, že dojde i k blokaci např Googlebota, ale v případě emergency nás toto nezajímá a potřebujeme hlavně, aby web běžel. Na začátek souboru .htaccess dáme následující:
RewriteCond %{THE_REQUEST} HTTP/1\.
RewriteRule ^(.*)$ – [R=503,L]
Tyto řádky zajistí blokaci HTTP požadavků typu 1.* (tedy HTTP/1.0, HTTP/1.1 apod.)
Běžní zákazníci totiž přistupují přes HTTP/2.0, útočníci ve valné většině případů nikoliv.
Nicméně, pokud by útok trval déle a Vy jste chtěli Googlebota/SeznamBota povolit, možné to je, ovšem má to jeden háček, útočník se může za Googlebota také vydávat a pokud byste tuto výjimku udělali, sice povolíte přístup Googlebotovi, ale zároveň i útočníkovi, pokud se za Googlebota bude vydávat (je to velmi běžná praktika při útoku, maskovat se jako regulérní bot). Možnosti detekce jestli se jedná o regulérního bota jsou, ale to už je více složité a mimo obsah tohoto článku.
Pro aplikaci whitelistu na Googlebota/SeznamBota/OpenServis/GoPay/Comgate(Zend_Http_Client) by pravidla vypadala takto. Toto řešení doporučujeme jen v případě, že útok bude trvat delší dobu a nebude jiné řešení – zároveň je nutno provést analýzu bližší, jelikož se útočník může schovávat za tyto user agenty.
RewriteCond %{THE_REQUEST} HTTP/1\.
RewriteCond %{HTTP_USER_AGENT} !^.*(Googlebot|SeznamBot|OpenServis|GoPay|Zend_Http_Client).*$
RewriteRule ^(.*)$ – [R=503,L]
Pokud by se útočník schovával a vydával se za tyto User Agenty, lze provést whitelist místo user agentů třeba dle IP adres. Pak by kód mohl vypadat takto:
RewriteCond %{THE_REQUEST} HTTP/1\.
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123$
RewriteCond %{REMOTE_ADDR} !^111\.111\.111\.111$
RewriteRule ^(.*)$ – [R=503,L]
Tím jsme povolili 2 imaginární IP adresy:
123.123.123.123 + 111.111.111.111
Zhodnocení tohoto kroku:
Je to velmi vhodné a účinné, jelikož dojde k odfiltrování většiny útoku již na úrovni .htaccess, tedy výhradně apache a není NIJAK zatěžováno PHP, ani MySQL. 90% prostředků bere právě PHP/MySQL. Proto blokace na úrovni apache je nejlepší možnou volbou pro běžného uživatele (samozřejmě nejlepší je to řešit již na úrovni firewallu, tedy ještě na síťové vrstvě, nikoliv té aplikační, ale to není obsahem tohoto článku)
Doporučujeme variantu bez whitelistu Googlebota/SeznamBota.
Pokud útok probíhá přes HTTP/2.0, a nikoliv HTTP/1.x, je toto řešení k ničemu, protože zablokování HTTP/2.0 = zablokování regulérních návštěvníků. Tento krok tedy vynechte, pokud jste pod útokem typu HTTP/2.0.
„R=503“ = dává stavový kód 503 (pokud byste chtěli 403, použijte „F“ místo „R=503“
„L“ = říká, že žádná další pravidla .htaccess nebudou provedena (není důvod)
Nutno podotknout, že po skončení útoku je vhodné vrátit vše zase zpět, aby nedošlo k dlouhodobé blokaci např. Googlebota apod. Googlebot není hloupý, krátkodobá nedostupnost je věc se kterou si poradí, ale blokovat ho týdny není ideální. Blokace by měly probíhat pouze po dobu útoku a chvíli po něm (max. 24h), pokud ovšem čelíte útoku dlouhodobě a není to jen jednorázové, je nutno nechat pravidla zapnutá a mezitím vyhledat odbornou pomoc. V praxi 99% útoku není pravidelných, takže se tím 1% pravidelných útoků nebudeme zabývat a budeme brát v potaz, že se jedná o „jednorázovou“ záležitost.
V případě delšího útoku je možno také aplikovat whitelist na IP adresy Google (Soupis IP adres google je k dispozici přímo v PrestaShopu v sekci „Geolokace“ -> „Bílá listina IP adres“, či se dá vygooglit)
B) 2: možnost obrany: PrestaShop Geolokace
V PrestaShopu můžete aktivovat Geolokaci, „Geolokace v PrestaShopu, aneb blokujeme nežádoucí země„, jediný rozdíl oproti uvedenému článku je, že nastavíte Geolokaci takto:
1) „Chování Geolokace pro omezené země“ -> „Návštěvníci nevidí váš katalog“
2) „Chování Geolokace v jiných zemích“ -> „Návštěvníci nevidí váš katalog“
3) „Vyberte země, ze kterých lze přistupovat k vašemu obchodu“ -> Zvolte pouze země, kam reálně prodáváte. Útoky DDoS jsou specifické tím, že běží z celého světa, pokud tedy prodáváte pouze CZ/SK, je to ideální řešení. Pokud prodáváte např. i do zahraničí, budete muset bohužel odfiltrovat i reálné zákazníky z těchto zemí. Pokud prodáváte POUZE do zahraničí, máte problém a Geolokace Vám nemusí pomoci. (Škody vždy nějaké budou, je nutno je minimalizovat)
Zhodnocení tohoto kroku:
Je to méně vhodné než .htaccess řešení, jelikož sice dojde k odfiltrování většiny útoku, ale s tím, že požadavky projdou z apache vrstvy i do PHP a MySQL. Úspěšnost závisí na velikosti útoku. Výhodou tohoto řešení je, že PrestaShop již obsahuje nativní IP whitelist pro GoogleBota v sekci „Bílá listina IP adres“. Pokud by tam tato sekce nebyla vyplněna IP adresami, buďto je musíte uvést ručně a nebo povolit zemi USA ze které Googlebot přistupuje. Pokud ovšem útok není zrovna z USA, že? 🙂
Pokud by náhodou tento seznam ve Vaší verzi PrestaShopu nebyl, zde je k dispozici:
„PrestaShop – Originální seznam IP adres pro whitelist geolokace“
C) 3. možnost obrany: Cloudflare – „Under Attack mode“
Pokud máte DNS Vašeho webu přes Cloudflare, máte v tomto směru výhodu, že Cloudflare takové útoky zvládne ustát v případě, že ručně zapnete mód „Under Attack mode„.
Zhodnocení tohoto kroku:
Ne každý používá Cloudflare, vlastně 99% lidí ho nepoužívá, takže nebude vhodná pro každého, ale jedná se o velmi sofistikovanou ochranu.
Pokud jste pod útokem, Cloudflare nemáte a nedaří se Vám odfiltrovat útok pomocí bodu 5A+5B, doporučujeme CF zřídit. Pro tyto účely stačí účet zdarma, není třeba placený.
Výhoda CF je, že má datacentra po celém světe a obrovskou výpočetní kapacitu, aby si i s obrovským útokem poradil – to je konec konců smyslem těchto služeb.
CF má samozřejmě i nevýhody, ale zde se bavíme pouze o tom, co nám pomůže zmírnit případný DDoS útok.
Závěr
– Veškeré uvedené body A+B+C je možno zkombinovat a jsou vzájemně kompatibilní!
– Jakékoliv snahy o zjištění útočníka jsou marné, protože útočníci jsou převážně botnet, tedy běžní uživatelé, kteří o tom ani nevědí a mají infikovaný PC. IP adresy jsou z celého světa. Šance na odhalení reálného útočníka je prakticky nulová.
– Útoky mají více forem, zde je popsán ten nejběžnější a zároveň možné řešení, které je aplikovatelné na 90% útoků.
– Zdroje útočníků (respektive objednavatele útoku) nejsou nekonečné. Někdo si ten útok musel objednat a zaplatit a určitě ho nezaplatil na věky věkoucí… 🙂
– Pokud jste pod DDoS nikdy to není jen tak, je to velmi vzácné a zřejmě někomu lezete do zelí. Objednat DDoS také není úplně jednoduché a běžný člověk nemá šanci toto zajistit vlastními silami, pokud tedy čelíte DDoS útoku, je v tom určitě něco většího. Rozhodně to není „náhoda“…
Hezké Vánoce všem! 🙂