Útoků hrubou silou ubývá, útočníci jsou čím dál chytřejší, zaznělo na BSS 2026

Daniel Studený: Bezpečnost v roce 2025

CESNET CERTS neřeší jen samotnou počítačovou bezpečnost, ale někdy také fyzickou bezpečnost, která by mohla mít velké dopady. Takto řešili například odjezd zaměstnankyně do zahraničí včetně klíčů, nebo ztrátu důležité přístupové karty. Uživatel si ale nakonec uvědomil, že kartu měl v peněžence, kterou utopil na Ploučnici.

Velkým problémem jsou zastaralé servery, které běží mnoho let bez zásahu a aktualizací. Při napadení pak správci obvykle problém vyřeší obnovou ze zálohy, pokud ji mají. Je lepší takový stroj bez reálného využití vypnout rovnou a nezpůsobit tím další problémy. Stává se, že hypervizor omylem spustí starý virtuální server a ten pak způsobí bezpečnostní incident.

Správci často spoléhají na firewally, které ale mají být druhým stupněm ochrany. Někdy je špatně nastavená autentizace uživatelů a služba je pak dostupná všem, protože chyby testování. Do produkce se také dostávají testovací instance služeb, nebo služby obsahující zbytky citlivých informací po testovacím běhu.

Neustále se řeší nejrůznější útoky, včetně zneužití nakoupených přihlašovacích údajů. Takto bylo zaznamenáno přihlášení na RDP na první pokus, aniž by útočník zkoušel naslepo nějaké varianty. Podobné problémy se objevují také ve chvíli, kdy správce vybalí nové zařízení z igelitu a bez další konfigurace jej zapojí do sítě.

Zdrojem různých útoků bývají moderní multifunkční tiskárny, které umožňují uživatelům v místní síti velmi snadno tisknout. Nepočítá se ale se zapojením do velké sítě, takže řešení není jednoduché, obvykle musíme komunikaci blokovat na páteřních firewallech. Podobné problémy byly zaznamenány s kamerovými systémy, zobrazovací panely nebo zubním skenerem. Ten místo chrupu pacientů skenoval okolní sítě.

Situaci nezlepšuje problematická komunikace s některými správci, kteří buď nereagují vůbec, nebo nepodávají dostatečné informace. Prosím, komunikujte s námi, informujte nás o svých postupech a mějte své abuse kontakty aktivní.

Martin Krajčí: Vektory útoků v roce 2025

Nejčastějším vstupním vektorem byl phishing, který se objevuje v 60 % bezpečnostních incidentů. Nejčastějším motivem byla ideologie a politika. K tomu výrazně přispívají DDoS útoky.

Původem škodlivého phishingového souboru byly v 82 % maily, zbytek tvoří stažení z webu. Na vzestupu je varianta ClickFix a stále častěji také vishing. Útočník se nás pomocí kontaktního formuláře snažil přesvědčit ke změně kódu na webu jedné univerzity.

Objevuje se také zneužití GeoIP, kdy se například uživatelům z České republiky objevuje legitimní web, ale příchozím z ciziny se zobrazila phishingová stránka. Zaznamenáváme také phishing, který se snaží být nenápadný a neobsahuje standardní znaky. Nesnaží se přímo vylákat citlivé údaje, ale donutit uživatele v navázání další komunikace.

Informace o nových zranitelnostech je možné získat ze služby CyberFeed, která v loňském roce odeslala 327 reportů, nejčastěji chyby od CISCO, Fortinet nebo ve webovém serveru Apache. Nejviditelnější byla chyba s názvem React2Shel, která umožňuje vzdálené spouštění příkazů a kódu. Byla velmi rozšířená a masivně zneužívaná.

Tomáš Košňar: Bezpečnost v roce 2025 z perspektivy sítě

Nejviditelnější útoky pocházejí z vnější sítě a mají cíl uvnitř sítě CESNET. Celkem bylo vloni zaznamenáno přes 53 tisíc takových údálostí, u nichž je těžké určit, na který konkrétní cíl míří. Je to útok na celou naši komunitu, kterou chráníme bez ohledu na konkrétní organizace. Obvykle jsou tyto útoky v řádu gigabitů.

