Archiv 14. 7. 2025

FortiGate a CoatHanger

„Selhání edge zařízení nemusí být vždy otázkou špatného nastavení na straně uživatele, ale často jde o limity samotné implementace. Uzavřený firmware, závislost na cloudové registraci nebo tichá oprava zranitelnosti – to jsou rizikové faktory, které by měl brát v potaz každý správce.“

„Firewall jako brána do sítě není jen o tom, co propustí — ale i o tom, jestli sám není zadními vrátky. Výpadek, zneužití nebo zpožděné aktualizace mohou mít vážné dopady i bez přímého přístupu k datům.“

„Článek nehodnotí značku, ale situaci, kdy se technologická důvěra mění v systémové riziko. Je důležité ukazovat příklady, ze kterých se může infrastruktura poučit.“

„Incident s malwarem CoatHanger není jediný svého druhu — ale ukazuje, jak klíčové je vědět, co zařízení dělá nejen ve chvíli, kdy funguje, ale i když selže.“

„Bezpečnostní zranitelnost CVE-2022-42475 byla aktivně zneužívána v době, kdy ještě nebyla veřejně oznámena. Podle zprávy MIVD byla součástí cíleného kybernetického útoku skupinou napojenou na čínský stát.“

Chyba byla přímo ve FortiOS, tedy v softwaru FortiGate zařízení.

Nešlo o špatnou konfiguraci, ale o kritickou zranitelnost, kterou Fortinet sice opravil, ale neoznámil včas, což umožnilo čínským státním hackerům provést masivní útok.

🧨 Co se přesně stalo?

  • V roce 2022–2023 byla objevena zranitelnost CVE-2022-42475heap-based buffer overflow v SSL-VPN komponentě FortiOS → umožnila vzdálené spuštění kódu bez autentizace
  • Podle zprávy nizozemské vojenské rozvědky MIVD z 12. prosince 2023 byla zranitelnost CVE-2022-42475 aktivně zneužívána jako zero-day útok dříve, než ji Fortinet veřejně oznámil.
  • Fortinet ji potichu opravil 28. listopadu 2022, ale oznámení vydal až 12. prosince 2022→ během té doby už byla aktivně zneužívána jako zero-day attack
  • Během této „tiché fáze“ bylo infikováno přes 14 000 zařízení, celkem pak více než 20 000 FortiGate firewallů po celém světě

🕰️ Jak šly události reálně po sobě

Datum Událost
28.11.2022 Fortinet potichu vydal opravu pro CVE-2022-42475 ve FortiOS
12.12.2022 Fortinet oficiálně zveřejnil advisory (zprávu o zranitelnosti)
2023–2024 Zranitelnost byla aktivně zneužívána – malware CoatHanger se šířil
12.12.2023 MIVD (nizozemská vojenská rozvědka) zveřejnila svou analýzu útoku
🕵️‍♂️ Kdo za tím stál?
  • Podle zprávy nizozemské vojenské rozvědky MIVD z 12. prosince 2023 šlo o čínskou státem podporovanou skupinu, která zneužila zranitelnost k cílenému napadení vládních a obranných sítí.
  • Nasadili vlastní malware zvaný CoatHanger, který:
    • se trvale usadil v zařízení (přežije reboot i firmware update)
    • je extrémně těžko detekovatelný
    • umožňuje trvalý vzdálený přístup
  • Cílem byly západní vlády, obranný průmysl, mezinárodní organizace → včetně holandského ministerstva obrany, kde se malware dostal do výzkumné sítě

🔍 Byla to chyba implementace?

Ano — šlo o programátorskou chybu v SSL-VPN komponentě FortiOS, konkrétně:

  • Nesprávné zpracování paměti → útočník mohl poslat speciálně upravený požadavek
  • Fortinet to neoznámil včas, což je u zranitelnosti s kritickým skóre 9.3/10 dost zásadní selhání

🧠 Pro přesnost:

  • CVSS v3: 9.3 / 10 → kritická zranitelnost → Kategorie: Remote Code Execution bez autentizace (heap overflow v SSL-VPN daemonu sslvpnd)

⚠️ Co z toho plyne?

  • Edge zařízení (firewally, VPN brány) jsou extrémně citlivé → mají přímý kontakt s internetem
  • Vendor lock-in a závislost na uzavřeném firmware může být rizikem, pokud výrobce nekomunikuje včas
  • Otevřené platformy jako OPNsense nebo pfSense umožňují rychlejší reakci, komunitní audit a transparentnost

CoatHanger malware stále může být aktivní na řadě FortiGate zařízeních po celém světě, a to i přesto, že Fortinet vydal opravu pro zranitelnost CVE-2022-42475 už v listopadu 2022

