Přečtěte si také zápisky z prvního dne konference CSNOG 2020.
Václav Šraier: transparentní restartování služeb v Linuxu
Aktualizace služeb způsobují výpadky a nedostupnost zas způsobuje problémy. Chceme tedy aktualizovat kód běžící služby tak, aby nikdo zvenčí nepřišel na to, že se něco stalo.
Aby vše proběhlo navenek tak, jako by server běžel pořád a všechny požadavky jsou během toho odbaveny.
S linuxovým jádrem komunikujeme pomocí file descriptorů, které můžeme zachovat a přenášet je mezi procesy.
Jak to dělá třeba systemd? Jde o jednovláknový proces, který se nesmí za žádných okolností vypnout, jinak nám spadne celý systém. Aktualizace probíhá pomocí příkazu systemctl deamon-reexec
, proces serializuje svůj stav, pomocí exec
spustí novou binárku, ta deserializuje stav, převezme komunikační kanály a pokračujeme dále. Jako by se nic nestalo, ale máme nový kód.
Druhým příkladem služby je Knot Resolver, který je také jednovláknový, ale používá se ve více procesech poslouchajících na stejném socketu. Pokud si takto spustíme procesů více, můžeme restartovat jeden za druhým.
Vždy tedy bude existovat alespoň jeden proces, který bude na požadavky odpovídat. Postupně tak můžeme obměnit běžící kód za nový.
Posledním příkladem je Nginx, který má více procesů – jeden master proces a více workerů. Při restartu pošleme masteru signál, po kterém si spustí nový master a ten si naspouští nové workery. Požadavky zpracovává už jen nový kód a starý se postupně vypne.
Všechny tyto variantu fungují, ale zmíněné projekty mají větší týmy a bylo do nich investováno velké úsilí. Pojďme to zobecnit na něco, co je jednoduché a může to použít úplně kdokoliv.
Výsledkem je knihovna libzedr (library for zero-downtime restarts), kterou Václav Šraier vytvořil v rámci své bakalářské práce. Cílem je, aby transparentní restarty byly jednoduché a mohl je používat kdokoliv.
Jak to celé funguje? Na začátku máme proces služby, kterou chceme restartovat. Uživatel nějakým způsobem pošle restartovací signál, například pomocí systemd. Služba pak pošle své file descriptory jinému procesu zvanému restart server. Ten nám bude pomáhat při restartu.
Starý proces pak dokončí zpracování požadavku a postupně se vypíná. Během toho restart server zařídí spuštění nového procesu a předá jí informaci o komunikačních kanálů původního procesu. Navenek není vůbec vidět, že došlo k přehození toho, kdo poslouchá.
Nakonec se starý proces ukončí a nový pokračuje v jeho práci.
Problém je se stavem služby, protože knihovna nemůže triviálně zjistit, jak je stav ve službě uložen. Knihovna řeší jen předávání file descriptorů. Nemůže vyřešit serializaci a deserializaci dat.
Pokud služba používá databázi, je stav uložen v ní a není potřeba nic dalšího řešit.
Podle autora je API knihovny již stabilní a nepočítá s úpravami. Může se ale měnit integrace do systemd, kdy bychom mohli chtít sledovat různé generace služeb.
Měli bychom být schopni poznat, že například stará verze procesu nikdy neskončila.
Aleš Mrázek: konfigurace a správa služeb pomocí sysrepo
Netconf je zkratka pro netfork configuration, jde o konfigurační protokol nahrazující SNMP. V roce 2013 byl protokol označen jako standard.
Konfigurační nástroje využívající SSH (Ansible, Puppet…) se připojují vzdáleně a spouštějí na terminálu příkazy upravující příkazy. Proti tomu Netconf má jasně definovatelný mechanismus konfigurace, což jej činí složitějším na implementaci, ale z hlediska administrátora je snadnější jej používat.
Netconf nabízí validaci konfiguračních dat, pohodlné zachytávání chyb či transakce ve celé síti. Pokud aplikuji konfiguraci na více oddělených systémech, dojde při selhání na jednom z nich ke kompletnímu zrušení změny a obdržíme relevantní chybovou hlášku.
Implementaci je možné rozdělit do tří samostatných částí: datový model popisující konfiguraci, datové úložiště pro konfiguraci (datastore) a Netconf server pro změnu konfiguraci na vzdáleném úložišti. Transportním protokolem je nejčastěji TLS nebo SSH, samotný Netconf žádný způsob přenosu nedefinuje. Zabývá se jen mechanismem konfigurace.
Pro popis konfigurace se používá standardizovaný jazyk YANG, který využívá XML či JSON. Pomocí tohoto jazyka je možné definovat hierarchii dat, datové typy a sémantická pravidla. Výsledek funguje velmi dobře také jako slušná dokumentace.
CZ.NIC používá nástroje sysrepo, které vyvinulo sdružení CESNET. Jde o libyang
implementující YANG, sysrepo
poskytuje datové úložiště a netopeer2
implementuje Netconf server. Nástroje jsou napsané v C, ale je možné použít C++ či Python.
Pro integraci do služeb slouží knihovna libsysrepo
, pomocí níž se může knihovna přihlásit k odběru určitého podstromu a podle zpráv pak provádí potřebné operace.
Pro DNS resolvery existuje společný datový model, který se hodí správcům sítí, kteří často kvůli stabilitě používají kombinaci různých resolverů. Ty jsou si velmi podobné a mají obvykle podobnou konfiguraci.
Datový model se tedy skládá ze dvou částí: univerzální použitelné pro všechny a poté doplňující pro jednotlivé implementace.
Tomáš Podermański: kam až sahají meze síťového subsystému linuxového jádra
Kritický okamžik, kdy vás tohle začne zajímat, je okamžik DDoS útoku na vaši službu nebo server. Útoky je možné rozdělit na dvě skupiny: buď je cílem ucpat linku nebo vyčerpat zdroje cílového systému.
Konvenční postup je systém dimenzovat tak, aby toho ustál co nejvíc. To zní dobře, na druhou stranu si málokdo může dovolit provozovat obrovskou farmu serverů.
Další možností je předřadit „něco“, co zvýší odolnost služby za mě. Pokud se ale bavíme o systémech, kde je potřeba odbavovat desítky či stovky gigabitů, šplhá cena do astronomických částek.
Velké útoky nelze vždy ustát beze ztrát a je potřeba přemýšlet dopředu nad tím, co můžu hodit přes palubu. Typicky můžu odříznout zahraniční klienty a tím eliminovat velkou část útoku.
Když se na linuxový systém podíváme z hrubého pohledu, běží služba v uživatelském systému, který je připojený do jaderného prostoru. Ten v první řadě zajišťuje například TCP spojení, hlídá tabulky stavu, filtruje provoz, obsluhuje síťovou kartu a podobně.
Zátěž serveru je možné měřit pomocí geenerátoru provozu připojenému k měřenému zařízení. Sledujeme zátěž procesoru a rozložení zátěže. Pokud je procesor zatížen na 90 %, považujeme ho za stabilní.
Zkušenosti ukazují, že pokud jsme nad touto hodnotou, stačí už jen velmi malé zvýšení zátěže a systém se velmi rychle přetíží a přestane stíhat. Pro přesné měření zátěže je nejvhodnější používat nástroj turbostat
.
Z hlediska struktury provozu může přijít několik skupin paketů: zbytný provoz nesouvisející s provozem serveru (NTP, DNS, ICMP…), neidentifikovatelný zdroj (úvodní SYN, SYN-ACK) a nakonec provoz s identifikovatelným zdrojem. V řadě implementací, které mám možnost vidět, se zbytný provoz vůbec neřeší a nechá se k serveru dojít.
Z hlediska volumetrických útoků lze přitom jejich filtrací eliminovat minimálně 80 % útoků. Pokud to není možné, doporučuji alespoň filtraci v síťové kartě nebo ji alespoň přesunout do raw tabulky v Linuxu.
Tím se obejde velká část síťového stacku a jsme schopni filtrovat zhruba pětkrát více provozu než běžně v řetězci INPUT. Doporučuji toho zafiltrovat co možná nejvíce už v samotné infrastruktuře.
U provozu s neidentifikovatelným zdrojem nevíme, zda paket dorazil z legitimního zdroje nebo jde o podvrženou adresu. Typickým příkladem je úvodní SYN komunikace, kterou musíme pustit dále, protože může jít o legitimní provoz.
Pro každý paket se ale v cílovém systému musí založit fronta (SYN queue), ve které se čeká, jestli zdroj pošle SYN+ACK. Řešením je takzvaná SYN cookie, kdy do paketu s odpovědí vygenerujeme náhodně generovanou sekvenci a později můžeme zjistit, že další paket dorazil jako legitimní odpověď.
Pro útočníka je vygenerování validní odpovědi velmi „drahé“ a nejjednodušší je pro něj prostě chrlit SYN pakety.
V linuxovém jádře je to implementováno pod názvem syncookie
a mechanismus se aktivuje až ve chvíli, kdy systém přestane stíhat. Pokud normálně stíhá, řeší to tradičním způsobem.
Nastavení je možné provádět volbou sysctl
s názvem net.ipv4.tcp_syncookies
. Hodnota 1
znamená výchozí stav, hodnota 2
pak trvalé zapnutí. Bohužel je to mechanismus víceméně nepoužitelný, protože funguje jen na IPv4 a běží až na vyšších vrstvách síťového stacku, takže nás stojí výkon.
Existuje alternativní implementace z Red Hatu v podobě modulu SYNPROXY
do IPtables. Pro správce není úplně jednoduché ho použít, ale výhodou je, že je možné jej použít i na předřazeném serveru.
Existuje ještě další doplňující modul rawcookie, který přesouvá reakci na SYN paket a výrobu SYN cookie do nejnižší možné vrstvy jádra, tedy do raw tabulky v IPtables. Zaznamenali jsme nárůst výkonu o 47 % z 4,6 milionů paketů za sekundu na 8,8. To už stojí za řeč.
V případě provozu identifikovaného zdrojem si můžeme být jisti, že zdrojová IP adresa je autentická a je za ní komunikující zařízení. Zde je potřeba případný útok eliminovat individuálně podle samotné aplikace.
Můžeme vytvářet různé blacklisty a omezovat počet spojení podle IP adres, protože provoz už máme očištěn od podvržených paketů.
Radim Roška: Ansible a konfigurace sítí
Ansible znají linuxáci jako nástroj pro správu a konfiguraci linuxových serverů a virtualizačních prostředí. Ansible se už ale několik let etabluje jako nástroj pro konfiguraci síťových prvků.
Rozumně navržený design je základním předpokladem pro to, aby bylo možné služby automatizovaně spravovat. Mnoho firem má na začátku nastavený nějaký systém, ale postupným přidáváním prvků jej nahodile boří.
Automatizace zároveň umožňuje předcházet konfiguračním chybám. Nemůžete si dovolit jednou chybou shodit celé AWS.
Proto je možné přidávat validaci a testy konfigurací.
Ansible dokáže spravovat servery, cloudy, virtualizaci, síťové prvky i další součásti infrastruktury. Krása spočívá v tom, že musíte Ansible nainstalovat jen na řídicím uzlu, třeba na svém notebooku.
Spravované stroje nevyžadují řádné další změny, stačí správně nastavené přístupové rozhraní.
Ansible je možné použít pro generování konfigurace síťových prvků, přičemž se používají proměnné a na jejich základě se vyplní šablona pro jednotlivá zařízení. Tímto způsobem si vygenerujeme třeba 30 konfiguračních souborů, které pak chceme nahrát na switche.
Pro komunikaci se skutečnými zařízeními budeme potřebovat moduly vytvořené výrobci, které se se dělí do čtyř skupin: command pro spuštění příkazu, config pro idempotentní změnu konfiguraci, facts vrací strukturovaná data o zařízení a resource pro kontrolu a nastavení konkrétních zdrojů, například VLAN či síťových rozhraní.
Ansible je takto možné použít k různým účelům, například automatizovanému ověření verzí firmware všech síťových prvků nebo třeba pro zálohování konfigurace z celé sítě. Jeden playbook může vytvořit virtuály, připraví databázi, vše nainstalují a zkontrolují. Výhodou je jednoduchost, kterou jsme v síťovém prostředí doposud neznali.
Alexander Zubkov: Linux Switchdev the Mellanox way
Společnost Qrator Labs používá pro filtrování DDoS útoků přepínače značky Mellanox. Jde o takzvané whitebox switche, na které je možné nainstalovat vlastní software. K dispozici jsou systémy MLNX-OS, Cumulus, SAI, SONiC a také Switchdew založený na linuxovém jádře. Switchdev je infrastruktura v linuxovém jádře, která dovoluje přenést zátěž z síťového stacku na hardware switche.
S přepínačem se pak pracuje jako s běžným linuxovým serverem obsahujícím velké množství síťových rozhraní.
Přepínač podporuje mnoho běžných vlastností, které jsou implementovány v hardware a jsou propagovány do prostředí linuxového jádra: LACP (agregace linek), VLAN, bridge, VRF, ECMP, ACL, GRE tunely a další. Pro konfiguraci se používají běžné linuxové nástroje z balíků iproute2, ethtool, lldpad či sysctl.
Pro správu používají v Qrator vlastní sadu nástrojů napsanou v Perlu.
Sarmad Hussain: mezinárodní doménová jmena a e-mailové adresy
Cílem snahy je, aby všechny domény a e-mailové adresy byly použitelné ve všech aplikacích. Chceme nabídnout uživatelům možnost volby a posílit konkurenční prostředí.
V případě doménových jmen jde jednak o nové domény prvního řádu (.sky, .berlin,…) a IDN domény využívající jiné znaky než základní latinku. Podobné je to u e-mailových adres, kde můžeme mít uživatelská jména v místních znakových sadách či je přímo kombinovat s IDN doménou. V průběhu posledních tří let roste počet služeb, které nové domény umí využít. U některých kombinací je to ale bohužel stále jen okolo 10 %, postupně by to mělo být 100 %.
Problémy nebývají u ASCII domén, ale například u arabštiny či čínštiny je situace velmi špatná.
V případě e-mailu je nutné, aby všechny SMTP servery po cestě rozuměly EAI (Email Address Internationalization). Protokoly SMTP i POP mají rozšíření pro signalizaci podpory. Na základě tohoto signálu se pak odesílatel rozhodne odeslat adresu v mezinárodním tvaru.
Pokud jediný server podporu nenabízí, zpráva nedorazí. Poslední server v řadě není schopen doručit zprávu dále a uživatel pak obvykle dostane chybu podobnou té, jako když adresa neexistuje.
Podpora v různých nástrojích se velmi liší. Thunderbird například neumí odeslat EAI zprávu, ale bez problému ji zobrazí. Outlook, Roundcube a Postfix naopak většinu testů zvládnou velmi dobře. Podporu EAI vůbec nezahrnují nástroje Sendmail a Fetchmail. Můžete pomoci tím, že své systémy správně nakonfigurujete a budete o problematice informovat ostatní.
Komunita okolo IDN neustále roste, domén v ne-ascii znakových sadách přibývá, stejně jako vhodných nástrojů. Současné standardy umožňují mít e-mailovou adresu v mezinárodním tvaru.
Miroslav Hanák, Michal Hrušecký: ochrana před útoky pomocí routerů Turris
Turris vznikl v roce 2013 jako výzkumný a bezpečnostní projekt, během kterého byla vytvořena bezpečnostní sonda. Ta byla rozdána do domácností a mimo jiné se chovala jako router. Jelikož jsme to dělali v CZ.NIC, všechno bylo open source. Doufali jsme, že nám lidé pomohou posbírat informace o situaci v domácnostech.
Cílem bylo zjistit, jestli někdo útočí i na běžné uživatele, nejen na servery, na kterých běží nějaké služby.
Původní uživatelské rozhraní nebylo příliš uživatelsky přívětivé, ale už od začátku nabízelo automatické aktualizace. Opravovali jsme bezpečnostní chyby a zároveň jsme měli možnost aktualizovat software pro sběr dat.
Sbíraly se záznamy z firewallů, data z pastí na útočníky a anonymizované statistiky o provozu. Snažili jsme se charakterizovat různé typy provozů a zkoumat, zda někdo po cestě například nepodvrhuje certifikáty.
Router byl oblíbený mezi geeky a zaujal i v cizině.
Ukázalo se, že poznat něco z provozu zevnitř je bez kontextu velmi těžké. Typicky nám tam vyskakovali klienti Bittorrentu, kteří obvykle vytvářejí divný provoz.
Zároveň správcům chyběly informace o obsahu, které se od začátku rozhodli kvůli ochraně soukromí nesbírat. Zajímavější výsledky nám dávají data o tom, co přichází z vnější strany.
Zjistilo se, že i na domácí uživatele se často útočí. IPv4 adres je tak málo, že si je útočníci najdou.
Později bylo rozhodnuto o pokračování v projektu, takže vznikl router Turris Omnia, který bylo možné pořídit během crowdfundingové kampaně a později v běžných internetových obchodech. Přišli jsme s přívětivější verzí uživatelského rozhraní, která je vhodnější pro běžné komerční uživatele.
Ukázalo se také, že uživatelé rádi házejí klacky pod nohy útočníkům. Vznikla proto služba HaaS (Honeypot as a Service). Uživatel si může jednoduše nainstalovat službu, která přesměruje provoz na servery CZ.NIC.
Útočník pak má pocit, že je na běžném SSH, ale je v pasti, která zaznamenává veškeré jeho chování včetně hesel. Ta data jsou veřejně k dispozici, takže se může kdokoliv podívat, co útočníci zkoušejí.
Později vznikl další hardware: Turris Mox. Jde o modulární router, který umožňuje postavit vlastní hardware podle svých potřeb. Ukázalo se, že to je zajímavý koncept hlavně pro ještě větší geeky než původní Omnie. Pro běžné uživatele je to ale už těžce uchopitelné.
Proto přišel další krok v podobě Turris Shield, což je Turris pro běžné lidi. Z uživatelského rozhraní jsme vyhodili všechna složitější nastavení, aby byla správa jednoduchá.
Turris Shield obsahuje OpenVPN klient a server, velmi zjednodušené uživatelské rozhraní reForis a hardware vychází z Turris Mox. Ve výchozím stavu je zapnutý modul Turris:Sentinel, který umožňuje uživatele chránit.
Sentinel je nový a lepší systém pro sběru dat, který odstraňuje nedostatky starého systému uCollect. Vstupem jsou bezpečnostní data a výstupem je pak dynamický firewall, greylist a data pro další analýzy a statistiky. Data jsou sbírána na jednotlivých routerech a posílají se do našeho datacentra, kde se vyhodnocují.
Každá IP adresa má jisté hodnocení a pokud je překročena nastavená hodnota, je přístup zablokován na všech připojeních routerech. Data jsou zpracovávána v reálném čase, proudově a při přenosu se využívají protokoly MQTT a ZMQ.
Součástí Sentinelu jsou také Minipoty, což jsou minimalistické pasti, které sledují útočníkovy aktivity. Zajímají nás jen připojení a pokusy o přihlášení.
V současné době jsou k dispozici čtyři typy minipotů: HTTP, FTP, SMTP a telnet. Útočník nemá přístup k reálnému systému, jsou mu emulovány nejpoužívanější servery.
Útočník se úspěšně připojí, zkusí se několikrát přihlásit a potom je odpojen. Z hlediska útočníka to vypadá legitimně jako nepovedené přihlášení, ale my jsme vylákali přihlašovací údaje, které se pokusil použít.
Většina nasbíraných dat pochází ze SMTP, obecně se většina útočníků jen pokusí připojit a nic dalšího nedělá. Většina IP adres také útočí jen na jeden z protokolů.
Nejvíce přihlašovacích údajů bylo získáno ze SMTP, celkem bylo použito více než 100 tisíc různých hesel. Unikátních hesel je výrazně více než uživatelských jmen.
Vizualizace získaných dat jsou dostupné na view.sentinel.turris.cz.