Druhou skupinu tvoří cílené útoky na některé služby, což zahrnuje například zesilující útoky pomocí UDP či aplikačně orientované útoky na TCP. Provozovali jsme donedávna otevřený DNS resolver, který byl neustále cílem nejrůznějších útoků.

CESNET hlídá také to, co se děje ve vlastních řadách, podle principu, kdy nechce činit ostatním to, co oni by neměli činit jemu. Za loňský rok šlo o čtyři tisíce událostí, obvykle se aplikuje omezení provozu a probíhá komunikace s připojenou organizací. Když to není nijak významný tok, obvykle to vyřeší bezpečnostní tým dohodou. V běžném provozu se na výstupu ze sítě zahazují desítky či maximálně stovky megabitů za sekundu.

V poslední době ubývá jednoduchých útoků pouhou hrubou silou a přibývá chytřejší zaměření na konkrétní problémy. Ať už to je vyčerpání zdrojů serveru pomocí různých TCP flagů, tak i zneužití webové aplikace a zaměření se na její slabé místo. Je to velmi komplexní problematika a vyžaduje komunikaci a spolupráci na řešení.

Pavel Härtel: Možnosti a cíle měření síťového provozu

VŠCHT má asi 2500 zaměstnanců, šest desítek fyzických serverů, asi 5000 koncových zařízení a několik různých vzdálených lokalit. Infrastruktura je tvořena dvěma datovými centry, které jsou chráněny perimetrovými firewally. V celé síti je zavedeno 802.1×, kde je několik kategorií uživatelů.

Základem monitoringu je Qradar od společnosti IBM, kde se sbíhají logy ze všech služeb a serverů. V rámci infrastruktury je nasazen Flowmon, kde se sbírají všechny datové toky. Data z Flowmonu posíláme do Qradaru, stejně jako z firewallu. Automatika může v případě potřeby spustit zásah přímo na firewallu.

Paradoxní incident zahrnoval počítač, který komunikoval se servery na darknetu. Po blokaci se ozval pan profesor, že tu komunikaci potřebuje, protože na darknetu nakupuje drogy. Ukázalo se, že spolupracuje s protidrogovou centrálou a společně zjišťují, z čeho je možné v současnosti různé drogy připravit.

Na síťové vrstvě se dají podobné problémy detekovat a řešit, ale co když uživatel použije Tor nebo VPN? Tor blokujeme automaticky, stejně jako VPN. K těm se nepřipojíte. Jen v případě, že použití VPN zdůvodníte, může vám být konkrétní spojení s koncentrátorem povoleno.

VŠCHT řeší ve své síti také těžbu kryptoměn, která může mít dopad i v trestněprávní rovině. Podařilo se také zachytit útočícího studenta, který skenoval vnitřní síť a hádal hesla k SSH a RDP. Díky identifikaci pomocí 802.1× bylo dohledání konkrétního studenta snadné. Přiznal se, že se nudil a skončilo to podmínečným vyloučením.

Lukáš Huták: monitorovací infrastruktura v síti CESNET

Základem monitoringu na perimetru sítě jsou sondy IPFIX, které zajišťují sledování provozu bez vzorkování paketů. Data se pak používají pro ladění sítě, automatickou detekci incidentů a další analýzu. Sondy generují stovky tisíc záznamů za sekundu a jsou na linkách od 10 Gbps až po 400 Gbps. Během útoků vyskočí počty záznamů ještě výše.

Vyhovujících sond není na trhu příliš mnoho a jsou velmi drahé, proto si v síti CESNET vyrábějí vlastní řešení. Základem je linuxový server doplněný o FPGA partu pro zpracování provozu a softwarová sonda ipfixprobe. Každá karta se nám chová stejně, což by neplatilo pro karty různých výrobců. Při změně rychlostí linek pak obvykle stačí jen vyměnit kartu.

Data se ukládají v kolektorech, které sbírají data podle různých kategorií a umožňují různou analýzu podle potřeby. Můžeme například ukazovat hezké grafy uživatelům nebo počítat zajímavé statistiky.

Jaroslav Pešek: detekce těžby kryptoměn a DeepSeek