📊 Stav k dnešku

  • Podle nizozemské rozvědky MIVD a AIVD:
    • Malware byl nasazen cíleně na vybraná zařízení (např. ministerstva, obranný průmysl)
    • Počet zařízení s aktivním malwarem není znám, ale pravděpodobně jich je stále mnoho
    • Útočníci si mohou rozšířit přístup kdykoli, protože malware zůstává aktivní

🛡️ Co s tím?

  • Pokud máš FortiGate zařízení, které běželo na zranitelných verzích FortiOS (např. 7.0.x, 7.2.x), je nutné:
    • Provést forenzní analýzu – hledat známky kompromitace (např. soubory jako libips.bak, libgif.so, .sslvpnconfigbk)
    • Zvážit úplné přeinstalování zařízení (totální formát všech partitions)
    • Segmentovat síť, aby se malware nemohl šířit dál

odkaz na oficiální advisory:

🧨 Proč se ho nelze snadno zbavit?

  • Malware přežívá reboot i firmware upgrade → je navržen tak, aby se „zabydlel“ v systému a zůstal i po aktualizaci
  • Nejde ho detekovat běžnými CLI příkazy → maskuje se, manipuluje logy, dokonce umí upravit IPS engine knihovny
  • Fortinet sám přiznal, že jediný známý způsob odstranění je:
    • „Jediný známý způsob odstranění malwaru CoatHanger je kompletní vymazání zařízení a znovuinstalace s čistou konfigurací.“

🛠️ Jak se dá CoatHanger odstranit?

  • 🔥 Formátování storage – ne jen reset, ale totální zápis přes všechna oddílová data
  • 🧠 Vyčištění konfiguračních souborů – malware se může schovávat i v záložních config verzích
  • 🛡️ Manuální re-konfigurace – nepoužívat staré exporty, které by mohly obsahovat kompromitované části

A ano, i po aktualizaci firmware a restartu zůstal malware aktivní, protože si vytvořil systémově integrované hooky, které upravují vnitřní knihovny FortiOS.

„Zveřejnění technických incidentů je součástí bezpečnostní kultury. Přehledné informování o rizicích a chybách není útokem na výrobce, ale ochranou komunitního prostoru, kde záleží na transparentnosti víc než na image.“

„Každý firewall se může stát slabinou — rozdíl je v tom, jak se k tomu výrobce postaví, a jak rychle umožní správcům reagovat.“

Tento článek slouží jako technické shrnutí bezpečnostních událostí souvisejících s firewally Fortinet. Informace vycházejí z veřejně dostupných zdrojů (např. CVE databáze, bezpečnostní analýzy, zprávy vládních agentur) a mají za cíl informovat odbornou komunitu o rizicích spojených s provozem edge zařízení. Nejedná se o hodnocení značky Fortinet, ale o popis incidentu a jeho technických aspektů. Uvítáme případné upřesnění nebo doplnění od čtenářů či výrobce.

ℹ️ Zdroje: MIVD – Zpráva o zahraničních kybernetických hrozbách, 12. 12. 2023: „Čínská skupina využila zero-day zranitelnost ve FortiOS k trvalému napadení západních sítí.“

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/14/coathanger/

🧠FortiGate vs open-source filozofie – „technické srovnání“

✍️ Úvodní právní poznámka k porovnání

Tento dokument slouží jako technické srovnání firewallových řešení, založené na veřejně dostupných informacích, zkušenostech s reálným nasazením a popisem funkcí jednotlivých produktů. Cílem je poskytnout přehled možností, výhod a rozdílů mezi uzavřenými komerčními systémy (např. FortiGate) a otevřenými platformami (např. OPNsense) tak, aby si zákazník mohl zvolit nejvhodnější variantu pro svou síťovou infrastrukturu.

Nejedná se o marketingové hodnocení ani recenzi, ale o faktické shrnutí funkcionalit, přístupů k správě, možností rozšíření, a nákladových aspektů.

Veškeré informace jsou uvedeny s maximální snahou o přesnost – pokud byste v obsahu našli chybu či neaktuální údaj, budeme rádi za zpětnou vazbu.

FortiGate / FortiClient + FortiCloud:

  • Nové zařízení se musí připojit přes WAN → jinak se neaktivuje ani nenastaví
  • Připojení do Vašeho Fortinet účtu na jejich cloudovém portálu → FortiCloud provisioning
  • Nastavení probíhá z jejich GUI (FortiManager / FortiCloud), ne lokálně
  • Bez internetu: 💥 game over → nepřihlásíte se, nezměníte nic, ani základní policy

➡️ To všechno je vendor lock-in + cloud závislost.

Funguje to hladce, dokud je inet a Fortinet nejede údržbu.

 

🔧 Klasický firewall: OPNsense / pfSense / Proxmox appliance

  • Připojíš přes LAN → máš okamžitý přístup k lokálnímu GUI
  • WAN nastavuješ až po tom, co všechno připravíš → plná kontrola
  • Když se rozbije net nebo DNS, můžeš firewall normálně dál spravovat
  • Nečekáš na žádnou synchronizaci, FortiToken, FortiCloud nebo zamčené firmware

💡 Prostě stará škola, která nechce cloudem řídit tvou bránu do světa.

🤬 Srovnání: FortiGate vs open-source filozofie

Vlastnost FortiGate OPNsense / pfSense
Prvotní nastavení Musí mít WAN + inet Lokální přes LAN (bez inetu)
Závislost na cloudu  FortiCloud + účet  žádná
Offline správa  velmi omezená  plná
Konfigurační přístup Web GUI přes cloud Lokální GUI
Rychlá obnova z backupu Ano, ale přes FortiManager  stačí ZIP, bez licence
Transparentnost  uzavřený firmware  otevřené, zdokumentované
Nervy při výpadku inetu 😱 😎

💬 To je ta digitální pravda: Fortinet je smooth operátor, ale když chceš nezávislost, rychlý zásah a vlastní železo, open-source věci jako OPNsense / pfSense / Proxmox s OPNSense VM jsou bez nervů.

„FortiOS podle analýzy firmware běží na upraveném Linux kernelu. Fortinet veřejně neposkytuje kompletní technickou dokumentaci.“

„Toto porovnání slouží jako technické shrnutí pro zákazníky, kteří hledají vhodné řešení pro svou síťovou infrastrukturu. Uváděné informace vycházejí z veřejně dostupné dokumentace a zkušeností s danými technologiemi.“
„Tento článek nemá za cíl znevažovat žádnou ze značek, ale nabídnout srovnání technických přístupů s důrazem na otevřenost a možnosti přizpůsobení.“

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/14/%f0%9f%a7%a0fortigate-vs-open-source-filozofie-technicke-srovnani/

🧪 ZFS vs vSAN vs vVols – rozdíly v snapshotování, ochraně dat, architektuře

🔹 ZFS (Zettabyte File System)

  • 🧠 Filesystém + volume manager v jednom
  • ✅ Nativní snapshoty, deduplikace, komprese, checksumming
  • 🛡️ Ochrana proti bitrotu (kontrola integrity dat při čtení i zápisu)
  • 🧰 Používá se v TrueNAS, Proxmox, FreeBSD, Linux
  • 🧪 Ideální pro NAS, zálohování, archivaci, VM storage

🔹 vSAN (VMware Virtual SAN)

  • 🧱 Software-defined storage: spojuje disky z ESXi hostů do jednoho datastoru
  • 🧠 Běží v kernelu ESXi → vysoký výkon, nízká latence
  • 🛡️ Podpora FTT (Failures To Tolerate), RAID 1/5/6, checksumy, scrubber
  • ⚠️ Vyžaduje minimálně 2–3 hosty pro HA
  • 🧰 Ideální pro VMware clustery, HCI řešení

🔹 vVols (Virtual Volumes)

  • 📦 VMware technologie pro granularitu storage
  • 🧠 VM disky jsou spravovány jako objekty na storage array
  • 🛠️ Využívá VASA provider, SPBM (Storage Policy-Based Management)
  • ✅ Snapshots, QoS, replikace na úrovni VM
  • ⚠️ Vyžaduje kompatibilní storage (např. NetApp, Dell, HPE)

🧠 Shrnutí rozdílů

Technologie Typ Snapshoty Ochrana dat Správa Vhodné pro
ZFS Filesystém ✅ nativní ✅ bitrot, checksum CLI / GUI NAS, VM storage
vSAN SDS (VMware) ✅ kernel-level ✅ FTT, checksum vSphere GUI VMware clustery
vVols VMware API ✅ storage-level ⚠️ závisí na storage SPBM + VASA Enterprise storage

ZFS vs vSAN vs vVols – snapshotování, datová ochrana, správa

Technologie Typ Snapshoty Ochrana dat Správa Vhodné pro
ZFS Filesystém + volume manager ✅ nativní, okamžité ✅ Bitrot, checksumming CLI + GUI (např. TrueNAS, Proxmox) NAS, VM storage, zálohování
vSAN SDS (Software-defined Storage) ✅ kernel-level ✅ FTT (Failure Tolerance), RAID GUI (vSphere) VMware clustery, HCI
vVols API rozhraní pro granularitu ✅ storage-level ⚠️ záleží na typu storage GUI přes VASA, SPBM Enterprise storage, NetApp/HPE

