V úterý 7. února se konal další ročník pravidelné akce nazvané Seminář o bezpečnosti sítí a služeb (BSS). Zároveň je tento den dnem bezpečnějšího internetu, jde o dvacáté výročí této mezinárodní akce, která má zvýšit povědomí o aktuálních nebezpečích v online prostředí a propagovat jeho bezpečné a pozitivní užívání.
CESNET provozuje rozsáhlou e-infrastrukturu s mnoha uživateli, dotýkají se ho tedy jak problémy týkající se bezpečnosti, ale například i změny v legislativě. Seminář je postaven tak, abychom se podělili o konkrétní zkušenosti s provozem takto rozsáhlé sítě s mnoha službami,
zahájila akci Andrea Kropáčová ze sdružení CESNET.
Radoslav Bodó, Jakub Urbanec: (Ne)bezpečnost 2022
Nacházíme se v době, kdy se během několika let proměnil celý svět: pandemie, ruská invaze na Ukrajinu, energetická krize a další problémy. Už 4. ledna roku 2022 začaly kybernetické útoky na koncové počítače na Ukrajině, ale i na průmyslová zařízení. Od 15. ledna začal Microsoft netradičně zveřejňovat data o destruktivních malwarech.
Od 25. ledna začaly útoky na běloruské dráhy s cílem omezit možnost přesunu ruských vojsk. Poté začala samotná ruská invaze.
Z vnějšího hlediska je velmi těžké některé informace ověřit. Máme mnoho různých zdrojů informací.
Z veřejných zdrojů je vidět, že v kyberprostoru je velmi aktivní Rusko, které se zajímá především o elektronickou poštu (port 25) a webové služby. Čína se naopak snaží poštu spíše sbírat a připojovat se na různé administrační porty a zkoušet přihlašovací údaje. Spojené státy americké jsou také velmi aktivní, provádějí skeny a zajímají se úplně o všechno.
Současný konflikt je válkou dronů, na různých veřejných službách je možné sledovat výzkumné drony, útočné drony a mnoho dalších letadel. Zajímavé je také se podívat, jaké aplikace se na obou stranách nejčastěji stahují. V Rusku je velká poptávka po něčem, co umožňuje obejít místní cenzuru, proto vedou VPN.
Ukrajinci zase stahují komunikační aplikace, které jim dovolují komunikaci ukrýt.
Zajímavou roli hraje také síť Starlink, kterou tvoří soustava družic, které umožňují připojit se k internetu téměř odkudkoliv na světě. Jeden z uživatelských terminálů byl analyzován a byl vytvořen útok na software uvnitř, který umožnil o celé síti zjistit další podrobnosti. Bylo například zjištěno, že terminály pracují především na IPv6 a některé porty jsou otevřené do internetu a jsou normálně vidět na Shodanu.
Pojmenování chyb mají svoje trendy. Dřív jsme všechno pojmenovávali česko-rusky, letos je všechno dirty, vloni bylo všechno 4shell.
První takovou chybou byl Log4shell, která byla velmi nepříjemná a stále se v mnoha projektech vyskytuje. Je ale místy obtížně zneužitelná.
Podobná chyba se pak objevila v knihovně Spring a byla nazvána Spring4Shell. Dává uživateli možnost transformovat uživatelské vstupy do objektů nesoucích hodnotu.
Umožňovala ale upraveným vstupem vytvořit na disku vlastní soubor a vykonat vlastní kód. Je vidět, že Java se stále táhne za PHP, podobnou chybu totiž mělo PHP už v roce 2005.
V Linuxu se také vyskytují nepříjemné chyby. Zajímavý problém byl objeven v příkazu sudo verze nižší než 1.9.5. Zneužitelná byla v případě, že se používá prastaré hašování hesel pomocí DES. Známe přetečení bufferu, které slouží ke spuštění kódu. Tady je to ale naopak a problém nastává u krátkých hesel.
Způsobí to buď pád nebo to, že se obejde přihlašování a sudo vás pustí.
Nedávno byla v linuxovém jádře objevena chyba Dirty Pipe, která zneužívá souběhu v práci s diskovou keší a umožňuje zapsat data do souboru otevřeného pouze ke čtení. Je to velký problém, protože umožňuje přepsat chráněné soubory, protože se vůbec neřeší oprávnění.
Podobně chyba Dirty Creds, která dovoluje díky složitému vícenásobnému souběhu zneužít domněle uvolněné paměťové keše k navýšení privilegií. Zavádí spoustu nových zranitelností a oprava je velmi náročná.
Také ve světě Windows se objevují zajímavé zranitelnosti. Speciálně konstruovaný dokument typu DOCX umožňuje donutit MS Office ke stažení dokumentu z webu. V tomto dokumentu je odkaz umožňující spustit v operačním systému libovolný příkaz. Řada zranitelností jsou elaboráty znovu používající dříve objevené problémy. Byla objevena chyba v Exchange, microsoftím RCE a dalších službách.
Měli bychom si dávat pozor také na to, že uživatelé rádi porušují pravidla. Můžeme mít spoustu pravidel na to, že nikdo nebude sdílet firemní data a dávat je do cloudu. Uživatelé to stejně udělají.
Je potřeba také nezapomenout na to, že stav bezpečnosti nezávisí jen na jednotlivých komponentách, ale také na jejich pospojování. Všechno je dnes součástí internetu a obsahuje obrovskou spoustu komponent, jejichž propojení může způsobovat nečekané výsledky. Stav bezpečnosti záleží především na to, jak se do toho třískne.
Příkladem může být ChatGPT, které dokáže i programovat a dělá stejné chyby jako řada programátorů. Postupně se nám začnou objevovat staré známé chyby a my se budeme moci vrátit ke starým skenerům.
Zajímavé je, že na druhé straně ale také kódu rozumí, takže dokáže na požádání sám chybu odhalit. Až to někdo pustí na celý GitHub, objeví se spousta nových chyb.
Tomáš Košňar: FTAS as a service
FTAS je nástroj, který zpracovává provozní záznamy na bázi toků (flows). Ten byl kdysi brán jako naprostá exotika a dnes je naprostou standardní součástí provozu sítě.
Umožňuje nám v reálném čase vyhledávat anomálie v provozu, abychom byli schopni na ně reagovat. Musíme mít schopnost řídit infrastrukturu a mít ji pod kontrolou.
FTAS umí sebrat metadata pomocí Netflow, NSEL, IPFIX, sFlow, zpracovat je a zpřístupnit. Kromě faktické správy sítě umí také uchovávat provozní a lokalizační údaje a detekovat kybernetické bezpečnostní události. Přístup je možný přes webové rozhraní nebo API.
Služba je dostupná pro sítě připojené do e-infrastruktury sítě. Nejjednodušší způsob použití je odklonit data z hraničních síťových prvků v síti CESNET. Pro uživatele je to nejjednodušší, ale umožňuje to vidět jen data na hranici sítě. Jsou vidět standardní metadata o síťovém provozu, informace o doručení a směr a trasa doručení.
Druhou variantou je monitoring z vlastní sítě, který je podstatně detailnější. Systém pak zpracovává data, která pocházejí z místních síťových prvků nebo sond uvnitř. Pokud nemáte vhodné síťové prvky, můžete využít softwarovou sondu ipfixprobe, kterou je možné provozovat na běžném hardware.
Sonda ovšem neposkytne informace o tom, jak se síťové prvky zachovaly ke konkrétnímu paketu.
Poslední možností je mít vlastní instanci FTAS, v tom případě je celé řešení v rukou provozovatele sítě. Výhodou je, že vám to poběží, i když se odpojíte od zbytku světa.
Nevýhodou je, že pokud vám útočník zašifruje všechna data, zničí tím i data o provozu na síti. Dává tedy smysl mít část monitorovací infrastruktury u sebe, ale data držet mimo ni.
Kromě ukládání metadat pro budoucí využití správcem, je možné také na základě sběru dat provádět automatickou obranu proti nejrůznějším útokům na síť. Tyto obrany se týkají celého autonomního systému a je potřeba nastavit pravidla pro konkrétní typy provozu.
Zároveň je ale možné individuálně pravidla přizpůsobit pro konkrétního uživatele či skupinu. Některé organizace mají zkušenosti se specifickým způsobem obtěžování uživatelů, takže musejí mít pravidla nastavená citlivěji, aby zabrala dříve než všeobecná ochrana celého autonomního systému.
Dává smysl kombinovat obě varianty. Nejprve postihnout anomálie, které ohrožují všechny uživatele a poté postupovat k jednotlivým institucím, které mají nějaké konkrétní problémy. Základním klíčem je: monitorujme, ať nejsme slepí. Je důležité vědět, co se v síti děje a v jakém je stavu.
Klíčový je pak personál, který umí informace vyhodnotit a reagovat.
Jan Kolouch: Role SOC v organizaci
Ideálním cílem bezpečnosti je stav absolutního bezpečí, což je utopie. Když se já budu cítit bezpečně, bude to v nějaké bublině bez interakcí.
Pokud chceme dosáhnout v organizaci určité úrovně bezpečnosti, musíme si položit zásadní otázky: O čí bezpečnost se jedná? Jaké hodnoty jsou chráněny?
Cílem by mělo být dosáhnout úrovně kybernetické bezpečnosti na základě definice, kterou si definujete. V posledních letech se objevují nabídky hotových řešení. Je to řešení, pokud odpovídá vaší definici.
Security Operation Centre (SOC) má celou řadu definic, ale v zásadě jde o tým analytiků, kteří detekují, analyzují, reagují a předávají zprávy.
Důležité je přesně vědět, co bude vás SOC všechno dělat. Měli byste si také stanovit rozsah, vůči komu bude vystupovat, jaké bude mít umístění a jakou bude mít velikost. Bohužel některé organizace si zaplatí externí SOC a mají nesplnitelná očekávání.
SOC totiž musí mít dokonalou znalost vnitřního prostředí firmy. Pokud si pořídíte externí tým, kam až ho pustíte? Povolíte mu měnit nastavení bez dokonalé znalosti vnitřního uspořádání?
Ani CESNET nemá zájem vstupovat dovnitř sítě, naopak pracuje jako konzultant a nezasahuje do vnitřního prostředí organizace. Základem by měli být lidé, kteří rozumí interním procesům v organizaci. Nebrání to ale spolupráci s ostatními organizacemi, forenzní laboratoří nebo třeba CESNET CERTS.
Pomoci může distribuování sil nad podobnými problémy mezi organizacemi. Základem jsou ale finance, jak bylo zdůrazněno, bez peněz není nikdo schopen kvalitní lidi udržet.
Radko Krkoš: Zranitelnosti, jak je neznáte
Zranitelnost je slabé místo, které je zneužitelné jednou nebo více hrozbami. Činí ho citlivým na poškození nebo zničení. Příbuzný termín je hrozba, což je fenomén s potenciální schopností poškodit.
Zranitelnost je pasivní schopnost, hrozba je naopak aktivní.
Každou zranitelnost je možné popsat, obvykle se k tomu používá standard CVE. Ten říká, že zranitelnost musí být popsána dostatečnými a dostatečnými vlastnostmi a musí se na ní shodnout majorita v bezpečnostní komunitě. Tyto zranitelnosti jsou označovány jedinečným číselným identifikátorem, za čtvrt století bylo takto katalogizováno 195 tisíc zranitelností.
Některá CVE jsou odmítnuta. Obvykle je to proto, že nejde o bezpečnostní chybu nebo problém spočívá ve špatné konfiguraci nebo nevhodném použití technologie. Příkladem je hlášení o nevhodné službě běžící na některém zařízení nebo chyba, jejíž zneužití vyžaduje úpravu původního software. Takový přístup k bezpečnosti je úplně absurdní.
Každá zařazená zranitelnost je hodnocena podle závažnosti na škále od 0 do 10. Zároveň jsou k ní přiřazena různá metadata, která chybu podrobněji popisují podle útočního vektoru, komplexity, potřebné úrovně oprávnění nebo potřeby uživatelské interakce.
Z dlouhodobého hlediska je důležité monitorovat zranitelnosti a spolupracovat s ostatními organizacemi. Sledovat byste měli celou řadu zdrojů, aby vám něco podstatného neuniklo. Za rok ale může jít až o 30 000 bezpečnostních chyb.
Dan Tovarňák: Asset management
Bez inventarizace není možné dělat rozumně bezpečnost. Zejména na vysokých školách se pak razí otevřenost, kdy je pro mnoho uživatelů jedno, co je kam zapojeno. Uživatele obvykle zajímá hlavně délka UTP kabelu, která je přímo úměrná vzdálenosti nejbližší funkční zásuvky.
Proč by bylo dobré chovat se k IT inventáři stejně dobře, jako se chováme k fyzickému majetku?
Do IT inventáře patří všechna zařízení, komponenty, ale i firewallová pravidla, směrovací pravidla, operační systémy, aplikace, knihovny nebo třeba uživatelé a jejich koncové prvky. Tohle všechno byste měli evidovat, ale určitě víte, jak to v organizacích obvykle vypadá.
Při řešení bezpečnostních rizik je prvním úkolem inventarizovat veškerý inventář. Pokud nevíme, co provozujeme, nejsme schopni to zabezpečit.
Základem by měla být geografická data, která zahrnují budovy, místnosti, okna, dveře a další prvky. Nad tím by měla stát technologická data všeho druhu včetně elektroinstalace a komunikačních sítí.
Situace se komplikuje v síťové a výpočetní infrastruktuře u datového centra. Zde se řeší infrastruktura (DCIM, Data Center Infrastructure Management) a síťové adresy (IPAM, IP Address Management). Kromě toho je potřeba zahrnout také informace o bezdrátových sítích, virtualizaci i technologické a nouzové kontakty.
Otevřené řešení představuje nástroj NetBox od DigitalOcean, který implementuje DCIM i IPAM. Zachovává jistou volnost, kdy je možné navolit vlastní atributy a některé koncepty lze ohnout požadovaným směrem.
Nabízí globální vyhledávání a podporuje řízení přístupu na úrovni objektů. Je napsaný v Pythonu a Djangu, je rozšiřitelný a nabízí API.
Ke každému aktivu je možné také přiřadit CVE nebo další informace.
Další vrstvu tvoří uživatelé, koncové prvky a software. To zahrnuje i zařízení, která si mohou uživatelé přinést. Pokud to je možné připojit do sítě, uživatelé to udělají. Cokoliv. Je potřeba s tím počítat.
Evidence těchto informací umožňuje zlepšit péči o uživatele a zlepšit situační povědomí. Když mi třeba uživatel volá na podporu, já hned vím, v jakém stavu má počítač.
Pokud známe název software či hardware a verzi, typicky známe alespoň základní zranitelnosti (CVE). Pokud disponuji seznamem zařízení, umím otestovat jejich shodu s nějakým profilem.
Kontrolovat to je možné pomocí SCAP (Security Content Aplication Protocol), který popisuje stavy různých komponent v našem inventáři.
Pro koncové prvky je možné použít bezagentní nebo agentní řešení. Pokud nechceme mít v koncových systémech nainstalovaného agenta, můžeme použít externí skenování pomocí nástrojů jako Nmap, Nessus, Sner4 nebo třeba OpenVAS. Agentem nainstalovaným na koncovém zařízení může být jakýkoliv sofware, včetně jednoduchého skriptu. Hotová řešení představují Rudder, Lansweeper, Snipe-IT nebo Pakiti.
V čem jsou největší překážky v nasazování podobného řešení a systému? Hlavním problémem je rozmanitost IT inventáře, vysoká zátěž na jednotlivce, nízká úroveň automatizace a absence politik a skutečného řízení. Důležitá je podpora z vedoucích pozic.
Radek Orkáč: Nezálohujte
Doporučovanou strategií zálohování je koncept 3–2–1, kterou vymyslel fotograf Peter Krogh. Vždy se vytvářejí tři kopie produkčních dat, dvě jsou uloženy na oddělených nezávislých zařízeních (disk, NAS, pásky) a třetí je uložena vzdáleně. Jde o strategii z roku 2009, kdy nebyla rozšířená cloudová úložiště.
Vznikají proto upravené strategie jako 3–2–2, kdy jsou dvě místní kopie na místních zařízeních a dvě například v cloudu. Je potřeba přemýšlet také nad rychlostí obnovy, proto se hodí mít rychle dostupné kopie u sebe.
Jako konkrétní implementace zálohovacího software byl podrobně popsán nástroj Borg Backup.
Jako další varianta byl zmíněn Rclone, který dovoluje synchronizovat data na desítky různých cloudových úložišť. Pozor na ukládání dat v cloudu, někteří poskytovatelé mají možnost pozastavit vám služby, pokud se domnívají, že porušujete podmínky. Dělá to automat a ty dělají chyby.
Důležité je také monitorovat zálohy, abychom si byli jisti, že vše funguje správně a nedošlo nám třeba místo na disku.
Pavel Valach: Role orchestrace při správě systémů
Většina uživatelů začíná při správě služeb s manuální konfigurací. Postupně se jim ale často rozroste počet spravovaných strojů a vznikne malá flotilka. Začnete si zapisovat různé postupy, které často opakujete. Ale máte ty informace aktuální? Doplňujete je o nové postupy?
Když už provádíme dokumentaci do textového souboru, můžeme snadno začít s orchestrací.
Orchestrace je vlastně dokumentační proces, ale prováděný standardizovaným a opakovatelným způsobem. Můžu si pak jednotlivé části oddělit a používat je samostatně.
Kromě toho vhodné nástroje umožňují rychlý sběr informací o spravovaném stroji. To je možné využít při konfiguraci pomocí proměnných.
Spuštění orchestračního nástroje se také zaznamenává v systémovém logu, čímž vzniká auditní stopa. Víme tedy přesně, co se dělo.
Orchestrační skripty je pak možné snadno testovat, protože je můžeme pustit na testovacím serveru. Jsme tak schopni rychle testovat a vyvíjet nové konfigurace.
Orchestraci je možné použít prakticky kdekoliv, přes servery, kontejnery, virtuální servery a další prvky. Pokud už ale používáte orchestrační nástroj, není dobré jej míchat s ručními zásahy.
Použití konkrétního nástroje záleží na osobní preferenci a na modelu fungování: buď z jednoho stroje spravujeme ostatní nebo si naopak klienti stahují konfiguraci z centrálního úložiště. Existuje celá řada různých orchestračních řešení: Ansible, Puppet, Salt. Chef a další.
K orchestrovaným serverům je možné se přihlašovat různými způsoby. Obvykle se nástroj hlásí pomocí SSH, kde je možné použít klíče, kombinovat je s OTP nebo využít klíče uložené na tokenu U2F. Některé nástroje používají jiný způsob přístupu a ověřují pak přístup například pomocí TLS.
Orchestrovat je možné i zálohování, tedy nastavení přístupů, jednotnou konfiguraci pro zálohování, kontrolu a automatizovanou obnovu záloh. Pokud používáte automatizaci, znáte postup obnovy záloh a umíte odhadnout dobu potřebnou k obnově.
Martin Šebela: Phishingator
Phishing je nejčastějším vektorem útoku a každý správce chce mít poučené uživatele, kteří se na něj nenachytají. CESNET nabízí organizacím službu zaměřenou na školení uživatelů, která je spojená i s praktickým testem. Řada organizací je schopná si podobné školení provést ve vlastní režii. Často to ale pokulhává z hlediska praktického textu.
Kompromis mezi oběma řešeními je Phishingator.
Jde o webovou aplikaci pro automatické zasílání cvičných phishingových zpráv. Původně vznikl jako bakalářská práce, nyní jde o open-source software. CESNET ji poskytuje formou Software as a Service, kdy se nemusí organizace o nic starat.
Umožňuje nenásilně uživatelům ukázat, čeho jsou útočníci schopni a co jim hrozí. Cílem není nikoho buzerovat, ale ukázat uživatelům, co je to phishing.
Správce nejprve připraví šablonu e-mailu a indicií, podle kterých by mělo být možné typický phishing rozpoznat. Poté je potřeba koupit podvodnou doménu, připravit na ní falešnou cílovou stránku a rozeslat e-maily. Většinu těchto věcí dělá Phishingator sám, sbírá pak informace o tom, jak uživatelé na přijetí zprávy reagují.
Je možné také definovat, co se má stát po vyplnění phishingového formuláře. Obvykle ukazujeme vzdělávací stránku, která uživateli vysvětlí, jak měl podvod rozeznat.
Uživatel pak vidí, co ho mělo na e-mailu zarazit. Stejně tak se ukáže i původní phishingový web, včetně upozornění na jeho neobvyklé prvky. I když uživatel formulář nevyplní a k výukové stránce se nedostane, přijde mu po něaké době další e-mail o tom, že test proběhl. Součástí zprávy je i odkaz na další informace na výukové stránce. Máme zkušenosti, že uživatelé na odkaz kliknou a informace si přečtou.
Administrátor kampaně má možnost přesně zjistit, jak uživatelé na rozeslané e-maily reagovali. Je možné sledovat průběžné výsledky, tedy informace o tom, jak se kampaň vyvíjí.
Při jednom z testů na fakultě bylo rozesláno 173 phishingových mailů s informacemi o mzdách a během půl hodiny bylo získáno 15 platných identit. V jiných kampaních jsme měli úspěšnost 40%.
Dobrá zpráva je, že uživatelé mají tendenci se poučit a s opakovanými pokusy procento nachytaných uživatelů klesá. Dokonce nám pak hlásí skutečný phishing, protože už ho pak rozeznají.
(Autorem fotografií je Petr Krčmář.)
ČLÁNKY DO MAILU