HollowByte je zranitelnost typu Denial of Service (DoS) v kryptografické knihovně OpenSSL. Útočník může odesíláním škodlivého payloadu o velikosti pouhých 11 bajtů zaplnit paměť serveru. OpenSSL před ověřením dat vyhradí nepřiměřený blok paměti (až 131 KB). Server pak čeká na data, která nepřišla. Zranitelnost je opravena ve verzích OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 a 3.0.21.
Ve španělské A Coruñě probíhá GUADEC 2026, tj. letošní konference vývojářů a uživatelů desktopového prostředí GNOME. Videozáznamy přednášek jsou k dispozici na YouTube.
Společnost Collabora ve spolupráci s Valve vyvíjí Holo Core, tj. port Arch Linuxu pro ARM64 procesory (AArch64), který bude pohánět VR headset Steam Frame. Pro testování Arch Linuxu pro AArch64 jsou k dispozici binární balíčky, zdrojové kódy i kontejner pro Docker nebo Podman.
Mikroprocesor Zilog Z80 byl oficiálně uveden na trh před 50 lety, tj. v červenci 1976. Výroba mikroprocesoru skončila v roce 2024.
Výzkumníci ze společnosti ESET objevili 11 zapomenutých UEFI shim zavaděčů, které byly podepsány společností Microsoft, a které umožňují útočníkům obejít ochranu UEFI Secure Boot na většině zařízení. Microsoft je zneplatnil (přidal jejich hash do databáze dbx) v rámci aktualizace Patch Tuesday dne 9. června 2026. Uživatelé Linuxu mohou databází aktualizovat pomocí LVFS. Ověřit zneplatnění zavaděčů lze pomocí skriptu uefi-dbx-audit. Jedná se o CVE-2026-8863 a CVE-2026-10797.
pico-usb-wifi je open source firmware pro Raspberry Pi Pico W, který jej promění v USB Wi-Fi adaptér. Po připojení k počítači se objeví jako zařízení USB CDC-NCM.
Americká společnost Google ze skupiny Alphabet bude muset podle nových požadavků Evropské unie umožnit společnosti OpenAI i dalším konkurentům v oblasti umělé inteligence (AI) a internetových vyhledávačů přístup ke svým službám. Ve svém rozhodnutí o tom včera informovala Evropská komise (EK). Opatření má zajistit dodržování pravidel, jejichž cílem je omezit v EU tržní sílu velkých technologických firem. Google s tím nesouhlasí.
… více »Nové verze webových prohlížečů Chrome a Firefox jsou vydávány každé 4 týdny. Aktuální verze Chrome je 150. Aktuální verze Firefoxu je 152. V březnu bylo oznámeno, že od září přejde Chrome na dvoutýdenní cyklus vydávání verzí. To by znamenalo, že Chrome v číslování verzí Firefox brzy přeskočí. Vývojáři Firefoxu proto také od září přecházejí na dvoutýdenní cyklus vydávání verzí. :-)
Microsoft Comic Chat (Wikipedie), tj. grafický IRC klient z devadesátek, který převáděl konverzace na IRC do podoby komiksových panelů, a který zpopularizoval font Comic Sans, je dnešním dnem open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Byla vydána (𝕏) nová verze 26.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 26.7 je Xenial Xenops. Přehled novinek v příspěvku na fóru.
V dnešním dílu se vám pokusím přiblížit základní funkce firewallu. Budeme se pohybovat v obecné rovině a podíváme se, z čeho vlastně čerpají profesionální návrháři. V závěru článku jsem pak uvedl odkazy na dokumenty, které pocházejí z dílny amerického normalizačního úřadu (NIST), a popisují velmi podrobně problematiku, kterou zde dnes budeme probírat. České normy zatím bohužel neexistují, takže nezbývá než se odkazovat na dokumenty v anglickém jazyce. Dnes se tedy budeme pohybovat v obecné rovině. Odkazy na zajímavé projekty z oblasti Linuxu uvedeme v některém z dalších dílů.
Síťové firewally jsou zařízení nebo systémy, které oddělují jednotlivé datové sítě a to prostřednictvím pravidel, kterým říkáme bezpečnostní politiky. Firewall je vlastně jakási ochranná hráz, skrze kterou musejí projít všechny informace (rozumějte pakety), které si chceme "mezi oddělenými světy" předat. Ve velké většině případů je firewall zmiňován právě v souvislostech propojení s Internetem a ve spojitosti s rodinou protokolů TCP/IP. Nicméně, firewally nejsou nutně závislé na Internetu a musejí být schopny pracovat i s jinými protokoly. Internet je sice častý, nicméně ne jediný případ jejich využití. Klasickým příkladem mohou být například vnitropodnikové sítě, kdy jednotlivé pobočky jsou k "hlavnímu stanu" připojeny pomocí privátních kanálů. Tyto kanály (např. WAN sítě) jsou rovněž chráněny firewally, přestože v těchto větvích se nemusí nacházet jediná přípojka do Internetu. V době zvané "informace nad zlato" se tak jejich provozovatelé snaží předejít neoprávněným přístupům k zařízením (k informacím v těchto zařízeních uložených), monitorovat provoz v těchto sítích, povolit jen vybrané síťové služby, omezit provoz na pronajatých linkách apod. Určité modelové topologie zapojení firewallu jsme si již ukázali ve 3.dílu, podrobný popis jednotlivých zapojení pak najdete v literatuře (1).
V 2. dílu jsme uvedli, že firewall má celkem 4 stupně. Pokud se však pozorně začtete do níže uvedené literatury (2), dozvíte se, že můžeme rozlišovat celkem až 8 (!) stupňů. Tento zdánlivý rozpor si hned vysvětlíme.
Členění stupňů firewallů vypadá (podle 2) v současné době takto:
Podíváte-li se blíže, pak pojmy dedicated proxy firewall, host based firewall a personal firewall jsme si ve druhém dílu dovolili vynechat, protože se jedná o zvláštní případy instalací. Ještě připomenu, že vlastní překlad adres (network address translation - NAT) bývá často zařazován na úroveň paketových filtrů. Nyní jsme tedy již u našeho starého známého schématu:
tak, jak jsme uvedli v druhém dílu. Podívejme se teď na jednotlivé stupně poněkud blíže.
Tvoří základní stupeň každého firewallu a to mimo jiné i proto, že má na své straně dvě velké výhody, kterými jsou rychlost a přizpůsobitelnost (flexibility). Paketový filtr může být použit v libovolné síti na libovolný typ protokolu (my se ale budeme věnovat jen rodině protokolů TCP/IP). I to je důvod, proč jsou paketové filtry využívány i na jiných zařízeních než firewallech, klasickým případem jsou směrovače (router).
Paketové filtry však mají i řadu nevýhod:
Klasickým příkladem zařízení, které bude používat pouze paketový filtr, je právě router provozující ACL (access list) pro kontrolu síťového provozu. Takovýto "přístupový" router je v literatuře (1) označován jako Boundary router a jeho zapojení může vypadat právě takto:
Vidíme, že náš Boundary router vlastně tvoří jakýsi "první stupeň" firewallu. Můžeme na něm provozovat paketový filtr, který odfiltruje nežádoucí pakety a zbytek provozu předá firewallu, který pak může provádět kontrolu na vyšších vrstvách OSI modelu, jak si řekneme níže.
Jakmile TCP (spojově orientovaná služba) aplikace vystaví TCP spojení (relaci) s protější stranou, ja na zdrojové straně tomuto spojení rovněž přiřazen určitý port. Tento port pak "obhospodařuje" spojení vystavené s protější stranou (remote host system). Paketový filtr musí povolit (přijmout) všechny příchozí pakety (příchozí ve směru od druhé strany) tak, aby spojově orientovaná služba mohla vůbec pracovat. Nicméně povolení určitého množství portů již vytváří prostor pro neposedy, kteří by této vlastnosti chtěli využívat k nejrůznějším pokusům, případně nekalostem.
Stavový firewall to řeší tak, že si vytvoří tabulku pro každé spojení, kam zaznamenává každé vytvořené (platné) TCP spojení a to včetně portů odpovídajících tomuto spojení. Tato "stavová tabulka" je pak následně využívána pro ověřování činnosti jednotlivých spojení. Dorazí-li tedy paket, který žádnému vystavenému spojení neodpovídá (neodpovídá tabulce), je stavovým firewallem vyhodnocen jako nevyhovující (přesněji, nevyhovující politice) a podle politiky s ním pak stavový firewall i naloží (zahodí jej, odmítne, propustí, přesměruje apod.).
Stavový firewall se oproti paketovému filtru liší také tím, že není obecně univerzální, ale je využitelný (nasaditelný) pouze pro TCP/IP protokoly.
Jistěže, stavové firewally mohou obsluhovat (podobně jako paketové filtry) řadu protokolů, ale technologie "stavových tabulek" je zatím využitelná pouze pro protokoly z rodiny TCP/IP. Z tohoto důvodu je stavový firewall někdy v literatuře označován jako "nadstavba" paketového filtru. Podrobnější popis stavového firewallu nad IPTABLES můžete najít například zde.
Jedná se o další rozšíření funkčnosti firewallu, které kombinuje tzv. "lower layer access control" (tedy na úrovni síťové vrstvy OSI modelu zde, což zajišťuje právě paketový filtr) s tzv. "upper layer" (tedy 7, neboli Aplikační vrstva OSI modelu). Všechny síťové pakety, které procházejí skrze firewall, pak musí projít skrze tuto bránu. Zde je tedy ono správné místo, kde můžeme narazit na výrazy typu "SMTP proxy, http proxy, ftp proxy" a podobně.
Velkou výhodou aplikačních serverů je právě ta skutečnost, že kontrolu provádějí přímo na aplikační, tedy 7. vrstvě OSI modelu. Nevýhodou je skutečnost, že tento provoz "něco stojí" a zaplatíte za něj částí výkonu stroje. To bývá obvykle hlavním důvodem, proč jsou jednotlivé aplikační servery umístěny v DMZ na samostatných strojích. Klasickým příkladem je samostatný stroj pro poštu (SMTP server), samostatný stroj pro ftp, samostatný stroj pro www služby apod. Modelová topologie pak může vypadat třeba takto:
Přece jen se o nich krátce zmíním. Tento firewall se od klasické aplikační proxy liší tím, že představuje jakýsi "mezistupeň". Jeho úkolem je zachycovat provoz sledované síťové služby a dané pakety přeposílat na další stroj, který se nachází v DMZ, Vnitřní síti apod. Vlastní provoz může být jak jednosměrný (tedy pakety zvenčí dovnitř nebo zevnitř ven), tak obousměrný. Klasickým příkladem je SMTP proxy zvaná SMTP on firewall. Popis konfigurace můžete najít zde.
Důvod tohoto zapojení je prostý - zvenčí je vidět pouze SMTP proxy, která však poštu předává dalšímu poštovnímu serveru v DMZ nebo ve vnitřní síti. Vlastní poštovní server pak není zvenčí vidět. Není asi třeba zdůrazňovat, že náš "dedicated proxy firewall" nebo-li SMTP proxy je jednoúčelový tupoučký automat, který skutečně neumí nic jiného než to, co po něm přesně chceme. Pak si jej můžeme dovolit předřadit před firewall a umístit buď někam na samostatný stroj nebo na přístupový router (opět náš Boundary router viz. literatura (1) na konci článku).
Vlastní analyzátor je samozřejmě pasivní záležitost. Výstupem mohou být zpracované výstupy v podobě logů, varovných nebo kritických zpráv. Klasickým analyzátorem paketů je třeba snort, který toho samozřejmě umí mnohem více (snort již lze zařadit do kategorie nástrojů IDS, nicméně u této kapitoly ještě zdaleka nejsme). Za další lze jmenovat např. portsentry (pro Debian např. zde) a anglicky psaný popis zde.
Nicméně, v této kapitolce bych uvítal aktivitu čtenářů a čtenářek. Pokud tedy máte odkaz na zajímavý nástroj z této oblasti, pak neváhejte a napište. Rádi vaše dílko uveřejníme.
Zde jen krátce. Hlavním posláním zmíněného překladu adres je "skrytí" vnitřní sítě před sítí vnější. Vlastní NAT pak může probíhat v několika režimech zvaných static, hiding a port. Vzhledem k tomu, že této věci se již věnoval Martin v jednom z předchozích dílů, dovolím si zájemce o podrobnější vysvětlení odkázat na literaturu na konci článku nebo na nějaké to NAT HOWTO, například sem nebo sem.
Shrneme-li tedy vše, co zde již bylo řečeno, pak lze základní funkce firewallu popsat asi takto:
Je celkem zřejmé, že všechny tyto stupně se mohou, ale také nemusejí, nacházet na jednom a témž stroji. Rozdělení těchto modulů na fyzické stroje bude závislé na konkrétní situaci a na celkové zátěži, kterou jsme ochotni "přidělit" každému stroji.
Filtrování paketů by pak mělo probíhat na základě následujících charakteristik:
NIST je zkratka pro National Institute of Standards and Technology a jak sami již z názvu tušíte, jedná se o organizaci zabývající se vývojem a vydáváním standardů (v našem případě se tedy jedná o standardy z oblasti informačních systémů). Bližší informace o NIST naleznete zde
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz