Nechal jsem AI analyzovat serverové logy. Článek z toho nebude, ranní reporty do Slacku ano

Serverů, o které se starám nebo ke kterým mám přístup, je více. Vybral jsem klasické VPS, na kterém běží Virtualmin hostující pár desítek webových projektů. Je tam mix různých platforem. Počínaje statickým HTML vyrobeným přes různé generátory, přes weby na WordPressu, Symfony aplikace až po stránky na Drupalu.

Image

S pomocí AI (jak jinak…) jsem si v Codexu nachystal skript, který na serveru posbírá logy za minulý den. Vezme v potaz:

• Klasickou linuxovou složku s logy (/var/log), vybírá podstatné soubory plus journalctl, mimo jiné auth, UFW a fail2ban
• Logy webserveru (error.log, access.log, php_log)
• Logy webů, kde to je možné (zatím pro Symfony a Drupal)
• Pokud je u projektu přítomen composer, provede composer audit
• U WordPressu se použije WP-CLI pro kontrolu aktualizací

Výsledek je poskládán do markdown souboru a předán do AI. V tomto případě využívám službu DeepInfra a model Qwen/Qwen3.6-35B-A3B. Jeden report mě stojí přibližně 11 haléřů.

Ke zpracování se neposílá celý obsah přístupových logů, to by bylo nekonečné. Jen metriky a omezené ukázky chyb.

Celé je to jeden skript v Bash, od sesbírání logů přes předání na Qwen pro článek a export odpovědi od AI do dalšího markdownu. V podkladech pro AI model jsem přidal i style guide, který mám vytvořen na základě vlastních článků tu na Maxiorlovi.

První výstupy mi přišly velmi dobré. Jakmile mi opadlo počáteční nadšení, tak jsem si uvědomil, že to takto nemůžu vůbec publikovat. Ani u svých, natož u klientských serverů si nemohu dovolit popisovat, kdo a jak na ně útočí a zda byl úspěšný, případně u kterých webů nejsou dořešeny aktualizace. 

💡Je bezpečné předávat souhrny logů do externího AI? DeepInfra uvádí, že u jejich běžného inference API data drží jen v paměti během požadavku, netrénují na nich modely a standardně neukládají obsah požadavků; vyhrazují si ale možnost malou část požadavků zalogovat pro debugging či bezpečnost.

Ve chvíli, kdy jsem do instrukcí pro AI přidal požadavek na zobecnění, to ale celé přestává mít šťávu. Posuďte sami, nechávám 1:1 včetně pravopisných chyb, kterých se Qwen dopustil:

Ukázka vygenerovaného článku

Dneska jsem se podíval na to, co se dělo na serveru během posledních dvaceti čtyř hodin. Tenhle report není seznamem hrozeb, které musíme okamžitě eliminovat. Je to spíš odraz zrcadla provozu – ukazuje, jak vypadá běžná špína internetu a jak naše nastavení reaguje na pokusy ji projít.

Průzkumné útoky jako každodenní reality

Pokud se podíváte na přístupové logy, narazíte na něco, co připomíná automatický hluk. Mnoho adres zkoušelo přistupovat k souborům, které by neměly být veřejné. Hledali konfiguráky, záložní soubory, skryté složky verzovacích systémů nebo dokonce cesty ven ze webového koše. Tyto pokusy jsou typické pro automatizované skenery, které probíhají celým internetem.

Naštěstí naše pravidla fungují tak, jak mají. Server tyto požadavky odmítal ještě předtím, než se mohly dotknout samotné aplikace. Vidíme tam snahy o čtení citlivých dat přes chybně zakódované cesty nebo pokusy o spuštění skriptů v adresářích, kde žádné nejsou. Je to sice otravné, protože to zaplňuje logy, ale z hlediska bezpečnosti je to dobrá zpráva. Bariera drží.

Zranitelnosti v závislostech

Další část dnešní analýzy se týká toho, co běží pod povrchem. Provedl jsem kontrolu balíčků, které jednotlivé projekty používají. Výsledek? Některé starší verze knihoven obsahují známé chyby. Nejde o to, že by byl server napaden právě teď, ale riziko roste s tím, jak dlouho ty staré verze necháme viset.

V několika případech jsme narazili na komponenty, které byly nedávno označeny za problematické. Jde hlavně o zpracování souborů, správu session nebo komunikaci s externími službami. Tyto chyby mohou umožnit útočníkovi získat nepřiměřený vliv na chování aplikace, pokud by se mu podařilo najít způsob, jak chybu vyvolat. Aktualizace těchto součástí není jen technická povinnost, je to základní hygiena.

Stav redakčních systémů

Mimo klasických PHP aplikací běží na serveru i několik redakčních systémů. U nich situace vypadá trochu jinak. Jeden z nich běží na nejnovější stabilní verzi, což je skvělé. Jiné systémy však vykazují známky nestability ve svých doplňcích.

V jednom případě se objevují varování ohledně špatně napsaného kódu v pluginu, který pracuje s neexistujícími daty. To samo o sobě nemusí být kritická chyba, ale signalizuje to, že kód není udržován kvalitně. V jiném případě jde o konfigurační nesrovnalosti, kdy systém očekává určitou strukturu dat, která tam není. Takové věci často vedou k pádům stránky nebo k tomu, že se uživatelům zobrazují matoucí chybové hlášky.

