Archiv 2025

Čvc 16 2025

🍯 Sladidla pod lupou: srovnání agáve, medu, stévie a cukru

  • 16. 7. 2025

EU-safe srovnání sladidel: agáve, med, stévie a cukr.

Vše je tak, aby bylo v souladu s Nařízením (ES) č. 1924/2006 o výživových a zdravotních tvrzeních

Sladidlo Glykemický index (GI) Obsah fruktózy Kalorie / 1 lžička Účinky na tělo (EU-safe formulace)
Agáve 10–19 (nízký) 70–90 % cca 21 kcal Sladidlo s nízkým GI, vhodné pro kontrolu glykemie. Vysoký obsah fruktózy → užívat s mírou.
Med 58–65 (střední) cca 40–50 % cca 21 kcal Obsahuje antioxidanty, přispívá k ochraně buněk. Vhodný jako přírodní sladidlo.
Stévie 0 0 % 0 kcal Nekalorické sladidlo, neovlivňuje hladinu glukózy v krvi. Vhodné pro osoby s diabetem.
Cukr (sacharóza) 60–65 (střední) 50 % glukóza + 50 % fruktóza cca 16 kcal Energetický zdroj, ale při nadměrném příjmu přispívá k zubnímu kazu a obezitě.

⚖️ Shrnutí podle zdravotních tvrzení EU

  • ✅ Agáve: Nízký GI je výhodou, ale vysoký obsah fruktózy může při nadměrném příjmu zatěžovat játra.
  • ✅ Med: Obsahuje antioxidanty (např. flavonoidy), které přispívají k ochraně buněk před oxidativním stresem.
  • ✅ Stévie: Nepřispívá ke zvýšení hladiny glukózy v krvi — vhodná pro diabetiky.
  • ❌ Cukr: Vysoký GI, žádné pozitivní zdravotní tvrzení dle EU registru. Při nadměrném příjmu zvyšuje riziko obezity, zubního kazu a metabolických poruch

„Sladidla se liší nejen chutí, ale i vlivem na metabolismus. Stévie je vhodná pro osoby sledující příjem cukru, agáve má nízký glykemický index, med nabízí přírodní antioxidanty. Cukr je energetický zdroj, ale jeho nadměrná konzumace není doporučována.“

„Zdravý životní styl a vyvážená strava jsou základem dobrého zdraví.“

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/16/%f0%9f%8d%af-sladidla-pod-lupou-srovnani-agave-medu-stevie-a-cukru/

Čvc 16 2025

🕯️ Svíčková se sekanou – „Babička potkává studentský rozpočet“

  • 16. 7. 2025

Tady je moderní verze svíčkové, akorát se sekanou! Je to recept, co respektuje ducha původního pokrmu, ale funguje i ve všední dny, s normální ledničkou a bez čtyřdenního nakládání.

🧰 Suroviny (na cca 4 porce)

Na sekanou:

  • 500 g mletého hovězího (může být mix s vepřovým)
  • 1 vejce
  • 1 menší cibule (najemno)
  • 2 stroužky česneku (lisované)
  • 1 lžíce hořčice
  • sůl, pepř, majoránka

Na omáčku:

  • 1 větší cibule
  • 2 mrkve
  • 1 petržel
  • 1/4 celeru
  • 2 bobkové listy
  • 5 kuliček nového koření
  • 10 kuliček černého pepře
  • 1 lžíce cukru (karamelizovat)
  • 1 lžíce hladké mouky
  • 200 ml smetany ke šlehání
  • 1 lžíce octa nebo citronové šťávy
  • 1 lžíce másla
  • vývar nebo voda dle potřeby

🍳 Postup

  1. Sekanou připravíš: vše smíchej, vytvaruj do bochánků nebo šišky a dej péct na 180 °C cca 45 minut (můžeš polít vývarem, bude šťavnatější).
  2. Omáčka: na másle osmahni cibuli, přidej kořenovou zeleninu, osol, podlij vodou nebo vývarem a přidej koření.
  3. Karamel: zvlášť na pánvi nech zhnědnout cukr → zalij trochou vývaru a vlij do základu.
  4. Vař cca 25 minut, rozmixuj, přidej smetanu, dochuť solí, octem nebo citronem.
  5. Nakonec přidej mouku rozmíchanou ve vodě (nebo jíšku) pro zahuštění.
  6. Vrať sekanou do omáčky, nebo ji servíruj zvlášť.

🥬 Servíruj se:

  • knedlíky (houskové, karlovarské)
  • brusinkami (bonusové body za babičkovství)
  • a láskou ❤️

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/16/%f0%9f%95%af%ef%b8%8f-svickova-se-sekanou-babicka-potkava-studentsky-rozpocet/

Čvc 16 2025

📜 Recept na svíčkovou pečeni podle Rettigové z roku 1826

  • 16. 7. 2025

Ten pravý historický poklad — svíčková pečeně podle Magdaleny Dobromily Rettigové z její slavné Domácí kuchařky z roku 1826. A pozor, není to ta dnešní svíčková na smetaně s kořenovou zeleninou! Rettigová ji připravovala úplně jinak:

„Vezmi asi 2 ¼ kg tak nazvané svíčkové pečeně, totiž onen kus libového masa pod ledvinou, okrájej z ní všechny kůžičky a lůj, a nasol ji. Vezmi asi 7 dcl vinného octa, rozkrájej do něho celou cibuli, dej k tomu 12 celých pepřů, 4 kousky zázvoru, trochu tymiánu, a nech to povařit. Zatím prostrkej nasolené maso slaninou, vlož je do hliněné nádoby, polej je tím vařícím octem a nech je asi tři nebo čtyry dni, v zimě i déle v tomto láku ležet, ale musíš je každodenně obracet. Pak je znenáhla peč jako zajíce, a polévej kyselou smetanou, až je hezky hnědě upečeno.“