Detekce probíhá na základě celé řady slabých indikátorů: detekce protokolu STRATUM pomocí DPI, analýza TLS SNI a statistiky provozu. Následně probíhá agregace více flow v čase a strojové učení, které dokáže odvodit, jestli jde o těžbu krypta nebo ne. Celé to děláme proto, abychom minimalizovali množství falešně pozitivních hlášení.

V současné době je tato detekce nasazena na IP adresách Metacentra, protože pro větší síť by bylo velmi nákladné takto netriviálně detekci provozovat. Při pozitivní detekci nahlásíme IP adresu, použitý indikátor, porty, časy a tak dále. Několik událostí se podařilo úspěšně odhalit a potvrdit.

Dalším podobným problémem je detekce čínského velkého jazykového modelu DeepSeek, který je zakázáno používat ve veřejné či kritické infrastruktuře. Zákon o kybernetické bezpečnosti nás nutí na tyto věci reagovat. Filtrování probíhá pomocí známých doménových jmen v TLS SNI a regulárních výrazů.

CESNET neprovádí samotnou blokaci, ale vytváří reporty, ve kterých předává informace o detailech komunikace. Dáváme tak organizacím informace k tomu, aby mohly dodržovat zákon. Mají tak přesné údaje o tom, co se v jejich síti odehrává.

Radek Hranický: detekce podvodných doménových jmen

Kybernetickým hrozbám už dlouhou dobu kraluje phishing, jehož detekci komplikuje všeobecné šifrování HTTPS na webu. Často ale máme přístup k doménovým jménům, která můžeme získat z vlastních DNS resolverů, komunikace TLS SNI a dalších zdrojů.

K doménám lze získat řadu dalších informací jako jsou registrační údaje, DNS záznamy, IP adresy, geolokační záznamy, certifikáty nebo obsahy webů. Všechny tyto informace nám mohou pomoci v odhalování různých aktivit jako phishing, provoz botnetových sítí a podobně.

V rámci Ministerstva vnitra a projektu FETA vznikl DomainRadar, který detekuje závadné domény bez nutnosti vidět dovnitř sítě. Není tím tedy dotčeno soukromí jednotlivých uživatelů. Dokáže zpracovat stovky milionů domén za den, čímž se podařilo odhalit různé nezákonné aktivity: falešné banky, malware, podvodné e-shopy a podobně.

Nástroj slouží k podpoře týmů CSIRT a SOC, kterým umožňuje snížit zátěž kladenou na správce. Hlavním cílem je ale ochrana kritické infrastruktury, či jakékoliv jiné sítě. Funguje také dobře v rámci prevence kriminality. Můžeme být schopni odhalit podvodný e-shop ještě před tím, než se podaří někoho okrást.

Nástroj identifikuje používaná doménová jména, sbírá informace z různých zdrojů: DNS, WHOIS, TLS, DOM, geolokace a podobně. Z toho extrahujeme zájmové příznaky, které jsou pro nás zajímavé a hledáme v nich podezřelé vzory a anomálie. Výsledky jsou pak uživateli vizualizovány a reportovány vhodným způsobem.

V lednu byl spuštěn projekt THOR, který řeší konsorcium CESNET a FIT ČVUT a který poběží tři roky. Řešitelský tým má 35 členů a cílem je klasifikace doménových jmen v reálném čase. Budeme zkoumat výskyt domén v čase, periodicitu a anomálie. Budou se tak odhalovat souvislosti domén s různými druhy problémů, podle kterých bude možné se adaptovat na nové hrozby.

Tomáš Košňar, Martin Kylián: DDoS – kdo se v tom má vyznat?

Provozovatel sítě potřebuje udržet funkčnost a zabránit saturaci přenosových kapacit. V druhém plánu chcete odlehčit uživatelům, pomoci infrastruktuře a hraničním prvkům či uzlům. Používá se k tomu kontrola směrovacích informací pomocí RPKI, filtrace podvržených adres v obou směrech pomocí ACL, regulace objemu provozu pomocí QoS, externí čištění, blokace provozu pomocí RTBH a regulace pomocí BGP FlowSpec.

Zásadní prerekvizitou některých typů útoků je možnost podvrhnout zdrojové adresy. Ošetřujeme to tam, kde je to možné a měli by to ošetřovat všichni. U zesilujících útoků je také potřeba mít otevřenou nějakou službu, která takové zneužití k odrazu umožňuje.

Od jaké intenzity je provoz považován za DDoS útok? Například některé skeny portů nebo protokolů mohou být tokem velmi nezajímavé, přesto mohou způsobit v koncové síti nemalé problémy. Máme na to nějakou metriku? Nebo budeme cokoliv neobvyklého považovat za DDoS útok? Obvykle se zabýváme jen výsledkem – tedy tím, zda došlo k nedostupnosti služby.

Provozovatel sítě se obvykle zabývá jen síťovým provozem, což má své limity. Pokud útočník postoupí na aplikační úroveň, už je nutné nasadit jiné postupy. Běžně se objevují útoky na TLS negotiation, které nejsou vůbec vidět v access logu, protože se spojení ani nepodaří sestavit. Na TLS je nejdražší to vyjednávání, samotné šifrování dat je pak už rychlé.

Stále se objevují útoky na HTTP(S) jako Slowloris, Flood nebo Desync. Je těžké se jim bránit, opatrně lze nasadit rate-limiting v kombinaci s otisky pomocí JA4. Je potřeba limity nasazovat s rozumem a ideálně po konkrétních URL.

Pokud jste koncová síť, nespoléhejte se na svého poskytovatele připojení. Když žijete v domě, kde je ochranka, také zamykáte vlastní dveře. Všichni jsme odpovědni za svou síť, protože ji nejlépe známe a umíme ošetřit nejslabší články řetězu.

Radoslav Bodó: Dev(Sec)Ops

Při moderním vývoji je klíčové mít možnost vytvořit vývojové prostředí „na klik“. Pro danou platformu je vhodné si napsat vhodný helper s jednoduchým API, které zvládne základní kroky jako vytvoření nového prostředí, jeho restart, vypnutí a odstranění.

Je potřeba také vše automatizovat a zvládnout při tom více prostředí. Kdo automatizuje, vytváří tím dokumentaci a získá opakovatelnost i testovatelnost. Použít je možné například kombinaci Ansible a Python.

Ansible nenabízí konkrétní připravený způsob správy systémů. Je to jen nástroj, podobně jako kleště nebo kladivo. Každý si musí najít svůj způsob, jak ho použít pro své potřeby. Zásadní je oddělit popis infrastruktury a citlivé údaje, které nechceme sdílet s kolegy.

Důležitá je také automatizace, kdy byste měli směřovat ke stoprocentnímu pokrytí. Pouze to dává smysl v CI pro měření kvality výsledku. Strukturujte své aplikace a propojujte je pomocí definovaných rozhraní. Čistý kód znamená čistou architekturu, což zajišťuje přehlednost a tím i bezpečnost.

Moderní aplikace jsou dnes složené z mnoha technologií, které používají hromadu závislostí a jsou spravovány balíčkovacími systémy. Nainstalovat takovou aplikaci je práce na tři dny a pak zjistíte, že to nedělá to, co jste chtěli. Kontejnerizace umožňuje zabalení komplexních aplikací složených z několika prvků do jednoho celku.

Kontejnery nejsou ideálním řešením pro všechny, ale rozhodně ulehčují život při správě. Měli by se to učit mladí, ale i staří matadoři.

Klára Moravcová: Kubernetes z pohledu bezpečnosti

Kubernetes je orchestrátor pro kontejnery, spouští je a zastavuje, rozhoduje o místě jejich běhu a zajišťuje jejich síťovou dostupnost. Dovoluje přesouvat kontejnery mezi nody a škálovat. Nasazení probíhá pomocí deklarativní konfigurace, která říká, jak má vypadat běžící aplikace.

Kubernetes je z hlediska Linuxu jen sada běžných procesů. Základem je kubelet, což je služba komunikující s API a container runtime. Démon containerd pak spravuje kontejnery přes jmenné prostory a cgroups. Standardními linuxovými příkazy se můžete podívat na jednotlivé služby a ověřit si, že to jsou standardní procesy.

