Radoslav Bodó, Jakub Urbanec: (Ne)bezpečnost 2024
Už před dvěma lety se objevily problémy s polskými vlaky, do kterých výrobce Newag přidal do kódu podmínku, která na správných souřadnicích vlak odstavila. Šlo o polohu servisního střediska, které nepatřilo výrobci, ale konkurenční společnosti. Polské dráhy kontaktovaly hackery, kteří tohle všechno odhalili.
Výrobce reagoval žalobami na ochranu autorských práv a porušení osobních práv, přičemž cílem žalob je hackerská skupina Dragon Sector. Newag byl naopak žalován řadou polských organizací. Tohle celé stojí spoustu peněz, lidé z Dragon Sector o tom mají spoustu přednášek a shánějí příspěvky na soudní výlohy.
Občas se k nám v rámci nějakého případu dostane nahrávka, u které potřebujeme zjistit, kdy byla přesně pořízena. Zjistilo se, že je to možné udělat pomocí frekvence elektrické sítě, která kolísá okolo 50 Hz. V Británii mají databázi, do které průběžně ukládají aktuální frekvenci sítě. V nahrávce pak můžete vyfiltrovat 50 Hz a podle sledování posunu je možné zjistit, kdy přesně na sekundu byla nahrávka vytvořena.
Před lety prozradily chytré hodinky a aplikace informace o tom, kde jejich uživatelé sportují. Prozradily se tak pozice jednotek v Afganistanu a v Nigeru. Nemusíte být zrovna Rambo, prodávají se například informace o ženské periodě.
Představte si ale, že někdo tato data spojí s tím, že žena měla vyšší karetní transakci ve státě, kde je legální potrat. V některých zemích je to ilegální a mluví se o změnách v legislativě, kdy to bude považováno za vraždu.
Během roku 2024 se rozšířil seznam ruských firem, jejichž software se nesmí používat ve Spojených státech. Firma Kaspersky to vzala zhurta a svůj software smazala ze všech počítačů ze Států a jinde na světě.
Dovolila si dokonce ho vyměnit za jiný antivirus. Vůbec si neumím představit, co by se mohlo stát, kdyby se takhle utrhl Microsoft.
V červenci se stala známou společnost CrowdStrike, která zveřejnila aktualizaci a tím rozbila 8,5 milionů počítačů po celém světě. Nejhorší bylo, že problém nebylo možné napravit na dálku a správce musel ke každému počítači přijít a fyzicky do něj zasáhnout.
Starlink má dnes na oběžné dráze ve výšce 550 kilometrů zhruba 7000 družic pro širokopásmové připojení k internetu. Celkem je kolem Země asi 30 tisíc registrovaných družic, takže asi třetina patří SpaceX.
Co všechno se s takovou sítí družic dá dělat?
Také v loňském roce byly objeveny nové zranitelnosti procesorů různých architektur, kterým se říká GhostRace. V roce 2024 se útočilo pomocí mutexu, který funguje jako softwarový štafetový kolík a umožňuje bezpečné střídání komunikujících procesů.
Pomocí spekulativního vykonávání je možné vytvořit pozorovatelný stav v CPU, ze kterého se dá odvodit hodnota, která útočníkovi nepatří. Zatím je útok k dispozici pro Linux, ale chyby je obecnější a týká se různých systémů i platforem.
Jednou z ochran před podobnými chybami je takzvaný Costant time programming, kdy všechny smyčky trvají stejný čas, vyhýbáme se předvídatelným smyčkám a nemícháme data s adresami. Tím se můžeme vyhnout všem spekulativním útokům.
Je však možné zneužít DMP (Data Memory-dependent Prefetchers), které se snaží dopředu načítat data a pokud jde o adresu v paměti, načíst data i z ní. Je pak možné vytvořit kód, který v případě uhádnutí části klíče z nedostupné paměti načte něco jako adresu a tím spustí načtení určitých dat z paměti.
Pak je možné změřit čas a zjistit, jestli jsou data načtená a máme kus klíče třeba z cizího virtuálního stroje.
Tématem současnosti je AI, který je všude okolo nás. Velké jazykové modely dříve pracovaly s posbíranými historickými daty, čím dál více se ale posouváme k současnosti. Z logu na webových serverech mi přijde, že crawler OpenAI je jen další Googlebot, který prochází web a stahuje úplně všechno.
Na to začínají reagovat copywriteři, kteří prodávají informace o tom, jak psát webové stránky pro současné modely. Zvýšíte tím šanci, že se informace o vás objeví ve výsledcích komunikace s AI.
V loňském roce se také objevila křehkost mnoha systémů, které jsou založeny na malých otevřených projektech. V knihovně xz byla objevena zranitelnost, konkrétně v jeho sestavovacích skriptech, které používají testovací data k vytvoření backdooru. Jde o nepřímý backdoor, který se projeví jen při splnění konkrétních podmínek.
Konkrétně vytváří vlastní funkci RSA_public_decrypt, která obchází autentizační proces. Nakonec byla chyba objevena díky náhodě, protože jednomu z vývojářů se nelíbila 25milisekundová prodleva při přihlašování.
V tiskovém subsystému CUPS byla nalezena chyba, která jedním UDP paketem dovolila do systému přidat vlastní tiskárnu a nakonfigurovat ji. V některých případech bylo možné dokonce spustit tisk a tím spustit v systému vlastní kód.
Martin Kylián: DDoS: techniky a taktiky
DDoS útoky mohou mít celou řadu cílů: linky pro připojení k internetu, síťová infrastruktura, DNS servery a útoky na samotné aplikační služby. Když útočníci zaplní trubky, nejste dostupní, ale to se naštěstí neděje příliš často. Pokud vyřadí infrastrukturu, také nejste dostupní a když někdo zaútočí na služby, přestanou servery odpovídat.
Nejčastěji se útočníci zaměřují na HTTP služby.
Společným cílem je vždy vyčerpat zdroje, ať už to jsou tabulky spojení, limity propustnosti nebo množství paměti či výkon procesoru. Útočník chce internetové linky saturovat a všechno ostatní vyčerpat z hlediska zdrojů.
Cílem je dělat DDoS útoky co nejlevněji a nejjednodušeji. Útočníci si osvojili sadu metod, které obvykle fungují. Základní vektory je proto dobré znát.
Typicky útočníci kombinují několik různých vektorů útoků. Důležitá je rychlost reakce a její účinnost. Útočníci obvykle spustí palbu ze všech hlavní najednou a během několika minut vaše infrastruktura nefunguje. Než zjistíte, co se děje a nasadíte ochranu, je po všem.
Když navíc z terabitového útoku odstraníte jen 95 %, zbytek pořád stačí na složení většiny běžných infrastruktur.
Na jednoduché útoky na ucpání linek není jednoduchá ochrana, existují ale pokročilé pračky provozu, které je možné v případě útoku nasadit. Pračka v běžném provozu nic nedělá a až jí řeknete, začne pracovat. Je ale důležité reagovat dostatečně rychle, jakmile je to více než deset minut, může být po všem.
Ochrana internetových linek se bez schopného partnera nedá dělat.
Velmi běžným útokem je SYN Flood, který se opírá o to, že požadavek na vytvoření TCP spojení alokuje na cílovém systému část paměti. Když budu útočník, podvrhnu zdrojovou IP adresu, ze které požadavek SYN pochází.
Útočník se může ke spojení chovat, jako by šlo o UDP. Záleží na tom, jestli zdrojová síť umožňuje podvrhnout libovolnou zdrojovou IP. Existuje stále ještě řada sítí, ze kterých můžete zdrojové IP adresy podvrhnout. Útočníci si vybírají právě takové sítě.
Počet naalokovatelných TCP socketů je v Linuxu konfigurovatelný, ve výchozím nastavení to bývá 1024 socketů v polootevřeném stavu. Pokud přijde SYN Flood, je pravděpodobné, že útočník vám vyčerpá všechny sockety, ať jich máte nastavených třeba deset tisíc.
Pak nastoupí mechanismus SYN cookie, kdy se do odpovědi SYN/ACK zakódovávají všechny informace potřebné k sestavení spojení.
Pro SYN cookies je ale potřeba počítat hašovací funkce, za což ale zaplatíme výkonem. Klesne nám tím tedy propustnost síťového prvku, která je definovaná celou řadou parametrů.
Existuje pak celá řada různých technologií, které dovolují celou věc akcelerovat a výkon zase trochu zlepšit.
Relativní novinkou je útok DNS Bomb, kdy si útočník nahromadí dotazy na rekurzivním serveru, třeba pomocí fragmentů, které najednou ukončí. Rekurzivní server pak najednou vychrlí hromadu dotazů na autoritativní servery, které má útočník pod kontrolou. Útočník se pak snaží odpovědi pozdržet co nejdelší dobu a pak na ně najednou odpoví.
Dotazy ale mají falešné zdrojové IP adresy a rekurzor pak najednou odpoví směrem na obeť. Amplifikační faktor je tu obrovský, řádově v tisících. Tvůrci rekurzivních serverů reagovali snížením počtu rozjednaných dotazů od jedné oběti.
To ovšem jen zmírnilo dopady, stále jde o velmi úspěšný útok.
Dalším rozšířeným útokem ne DNS Water Torture, kdy útočník generuje velké množství dotazů na náhodně vygenerované subdomény. Tyto dotazy nejsou v keši, takže rekurzor se musí neustále ptát autoritativních serverů.
Autoritativní servery jsou pak zahlceny dotazy od legitimních služeb, které není možné zablokovat, protože je využívají i běžní uživatelé. DNSSEC by měl pomoci s ochranou, ale mnoho implementací je špatných a zhoršují situaci tím, že zvyšují zátěž rekurzoru.
Těžiště útoků v DDoS se přesouvá na sedmou vrstvu, tedy na aplikační vrstvu. Velmi starým, ale stále funkčním, útokem je HTTP Slowloris. Ten vytváří nekompletní HTTP dotazy a nikdy je neukončí, čímž server neustále zdržuje. Těsně před vypršením timeoutu pošle vždy další hlavičku a tím odčerpává volné sockety na HTTP serveru.
Hlavičky přitom vůbec nemusejí dávat smysl, podstatné je, že se posílají a server na ně musí čekat. Jedním notebookem na domácí přípojce dokážete vyčerpat zdroje webového serveru. Je to vyzkoušené, funguje to.
Klíčovou ochranou je nastavit správně timeouty.
Útočníci se obvykle zaměřují na takzvané heavy URL, které vytvářejí zátěž na aplikaci, nejlépe přímo na databázi. Takovému útoku se říká HTTP/S Flood a je velmi těžké podobné dotazy blokovat, protože obvykle vypadají úplně normálně. Tvůrci ochran obvykle sledují počty požadavků, množství vrácených chyb, zpoždění a propustnost odpovědi. Pokud tyto hodnoty rostou, je to známka toho, že se něco děje.
Do vyhodnocení dnes často zasahuje AI, která zná běžný provoz a umí najít abnormality.
Útočníci se snaží využívat všeho, co je k dispozici. V loňském roce začaly být například zneužívány domácí routery TP-Link, které trpí zranitelností CVE-2023–1389 a umožňují vzdálené spuštění kódu. Bohužel tuhle chybu v mnoha zařízeních už nikdo nikdy neopraví.
Vláda Spojených států uvažuje, že prodej zařízení tohoto výrobce zakáže.
DDoS útoky jsou různě velké a různě četné, je možné je přirovnat k záplavám. Ve většině případů jde o dvacetiletou vodu a vy si vůbec nevšimnete, že se něco stalo. Ráno uvidíte na grafu nějakou špičku, ale vaše infrastruktura to absorbovala.
Přibývá ale středně velkých útoků, které mohou připomínat padesátiletou vodu a je dobré vědět, kam se podívat pro další informace.
Jednou za čas ale přijde stoletá voda, se kterou už si ale sami neporadíme. Je potřeba mít k dispozici vhodného partnera, který vám s tím pomůže.
Je dobré si předem otestovat svou infrastrukturu, abychom věděli, jak na tom jsme. Stačí k tomu spustit sadu virtuálních serverů třeba v AWS a generovat si simulovaný útočný provoz. Můžeme to dělat všichni a stojí to doslova pár dolarů.
Lukáš Macura: Jak na centrální logmanagement
Každý správce zodpovídá za aktuálnost logů, formát a transport záznamů. Na manažerovi pak je, aby zajistil, že logují opravdu všechna zařízení.
Zákon o kybernetické bezpečnosti to říká zcela jasně: bez centrálního logování ani krok.
Logovat bychom měli opravdu všechno, jen je potřeba pohlídat aplikační data. Log by neměl obsahovat citlivá data jako uživatelská jména a hesla.
Je velmi těžké vyvážit množství informací, které potřebujeme a zároveň neporušovat GDPR. Na jedné straně musíme data uchovávat a zároveň musíme citlivé informace mazat.
CESNET má dvě geograficky oddělené lokace pro logy: Brno a Prahu. Pro klienta je to transparentní, je to redundantní anycast.
Vše je propojeno s autentizačním systémem a asset managementem. Aby systém věděl, které servery mají logovat a jak se mají třídit.
Vše pak končí v Greylogu.
V současné době do centrálního logu zprávy posílá přibližně 1300 strojů, průměrně se generuje 1800 zpráv za sekundu. Na disku to zabere 80 GB za den, přičemž asi 50 GB denně se ušetří standardní kompresí starších záznamů.
Ve Windows se používá NXLog, který posílá data zároveň na Syslog-ng servery a také rovnou do Graylogu. Generuje to JSON, umíte si představit, jak dobře se to analyzuje pomocí grepu.
Mnohem lépe si s daty poradí Greylog.
V Linuxu je situace jednodušší, tam je možné použít syslog-ng nebo rsyslog, odkud se události posílají na Syslog-ng servery a odtud putují do dalších služeb. Syslog-ng neumí na výstupu load balancing, TCP stream také už není možné jednoduše balancovat.
Je ale možné využít unikátní číslo logu a pomocí modula přerozdělovat logy mezi nody Graylogu.
Z Windows přicházejí data ve formátu GELF (Graylog Extended Log Format), což je JSON posílaný přes TCP. V Linuxu se používá Syslog dle RFC 5424 nebo méně striktní RFC 3164. Podporujeme oba protokoly, ale zásadní je nemíchat je mezi sebou. Máme pro ně vyhrazené různé porty.
Logy by měly být posílání přes TCP a ideálně přes TLS. Musíme mít jistotu, že log dorazil do svého cíle. Musíte mít taky lokální buffer, který data podrží, když je server nedostupný nebo je linka dole.
Primární důvěra je v IP adresu zdroje logu, sekundární důvěra pak v Common Name v certifikátu. Doporučuje se používat FQDN stroje, aby byly názvy unikátní a lépe se nám v nich orientovalo.
Pro monitoring logování je možné používat Zabbix, do kterého je možné odebírat informace o počtu logů až na úroveň jednotlivých agentů. Důležité je také označení zdroje, pokud přestane posílat logy.
Logy se pak komprimují pomocí zstd, který byl vybrán pro rychlost dekomprese. Ta je velmi důležitá, nechcete při analýze trávit spoustu času čekáním na to, až se věci dekomprimují.
Milan Čermák: systém pro detekce a korelace kyberbezpečnostních událostí
Původní univerzální centrální systém v otevřené akademické síti příliš nefungoval, protože kdokoliv si může uvnitř spouštět libovolné služby a bezpečnostní systém pak vytvářel spoustu falešně pozitivních bezpečnostních hlášení. Proto jsme postupně sběr dat vypínali, až jsme byli spokojení.
Aktivním sledováním telegramových skupin se ale ukázalo, že v síti je spousta infostealerů, hesla kolují po internetu a správci o tom nemají tušení.
Byly tedy definovány požadavky na nový systém, který musí mít možnost korelace detekovaných událostí, bude moci dávkově zpracovávat IP toky a logy a mít propojení s CTI a asset managementem. K dispozici bylo několik hotových řešení: AlienVault OSSIM, OpenSearch, DSIEM a Wazuch. Komerční nástroje jsme z finančních důvodů vůbec neuvažovali.
Velká naděje byla vkládána do OpenSearch, který podle dokumentace splňuje všechny požadavky. OpenSearch už používáme pro analýzu logů a není tak třeba nasazovat a provozovat nový systém.
Ukázalo se ale, že korelační pravidla je možné definovat pouze pro předem známé hodnoty a nikoliv pro obecně daný klíč – například stejné zdrojové IP adresy.
Další variantou byl Wazuch, což je systém s obrovským množstvím funkcí, který je primárně zaměřený na sběr dat ze systémů. Má možnost definovat si vlastní pravidla a korelace sbíraných logů založených na nástroji HID OSSEC. Hlavní komponentou je Wazuh Manager, který zajišťuje vyhodnocení příchozích událostí a zpřístupňuje je v dalších komponentách.
Komplexní datový platforma Wazuchu umožňuje rychle analyzovat sbíraná data, díky čemuž je možné efektivně napojit více detekčních skriptů. Detekce spravujeme v GitLabu, programujeme v Pythonu a používáme schéma IDMEFv2.
GitLab má Ci/CD pipeline usnadňující nasazení nových skriptů v Kubernetes skrze ArgoCD.
Ze všech těchto komponent je vytvořen základ, který je spojen v jednom detekčním systému nazvaném CRATOS. Záhy se ale objevily limity navrženého řešení: Temporal špatně pracuje se skripty používajícími blokující funkce, Wazuh nezohledňuje pořadí událostí a neumožňuje korelovat události s více zdrojovými či cílovými IP adresami a vygenerované výstrahy obsahují informace pouze o jedné korelované události. Vše je potřeba přepsat do asynchronních funkcí a je třeba napsat pravidla duálně pro obě korelované události.
Výhodou systému je, že rychlé zpracování dotazů v datové platformě umožňuje vytvořit velké množství detekčních skriptů, detekce mohou kombinovat data ze sítě, systému i služeb, Python dovoluje propojit data z různých systémů a API umožňuje přeposlat systémy do dalších nástrojů. Detekované události mají také definovanou míru důvěry, kterou je možné zohlednit v rámci korelačních pravidel a reakcí na incidenty.
Pavel Valach: Jak si postavit honeypot
Honeypot simuluje důležitý síťový zdroj a ukládá informace o tom, jak se při práci s ním útočník choval. K dispozici je pak celá řada informací jako čas detekce, IP adresy, používané příkazy, stahované soubory a podobně. Dat je z toho opravdu hodně a je možné je různě korelovat.
Informace pak mohou přecházet do SIEM systému Mentat, URL Evaluatoru nebo IP reputační databáze. Adresa, která útočí na celý internet, asi nebude příliš zdravá.
Jako honeypot může soužit řada různých síťových prvků, na firewallu můžeme vyhradit například nepoužívaný rozsah a spustit na něm černou díru v podobě nástroje LaBrea. Kromě toho je možné spustit také simulátor služeb jako Cowrie, Dionaea nebo Conpot. Mnohem méně se používají reálné zranitelné systémy, což je složité správně připravit, ale útočník pak pracuje se skutečným systémem a nemusí to dlouho zpozorovat.
Simulátory služeb se liší ve věrnosti simulace a toho, co přesně se snaží napodobovat. Můžete mít spoustu malých simulátorů nebo můžete útočníka zatáhnout do komplexního systému.
Samostatnou kapitolou jsou generativní honeypoty, kdy moderní jazykové modely (LLM) mohou emulovat docela věrně i funkční shell. Je možné ho ale vhodným promptem odhalit.
Existuje celá řada generativních honeypotů jako je Beelzebub simulující shell v Ubuntu, Galah simulující různé webové aplikace nebo VelLMes-AI-Honeypot simulující celou řadů různých služeb. Hodně se to vyvíjí a doporučuji tuhle oblast pozorně sledovat.
Při vývoji vlastního honeypotu je potřeba nejprve vybrat podkladový systém. Je možné použít minimalistický systém jako Alpine Linux, opakovatelný systém jako NixOS nebo tradiční distribuci jako Debian či Ubuntu. Používejte to, co už znáte. Pokud nastane nějaký problém, budete si moci něco opravit sami.
Výhodou jsou i automatické aktualizace a možnost snadného rozšíření.
Instalaci je možné provést z ISO obrazu, nebo je možné využít nějaké cloudové obrazy. My instalujeme Debian do VirtualBoxu pomocí automatické instalace.
Základ je pak možné libovolně upravovat, přidávat moduly nebo třeba konfigurovat místní firewall. Celý proces je řízený GitLab CI, používáme Puppet a shellové skripty.
Poté je třeba zvážit, jak omezit komunikaci honeypotu s okolní sítí. Doporučuji otevírat jen potřebné porty a omezit odchozí provoz do internetu.
Cowrie má ochranu v kódu a nepustí útočníka do privátní sítě, ale přesto je doporučováno ji zablokovat i na firewallu.
Je potřeba také vyřešit, jak se k honeypotu připojit pomocí skutečného SSH a spravovat jej. Buď je možné používat pro správcovské SSH jiný port než standardní 22, nebo je možné v obou případech používat pro připojení výchozí port a ve firewallu vyjmenovat zdrojové IP adresy, ze kterých se správce připojí ke skutečnému SSH. Útočník se pak z jiných adres připojí na honeypot.
Cowrie má spoustu možností úprav, které je možné konfigurovat. Je možné například přizpůsobit hlavičku zobrazovanou útočníkovi, algoritmy používaných klíčů, různé způsoby přihlášení a podobně. Přístupové údaje je možné konfigurovat v /etc/userdb.txt. Je možné tam dát skutečná uživatelská jména z vaší organizace a hlídat, zda se na ně někdo úspěšně nepřihlašuje.
Také lze přizpůsobit celý souborový systém a nahradit jej vlastní distribucí.
Honeypot je potřeba poctivě hlídat, útočník vám v něm může například zaplnit disk nebo vyčerpat jiné zdroje. Útočníci se snaží někdy honeypot zneužít pro další útoky, což je nutné omezovat na firewallu. Je třeba dát také pozor na zranitelnosti honeypotu a průběžně aktualizovat.
Martin Šebela: Phishingator
Phishing je stále aktuální téma, i když by mohla mít řada uživatelů pocit, že ho bez problémů poznají. Útočníci zdokonalují své pokusy o phishing a využívají další metody.
Čím dál častěji se tedy objevuje quishing, smishing a cílení na uživatele kryptoměn.
Útočníci využívají i vizuálů různých známých značek či osobností a lákají na výhodné investice. Začali ve velkém používat i AI, což jim umožňuje generovat obsah e-mailů či lokalizaci do různých jazyků.
Podvodné stránky jsou často hostovány na legitimních místech, kde by to málokdo čekal.
K odesílání phishingu se mohou používat důvěryhodné identity získané od skutečných uživatelů. Útočníci získají například přístup do VPN konkrétní univerzity a z místní sítě začnou odesílat phishingové e-maily, aby získali další identity na jiných univerzitách.
Podvodné stránky jsou často vytvořeny na běžných důvěryhodných webech jako Weebly, Wix nebo Web.app. Další možností jsou hacknuté redakční systémy jako WordPress.
Zneužívány jsou i známé legitimní služby jako zkracovače URL, GitHub Pages, Microsoft Sway nebo Google Ads.
Zajímavá metoda je útok typu Browser-in-the-Browser, která umožňuje uvnitř phisingové stránky simulovat další okno webového prohlížeče s přihlášením do známé služby. Vy se pak věnujete falešnému přihlašovacímu oknu, které má ale pod kontrolou útočník a na první pohled vypadá legitimně.
CESNET poskytuje službu Phishingator, což je webová aplikace pro rozesílání cvičných phishingových zpráv. Poskytujeme jej formou Software-as-a-Service a stále jej vylepšujeme na základě zpětné vazby od našich uživatelů.
Cílem je především vzdělávání uživatelů u různých organizací.
Průměrně mají společnosti založeno devět phishingových kampaní a celkem bylo proškoleno asi 25 000 uživatelů. Úspěšnost získání platného hesla se pohybuje okolo 10 %.
U propracovanějších cvičných phishingů může být ale úspěšnost 20 až 30 %.
Phishingové útoky jsou stále propracovanější a i ty nejjednodušší si najdou své oběti. Útočníci nabízejí phishing jako službu a snaží se zneužívat legitimní služby.
Čím dál častěji také využívají AI a mohou vytvářet různé varianty podvodných e-mailů.
Dominik Marek: Zvyšování odolnosti proti phishingu
Kraj Vysočina nabízí svým příspěvkovým organizacím strategickou pomoc na úrovni zavádění procesních opatření, metodickou pomoc s bezpečností, ICT služby a školení. Celkem jde o 94 organizací, které často zpracovávají citlivé osobní údaje.
Na počátku nasazení Phishingátoru bylo politické zadání od jednoho z radních na otestování všech ekonomických zaměstnanců příspěvkových organizací. Pomohl nám incident, kdy jedna ze škol zaplatila falešnou fakturu a přišla o tři čtvrtě milionu korun.
Nakonec bylo rozhodnuto školit všechny uživatele.
Zájem o prezenční školení byl nakonec velký, protože příspěvkové organizace nejsou schopny z vlastních zdrojů řešit komplexní bezpečnostní otázky. Vytvořili jsme e-learningové školení a nabídli jsme možnost uživatele dále trénovat.
Cílem bylo seznámit uživatele s praktikami útočníků, představit technické možnosti, poukázat na důležitost detekce probíhající kampaně a na potřebu dalšího vzdělávání. Konečně nám to celé začalo dávat smysl, takže jsme implementovali Phishingator.
Zaměstnanci s krajskými identitami se školení účastnili povinně, celkem bylo takto proškoleno 1500 uživatelů. Poté byl projekt rozšířen na nemocnice a ZZS a později také na další příspěvkové organizace. Zájem projevila většina, celkem mají všechny příspěvkové organizace dohromady 8000 zaměstnanců.
Celkem se zapojilo 91 organizací, z nichž se zatím proškolilo 2500 uživatelů. Kampaně jsme opřeli o podvodný web, který vypadá jako web Kraje Vysočina.
Uživatelé se tedy autentizovali proti krajskému IdP. Celkem útok nahlásilo šest uživatelů, což je velmi málo. O podobných útocích se my jako bezpečáci musíme dozvídat, abychom na ně mohli reagovat.
Přibližně čtvrtina uživatelů na phishing zareagovala, necelá desetina pak zadala přihlašovací údaje. Obvykle to byly platné údaje, někteří uživatelé to zkoušeli vícekrát a viděli jsme například překlepy v heslech.
Získat neautorizovaný přístup do organizace je překvapivě jednoduché, nakonec je jedno, kolik procent uživatelů se stane obětí. Důležitá je včasná reakce na to, co se stalo.
Uživatel by se neměl bát přiznat, aby bylo možné minimalizovat dopady.
Martin Krajčí: Služba Situational awareness (rok poté)
Situational awareness je služba, ve které se z různých zdrojů scházejí informace o aktuálních zranitelností produktů, které by se mohly nacházet v síti CESNET. Informace jsou k dispozici na webu, pomocí e-mailu nebo v RSS kanále. Jsou to krátké reporty, ze kterých je patrné, jak moc je zranitelnost závažná.
Kromě toho jsou k dispozici konkrétní CVE, krátká popis, případně informace o možnosti ochrany proti dané chybě. Cílem služby je zvýšit úroveň bezpečnosti v síti a ulehčit práci správcům a bezpečnostním specialistům.
Nenahrazuje sledování zranitelností, protože v některé síti mohou být prvky, o kterých správci služby nemají tušení.
V plánu je umožnění odebrání informací o jednotlivých produktech, možné změny ve formátování a spolupráce s dalšími organizacemi. Služba je dostupná na va2am.cesnet.cz.
Jiří Menšík: Zkušenosti s provozem otevřeného DNS resolveru
Dříve bylo běžné, že každá větší organizace provozovala otevřený resolver pro kohokoliv, kdo přišel z internetu. CESNET provozuje rekurzivní server už desítky let.
Zatímco autoritativní server musí být vždy otevřený a dostupný, rekurzivní server obvykle otevřený do světa není. Výjimky samozřejmě existují a takové servery provozuje například CZ.NIC, Google nebo Cloudflare.
Veřejný rekurzor ale může být zneužit pro zesilující DDoS útoky, skenování a enumeraci domén a zneužití pomocí otrávení keše. Rekurzor může být zneužit pro útoky na autoritativní servery pomocí náhodně generované domény.
Rekurzory sítě CESNET denně odpovídají na 100 až 150 milionů dotazů, z nichž podstatná část není legitimní. Naše servery to zvládají, ale zatěžují svými dotazy autoritativní servery.
Ty pak často reagují zablokováním zdrojových IP adres a tím znepřístupnění domén uživatelům. Někdy se správce autoritativního serveru ozve, ale to už je obvykle pozdě a útok skončil.
Už na síťové vrstvě jsou servery chráněny pomocí FTAS, který zabrání útokům jako SYN Flood. Na firewallu je pak limitováno množství paketů z jednotlivých IP adres pomocí modulu Hashlimit, provoz je pak dynamicky limitován pomocí dynamických IPsetů.
Jako rekurzor slouží Unbound, který umožňuje nastavit ratelimiting pro konkrétní zóny nebo globální. Je také možné blokovat konkrétní adresy a sítě, ale těch je obrovské množství.
Přes všechna tato opatření stále rostou snahy o zneužití serverů, proto bylo rozhodnuto o jejich ukrytí před veřejným internetem. Plánujeme rekurzory uzavřít, od začátku března pak budou dostupné jen ze sítí připojených přes CESNET.
Daniel Studený: Certifikáty včera, dnes, zítra a možná naposled
Doba platnosti certifikátů se neustále zkracuje, zhruba do roku 2012 nebyl stanoven žádný limit a běžné byly certifikáty s platností 5 až 10 let. V roce 2012 pak byl limit stanoven na 5 let a v roce 2015 pak došlo k dalšímu zkrácení na tři roky. V té době přišel Lets Encrypt, který dobrovolně zkrátil platnost na tři měsíce.
V roce 2018 došlo ke zkrácení na dva a čtvrt roku a později ještě na jeden rok. V roce 2023 prohlásil Google, že by rád v CA/B fóru navrhl zkrácení na tři měsíce. Nakonec se tak stalo 9. října 2024, kdy se toho ujal Apple a založil návrh na hlasování, který dostal značku SC-081.
Bylo navrženo, aby po 15. září 2025 měly certifikáty platnost maximálně 200 dnů. Návrh je prodiskutovaný a už kolem něj neprobíhá další debata. Vypadá to, že si to takzvaně sedlo a zřejmě k hlasování brzy dojde.
Podporu tohoto návrhu už deklarovala certifikační autorita Sectigo.
Pavel Bašta: zapojení komunity do boje se sociálním inženýrstvím
Projekt Blockers má umožnit koncovým uživatelům hlásit podezřelé webové stránky. Nemusí jít jen o phishing, ale také třeba o falešené investiční příležitosti.
Výhodou je, že uživatelé budou identifikováni, budou mít svou historii hlášení a bude možné ty nejlepší ocenit a upozornit na ně bezpečnostní komunitu.
Karel Hynek: Pasivní objevování a analýza zařízení na síti
PANDDA je zkratka pro PAssive Network Device Discovery and Analysis. Základem jsou sondy, které sbírají Flow data, která se ukládají a analyzují. Práce s daty může trvat poměrně dlouho, proto vzniklo pohodlné uživatelské rozhraní.
Nástroj se přihlašuje na servery pomocí SSH, uživateli zobrazí veřejný klíč, který je potřeba nahrát na servery. Podporujeme i přihlašování heslem, ale uživatele od toho odrazujeme.
Pro sběr dat slouží ipfixprobe, kterou si CESNET sám vyvíjí. V plánu je, aby PANDDA sama podle cílového stroje připravila vhodnou konfiguraci pro sondu. Poté se spustí Ansible, který vše na cílovém stroji připraví pro sběr dat.
Analytická složka se skládá z automatické detekce síťových prvků, přičemž PANDDA sama po určité době běhu ukáže dostupná zařízení a otevřené síťové porty. Detaily jsou pak získány z SSH logu, kde je identifikováno konkrétní zařízení a sledujeme otevřené porty.
(Autorem fotografií je Petr Krčmář.)
