Stručně: Automatizované útoky na webové servery probíhají ve vlnách: Programy prohledávají internet kvůli dostupným serverům, zařazují je podle vnějších znaků a masově zkoušejí známé zranitelnosti, jako je PHP2Shell. Velikost firmy přitom nehraje roli. Ochranu poskytuje záplatované PHP, malá plocha pro útok a dohled, který rychle zaznamená úspěšné zásahy.
Výchozí bod: „Kdo by se měl zajímat o náš web?“
Tuto otázku slyšíme po PHP2Shell často, zvláště od menších firem. Poctivá odpověď: pravděpodobně nikdo osobně. Ale u zranitelností tohoto druhu to ani není nutné. Útoky provádějí programy, které nehledají jména, ale příležitosti.
BSI (německý Spolkový úřad pro informační bezpečnost) u PHP2Shell počítalo s rychlým a plošným zneužíváním. Cloudflare informoval o pokusech o útok a o tom, že útočníci své vzorce měnili, aby obešli ochranná pravidla. Obojí odpovídá tomu, co se u kritických zranitelností ve velmi rozšířeném softwaru pravidelně děje.
Jak automatizované útoky na webové servery probíhají
Automatizované kampaně sledují zpravidla podobný vzorec. Následující přehled popisuje fáze obecně, bez podrobností útoků:
| Fáze | Co se děje | Co pomáhá |
|---|---|---|
| Hledání | Programy kontrolují velké rozsahy adres nebo veřejné adresáře, například protokoly certifikátů, kvůli dostupným webovým serverům | málo veřejně dostupných systémů, inventář všech adres |
| Zařazení | Vyhodnocují se odpovědi: webový server, verze PHP, CMS, typické cesty | skrýt údaje o verzi, odstranit nepotřebné soubory |
| Zkoušení | Známé zranitelnosti se testují masově, často bez předchozího zařazení | aktuální PHP, restart, WAF jako dodatečná vrstva |
| Uchycení | Při úspěchu se založí zadní vrátka, například webshell nebo cron úloha | omezená oprávnění k zápisu, žádné spouštění PHP ve složkách uploadu |
| Zužitkování | Server se využívá například pro spam, těžbu kryptoměn, přesměrování nebo krádež dat | dohled nad procesy, soubory a odchozími spojeními |
Důležitý je třetí řádek. Mnoho kampaní se vůbec nenamáhá servery předem přesně zařazovat. Prostě zkoušejí všechno, co je dostupné. Proto samotná nenápadnost nechrání.
Proč útoky přicházejí ve vlnách
Automatizované kampaně jen zřídka proběhnou jednou a už nikdy. Typický je vzorec ve vlnách. První vlna přichází krátce po zveřejnění zranitelnosti, často ještě s nedotaženými nástroji. Další vlny přicházejí, když útočníci své nástroje zlepší nebo je přizpůsobí ochranným pravidlům. Cloudflare přesně to u PHP2Shell pozoroval: změněné vzorce útoků k obejití pravidel.
Pro vás z toho plyne: Server, který první vlnu přečkal bez újmy, není trvale v bezpečí, dokud je nezáplatovaný. A nově nastavený server je cílem od okamžiku, kdy je dostupný. Kdo si například nechá vystavit nový certifikát TLS, zviditelní jméno ve veřejných protokolech certifikátů, které vyhodnocují i skenery. Nový systém by proto měl jít do sítě teprve tehdy, když je již aktualizován.
Proč jsou malé firmy dotčeny stejně
U automatizovaných útoků nezáleží na hodnotě jednotlivého cíle, ale na množství. Server malé firmy nabízí výpočetní výkon, doménu s dobrou pověstí, odesílání pošty a někdy zákaznická data. Pro útočníky to stačí.
Přistupuje k tomu: Menší firmy často nemají vlastní IT, které by aktualizace nasazovalo hned. Jejich servery zůstávají zranitelné déle a proto se častěji ocitají ve výsledkových seznamech skenerů. Kdo záplatuje jako první, z těchto seznamů vypadne.
Další bod je dodavatelský řetězec. Mnoho malých webů leží na serverech agentur nebo malých poskytovatelů hostingu, na nichž vedle sebe běží desítky projektů zákazníků. Pro útočníky je takový server obzvlášť lákavý, protože jediný zásah postihne mnoho webů najednou. Vaše riziko pak nezávisí jen na vaší vlastní pečlivosti, ale i na pečlivosti vašeho dodavatele.
Skeny ve vašich lozích jsou normální a nejsou důkazem průniku. Úspěšný útok se projeví jinými stopami: nové soubory, cizí procesy, neznámé účty, neobvyklá odchozí spojení.
Co můžete zkontrolovat sami
Pohled do logů ukazuje, jak silně je váš server skenován. Následující příkazy jen čtou a nic nemění:
# Deset adres s nejvíce požadavky v aktuálním přístupovém logu
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Požadavky zodpovězené jako „nenalezeno“, podle četnosti
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Prozrazuje server svou verzi PHP v hlavičce?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Mnoho požadavků na neexistující cesty je typický šum skenů. Pozornější byste měli být, pokud na takové požadavky najednou následují úspěšné odpovědi, pokud se ve složkách uploadu volají soubory, které neznáte, nebo pokud uživatel webového serveru spouští procesy, které jinak nikdy nespouští. Potvrzené rozpoznávací znaky speciálně pro PHP2Shell zatím neexistují, zařazení se proto opírá o takové nápadnosti v chování. Jak logy vyhodnocovat důkladněji, popisuje průvodce Vyhodnocení logů webového serveru. Pokud třetí dotaz ukáže verzi PHP, vyplatí se nastavení expose_php = Off; souvislosti stojí v článku Skrýt údaje o verzi.
Ochranné vrstvy ve správném pořadí
- Aktualizovat PHP a restartovat: Bez tohoto kroku zůstávají všechna ostatní opatření záplatováním děr.
- Zmenšit plochu pro útok: nepoužívané weby, testovací systémy a staré microsite odstavit nebo dát za přihlášení.
- Pravidla na okraji: Web application firewall s udržovanou sadou pravidel, například OWASP Core Rule Set s ModSecurity, zachytí část pokusů.
- Zbrzdit opakované pokusy: Nástroje jako Fail2ban blokují adresy, které vyvolávají nápadně mnoho chyb. Proti distribuovaným skenům to pomáhá jen omezeně.
- Sledovat: Mít na očích procesy uživatele webového serveru, nové soubory PHP a odchozí spojení, aby úspěšný zásah nezůstal týdny nepovšimnut.
Jak konkrétně pomáhá PHP SOS?
- Zmapovat plochu pro útok: Zjišťujeme, které z vašich systémů jsou dostupné zvenčí a co o sobě prozrazují.
- Záplatovat a zpevnit: Aktualizujeme PHP, restartujeme a omezujeme údaje o verzi, oprávnění k zápisu a nepotřebné služby.
- Pravidla a blokace: Zřizujeme pravidla WAF a mechanismy blokace přizpůsobené vaší aplikaci.
- Průběžný dohled: Hlásíme nápadné procesy, soubory a spojení dříve, než se zásah stane incidentem.
Jak to vypadá v trvalém provozu, popisuje Security Monitoring pro webové servery.
Závěr
Automatizované útoky se neptají, komu server patří. Ptají se jen, zda je zranitelný. Nejlepší odpověď je nenápadná: rychle záplatovat, nabízet málo, pozorně sledovat. Kdo to dělá, bude dál skenován, ale už ho nenajdou.
Časté dotazy
Jsou malé firmy cílem automatizovaných útoků?
Ano. Automatizované skeny kontrolují dostupné servery bez ohledu na provozovatele. Zda za nimi stojí koncern, nebo řemeslná firma, pro software nehraje roli. Rozhodující je, zda server působí zranitelně.
Podle čeho poznám skeny ve svých lozích?
Typické jsou mnohé požadavky na cesty, které na vašem webu vůbec neexistují, často z měnících se adres a s nápadnými identifikátory. Takové záznamy jsou normální a samy o sobě nejsou důkazem úspěšného útoku, ale ukazují, že se váš server kontroluje.
Pomůže skrýt verzi PHP?
Skenerům to poněkud ztíží cílené zařazení vašeho serveru a je to smysluplné základní nastavení. Před útoky, které prostě zkoušejí každý server, ale nechrání. Aktualizace zůstává povinná.
Mohu skeny zcela zabránit?
Ne. Každý veřejně dostupný server je pravidelně skenován. Cílem není skenům zabránit, ale zajistit, aby nic nenašly: aktuální software, malá plocha pro útok a dohled, který hlásí nápadnosti.