Popis stavu celého clusteru se nachází v databázi etcd, která ukládá data stylem klíč-hodnota a je možné k ní přistupovat pomocí standardních TLS certifikátů. Certifikáty se používají na mnoha místech a jde o klasické X.509. Používá se tu obvyklé PKI s vlastní certifikační autoritou.

Kubernetes byl původně vymyšlen jako platforma pro jednu organizaci nebo uživatele. Ve výchozím stavu spolu mohou všechny kontejnery libovolně komunikovat, mohou vytvářet požadavky na API a využívat neomezeně všechny zdroje. Pokud to chcete dělat jinak, musíte se trochu snažit.

Existují nástroje jako Rancher nebo OpenShift, které dovolují základní oddělení a hodí se pro různé týmy v jedné společnosti. Pro plné oddělení pro nezávislé zákazníky budete potřebovat například clusterAPI, vCluster nebo Kamaji. Můžete pak nastavovat kvóty, zakázat privilegované kontejnery, omezit síťovou komunikaci mezi pody a zapnout RBAC či audit logy.

Řada veřejně dostupných kontejnerů z DockerHubu má zastaralé komponenty, které obsahují zranitelnosti. Mohou obsahovat malware a cryptominery a často používají nebezpečné parametry příkazů. Proto bychom měli stahovat obrazy z ověřených zdrojů a používat tagy pro konkrétní verze. Případně je možné vytvářet vlastní obrazy a provozovat si i úložiště, nejen kvůli bezpečnosti, ale i dostupnosti.

Pro uložení citlivých údajů se standardně používají objekty secret, které ale nejsou šifrované a bez dalšího nastavení jsou v etcd čitelné v otevřené podobě. Je ale možné použít externí správce tajemství jako HashiCorp Vault.

Největším bezpečnostním rizikem zůstávají lidské chyby. Doporučuji automatizovat a zároveň používat nástroje GitOps. V clusteru je možné mít agenta, který sahá na gitovský repozitář jako na jediný zdroj pravdy. Nepotřebujete pak dokumentaci, protože v Gitu jsou všechny kroky popsány. Ruční změny jsou pak jen dočasné a agent je po chvíli vrátí do původního stavu.

Martin Kylián: Mění AI pravidla kyberbezpečnosti?

Firmy začaly v posledních letech ve velkém implementovat chatboty a napojovat na ně interní systémy. Je příjemné, že se někdo může zeptat na komplexní data a dostane je. Tyto systémy ale umožňují únik dat a mají slepá místa v oblasti dodržování procesů a legislativy.

V loňském roce například společnost Lenovo zveřejnila svého chatbota na portále zákaznické podpory. Někdo ho dokázal promptem zmanipilovat tak, že vytvořil cross-site scripting. Každý zaměstnanec, který pak portál navštívil, spustil skript a předal mu svou cookie. Ty se začaly brzy objevovat na darkwebu. Jak takovou věc rychle opravit? Lenovo to vyřešilo odpojením chatbota.

Klíčové je si uvědomit, že lidstvo v LLM vytvořilo systém, který je možný sociálně manipulovat. Dříve jsme mohli jít a přesně ukázat, kde je chyba. Pomocí kreativní konverzace tak bylo například možné získat data společnosti DeepSeek, která se opět objevila na darkwebu.

Podle Gartnera byla třetina projektů GenAI ukončena, zejména kvůli nízké kvalitě dat a nedostatečným kontrolám rizik. Typicky se to řeší tak, že k modelu pustíte jen vlastní uživatele a neotevřete ho ven. Pořád ale nemáte kontrolu nad tím, jaký prompt tam uživatelé vloží. Je to dobré, ale není to řešení.

Nasazení WAF nebo API gateway chrání infrastrukturu, ale nerozumí sémantice promptů. Také je možné dotrénovat vlastní model a přidat filtraci pro bezpečné chování. To je ale velmi nákladné a je nutné při každém problému model přetrénovat. Navíc výsledky penetračních testů jsou platné jen pro danou chvíli.