Přehled priorit

Abychom měli jasno v tom, co řešit jako první, shrnul jsem zjištěné body do jednoduchého přehledu. Tříídil jsem je podle toho, jak moc ovlivňují stabilitu a potenciální riziko.

Osobní pohled na monitoring

Když to všechno shrnu, mám pocit, že většina paniky kolem IT bezpečnosti je zbytečná. Většina „útoků“, které denně vidím, jsou jen roboti, kteří slepě klikají na odkazy. Naše hlavní práce není bojovat s těmito stíny, ale udržovat pořádek ve vlastním domě.

Nejdůležitější lekce tohoto dne je ta, že pasivní obrana (blokování přístupů) funguje skvěle, dokud máme aktivní péči (aktualizace a údržbu). Pokud bychom opustili tu druhou, ta první by časem selhala. Proto se držím principu, že lepší je věnovat čas opravě jednoho špatně napsaného řádku kódu dnes, než hádat, proč někdo v budoucnu unikl skrz starou knihovnu. Klid a čistota v kódu jsou nejlepší prevencí.

Poznámka redakce: Tento článek je automaticky generovaným návrhem založeným na technických datech. Před případným zveřejněním doporučujeme provést lidskou kontrolu kontextu a aktuálnosti informací.

A teď zpátky k praktické využitelnosti

Automatická publikace deníčku ze života serveru se sice jeví na první pohled jako fajn nápad, v reálu ale nebudete chtít jít s kůží na trh. Musel bych hodně ladit, co je a není možné zveřejnit, a hlavně bych chtěl mít stoprocentní kontrolu před zveřejněním. To pak ale nedává smysl.

Jak jsem nad tím vším přemýšlel, napadla mě jiná cesta. Vyrobit si takový report pro sebe. Ani ten nejzarputilejší linuxový admin určitě nechce půl dne pročítat logy. Ale mít rychlý přehled o tom, co se děje, není k zahození.

Upravil jsem tedy shell skript tak, aby nebylo nutné nic anonymizovat, z výstupů se nevytvářel článek s příběhem, ale poslaly se mi jen stručné a zásadní informace každé ráno k snídani. A výsledek? Je to něco se skvělým poměrem cena/výkon, to si určitě ponechám v provozu.

Ukázka automatizovaného výstupu do Slacku

Ranní přehled — 2026-08-14

🔴 Hned řešit
1. web_A: Drupal jádro obsahuje kritické zranitelnosti (SA-CORE-2025-001 XSS, SA-CORE-2025-002 Access bypass). Vyžaduje okamžitou aktualizaci.
2. web_B: Symfony komponenty mají vysoká rizika (CVE-2026-45075 HEAD bypass, CVE-2026-48489 Firewall bypass). Nutná patche.
3. web_C: PHPSpreadsheet má kritické chyby pro DoS a SSRF (CVE-2026-59931). Aktualizovat balíček.

🟠 Naplánovat
1. web_D: 112 advisory, včetně kritického Drupal SA-CORE-2023-006 a dompdf file read. Plánovat upgrade.
2. web_E: Drupal kritická PHP object injection (SA-CORE-2026-005). Prioritní patch.
3. web_F: Drupal kritická SQL Injection v Geolocation pluginu (SA-CONTRIB-2026-062). Opravit plugin.
4. web_G: league/commonmark DoS zranitelnosti. Aktualizovat závislosti.
5. web_H: Plugin short-codepress hlásí PHP warningy a chyby null pointer. Otestovat kompatibilitu nebo deaktivovat.

🟢 Provoz
Server nazev_serveru běží stabilně, systémové logy (syslog, auth, ufw) jsou prázdné, což potvrzuje absenci systémových incidentů nebo firewallových blokování mimo běžný provoz. Webtrafik je normální, ale pozor na vysoký podíl 4xx chyb u projektů web_I, web_J a web_K. Tyto chyby odpovídají běžnému automatizovanému skenování bezpečnostních hrozeb (cesty k .env, server-status, xmlrpc.php), nikoliv aktivnímu útoku nebo selhání aplikace. Firewall úspěšně blokuje přístup k citlivým souborům.
U web_G se opakovaně spouští cron během běhu předchozího cyklu; zvažte úpravu intervalu nebo uzamčení.

💡Doporučená první akce
Zahájit plánovanou údržbu a aktualizaci Drupal jádra a kritických modulů na projektech web_A, web_E a web_F kvůli přítomnosti vysoce kritických zranitelností umožňujících RCE/SQLi.

Možná lepší než dashboard

Názvy webů a serveru jsem pro účely tohoto článku anonymizoval. Taková jednoduchá zpráva do Slacku, navíc doplněná o ikonky, mi přijde lepší než jeden nebo více dashboardů s grafiky a čísly, ze kterých jde jednomu hlava kolem.

Není to samozřejmě úplně ideální, všimněte si, že v doporučení mixuje věci ze sekce Hned řešit a Naplánovat. Stejně tak, pokud jsou některé logy prázdné, neznamená to klid v duši, ale spíše bych k tomu přistoupil tak, že se všechno nezachytilo. I když v daném případě externí firewall dělá hodně.

Ale jako rychlá zpráva, která mi přijde na Slack, abych věděl, kde případně zakročit, je to prima.