Osmý ročník tradiční konference Ověřená řešení v sítích, se opět po dvou letech konal na Obchodně podnikatelské fakultě SLU v Karviné. Letos jsme mírně změnili název konference a OpenSource jsme změnili za Ověřená. Jediným cílem bylo rozšířit množství posluchačů a zájemců o témata konference, jiný záměr v tom nebyl,
řekl na úvod Petr Suchánek.
Dalibor Hula: Velké nesnáze s malým projektem
Na začátku projektu stál požadavek na kontrolu výrobní linky vyrábějící plastové díly pro automotive. Někdy se stane, že z formy výrobek nevypadne a když se zalisuje znovu, může se forma poškodit.
Proto bylo do IT oddělení zadáno, aby byla zajištěna kamerová kontrola, která v případě chyby pozastaví běh stroje. Protože jsem odchovanec open-source konferencí, rozhodl jsem se vše postavit na Raspberry Pi a open-source nástrojích.
Vše se podařilo a po uplynutí nějaké doby se společnost rozhodla řešení nasadit na další stroje. Vyšlo ale nové Raspberry a s tím i nový operační systém a nové nástroje.
Z Debianu 11 se stal Debian 12 a OpenCV bylo aktualizováno z verze 3 na verzi 4. Pak ještě přišly minoritní problémy, protože na nové Raspberry Pi nám nepasovaly krabičky.
Pro komunikaci po GPIO byla hojně využívaná knihovna Wiringpi, která přestala být vyvíjená. Totéž nastalo s knihovnou, kterou jsme používali pro přístup ke kameře.
Knihovna RaspiCam pro snadné získání obrázku z kamery a předání do OpenCV už tedy nebyla použitelná. Existuje ale fork libcamera, takže jsme jej nasadili a mohli jsme jet dál.
Další problém ukázal nemožnost zkompilovat původní program, protože bylo potřeba změnit názvy kolizních funkcí a upravit volání některých funkcí. Používáme funkci pro spouštění části kódu v samostatném vlákně a vývojáři se rozhodli zrovna u ní prohodit pořadí parametrů.
Tohle bylo nakonec poměrně jednoduché v takovém projektu opravit. Nevím ale, jak se tyhle problémy řeší ve velkých projektech.
Nakonec se podařilo program odladit a spustit. Poté přišel nový požadavek, aby v případě problémů Raspberry poslalo e-mail. Musel jsem k tomu hledat další knihovnu, která může někdy v budoucnu znamenat nový problém.
Kolegové se kvůli všem těmto problémům rozhodli použít ověřené řešení firmy Basler. Ověřená kamera Basler se ale začala náhodně odpojovat.
Na vině byl PoE switch DLink, na kterém bylo potřeba nasadit opravu výměnou firmware. Tohle nakonec nebyla naše chyba.
Jednoho dne pak přišel kolega s novým počítačem s Ubuntu a v celé síti se všechny kamery odpojily a nefungovaly. Zjistili jsme, že za to může zapnutí počítače s Ubuntu.
Ukázalo se, že aplikace KDE Connect posílá broadcasty pro průzkum svého okolí a to shodilo všechny kamery.
Když se vám stane něco podobného, víte, že v tom nejste sami. Existují dvě základní pravidla, která vám mohou pomoci: nesahejte na funkční věci a co do projektu nedáte, se nemůže pokazit.
Jakub Šafařík: Co se děje za obrazovkou
Celosvětové statistiky mluví o 2200 úspěšných útocích denně a roční škody jsou odhadovány na osm bilionů amerických dolarů. Letos jsme zaznamenali například smazání dvou petabjtů dat ruského vesmírného centra, velký incident CrowdStrike, ransomwarový útok CDK Global, dva obrovské úniky AT&T zasahující desítky milionů uživatelů. Služba 1Password uvádí, že vzrostl desetinásobně počet útoků na uživatelská hesla, v 95 % případů dochází k průniku kvůli lidské chybě a většina firem o úspěšném útoku ani neví. Týká se to i Česka, přestože si mnozí myslí, že jsme malá země a peníze tu nejsou.
NÚKIB uvádí 79% nárůst proti roku 2022, přičemž jde jen o data organizací spadajících pod kybernetický zákon. Polovina incidentů je klasifikována jako útoky na dostupnost a zhruba 40 % se pak zaměřuje na získání dat.
Útočníci byli letos aktivní zejména v červenci a srpnu, což je dáno zejména incidentem CrowdStrike. Pozitivní je, že většina útoků je vyhodnocena jako méně významný kybernetický incident.
Policie eviduje informace jiným způsobem a neprovádí žádnou kategorizaci jako NÚKIB. V posledních dvou letech jsme se pohybovali okolo 20 000 skutků týkajících se kybernetické kriminality. Objasnitelnost je poměrně nízká a pohybuje se okolo 3000 objasněných případů a bude se jednat o jednodušší případy.
Způsobené škody se jen v Česku pohybují ročně okolo tří miliard.
Primárním problém je stále ztráta dat a jejich nedostupnost. Je potřeba si uvědomit, jakou cenu pro mě mají data a zda mám metodiku pro jejich obnovení.
S tím je spojena nedostupnost, kdy společnost ještě nějakou dobu není schopna plnohodnotně fungovat a dále roste finanční ztráta. Ve výsledku může dojít k poškození dobrého jména a ztrátě klientů.
Počet útoků rok od roku stoupá a s nástupem AI se útoky stávají sofistikovanějšími. Je také čím dál jednodušší útočit na menší subjekty jako jsou obecní úřady nebo třeba nemocnice.
Opět tedy neplatí, že jsou menší společnosti v bezpečí, protože se na ně nevyplatí útočit.
Doporučuje se aplikovat softwarové záplaty do pěti dnů u aplikací dostupných z internetu a do sedmi dnů u těch interní. Průměrně se to ale děje až za třicet dnů a u 40 % aplikací se oprava nikdy nenasadí.
Průměrná doba do aktivního zneužití je okolo dvaceti dnů, ale 25 % exploitů je připraveno do 24 hodin po zveřejnění bezpečnostní slabiny. Jen 5 % zranitelností ale představuje vysoké riziko a dává smysl se jim věnovat přednostně.
Přemysl Soldán: Moderní trendy v ochraně dat před kybernetickými útoky
Útoky mohou být destruktivní, nebo mohou zamezovat přístupu. Nejhorší hrozbou je pro nás ransomware, který tyto přístupy kombinuje.
Není otázka zda se to stane, ale kdy nás tento problém postihne. Musíme minimalizovat ztráty a snížit pravděpodobnost na minimum.
Nejdůležitějším opatřením je správné zálohování, kde NÚKIB vydává rozumná doporučení na základě zkušeností z minulých incidentů. Je třeba si uvědomit, že zašifrování disků je až velké finále.
Útočníci se na začátku dostanou do nějakého systému, nainstalují si vlastní nástroje a poté se připravují na útok. Zaznamenali jsme útočníky, kteří byli v síti déle než rok.
Záloha by měla mít tři kopie, na dvou zařízeních, kdy jedno z nich je topologicky jinde a offline. Co není připojeno, to nemůže být napadeno.
Obnovení pak musí probíhat co nejrychleji, ale musíme počítat s tím, že zálohy jsou napadeny a musíme je v průběhu obnovování čistit.
Vektor útoku je obvykle úplně stejný: začne se phishingem, získají se nějaké přístupové údaje a je možné začít. Je možné začít i nějakou vážnou zranitelností, ale to je obvykle zbytečně pracné.
Základní pravidla pro prevenci jsou: oddělená oprávnění uživatelů, různá hesla pro různé služby, segmentace sítě, aktualizace software, průběžné skenování slabin, uzavření neaktivních služeb a sledování logů. To je spousta práce, ale existují společnosti, které se vám o to postarají, mají zkušenosti a dostatek lidí.
Rozhodně byste neměli útočníkům platit. Dnes možná data rozšifrujete, ale oni vám je pak mohou kdykoliv zašifrovat znovu.
Útočníci často pracují jako profesionální firmy a začnou vám nabízet různé doplňkové služby, což vás nakonec bude stát mnohem víc peněz než správná prevence.
Robert Fárek: ERP – ochrana dat a prevence hrozeb
ERP znamená Enterprise Resource Planning, kdy prostředím softwaru řídíme procesy celé firmy. Od nákupu přes sklady, výrobu, expedici a fakturaci. ERP je takové srdce podniku.
Když máme data centralizovaná v jednom systému, je to zajímavý cíl pro útočníky. Při vyřazení systému ve výrobním podniku sice stroje mohou dále pracovat, ale skladníci a plánovači jsou slepí a výroba se stejně zastaví.
Největšími hrozbami jsou malware a ransomware, které se do infrastruktury dostanou přes phishing. Lidé jsou často nejslabším článkem v řetězci systému řízení informační bezpečnosti.
Občas se objevují i záměrné útoky frustrovaných zaměstnanců, kdy může škodit konkrétní osoba.
Podle společnosti Sophos má více než polovina výrobních společností negativní zkušeností s kybernetickými útoky. Zároveň téměř polovina společností nezálohuje, což je katastrofa.
Navíc jen asi 20 % firem má plány obnovy a zachování kontinuity provozu. Při reálném napadení není čas na brainstorming!
Řešení přitom mohou být jednoduchá a vyžadují vytipování klíčových částí, které je možné rychle spustit na náhradní infrastruktuře. Pokud ale tyto informace nemáme předem sepsané, bude to znamenat hodně stresu.
Nové typy hrozeb přináší umělá inteligence, která nabízí novou úroveň automatizace. Obsah phishingového e-mailu může být personalizovaný a může se adaptovat na různé typy ochrany.
Nejlepší ochranou je prevence, která staví na uvědomění si toho, že útok jednoho dne přijde.
Z pohledu ochrany dat je nejdůležitější správně zálohovat mimo samotnou infrastrukturu. My třeba dáváme zálohy do banky.
Rizikem může být také třeba velká voda, která může zálohy uvnitř hlavní budovy zničit.
Dalšími typickými problémy jsou chybějící aktualizace, nezabezpečený přístup do sítě a chybějící organizační bezpečnostní politiky. Musíme mít sepsané politiky, co mám udělat, když se něco stane.
Jednou za rok je potřeba si dokumentaci projít a aktualizovat, aby byla stále živá.
Úplně zásadní věcí je, aby uživatelé nepoužívali v práci stejná hesla, jako v soukromém životě. To by měl být naprostý základ, protože jinak by to mohlo dopadnout špatně.
Hesla totiž ve velkém unikají a pak můžeme najít hesla k interním systémům na webu.
Dodavatel ERP systému může přispět k ochraně tím, že bude nabízet bezpečnostní funkce a architekturu a poskytovat pravidelné bezpečnostní aktualizace. Naše role je ve vysvětlování toho, že je potřeba aktualizovat a chránit data firmy i zákazníků.
Zásadním trendem v oblasti ERP systémů je přechod do cloudu v režimu SaaS (Software as a Service), který může velkou část bezpečnostních hrozeb eliminovat. Řada výrobců už ani nenabízí možnost instalovat řešení do firemní infrastruktury.
Cloud může nabídnout pokročilé bezpečnostní funkce, centralizované řízení a monitoring a automatické aktualizace.
Rizika v každém případě není možné eliminovat, je možné je ale významně snížit. Ochrana dat je kontinuální proces, který nikdy nekončí a je třeba se mu průběžně věnovat.
Technologie můžou poskytnout silnou ochranu, ale skutečný rozdíl dělají lidé a procesy.
Jiří Kohout: Praktické řešení DevSecOps v KB a důvody jeho nasazení
Tradičně se IT provozuje tak, že centrální tým provozuje jednotlivé aplikace a byznys vytváří nové požadavky. Správci pak mají stanovená pravidla, jak musí nová aplikace vypadat a co musí splňovat.
Aplikace se provozují jako jeden obrovský blok, který se musí nasazovat jen několikrát do roka a při té příležitosti se udělají také nějaké penetrační testy.
V režimu DevOps provozuje IT oddělení pouze sdílené velké bloky funkcionalit jako databáze a sítě. Vývojáři se musejí naučit provozovat své aplikace a mají pod kontrolou celý životní cyklus své aplikace.
Je pak možné dělat malinké změny a rozdrobit velké monolitické aplikace. Dochází tak k větší dělbě práce a decentralizaci.
V Komerční bance je 1200 informačních systémů, o které se dnes stará 250 malých týmů. Klient vidí samozřejmě jen malou část z nich.
Při bezhotovostní transakci se například použije 28 různých systémů, nejde o jeden monolit, ale celou řadu menších aplikací.
Z pohledu byznysu si firmy od tohoto způsobu práce slibují redukci nákladů, rychlejší vstup novinek na trh a vývojářskou kreativitu. Rizikem je naopak vyšší komplexita, nutnost naučit se řadu nových věcí a problémy s neznalostí provozu. To přináší řadu rizik, která se snažíme analyzovat a eliminovat.
Proto je třeba zajistit metodiku bezpečného vývoje a standardizace procesů.
Jedním ze zásadních opatření je přístup Shift left, kdy se bezpečnostní témata přesouvají v plánech na začátek, tedy už do raných fázích vývoje a plánování. Ještě před samotnou změnou kódu se začne o věcech diskutovat, čímž se vývoj v následných krocích zásadně zlevňuje.
Proti tradičnímu přístupu se až šedesátkrát sníží cena oprav. Lidé z různých týmů se musejí o konceptech bavit mnohem dříve a vzájemně se chápat.
Metodika bezpečného vývoje je návodem, jak správně vyvíjet. Příručka v KB má 334 stran rozdělených do 85 kapitol. Pokud to vývojáři neznají, velmi rychle začínají narážet při integracích.
Když všichni znají jednotné postupy, mohou jejich služby snadno zapadnout do celého prostředí. Máme popsaný celý stack a vývojáři znají celý proces vývoje a provozu služeb.
Inspirací může být OWASP SDLC, NIST 800–64 nebo Microsoft SDL.
Vysokou výstupní kvalitu kódu zajišťuje bezpečnostní a kvalitativní kontrola, která se provádí automaticky v průběhu procesu buildu aplikace. Jednotlivé testy mohou být doporučující či blokující s ohledem na související riziko či dopad funkcionality. Kvalitu si hlídáme už v průběhu vývoje a už nemusíme tolik tlačit na penetrační testy.
Standardizace podkladových systémů umožňuje snížit úsilí potřebné pro kontrolu shody se standardy a regulacemi.
Vývojáři dělají dokola stejné chyby, proto vznikla interní certifikace aplikací a vývojářů. To zahrnuje školení a následující test a průběžnou kontrolu každý rok. Celkem je takto certifikováno 77 vývojářů a 32 aplikací. Vývojáři se učí hackerské techniky a zkoušejí si penetrační testy, čímž začnou chápat bezpečnostní principy a už nedělají obvyklé chyby v aplikacích.
Bezpečnost je ochranou podnikání a není možné ji ignorovat ani ošidit. Správný přístup stojí úsilí, ale umí ušetřit spoustu peněz a ocení ho zákazníci. Nikdy není pozdě začít.
Vždy se ale musíme ptát, proč něco potřebujeme, chceme nebo musíme dělat.
Jan Kundrát: Otevřený optický přenosový systém CzechLight
CESNET provozuje rozsáhlou akademickou počítačovou síť, která je postavená na optice. Říká se tomu počítačová síť, ale vlastně je to analogová síť podobná rádiovým systémům.
Používají se tu modulace, zesilovače a jiné analogové prvky. Staví na dvou hlavních principech: optickém vlákně a optickém zesilování signálů.
Lidé ze sdružení CESNET vyvíjejí vlastní optický zesilovač, což je vlastně průmyslový linuxový počítač, kterým se konfigurují jednotlivé prvky přenášející samotné fyzikální veličiny. Podobně jako používáme softwarově definované rádio, používáme tu softwarově definovanou síť.
Ta je definovaná pomocí formátu YANG a přenášená protokolem NETCONF.
Konfigurační strom je uložený v databázi Sysrepo, což umožňuje mít všechna data uložena na jednom místě. Poté je možné například pomocí Ansible tato data přenést do síťových prvků. Jakmile máme něco standardního, můžeme s tím dále pracovat, například grafovat různé veličiny v Grafaně.
Uvnitř síťových prvků pak běží konkrétní obraz systémů, neřeší se inkrementální aktualizace jednotlivých částí jako v běžné distribuci. Na systémovém disku jsou pak oddíly A a B a je možné z jednoho běžet a druhý aktualizovat.
Systém je bezestavový a běží v režimu pouze ke čtení.
Základem je počítač SolidRun Clearfog Base, který je postaven na dvoujádrovém 32bitovém procesoru Marvell Armada A38× a má 1 GB paměti. Vybírali jsme poměrně dlouho, protože jsme chtěli průmyslový počítač bez grafického jádra, který bude mít navíc nízkoúrovňový přístup k SFP.
Tomáš Tichý: Potíže s IPv6 tunely
Běžné domácí připojení zařízené pomocí dual-stacku, běží vám oba protokoly zároveň. Případně je možné mít v koncové síti jen IPv6 a na weby dostupné pomocí IPv4 pak přistupujete pomocí DNS64 a NAT64. Nebo máte poskytovatele jako já, který poskytuje jen IPv4. Pak potřebujete tunel.
Tunel umožňuje zabalit IPv6 komunikaci do IPv4 a přenést sítí do bodu, kde se vybalí a pošle se do internetu.
Je možné použít celou řadu různých tunelovacích protokolů jako 6to4, AYIYA, Teredo, OpenVPN, WireGuard nebo 6in4. Existuje několik různých poskytovatelů tunelovacích serverů jako Hurricane Electric, Route48 nebo 6project a vlastní tunely nabízí také vpsFree.cz. Já doma používám Hurricane Electric, se kterým jsou občas problémy.
Služba HBO Max například při použití tunelu od HE tvrdí, že je uživatel ve Spojených státech. Služba sice funguje jen po IPv4, ale používá geolokační službu, která IPv6 umí.
Řešením bylo vyhledat všechny IPv6 adresy používané v HBO Max a nahradit je čtyřkovými protějšky.
Letos se ale služba v Česku přejmenovala na Max a opět se rozbila. Podporuje totiž IPv6, takže jsem pro ni musel šestku zakázat a přejít u ní na IPv4.
V opačném případě si služba myslela, že je uživatel zase ve Spojených státech. IPv6 adresy se ale občas mění, proto je potřeba jejich seznam aktualizovat. Mám skript, který vždycky o půlnoci projde seznam domén a nahradí jejich adresy za IPv4 variantu.
Celý rozsah od HE je například blokován na Wikipedii nebo omezuje použití některých služeb, včetně YouTube. Je velmi jednoduché tunely zneužívat, protože si je můžete zřizovat zdarma a měnit je.
Tunely od HE jsou sice funkční, ale uživatelům způsobují nečekané potíže.
Jan Vachtarčík: Boj firem s kybernetickou kriminalitou
Kybernetická kriminalita roste obrovským tempem, naštěstí si to uvědomujeme a vznikají nová legislativní opatření, která organizacím pomáhají. Cílem jsou firmy všech velikostí a ve všech odvětví. Kybernetická kriminalita nezná hranice a hrozby jsou čím dál více globální.
Dříve se bezpečnostní oddělení týkala jen určitých odvětvích, jako například v bankovním sektoru. Čím dál častěji se poskytovatelé bezpečnostních služeb snaží nabízet své služby menším firmám.
Dokonce i některé firmy o jednom člověku chtějí spolupracovat s poskytovateli takových služeb.
Klíčem k minimalizaci rizik jsou prevence a rychlá reakce. Kdo je připraven, není překvapen. Je třeba mít zpracované plány pro řešení incidentů a návratu do normálního stavu.
Velkým problémem ve firemních sítích je ransomware, který dokáže zastavit výrobu a vyžaduje jen neopatrného uživatele, který otevře napadenou přílohu. Museli jsme zavést školení a pravidelně uživatele testovat v e-learningu.
Útočníci se ale přizpůsobují a začali uživatelům posílat podvodné linky a snažit se přes ně získat přihlašovací údaje. Všem jsme tedy aktivovali dvoufaktorové přihlašování.
Poté ale začali útočníci uživatelům telefonovat a chtít po nich kód pro druhý faktor. Tohle jsme vyřešili osvětou, ale trvalo to roky.
Klíčovým dotazem je: kdo na nás útočí a proč zrovna na nás? Nejčastěji to jsou skupiny, jejichž primární motivací je finanční zisk. Mohou to ale také být státní aktéři, kyberteroristé a hacktivisté. Nezanedbatelnou částí jsou dnes hacktivisté, kteří se snaží napadat naše systémy a zobrazit na nich třeba nějakou hlášku.
Pro boj proti kyberkriminalitě slouží celá řada technologií jako antivirové programy, firewallové systémy, detekce a prevence ztráty dat (DLP), šifrování citlivých dat, vícefaktorová autentizace a biometrie, monitoring (SIEM+SOC/NOC) a další. Měl by být nastavený proces řešení zranitelností a na ty nejkritičtější by se mělo včas reagovat.
Prevence je efektivnější než reakce na útoky. Je to investice do budoucnosti firmy.
Firmy musejí přijmout zodpovědnost a učinit strategické rozhodnutí, že bezpečnost je prioritou. Je třeba také přidělit lidem konkrétní role.
Nutné je určitě pravidelně provádět audity kybernetické bezpečnosti, spolupracovat s externími odborníky, rozvíjet kulturu bezpečnosti mezi zaměstnanci a vytvořit krizový plán pro případ kybernetického útoku.
Lukáš Macura: Jak na centrální log management
Správa logů je vynucena mnoha směrnicemi a doporučeními. Log management je jeden ze zásadních nástrojů, které potřebujete při řízení rozsáhlejší infrastruktury. Bez něj nedokážete dohledávat informace o incidentech.
Není možné reagovat na incident, pokud o něm nevíte.
Nestačí jen sbírat informace do obrovských souborů, do kterých se už nikdo nikdy nepodívá. Musím být schopen zpětně dokázat, jak se událost stala.
Pokud bude firma řešit například porušení GDPR, kde hrozí drakonické pokuty, je nutné mít v ruce detailní informace.
Nejprve je potřeba data sbírat ze všech serverů, které společnost provozuje. Které všechny servery to ale jsou? Spousta firem vůbec netuší, co v síti mají.
Je proto potřeba nejprve zajistit asset management a zjistit, z čeho data sbírat.
Pro transport protokolů je možné použít protokol syslog, ale to jsou vlastně dva protokoly: BSD protokol podle RFC 3164 a Syslog protokol podl RFC 5424. Je to v podstatě je text, není tam žádná složitější struktura. Jen musí splňovat nějaká pravidla.
Další možností je GELF, což jsou strukturovaná data v JSON. Dají se s tím dělat divy, často je to ale jen text v jednoduchém JSON.
Data se pak dnes obvykle přenášejí pomocí TLS a je třeba si dát pozor na autentizaci zdroje i serveru. Server si musí být jistý tím, že dostává data od oprávněného klienta, a klient musí věřit, že komunikuje s legitimním serverem.
Je potřeba také neměnit po cestě způsob transportu, používat stejné šablony u všech agentů a používat jednotný identifikátor přes celou síť.
Pro agregaci dat je možné používat syslog-ng, rsyslog nebo jiné komerční varianty. Nejlepším a nejmocnějším nástrojem je pořád grep.
Důležité je, že máte data uložená, zpracovat je pak můžete různými metodami.
Pokud chceme nad daty provádět složitější operace, musíme je nějakým způsobem indexovat. Je to nejnáročnější část, na kterou potřebujeme velké zdroje.
Nesmíme ji přehltit a zároveň nesmíme přijít o žádná data. Je potřeba zvolit, v jakém časovém období budeme data indexovat. Budu předpokládat, že devadesát procent incidentů budu řešit třeba do šedesáti dnů.
K indexaci je možné použít například otevřené nástroje ELK nebo Graylog.
Nejsložitější částí je pak analýza dat, která vyžaduje zdroje, vytvoření vzorů a pozornost při nastavení. Cílem je, aby systém zpracoval co nejvíce záznamů automaticky, aby se člověk zabýval jen tím opravdu důležitým.
Důležité je také mít logy na více místech a monitorovat chod celého systému. Myslet si, že něco loguju, je něco jiného, než logovat.
(Autorem fotografií je Petr Krčmář.)
