Ondřej Caletka: IPv6-only, IPv6-mostly a Linux
Když se mluví o IPv6, většina lidí tím automaticky myslí dual-stack. Máme IPv4, tu si necháme, a přidáme IPv6.
To je funkční řešení, kdy máme dostupné obě sítě a IPv6 je preferováno. Vše funguje, ale dual-stack neřeší nedostatek IPv4 adres. Protokol IPv6 byl ale navržen především proto, aby nám pomohl řešit docházející IPv4 adresy.
Přechodových mechanismů byla vymyšlena spousta, ale jeden z nich stojí stranou – je jím NAT64. Do IPv6 adresy se bez problému vejde IPv4 adresa.
NAT64 je překladač, který překládá IPv4 pakety do IPv6 a naopak. Koncový počítač pak má nastavenu pouze IPv6 adresu a ke zdrojům dostupným jen po IPv4 se dostane přes překladač. K tomu mu pomůže trik nazvaný DNS64, kdy se doplňují syntetické IPv6 adresy pro všechny cíle.
Funguje to velmi dobře, ale má to své problémy. Když například nepoužíváte DNS, nemůžete použít trik s DNS64.
Můžete mít také zastaralý software používající IPv4-only sockety nebo chcete komunikovat se serverem s rozbitým IPv6. Abychom to vylepšili, máme tu koncept 464XLAT, což je další překladač uvnitř zařízení.
Ten překládá IPv4 do IPv6, pakety pak projdou sítí a opět se přeloží do IPv4. Aplikace pak vidí starý dobrý dual-stack.
Tohle je plnohodnotné řešení, které dnes už mnoho let běží v řadě mobilních sítí.
Není tedy problém provozovat IPv6-only síť s operačními systémy Android, iOS nebo macOS. Ve Windows a v Linuxu není dostupný CLAT, takže aplikace vyžadující IPv4 nefungují. Smutný příběh je IoT a chytrá domácnost, což jsou zařízení, která vyžadují IPv4 a DHCP.
Microsoft nedávno oznámil, že ve Windows přibude podpora CLAT, takže z běžných systémů zbývá už jen Linux.
Pro bezproblémové nasazení IPv6-mostly sítě slouží DHCP volba 108, která je definovaná v RFC 8925. Pokud klient této volbě rozumí, pošle ji v požadavku na přidělení adresy. Server v odpovědi pošle stejnou volbu a tím řekne, že v síti se preferuje provoz pouze o IPv6 a adresa v IPv4 se vůbec nepřidělí. Zařízení, které IPv4 adresu vůbec nepotřebuje, ji nedostane a bude používat jen IPv6.
Taková síť se jmenuje IPv6-mostly a nabízí zařízením nějaké IPv4 pro stará zařízení.
Dnes přibližně 80 % zařízení v takové síti nebude vůbec používat IPv4. Většina zařízení v dnešních sítích jsou nějaké mobily a ty v tomhle režimu bez problému fungují.
Jak se zbavit potřeby nativního IPv4 na Linuxu? Výhoda je, že většina software je open-source, takže je možné staré aplikace opravit.
To je vlastně už hotové, ale ke stu procentům se nikdy nedostaneme. Vždycky bude nějaký okrajový případ, kdy něco fungovat nebude. Problémem bývají různé virtualizační a kontejnerové platformy, které používají NAT a předpokládají IPv4.
Můžeme také zprovoznit CLAT pro řešení zbývajících problémů. Je to složité a vyžaduje to instalaci dalšího software, ale je to zřejmě nevyhnutelné.
Poté je možné také v DHCP implementovat volbu 108. Dobrá zpráva je, že tohle už je to hotové v dhcpcd a systemd-networkd.
Pro použití CLAT existuje několik nástrojů: Tayga, tundra-nad64, nat46 nebo Jool. Pro otestování existuje perlovský skript clatd, který detekuje nutnost CLAT a nastaví překlad.
Konfigurace ale vyžaduje přepnout jádro do režimu směrovače a nastavit například také firewall. Navíc skript nedokáže reagovat na přeadresování sítě. Je to dobré na vyzkoušení, ale na produkční nasazení to není.
Ideální CLAT pro Linux by měl podporovat více instancí pro různá rozhraní a měl by si umět poradit i s kolidujícími prefix pro NAT64. Měl by se také zapnout hned po detekci NAT64, buď pomocí RA PREF64 nebo doménového jména ipv4only.arpa. Na něm jsou nastaveny pouze IPv4 adresy a pokud od místního resolveru dostanete IPv6 adresy, detekujete tím překlad a odvodíte si prefix.
Ideální CLAT by měl také dynamicky reagovat na změny a neměl by nastavovat firewall nebo forwarding.
V Linuxu je možné použít síťové jmenné prostory (namespaces) známé z kontejnerové virtualizace a oddělit CLAT do samostatného prostoru s vlastní síťovou konfigurací. Hlavní prostředí pak nemusí fungovat jako směrovač, jen mu přibude další síťové rozhraní.
Je možné takto provozovat jakýkoliv překladač, například jaderný Jool a pokud jej nemáme, můžeme nasadit tundra-nat64. Pro ukončení stačí smazat jmenný prostor a vše se vrátí do původního stavu. Chybí nám ale program zodpovědný za nastavení, konfiguraci a vypnutí CLAT. Měl by být ideálně integrovaný s běžnými linuxovými distribucemi.
Vývojáři NetworkManageru na tom pracují, už je k dispozici podpora pro čtení volby PREF64 a implementuje se volba 108 pro DHCP. Nejtěžším problémem je CLAT, který bude implementován v eBPF a nebude mít externí závislosti.
Překladač bude tedy implementován v jádře, ne jako modul, ale v podobě kódu pro eBPF.
Radek Zajíc: IPv6-only Kubernetes: přelet nad infrastrukturním hnízdem
IPv4 má jen čtyři miliardy adres, proti tomu IPv6 umožňuje vytvořit 264 sítí a v každé z nich mít 264 zařízení. Svět IPv4 je dnes závislý na krabičkách nazvaných NAT, které dovolují sdílet jednu adresu mnoha uživateli. Funguje to, ale jen jedním směrem.
Už přes dvacet let se snažíme tenhle problém změnit, podle Google se už téměř polovina uživatelů na světě už připojuje po IPv6. Rozvoj ale není na celém světě stejně rychlý.
Už dlouho je jasné, že provoz obou sítí v režimu dual-stack je jen dočasné řešení.
Kontejnery jsou koncept, který umožňuje oddělit aplikaci do samostatného uzavřeného prostředí s vlastní konfigurací. Postupně jsme se dostali do fáze, kdy tyto kontejnery spouštíme v rámci nějakého orchestrátoru, který se o běh těchto kontejnerů stará. Takovým orchestrátorem může být například Kubernetes.
Hostitel má svou IP adresu, jednotlivé kontejnery mají vlastní jmenný prostor s vlastními adresami a služby mají také své adresy. Musíte tedy nějak vyřešit síťování a může se vám stát, že vám začnou adresy docházet.
Švýcarským nožíkem pro řešení sítě v Kubernetes je Cilium, který mimo jiné funguje jako load balancer a umí také BGP. Nahrazuje Kube-proxy, takže místo nekonečné manipulace s IPtables se pracuje s eBPF.
Nevyhneme se ovšem DNAT, abychom se mohli připojovat k interním službám.
Problémem je už přidělování adres, protože musíme řešit jejich získání a také případné překrytí například s klasickou virtualizací. Jak hledat problémy na síti, když je pro nás komunikace jednotlivých podů zakryta překlady adres?
Pomůže nám s tím IPv6?
Úplně se bez IPv4 neobejdeme, ale můžeme uvnitř clusteru provozovat jen IPv6 a na okraji sítě se pak postarat o překlad do IPv4. Kde to půjde, můžu komunikovat rovnou po šestce. Pokud nemám jinou možnost, můžu použít IPv4.
V Kubernetes se případný překlad provede až na load balanceru a komunikace uvnitř probíhá pouze po IPv6.
Existuje iniciativa, která se snaží, aby se začaly používat IPv4 adresy třídy E. Jde o adresy 240.0.0.0 až 255.255.255.254, které se od začátku v internetu vůbec nevyužívají. Jde vlastně o squatování na adresách, které vám nepatří.
Jejich použití doporučuje ve svém cloudu společnost Google. Není to ale dobrý nápad, já bych to rozhodně nedělal.
Existuje několik různých veřejných služeb nabízejících Kubernetes, které běží v režimu dual-stack: Google Kuberenetes Engine Azure a Vultr. To úplně nechcete, protože vás to nezbavuje problémů s IPv4.
Jedinou veřejnou službou nabízející IPv6-only je AWS. Pokud chcete používat veřejné storage, je možné použít služby na dual-stacku jako Amazon S3, Google Cloud Storage, Backblaze a další.
Pokud chceme provádět překlad na vlastním řešení, můžeme použít Unbound pro DNS64 a Jool pro NAT64. Můžete ale také použít externí služby jako nat64.net nebo Google DNS64.
Pro správu kontejnerů se používají takzvané Container registry. Na vlastním řešení je možné nasadit Harbor, který nemá se šestkou problém. Stejně tak DockerHub, Google pkg.dev, Digital Ocean nebo Gitlab, dostanete se tam po šestce také. Například na GitHubu ale máte problém, tam se po IPv6 nepřipojíte.
Když chcete takové prostředí provozovat, je třeba se mít na pozoru před některými problémy. Občas je potřeba například hlídat některé aplikace, které ve výchozím stavu nefungují v IPv6-only. Například Kibana poslouchá na 0.0.0.0 a je třeba ji překonfigurovat pro ::.
Je také potřeba hlídat správné MTU, protože směrovače na cestě nefragmentují samy. Občas je složitější konfigurace některých služeb, IPAM a směrování bloků adres.
Vlastimil Slinták: Úvod do LoRa sítě Meshtastic
Meshtastic je otevřená komunitní síť postavená na technologii LoRa, která využívá svůj vlastní síťový protokol. Síť je meshová, takže každé zařízení je zároveň směrovač a všechna zařízení jsou si rovna. Pokud mám zařízení pro Meshtastic, můžu ho použít ke komunikaci se svým okolím. Nejčastěji to uživatelé používají pro výměnu krátkých zpráv, takový kecálek.
Hardware je možné si připojit k počítači nebo telefonu prostřednictvím bluetooth.
Čtěte: Meshtastic: otevřená meshová síť s dlouhým dosahem pro každého
Zařízení se pravidelně v síti ozývají a je možné si tedy prohlédnout, kdo je v okolí. Mohou o sobě vysílat spoustu informací, včetně polohy, takže je možné si je zobrazit na mapě.
Rovnou je možné posílat zprávy ostatním uživatelům a není potřeba žádná další infrastruktura. V případně povodní třeba mohla vypadnout mobilní síť a Meshtastic mohl fungovat.
Přenášejí se krátké zprávy do 240 bajtů rychlostí mezi jedním a třemi kilobity za sekundu.
Celá síť je decentralizovaná a neexistují žádné uzly, které by řídily provoz nebo rozhodovaly o tom, kdo se může do sítě připojit. V Česku se používá komunikace na frekvenci 868 MHz, existují ale i další pásma, která se používají jinde po světě. Radioamatéři mohou použít i některé z vlastních pásem.
Meshová síť zajišťuje, že je zpráva automaticky předávána na další stanice. Obvykle se používá nastavení na tři hopy, ale tato hodnota se dá zvýšit či snížit.
Na přímou viditelnost i s malou všesměrovou anténku se běžně vysílá na desítky kilometrů. Rekord je 331 kilometrů mezi Řeckem a Itálií.
Všechny zprávy jsou šifrované pomocí AES256, kdy je potřeba si klíče předsdílet dopředu. Jeden klíč je veřejně známý a je součástí firmwaru, tím existuje veřejný kanál.
Pokud si vytvoříte a vyměníte své klíče, můžete si vyměňovat šifrované zprávy.
Hardware je velmi levný, vysílač je možné postavit za vyšší stokoruny až nízké tisícikoruny. Můžete si to postavit i levněji, záleží na tom, co už máte doma v šuplíku.
Pokud rádi bastlíte a hledáte nový koníček, bude vás Meshtastic bavit. Síť můžete využívat i jiným způsobem, můžete si posílat vlastní data, například ze vzdáleného stanoviště.
Existuje celá řada různých hotových desek, například T-Beam s ESP32, nebo T-Echo s NRF52840. Ten už je hotový, nemusíte nic stavět. Stačí nahrát nejnovější firmware a můžete vyrazit do terénu.
Pokud chcete naopak něco stavět, můžete koupit RAK19007 a RAK 4601, přidat napájení a malý displej. Poté se typicky k zařízení připojíte z mobilního telefonu s aplikací pomocí bluetooth nebo je možné použít vestavěné webové rozhraní.
Michal Frič: Hackni svůj server
Řada lidí provozuje vlastní servery, ale nemají přehled o jejich aktuálním stavu z hlediska bezpečnosti. Neprovádějí penetrační testy a spoléhají na to, že to jednou za čas udělá někdo za ně.
Když máme pochybnosti, nejlepší je situaci prověřit a vše si vyzkoušet.
Nejprve je potřeba určit, jak a co budeme přesně testovat. Zda se zaměříme na servery, infrastrukturu, aplikace nebo sítě. Můžeme pak testovat IP rozsahy, doménu a zaměřit se na různé prvky jako jsou uživatelské účty nebo jednotlivé služby. Můžeme začít pasivní fázi, tedy vytěžováním informací z veřejných zdrojů.
Dají se použít služby jako DNS dumpster, Shodan nebo Censys. Není to tak přesné jako aktivní skeny, ale získáte nějakou představu.
Cílem testování je objevit zranitelnost, která může ohrozit naše služby nebo data a poté provést nápravné opatření. Součástí výsledků testu by měla vždy být i doporučení k řešení objevených problémů.
Nejčastěji se chyby klasifikují systémem CVSS, který rozlišuje a hodnotní zranitelnosti podle způsobu zneužití a dopadu.
Řada nástrojů jsou komerční profesionální nástroje, které stojí spoustu peněz. Je možné ale použít i nekomerční nástroje, napříkladnmap s parametrem --script vuln . Dokáže vám to dát základní přehled o zranitelnostech.
Podobně lze doporučit také fork Nessusu s názvem Greenbone.
Při testování webu a API je možné začít základními testy: stahování hlaviček odpovědí, kontrola nastavení TLS a objevit na webu soubory pomocí procházení struktury hrubou silou třeba pomocí nástroje dirb. Je možné také zkontrolovat nastavení bezpečnostních hlaviček, aby webserver posílal prohlížeči moderní volby. Otestujete si to za pár minut a pak stačí jen upravit konfiguraci webového serveru.
S tím souvisí i kontrola parametrů při posílání cookies.
Při aktivním testu je možné zkoušet například fuzzing, kdy zneužijeme vstupy do aplikace a doplníme je řadou různých řetězců, které mají ověřit odpovědi na nestandardní dotazy. Může to být docela náročné na přípravu, ale řada nástrojů už má připravené slovníky s různými typy řetězců.
U plnohodnotné aplikace v systému je možné sledovat soubory ukládané při instalaci, požadavky na vysoká oprávnění, otevřené síťové porty a pokusy o komunikaci po síti. Můžete si takhle otestovat aplikace čistě pro svůj klid, protože autor může mít jiné úmysly než vy.
Při objevení zranitelnosti je dobré vyzkoušet, zda je vůbec zneužitelná. Spousta jich exploitovatelná vůbec není, takže můžete zůstat v klidu. Někdy je to naopak velmi jednoduché.
Můžete použít například nástroje Metasploit a reNgine.
Důležité je testování automatizovat, protože situace se může rychle změnit a výsledky testů platí jen pro danou chvíli. Na automatizaci jsem neobjevil nic lepšího než Jenkins.
Tomáš Tichý: Hackujeme autobus
Metro jako první dopravní prostředek zavedlo hlášení stanic, nejprve pomocník strojvedoucího hlásil sám do mikrofonu. Později to bylo nahrazeno magnetofonem a ještě později digitálně.
Po revoluce byla přejmenována řada stanic, nejvíce na lince C. V roce 2004 došlo k prodloužení linky a bylo potřeba ji celou nahrát znovu novým hlasem.
Aby celý informační systém v autobuse fungoval, je potřeba řada různých zařízení. Například palubní počítač, terminál pro řidiče, hlásič, označovač jízdenek, hodiny a několik informačních panelů. Vše propojuje sběrnice Ibis využívající šesti drátů, které zajišťují napájení i komunikaci.
Komunikace probíhá rychlostí 1200 bitů, kdy se přenáší příkazy pro jednotlivá zařízení, pro text se používá znaková sada s kódováním bratří Kamenických. Kdybyste si chtěli hrát, dalo by se to jednoduše naprogramovat třeba v Arduinu.
Na konci příkazu jsou různé řídicí znaky pro nový řádek, opakování výpisu nebo ukončení sekvence.
Moderní informační systémy používají běžné počítače, které jsou u Pražského dopravního podniku poháněny Puppy Linuxem a u soukromých dopravců jsou tam Windows. Při otevření dveří se na panelu spustí VLC se čtyřmi obrazy z kamer.
Grafické zobrazení zastávek je vyřešeno v HTML a zobrazuje ho Firefox. Přesný čas se získává z GPS, ale systém má i vlastní hodiny reálného času zálohované baterií.
(Autorem fotografií je Petr Krčmář.)
ČLÁNKY DO MAILU