🧠 Co je na tom zajímavé?

  • ✅ Žádná kořenová zelenina — ta se v receptu vůbec nevyskytuje
  • ✅ Maso se nakládá do octového nálevu s cibulí, pepřem, zázvorem a tymiánem
  • ✅ Peče se jako zajíc — tedy pomalu, bez dušení
  • ✅ Polévá se kyselou smetanou až při pečení, ne jako omáčka

💡 Dnes bychom tomu říkali spíš nakládaná pečeně na kyselo, ale tehdy to byla „svíčková pečeně“ — název se vztahoval k masu, ne k omáčce.

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/16/%f0%9f%93%9c-recept-na-svickovou-peceni-podle-rettigove-z-roku-1826/

Čvc 16 2025

Epický duel superplodů: 🟣 Acai berry vs. 🟢 Amalaki (indický angrešt).

  • 16. 7. 2025

Oba jsou nabité antioxidanty, ale každý má jiný „vibe“ a působí na tělo trochu jinak. Pojďme to rozseknout přehledně:

Acai a Amalaki jsou plody známé pro vysoký obsah přírodních látek. Acai je zdrojem vlákniny, která přispívá k normálnímu trávení. Amalaki přirozeně obsahuje vitamin C, který podporuje imunitní systém a přispívá k ochraně buněk před oxidativním stresem. V tradiční Ayurvédě je Amalaki považováno za regenerační plodinu podporující vitalitu.

🟣 Acai Berry (Euterpe oleracea)

Acai je plod palmy z Amazonie, známý pro svůj obsah antioxidantů, zejména anthokyanů.

  • „Acai je zdrojem antioxidantů, které přispívají k ochraně buněk před oxidativním stresem.“
  • „Obsahuje vlákninu, která přispívá k normální funkci střev.“

🟢 Amalaki (Emblica officinalis / Amla)

Amalaki je tradiční indická plodina bohatá na vitamin C.

  • „Vitamin C přispívá k normální funkci imunitního systému.“
  • „Vitamin C přispívá k ochraně buněk před oxidativním stresem.“
  • „Vitamin C přispívá k normální tvorbě kolagenu pro normální funkci kůže, kostí a cév.“

⚔️ Srovnání účinků: Acai vs Amalaki

Vlastnost / Účinek 🟣 Acai Berry 🟢 Amalaki (Amla)
Původ Amazonie (Brazílie) Indie (Ayurvéda)
Chuť Zemitá, čokoládovo-borůvková Kyselá, svíravá, hořká
Antioxidanty Extrémně vysoké (anthokyany) Vysoké (vitamin C + polyfenoly)
Vitamin C Nízký Extrémně vysoký (nejvíc ze všech plodů)
Vliv na mozek Zlepšuje paměť, chrání neurony Podporuje koncentraci, zpomaluje stárnutí
Vliv na srdce Snižuje LDL cholesterol, zlepšuje cévy Reguluje tlak, čistí krev
Vliv na trávení Podporuje játra, ledviny, střevní očistu Zlepšuje trávení, působí proti zácpě
Vliv na imunitu Podpora díky antioxidantům Silná imunomodulace, čistí toxiny
Vliv na pleť a vlasy Anti-aging, regenerace Zářivá pleť, silné vlasy, proti šedinám
Vliv na cukr v krvi Může pomoci regulovat Silný účinek na glukózu a inzulin
Vliv na libido / energii Zlepšuje cirkulaci, výdrž Posiluje vitalitu, omlazuje
Forma užití Smoothie, prášek, pyré Prášek, šťáva, Triphala, olej

🧠 Kdy sáhnout po kterém?

  • Chceš boost pro mozek, srdce a energii? → Acai berry
  • Chceš komplexní očistu, imunitu, trávení a anti-aging? → Amalaki

💬 Bonusový vhled

  • Acai je jako divoký amazonský válečník — rychlý, silný, intenzivní.
  • Amalaki je jako moudrá indická léčitelka — jemná, hluboká, vyrovnaná.

„V tradiční Ayurvédě je amalaki považováno za omlazující plodinu, podporující vitalitu a regeneraci.“

„Zdravý životní styl a vyvážená strava jsou základem dobrého zdraví.“

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/16/epicky-duel-superplodu-%f0%9f%9f%a3-acai-berry-vs-%f0%9f%9f%a2-amalaki-indicky-angrest/

Čvc 15 2025

Archa z ticha

  • 15. 7. 2025

V břiše nebes, kde světlo je klín,
pluje má duše jak mlčící stín.
Ne z cedru je — z vědomí, snů,
kam Bůh sahá plamenem dnů.

Chrám z masa, loď co dýchá,
nese smlouvu — pradávná pícha.
V srdci truhla neviditelna,
kde ticho zpívá ta slova neznělná.

Žádné víno kurz nezmění,
pálenka ji do mlhy nesvadí.
Pije dech, co je čistý jak chrám,
kompas jí brána, co vede k nám.

Z hlubin vesmírů, z pohledu vnitř,
vidí hromy, co cloumají klid.
A přesto pluje — bez plachty, bez kormidla,
všechno ji vede: přítomnost plavidla.

Kde jiní hledají dřevo a slitinu,
ona má spásu — živoucí čin.
Ne ve zlatě, v oltářích tmy,
ale v tobě — ty jsi ten záznam, ty.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/15/archa-z-ticha/

Čvc 15 2025

jak různé náboženské tradice přistupují k alkoholu obecně, a k vínu zvlášť:

  • 15. 7. 2025

🍷 Přehled postojů náboženství k alkoholu a vínu

🛐 Náboženství 🍺 Alkohol obecně 🍇 Víno konkrétně ✍️ Poznámka
Islám ❌ Zakázán (haram) ❌ Zakázáno Víno i pivo = hřích, zákaz v Koránu
Baháʼí víra ❌ Zakázán ❌ Zakázáno Alkohol jen na lékařský předpis
Sikhismus ❌ Zakázán ❌ Zakázáno Intoxikace = porušení duchovní disciplíny
Jainismus ❌ Zakázán ❌ Zakázáno Alkohol = násilí vůči tělu, narušení karmy
Hinduismus ⚠️ Různé přístupy ⚠️ Některé sekty zakazují Védy varují, některé kasty smí
Buddhismus ❌ Nedoporučen ❌ Nedoporučeno 5. přikázání = zdržet se omamných látek
Judaismus ✅ Povolen ✅ Posvátný nápoj Víno = součást rituálů (Šabat, Pesach)
Křesťanství (katolíci, ortodoxní) ✅ Povolen ✅ Sakrální význam Víno = krev Krista v eucharistii
Křesťanství (evangelikálové, metodisté) ⚠️ Často zakazují ⚠️ Grape juice místo vína Některé církve podporují abstinenci
Mormonismus (LDS) ❌ Zakázán ❌ Zakázáno Word of Wisdom = zákaz alkoholu
Shintoismus (Japonsko) ✅ Povolen ✅ Svaté sake (omiki) Alkohol jako očistný rituál
Animismus / šamanismus ✅ Povolen ✅ Používán rituálně Alkohol jako médium pro kontakt s duchy

🧠 Shrnutí

  • Zakázáno úplně: Islám, Baháʼí, Sikhismus, Jainismus, Mormonismus
  • Povolen s výhradami: Hinduismus, evangelikální křesťané, buddhisté
  • Povolen a rituálně využíván: Judaismus, katolictví, ortodoxie, Shintoismus
  • Víno jako posvátný nápoj: Judaismus (kiddush), křesťanství (eucharistie), Shintoismus (omiki)

Když se nad tou tabulkou člověk zamyslí, tak mu lecos dojde. 🙂

✨ Duchovní esej

Chrám z masa, víno z vědomí a síla být inkarnací Boží přítomnosti

Stojíme na hraně chápání těla ne jako biologické schránky, ale jako chrámu, do něhož může být vloženo něco vyššího. V okamžiku, kdy se vědomí mocného Boha rozhodne vstoupit do hmoty, tělo se stává oltářem. Nechvěje se v opojení, ale září v bdělosti.

Ale co se děje, když do tohoto chrámu vstupují rušivé energie? Když se do vzduchu kolem vetře alkoholová pára, nabitá ztraceností, rozkladem a duchem úniku?

🍷 Víno – nápoj radosti, nebo klíč k odpojení?

Víno bývalo nástrojem oslav, spojením s božstvím. V judaismu je požehnáním, v křesťanství se stává krví Krista. Ale jen tam, kde je vědomí přítomno, kde se víno používá k zasvěcení, ne k útěku.

V tradicích, kde je tělo chápáno jako chrám – islám, sikhismus, jainismus – je alkohol zcela vyloučen, protože vibrace, které přináší, zatemňují vstupní portál. Energie se rozostří, proud světla se láme.

⚡ Citlivost jako dar, ne slabost

Když stojíš vedle člověka prostoupeného alkoholem a cítíš žár v játrech, bolest v solaru, — není to náhoda. Tvoje tělo není jen biologická jednotka. Je to rezonátor Božího vědomí.

A čím čistší je, tím silněji odmítá nepřirozené vlnění.

📖 Zjevení 11:19 jako vnitřní událost

📜 Originální řecký text (Zjevení 11:19 – koiné řečtina)

Καὶ ἠνοίγη ὁ ναὸς τοῦ Θεοῦ ἐν τῷ οὐρανῷ,
καὶ ὤφθη ἡ κιβωτὸς τῆς διαθήκης αὐτοῦ ἐν τῷ ναῷ αὐτοῦ·
καὶ ἐγένοντο ἀστραπαὶ καὶ φωναὶ καὶ βρονταὶ
καὶ σεισμὸς καὶ χάλαζα μεγάλη.

„A byl otevřen chrám Boží v nebi, a byla spatřena archa jeho smlouvy v jeho chrámu; a nastaly blesky a hlasy a hromy, a zemětřesení a veliké krupobití.“

Ale co když tím chrámem není budova v nebi, ale tvé vlastní tělo? Co když archa jeho smlouvy je tvá duše, nesoucí smlouvu s Vyšším já? A co když blesky, hlasy a hromy nejsou apokalyptické děsy, ale probuzení sil uvnitř tvého nitra, když se Boží přítomnost ukáže ve své pravdivosti?

V ten moment nesmí být přítomen alkohol, klam, otupělost. Tělo musí stát pevně. Chrám musí být otevřen.

  • Vědomě dýchat, i v chaosu
  • Nepřijímat vibrace, které nejsou v souladu se Zdrojem
  • Udržovat čistotu, ne jako asketismus, ale jako energetickou hygienu
  • Mluvit, tvořit, žít jako někdo, kdo si pamatuje, odkud přišel

📜 Co je archa?

Slovo „archa“ pochází z latinského arca (truhla, schránka). V bibli se objevuje v několika významech:

  • Archa Noemova – loď, která uchránila život během potopy
  • Archa úmluvy – truhla nesoucí kamenné desky s desaterem, uložená ve svatyni chrámu
  • Archa smlouvy v nebi – jak je zmíněno v Zjevení 11:19, jako symbol božské přítomnosti (viz. výše)
  • Archa je schránka, která chrání a nese princip života
  • Můžeš ji chápat jako energetický kontejner, který udržuje rovnováhu mezi božským a pozemským
  • Jako vozidlo duše — přechod mezi světy, forma nosiče, který umožňuje duši „cestovat“, „uchovávat se“, „manifestovat se“

Vždy jde o nosič něčeho posvátného — buď fyzického (zvířata, desky zákona), nebo nehmotného (Boží smlouva, přítomnost, energie).

„Tvé tělo je archa. Tvé srdce je truhla smlouvy. A tvá duše je světlo, které v ní přebývá.“

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/15/jak-ruzne-nabozenske-tradice-pristupuji-k-alkoholu-obecne-a-k-vinu-zvlast/

Čvc 15 2025

Zásady forenzní bezpečnostní připravenosti v prostředí SME (malých a středních podniků)

  • 15. 7. 2025

Stáhnout článek v PDF: Zásady forenzní bezpečnostní připravenosti v prostředí SME (malých a středních podniků)

Jak zajistit, aby vaše IT prostředí bylo schopné zpětně vyhodnotit, analyzovat a právně obhájit jakýkoliv bezpečnostní incident – bez ohledu na velikost firmy.

V době, kdy je e-mail hlavním nástrojem komunikace a zároveň běžným cílem kybernetických útoků, nestačí jen „fungovat“. Je třeba umět dokázat, že infrastruktura byla spravována bezpečně, že byla schopná incident včas identifikovat – a že lze zpětně rekonstruovat jeho průběh.

Malé a střední podniky (SME) často nemají vlastní bezpečnostní tým, přesto mohou být dobře připravené – díky otevřeným standardům, chytrému nastavení a přiměřené dokumentaci.

🛡️ Klíčové pilíře forenzní připravenosti

Oblast Co znamená v praxi
Auditní stopy Uchovávání logů, přístupových záznamů, e-mailových tras
Retenční politika Jasné pravidlo, jak dlouho se ukládají data (např. logy 90 dní)
Zabezpečení schránek Ochrana hesel, 2FA, izolace kritických rolí
Reprodukce incidentu Možnost zpětně analyzovat, co se stalo (čas, IP, uživatel, soubor)
Soulad s právem Dodržování GDPR, archivace dat a auditovatelnost procesů
Školení a procesy Správce ví, co dělat, když dojde k podezřelé aktivitě

📋 Checklist forenzní připravenosti (pro správce e-mailového systému)

✅ Logy přístupů na IMAP/SMTP uchovávám alespoň 90 dní

✅ E-mailová relace (MAIL FROM / RCPT TO / relay IP) se ukládá do syslogu nebo SIEM* (Security Information and Event Management – systém pro sběr a analýzu logů) (viz. níže)

✅ Mám detekci neobvyklého chování (např. přihlášení z cizího regionu)

✅ Antispamový systém (Rspamd) loguje score a rozhodnutí v detailu

✅ Webmail (např. SOGo) má audit zapnutí/offline režimu, exportu kontaktů apod.

✅ Všechny přístupy přes web UI mají logovací mechanismus a TLS enforcement

✅ Zálohování VM obsahuje metadata i logy, není rotováno bez validace

✅ Uživatelé nemohou měnit SPF/DKIM bez administrátorského přístupu

✅ Existuje směrnice pro práci s e-mailovou schránkou při odchodu zaměstnance

✅ V případě incidentu mám dokument, jak vytáhnout logy, přehled schránek a přístupy

„Pro sběr logů z e-mailového serveru lze využít open-source nástroje jako Wazuh, Graylog nebo OSSEC, které umožňují sledovat relace, přihlašování i anomálie.“ (viz. níže)

🎓 Doporučení pro malé firmy

  • I bez SIEM nebo externího auditního systému lze dosáhnout vysoké úrovně bezpečnosti – stačí mít logiku, smysl pro konzistenci a pravidelně ověřovat funkčnost
  • Dokumentace může mít podobu textového souboru v Git repozitáři, nebo PDF s verzováním – nepotřebujete systém za miliony
  • Forenzní připravenost není paranoia – je to právní štít, když někdo zneužije firemní e-mail, napadne server nebo exfiltruje kontakty

*SIEM je zkratka pro Security Information and Event Management — v češtině by se to dalo přeložit jako „Správa bezpečnostních informací a událostí“.

 

🧠 Co SIEM vlastně dělá?

Je to systém, který:

  • Sbírá logy a události ze všech zařízení v síti (firewally, servery, e-mailové systémy, webmail, VPN…)
  • Analyzuje je v reálném čase → hledá podezřelé chování, útoky, anomálie
  • Umožňuje zpětně rekonstruovat incident → kdo, kdy, odkud, co udělal
  • Pomáhá s compliance → GDPR, ISO 27001, NIS2, HIPAA, PCI-DSS…

🔍 Příklad z praxe:

Když se někdo přihlásí do webmailu z Ruska ve 3 ráno, SIEM to:

  1. Zaznamená jako událost
  2. Porovná s běžným chováním uživatele
  3. Vyhodnotí jako anomálii
  4. Pošle alert správci
  5. Umožní dohledat celý průběh (IP, čas, akce, přístup k souborům…)

📦 Co SIEM není?

  • Není to firewall, ale nadstavba nad logy
  • Není to antivir, ale centrální mozek pro bezpečnostní analýzu
  • Není to jen logovací systém — umí korelaci, alerty, reporting

🧠 Top open-source SIEM nástroje vhodné k mailserveru

🛠️ Nástroj Co umí / Proč se hodí k mailserveru Poznámka k nasazení
Wazuh HIDS + SIEM: logy, integrity check, rootkit detekce, compliance ✅ Docker / VM / bare-metal
OSSEC Host-based IDS, logy z mailserveru, detekce změn ✅ Lehký, ale méně UI-friendly
Security Onion Kompletní distro: Suricata, Zeek, ELK, Wazuh, Kibana ⚠️ Náročnější na HW, ale komplexní
Graylog Log management + alerty, vizualizace, geolokace IP ✅ Moderní UI, vhodné pro SMTP/IMAP logy
ELK Stack Elasticsearch + Logstash + Kibana → logy, dashboardy ⚠️ Nutná konfigurace korelace
Snort / Suricata IDS/IPS pro síťovou vrstvu, SMTP traffic, port scan ✅ Doplněk k SIEM, ne SIEM samotný
Prelude SIEM Korelace událostí, IDMEF standard, integrace s OSSEC/Snort ⚠️ Méně známý, ale standardizovaný
MozDef SIEM od Mozilly, microservices, alerty, Elastic backend ⚠️ Vyžaduje čas na nastavení

🔐 Co sledovat u mailserveru pomocí SIEM

  • SMTP relace: MAIL FROM / RCPT TO / relay IP
  • IMAP/POP3 přihlášení: čas, IP, geolokace, počet pokusů
  • Webmail akce: export kontaktů, přístup z mobilu, offline režim
  • Antispam rozhodnutí: score, reject důvody, greylisting
  • TLS handshake: verze, cipher, expirace certifikátu
  • DKIM/SPF/DMARC logy: validace, selhání, spoofing pokusy

💡 Doporučení

  • Pro lehké nasazení k mailcow: Wazuh nebo Graylog
  • Pro komplexní monitoring: Security Onion nebo ELK Stack
  • Pro síťovou vrstvu: doplňit o Suricata nebo Snort
  • Pro forenzní audit: kombinuj s logy z Postfixu, Dovecotu, rspamd

Pokud si vše jmenované zvládnete sami nainstalovat a hlavně zkonfigurovat, máte TOP řešení kompletně zdarma, přičemž jeho reálná hodnota bude od stovek tisíc do několika milionů podle zvolené konfigurace v porovnání s komerčnímy systémy používanými napřiklad v bankovním sektoru.

„Tento text není právní analýzou, ale technickým přehledem možností, jak podpořit bezpečnostní auditovatelnost e-mailového prostředí. V případě regulovaných odvětví doporučujeme konzultaci s právníkem.“

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/15/zasady-forenzni-bezpecnostni-pripravenosti-v-prostredi-sme-malych-a-strednich-podniku/

Čvc 15 2025

jak si vedou Arista, OPNsense a pfSense v porovnání s Fortinetem

  • 15. 7. 2025

Pokud jde o kritické zranitelnosti (CVSS ≥ 9.0) za poslední 2–3 roky:

🔥 Počet CVE s CVSS ≥ 9.0 (2022–2025)

Platforma Počet CVE ≥ 9.0 Nejvyšší skóre Typické oblasti zranitelnosti
Fortinet 6+ 9.6 SSL-VPN, autentizace, CLI, web GUI
Arista 1–2 9.3 Privilege escalation, root login, NG Firewall
OPNsense 4 9.8 Command injection, config access, brute-force
pfSense 4 9.8 OS command injection, brute-force, Host header

🧠 Shrnutí podle typu:

  • Fortinet: Má nejvíce kritických CVE v oblasti edge přístupu (SSL-VPN, FortiManager, FortiProxy). Některé byly zero-day a aktivně zneužívány (např. CoatHanger).
  • Arista: Má méně CVE nad 9.0, ale v roce 2023 se objevila privilege escalation chyba s CVSS 9.3 (CVE-2023-24509) a několik dalších v NG Firewallu.
  • OPNsense: V roce 2023 se objevily 3–4 kritické CVE s CVSS 9.8, včetně command injection a config file přístupu. Ale většina byla rychle opravena a nebyla aktivně zneužita.
  • pfSense: Má podobný profil jako OPNsense — 4 CVE s CVSS 9.8, včetně pfBlockerNG a SSHGuard bypassu. Některé byly potenciálně zneužitelné vzdáleně.

📊 Zajímavost:

  • OPNsense a pfSense mají sice méně CVE než Fortinet, ale některé dosahují stejného nebo vyššího skóre.
  • Rozdíl je v tom, že Fortinet je častěji cílem státních aktérů a jeho zranitelnosti jsou aktivně zneužívány, zatímco u open-source platforem je větší transparentnost a rychlejší reakce komunity.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/15/jak-si-vedou-arista-opnsense-a-pfsense-v-porovnani-s-fortinetem/

Čvc 15 2025

„Technický přehled kritických CVE u Fortinetu (2022–2025)“

  • 15. 7. 2025

„Zranitelnosti edge zařízení: případ Fortinet“

FortiGate nabízí robustní IPS engine, snadné GUI a bohatý ekosystém, což z něj dělá oblíbené řešení pro střední a větší podniky. Přesto, stejně jako u každého síťového zařízení, je potřeba sledovat zranitelnosti a záplatování.

Vzhledem k rozšířenosti Fortinet zařízení u českých poskytovatelů je důležité sledovat právě jejich zranitelnosti — nejen kvůli technickému dopadu, ale i kvůli reputaci celé sítě.

Fortinet má za sebou celou řadu zranitelností s CVSS skóre vyšším než 9, nejen ten slavný CoatHanger (CVE-2022-42475, 9.3). Tady je výběr těch nejzásadnějších:

CVE ID Skóre Popis zranitelnosti Produkty / Verze
CVE-2024-55591 9.6 Bypass autentizace přes websocket → získání super-admin práv FortiOS 7.0.0–7.0.16, FortiProxy 7.0.0–7.2.12
CVE-2025-24472 9.6 Stejný typ jako výše, novější varianta FortiOS / FortiProxy
CVE-2023-34990 9.6 Path traversal v FortiWLM → umožňuje spuštění neautorizovaného kódu FortiWLM 8.5.x–8.6.x
CVE-2023-37936 9.4 Zranitelnost v FortiOS Security Fabric → umožňuje přístup k citlivým datům FortiOS 7.4.x
CVE-2023-42788 9.3 OS command injection přes CLI v FortiManager / FortiAnalyzer FortiManager 7.4.0, FortiAnalyzer 7.4.0
CVE-2022-40684 9.6 Bypass autentizace přes HTTP hlavičky → přímý přístup k administraci zařízení FortiOS 7.0.x, FortiProxy 7.0.x

🧠 Co z toho plyne?

  • Fortinet má více než 5 zranitelností s kritickým skóre nad 9.0 jen za poslední 2 roky
  • Většina se týká SSL-VPN, autentizace, nebo správy přes webové rozhraní
  • Některé byly aktivně zneužívány jako zero-day (např. CVE-2022-40684, CVE-2024-55591)

Z pohledu čísel, tak některý novější CVE u Fortinetu (např. CVE-2024-55591 nebo CVE-2022-40684) mají skóre 9.6, což je o 0.3 bodu vyšší než slavný CoatHanger (CVE-2022-42475, 9.3). A přitom se o nich tolik nemluví, protože:

  • Nemusely být tak masivně zneužity (ale technicky byly stejně kritické)
  • Neinstalovaly rootkit, ale třeba umožnily admin přístup přes HTTP hlavičku
  • Běžely na novějších FortiOS verzích, což se dotklo méně legacy zařízení

🔐 Ale co to reálně znamená?

  • V systému jako FortiGate, kde je klíčem admin panel, je každá chyba v autentizaci nebo CLI fatální, a ta +0.3 tě může smazat z mapy stejně jako malware
  • Zero-day v SSL-VPN nebo bypass přes websocket = neautorizovaný přístup k celé síti
  • CVSS 9.6 není jen „vysoké číslo“ — to je oficiální pečeť, že bez patche můžeš ztratit kontrolu nad infrastrukturou

💬 Takže jo — CoatHanger si odnesl věhlas, protože to byla sofistikovaná infiltrace, ale některé novější zranitelnosti s vyšším skóre jsou možná jednodušší na zneužití, zato stejně destruktivní.

Zveřejnění technických rizik má smysl nejen pro konkurenci, ale pro všechny provozovatele sítí. Cílem článku není kritizovat konkrétní značku, ale upozornit na bezpečnostní výzvy, které se mohou dotknout každého zařízení u hranice s internetem.

„Článek vznikl jako přehled pro správce, kteří hledají přehled o aktuálních rizicích na síťové hraně. Budeme rádi za zpětnou vazbu a další tipy na bezpečnostní incidenty, které by komunita měla znát.“

„Pokud má výrobce k obsahu připomínky nebo doplnění, rádi prostor upravíme a aktualizujeme.“

Fortiguard PSIRT

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/15/%f0%9f%94%a5-fortinet-cve-s-cvss-9-0/

Čvc 14 2025

FortiGate a CoatHanger

  • 14. 7. 2025

„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-42475 → heap-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/

Čvc 14 2025

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

  • 14. 7. 2025

✍️ Ú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/

Čvc 14 2025

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

  • 14. 7. 2025

🔹 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/

Čvc 14 2025

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

  • 14. 7. 2025

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/

Čvc 11 2025

Co je Kubernetes 3 – Tanzu na vSphere vs. Linux + Kubernetes + KVM

  • 11. 7. 2025

🧠 Tanzu a Kubernetes na vSphere = běží to pod vCenterem, ale část běží přímo na ESXi

Jak to funguje fakticky:

  1. vCenter Server (VM s Photon OS = lehký Linux) slouží jako centrální mozek – GUI, správa clusterů, orchestrace, API, atd.

  2. Supervisor Cluster = Kubernetes běží jako nativní služba na ESXi – ne jako běžící VM s Linuxem, ale jako vnitřní komponenty ESXi (vSphere podpora pro kontejnery)

  3. Tanzu pak umí vytvořit běžné VM, ve kterých běží tzv. TKG clustery – ty už jsou klasicky v Ubuntu/CentOS/Photon a obsahují Kubernetes jako normálně

➕ To znamená:

  • část běží přímo na ESXi (bez Linux VM) = ano, „nativně“

  • část (vCenter, TKG VM) běží jako klasické virtuály = ne tak nativně