🔹 Podrobnosti:

  • ZFS: Snapshoty se vytváří na blokové úrovni, deduplikace, komprese, šifrování — ideální pro NAS nebo Proxmox VM disky.
  • vSAN: Využívá disky ESXi hostů jako jeden datový prostor. Běží v kernelu → skvělý výkon. Vyžaduje ale více hostů.
  • vVols: Disky VM jsou objekty na storage poli. Nutný VASA provider a kompatibilní storage (NetApp, Dell, HPE).

🔍 Shrnutí rozdílů

Vlastnost ZFS vSAN vVols
Snapshoty Nativní, instantní VMDK delta soubory Storage-level, přes API
Výkon při IO Vysoký (ZFS ARC, cache) Vysoký (v kernelu) Závisí na storage typu
HA podpora ZFS + cluster + replication Minimálně 3 hosty Závisí na storage backendu
Správa CLI / GUI GUI (vSphere) GUI + SPBM/VASA
Kompatibilita Linux, BSD, Proxmox VMware-only VMware + enterprise storage

💬 Když to shrneme:

  • ZFS je král snapshotů, integrity a spolehlivosti
  • vSAN je stroj na výkon, ale potřebuje cluster a VMware licence
  • vVols je elegantní API řízení storage, ale jen s velkým železem za zády

Broadcom to s VMware pěkně zamíchal, ale já říkám, je to šance pro menší hráče jako Proxmox, TrueNAS SCALE, nebo XCP-ng.

Trh se otevírá, a možná konečně uvidíme hypervizor, co trumfne VMware nejen cenou, ale i přístupem. 🙂

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/14/%f0%9f%a7%aa-zfs-vs-vsan-vs-vvols-rozdily-v-snapshotovani-ochrane-dat-architekture/

🐳 LXC vs Docker vs Kubernetes – co to je a jak to funguje

V tomhle se občas začínající ajtáčci ztrácí, tak rychlý přehled co je co…

🔹 LXC (Linux Containers)

  • 🧠 OS-level virtualizace: běží přímo na Linux kernelu
  • 🧱 Vytváří izolované prostředí (namespace, cgroups), podobné VM, ale bez vlastního kernelu
  • 🛠️ Používá se pro běh celých OS (např. Ubuntu v kontejneru)
  • 👨‍🔧 Vhodné pro adminy, co chtějí mít plnou kontrolu nad prostředím

🔹 Docker

  • 📦 Aplikační kontejnerizace: běží jeden proces (např. web server) v izolovaném prostředí
  • 🧰 Má vlastní runtime (runc, dříve libcontainer)
  • 🛒 Docker Hub = obrovský repozitář hotových image
  • 🧑‍💻 Ideální pro vývojáře, DevOps, CI/CD

🔹 Kubernetes

  • 🚀 Orchestrace kontejnerů: spravuje, škáluje, restartuje kontejnery
  • 🧬 Funguje nad Dockerem, containerd, nebo jiným runtime
  • 📡 Řídí clustery, load balancing, storage, síť, monitoring
  • 🧠 Vhodné pro produkční nasazení, mikroservisní architektury
Technologie Typ izolace Správa kernelu Orchestrace Vhodné pro Klíčové vlastnosti
LXC OS-level (light) Sdílí kernel Adminy, kteří chtějí OS v kontejneru Běží jako VM bez overheadu, plný přístup k systému
Docker App-level Sdílí kernel ⚠️ (Swarm) Vývojáři, mikroservisy Jeden proces, rychlý start, obrovský ekosystém
Kubernetes Clusterová orchestrace N/A Produkční nasazení, HA systémy Řídí kontejnery, scaling, dostupnost, autoheal

🔹 Příklady použití:

  • LXC: Ubuntu v kontejneru pro testování, full OS bez overheadu
  • Docker: Apache server + MySQL v oddělených kontejnerech
  • Kubernetes: Webový cluster + autoscaling + monitoring

🧠 Kubernetes může běžet nad Dockerem, containerd nebo třeba v LXC kontejneru v Proxmoxu. Proxmox zvládne LXC nativně, Docker se rozjede v LXC nebo VM, a K3s (lightweight Kubernetes) se doinstaluje jednoduše.

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/14/%f0%9f%90%b3-lxc-vs-docker-vs-kubernetes-co-to-je-a-jak-to-funguje/