Jako ochranný prostředek pro LLM se používají takzvané guardrails, což jsou filtry bránící modelu v určitém chování. Je takto možné zkoumat prompty pomocí statických filtrů, nebo je možné vstup předem analyzovat v malém jazykovém modelu. Proti tomu je možné ale nasadit celou řadu různých technik, které používají sociální inženýrství a upravují problematický prompt tak, aby nebyl filtry zachycen.

Cílem těchto snah může být exfiltrace citlivých dat, poškození reputace modelu nebo vyzrazení intelektuálního vlastnictví. Když se dozvíte systémový prompt, obvykle získáte informace o tom, jak daná služba funguje. Takové prompty bývají docela velké a vytvářejí je specialisté na tuto oblast. Pokud je někdo získá, přestane vaši aplikaci potřebovat nebo si vytvoří konkurenci.

Celá tato problematika nijak zásadně nemění pravidla kyberbezpečnosti, jen přináší nový prvek, který je potřeba zvažovat. Je třeba přemýšlet nad tím, kde se objevují nová rizika a jak se jim vyhnout. Například si na personálním oddělení musejí uvědomit, že některý uchazeč o práci může do životopisu napsat skryté instrukce pro LLM, aby byl označen jako nejlepší kandidát.

AI agenti dnes ale začínají zasahovat například do správy serverů a systémů, ale také dokáží dělat ošklivé věci jako automatizace útoků. Dostupné je to pro kohokoliv, kdo si dokáže správné nástroje napojit na dostupný LLM. Běh trvá dlouho, je to nedokonalé, ale je to schopné udělat spoustu věcí. AI mění rychlost, se kterou je možné útočit. Obránci se budou muset přizpůsobit a začít jednat proaktivně a v reálném čase.

Stanislav Špaček: Metodická podpora pro log management v organizaci

Centrální logovací infrastruktura sbírá záznamy o dění v síti a zpracovává je pro různé účely, od prezentace uživateli, až po automatické reakce na různé události. Hodně nám pomohla systematizace infrastruktury, což je protipól živelnému přístupu. Tedy plánování, dokumentace a procesy místo nahodilého logování na mnoha různých místech.

Na logování má vliv také aktuální legislativa, protože je regulováno minimálně dvěma zákony. V budoucnu vám mohou za nesoulad hrozit sankce. Je třeba se tedy zabývat metodikou, procesy a podpůrnými materiály. Je vhodné vše automatizovat, protože vám to ušetří čas a sníží chybovost.

Je třeba se zabývat zaměřením logovací infrastruktury, tedy jaké služby a jaké parametry optimálně logovat. Abychom sbírali všechna potřebná data a zároveň zbytečně neplýtvali prostředky. Musíme tedy vědět, jak je pro nás služba kritická, jaké hrozby přináší a jaké jsou indikátory ohrožení.

Proces je potřeba periodicky opakovat, abychom reagovali na rozvoj služeb a také na vývoj v oblasti bezpečnostních hrozeb. Je potřeba se neustále přizpůsobovat. Připravenou infrastrukturu je potřeba také monitorovat a vše dokumentovat pro správce, ale i pro uživatele.

Ukládání dat ovlivňuje Zákon o kybernetické bezpečnosti, Zákon o elektronických komunikacích a Nařízení o ochraně osobních údajů (GDPR). Technici a právníci obvykle vnímají situaci hodně odlišně. Osvědčilo se nám diskutovat nad konkrétními případy.

V budoucnu je na MUNI v plánu dynamické stanovení retence podle legislativy. Znamená to ale vyřešit problémy s klasifikací na osobní údaje a osobní údaje zvláštní kategorie. Musíme ale nejprve stanovit, jestli takové údaje shromažďujeme a jak je odlišit. Je vůbec možné takovou věc vyřešit automatizovaně a dostatečně rychle?

Dále bude potřeba identifikovat tituly a zvláštní tituly pro zpracování. Proces bude navíc potřeba provádět opakovaně a reagovat na změny legislativy nebo složení služeb organizace. Bylo by možné to nějak automatizovat, třeba pomocí AI?

Systematizace logovací infrastruktury přinese zrychlení provádění operací, nižší chybovost, efektivnější komunikaci, spolehlivější reakce na změny a možnou kontrolu souladu s legislativou.

(Autorem fotografií je Petr Krčmář.)