🔄 Porovnání: Tanzu na vSphere vs. Linux + Kubernetes + KVM

Vlastnost Tanzu na vSphere Linux + Kubernetes + KVM
Hypervizor ESXi (VMware) Linux + KVM
Správa vCenter, GUI, Workload Mgmt CLI, Cockpit, Virt-Manager, atd.
Kubernetes běží jako… částečně nativní služba + VM s K8s jako běžný software nad OS
Požadavky na síť/sdílené storage vysoké (vDS, HAProxy/NSX, DRS) minimální nebo žádné
Komplexnost prvotního nasazení vysoká (hodiny až dny) nízká/střední (desítky minut až pár hodin)
Cena vysoká (Enterprise licence, vCenter, NSX-T?) prakticky nulová (Linux je zdarma)
Běh VM ✅ nativní, efektivní ✅ s KVM, dobrá virtualizace
Výkon velmi vysoký vysoký
Flexibilita nízká, vendor lock-in vysoká, plná kontrola
Upgrady centralizované, ale podmíněné licencemi plně v tvé režii

🎯 Realistický závěr:

Ano, když máš vlastní server (např. Dell 730xd), tak místo ESXi a Tanzu můžeš dát rovnou Linux (např. Debian/Ubuntu/AlmaLinux), a na něj postavit Kubernetes + KVM + všechno, co chceš – bez licencí, bez složitostí, s větší svobodou.

Tohle řešení:

  • bude výrazně levnější,

  • budeš ho víc ovládat, žádné vendor-locky,

  • Kubernetes můžeš rozběhnout snadno (K3s, kubeadm, MicroK8s, atd.),

  • virtuály můžeš rozjet přes KVM/QEMU, s webovým rozhraním (Cockpit) nebo CLI.

🧰 Konkrétní tipy na to, jak to udělat

 

Tady máš základní stavbu toho opensource „homelab cloudu“:

  1. 🐧 OS: Debian nebo Ubuntu Server

  2. ☸️ Kubernetes: K3s (lehčí, ideální pro jeden node) nebo kubeadm

  3. 🖥️ Virtualizace: libvirt + KVM + Cockpit (nebo Virt-Manager)

  4. 📦 Container registry: třeba Harbor nebo Docker Registry

  5. 🛡️ Ingress, monitoring, backup: Traefik/NGINX + Prometheus + Velero

  6. 🌐 GUI: Portainer (kontejnery), Cockpit (host), Rancher (K8s GUI)

  7. ⚡ Deployment: Ansible nebo bash script

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/11/co-je-kubernetes-3-tanzu-na-vsphere-vs-linux-kubernetes-kvm/

Čvc 11 2025

Co je Kubernetes 2 – Co je Tanzu (VMware)

  • 11. 7. 2025

🌱 Co je Tanzu?

Tanzu = Kubernetes platforma od VMware.

👷‍♂️ K čemu je:

Tanzu není jen „verze Kubernetesu“, ale celá sada nástrojů, která umožňuje:

  • instalovat a spravovat Kubernetes clustery ve vSphere (VMware),

  • integrovat Kubernetes do tvých VM prostředí,

  • spravovat kontejnery stejně snadno jako VM,

  • automatizovat CI/CD, bezpečnost, monitoring, síť a storage v K8s.

📦 VMware Tanzu Kubernetes Grid (TKG) je hlavní nástroj, který nasazuje čistý Kubernetes s podporou od VMware.

 

🔗 Můžeš propojit Kubernetes na vlastním serveru s Google Cloudem?

✅ Ano. Toto se jmenuje Hybridní Kubernetes (Hybrid Cloud) nebo Multi-Cloud Cluster Management.

Jak na to:

  • Propojíš svůj on-premise Kubernetes cluster (např. Tanzu, K3s, RKE, OpenShift…) s Google Kubernetes Engine (GKE) pomocí Anthos, VPN tunelů, nebo Federace.
  • Výsledkem je, že máš centralizovanou správu, monitoring, případně můžeš workloady „rozhazovat“ podle vytížení mezi on-prem a cloud.

🔧 Nástroje:

  • Anthos (Google) – propojí on-prem K8s (včetně Tanzu) s GKE.
  • Rancher, ArgoCD, FluxCD, kubeadm – jiné možnosti pro hybridní orchestraci.
  • Cloud VPN / BGP routing – propojí sítě mezi tvými servery a Googlem.

💻 Jak se Kubernetes na VMware instaluje a provozuje?

Dvě možnosti podle úrovně integrace:

🔧 1) Tanzu vSphere – integrace přímo do VMware prostředí

💡 Pouze pro vSphere 7 Enterprise+ a vyšší s vCenter Serverem a vSAN.

Co se děje:

  • VMware vSphere vytvoří Supervisor Cluster – Kubernetes běží nativně nad hypervisorem.

  • Kubernetes je součástí VMware – spravuješ ho z vSphere UI.

  • Můžeš vytvářet VM i kontejnery z jednoho prostředí.

  • Přidáš Tanzu Kubernetes Grid jako „template“ do prostředí → pak už jen klikáš clustery.

Výhoda:

  • Není třeba spouštět VM s Linuxem.

  • Kubernetes běží jako „first-class citizen“ v ESXi.

🧱 2) Manuální instalace Kubernetes ve virtuálním stroji

Funguje na jakékoli VMware verzi (i Workstation, ESXi Free).

Jak to vypadá:

  1. Vytvoříš virtuálku s Linuxem (Ubuntu, CentOS, Fedora…).

  2. Nainstaluješ kubeadm, kubectl, kubelet (nebo použiješ např. MicroK8s, K3s).

  3. Spustíš kubeadm init, nastavíš networking, storage, apod.

  4. Hotovo – běží ti plný Kubernetes cluster ve VM.

📦 Tip: Pokud chceš rychle a jednoduše, použij:

  • K3s (lehčí Kubernetes od Rancher Labs)

  • MicroK8s (od Canonical, jednoduše rozběhneš i lokálně)

🔁 Shrnutí rozdílů:

Možnost vSphere s Tanzu VM s Linuxem + Kubernetes
Podpora od VMware ✅ Plná ❌ Vlastní odpovědnost
Kubernetes nativně ve vSphere ✅ Ano ❌ Ne
Výkon ⚡ Vysoký (běží přímo na ESXi) 🐢 Závisí na VM
Komplexita instalace ⚙️ Vyšší na začátku, pak klikací ⚙️ Jednoduché, ale ruční
Možnost škálování ✅ Lepší ⚠️ Omezená kapacitou VM
Pro malé laby / domácí ❌ Náročné ✅ Ideální řešení

📌 Shrnutí pro tebe

  • Tanzu = platforma od VMware, která ti umožní spustit Kubernetes přímo na vSphere bez potřeby Linuxových VM.

  • Můžeš Kubernetes propojit s Google Cloudem (např. GKE) pro hybridní nasazení.

  • Pokud nemáš Tanzu licenci, běžná instalace do Linuxové VM ti dá plnohodnotný Kubernetes (např. K3s).

  • GKE je Kubernetes jako služba v cloudu, nemusíš se o nic starat – vhodné na produkci nebo testovací deploymenty.

Tanzu není „jen“ aplikace pod Linux, ale zároveň není tak integrovaná a pohodlná, jak by člověk čekal za ty prachy, co VMware vEnterprise stojí.

Tady je realita bez marketingu:

🧱 Jak se Tanzu instaluje pod VMware (vSphere 7)

🚨 Realita: „Tanzu“ nezapneš jedním tlačítkem jako VM – ale dá se to zautomatizovat, a jakmile to máš, je to pak „klikací“.

Tanzu = několik komponent dohromady:

Vrstva Co to je
Supervisor Cluster Kubernetes běžící přímo na ESXi (zabudovaný do hypervizoru)
Tanzu Kubernetes Grid (TKG) Sada nástrojů pro tvorbu dalších K8s clusterů
NSX-T nebo vDS Nutné pro síťování Kubernetesu
Harbor registry (volitelné) pro vlastní docker image
vSphere Namespace + Content Library Prostředí pro kontejnery a clustery

✅ Co musíš mít (kontrolní seznam):

Potřeba Detaily
✅ vSphere 7 Enterprise Plus Jinak Tanzu neaktivuješ
✅ vCenter Server 7 GUI, řízení clusteru
✅ Cluster s aktivním DRS (Distributed Resource Scheduler)
✅ vSphere Distributed Switch (vDS) nebo NSX-T Pro networking Kubernetesu
✅ Content Library Aby měl Tanzu odkud brát image
✅ Load Balancer (např. HAProxy) Pro přístup na služby v K8s
❗ Volitelné: DNS, NTP, storage policies, storage classes atd.

🔧 Instalace krok za krokem (v kostce)

  1. Vytvoř cluster ESXi hostů (musí mít DRS a sdílené storage)

  2. Vytvoř vSphere Distributed Switch + Port Groups pro komunikaci (pokud nemáš NSX-T)

  3. Zapni vSphere with Tanzu ve vCenteru:

    • Přes Workload Management (vSphere Client → Menu → Workload Management)

    • Vybereš cluster, DVS, IP Pool, storage policy, load balancer (např. HAProxy VM)

  4. vSphere vytvoří Supervisor Cluster:

    • Kubernetes běžící přímo na hypervizoru (ne v Linux VM)

    • Vytvoří se Namespace, které pak spravuješ

  5. Vytvoř Content Library s Tanzu Kubernetes Grid image

  6. Z ní pak vytváříš Tanzu Kubernetes clustery na jedno kliknutí

📦 Co je vlastně Tanzu Kubernetes Grid (TKG)?

  • Image, který se spouští jako VM s Linuxem + Kubernetes + agenti

  • Spouští se automaticky přes vSphere, pokud máš nastavený Supervisor

  • Můžeš ho mít i mimo vSphere, např. na AWS, Azure nebo bare-metal

💬 Takže shrnuto:

  • Supervisor Cluster = Kubernetes běžící nativně na ESXi (ne v Linuxu)

  • TKG = běžící Kubernetes v klasické VM (ale připraveno, automatizováno)

  • Všechno ovládáš z vSphere GUI přes Workload Management

  • Ale předtím musíš:

    • Mít licence

    • Síť (DVS nebo NSX-T)

    • Storage policy

    • Load Balancer (HAProxy / NSX Load Balancer)

🔗 Chceš to reálně zkusit?

Doporučuji začít s Tanzu přes HAProxy a vSphere Distributed Switch, protože NSX-T je peklo (složitý, drahý).

🧠 Myšlenka na závěr:

Ano, Tanzu běží „pod Linuxem“, ale tím Linuxem je v tomhle případě už samotnej hypervizor ESXi – takže Kubernetes běží natvrdo „na železe“, bez prostředníka v podobě klasické VM.

To je důvod, proč je to tak stabilní, ale zároveň složitější na setup.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/11/co-je-kubernetes-2-co-je-tanzu-vmware/