15.1.2014 05:16
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Rozbalit Rozbalit vše Re: Jaderné noviny – 19. 12. 2013: Port knocking v jádře
Portál AbcLinuxu, 5. června 2024 14:51
Aktuální verze jádra: 3.13-rc4. Citáty týdne: Hugh Dickins, Al Viro. Návrh na "tiché" klepání na porty.
Aktuální vývojová verze jádra je 3.13-rc4 vydaná poněkud rozmrzelým Linusem 15. prosince. Takže jsem to tentokrát opozdil o několik dnů, abych se vrátil k mému běžnému vydávání v neděli, ale nejsem s výsledkem úplně spokojený. Věci se neuklidňují tak, jak by měly, a -rc4 je větší než ty předchozí. A nemyslím si, že by byly na vině ty dva dny navíc.
Stabilní aktualizace: verze 3.12.5, 3.10.24 a 3.4.74 vyšly 11. prosince. Verze 3.12.6, 3.10.25 a 3.4.75 se aktuálně revidují. Jejich vydání lze očekávat 20. prosince nebo později.
A jéje, ty po mně chceš, abych si znovu pročetl memory-barriers.txt (Vánoční vydání 2013) a dospěl k nějakému závěru. [...]
Jedním z problémů je, že u ACCESS_ONCE člověk snadno nabude mylného dojmu, že je zapotřebí všude; ale této iluzi je třeba odolat.
Se spinlockem by to nemělo být potřeba, ale budu se muset zamyslet nad polopropustnými membránami, osmózou a podobnými věcmi.
-- Hugh Dickins
Po pravdě přemýšlím, jestli se toho nesnažíme nacpat do jednoho syscallu příliš – nejen co se přetěžování týče (to je zjevné), ale i co se vměstnání sekvence syscallů do jediného týče. Pokud nakonec budeme zavádět nové/á API pro mount(), tak bychom asi měli zvážit následující:
-- Al Viro uvažuje o lepším mount()
Klepání na porty (port knocking) je již dlouho existující technika, jak se vyhnout skenování portů, která je obvykle implementována v uživatelském prostoru. Nedávný patch navržený pro jádro by toto změnil tím, že přidává podporu pro port knocking přímo do vrstvy TCP/IP. Kromě možnosti toho, aby administrátoři skrývali otevřené porty, by patch také nabízel jistý způsob, jak zmařit útoky typu man-in-the-middle, protože se útočníkovi nepodaří připojit se na tyto skryté porty. Patch ale čelí jistému odporu od vývojářů síťové vrstvy, kteří si myslí, že věci jako port knocking je lepší řešit v uživatelském prostoru.
Detaily kolem „klepání“ se liší, ale obecně jde o to, že chráněný port na serveru nebude reagovat na běžnou snahu o navázání spojení; místo toho je nutné udělat určité speciální kroky. Mezi ně může patřit pokus o připojení na jiný port nebo na celou řadu jiných portů, což serveru ukáže, že klient zná tajné zaklepání, aby mohl být vpuštěn do klubu. Jelikož nástroje pro skenování portů neznají tajné zaklepání a je velmi náročné zkoušet spousty možností, tak jsou služby chráněné klepáním ukryty před zraky.
Pro skrývání služeb mohou být různé důvody. Jedním může být, že serverový program má zranitelnosti, ať už protože nebyl aktualizován nebo protože jsou v kódu neznámé chyby. Pokud o zaklepání vědí jen důvěryhodné osoby, snižuje se riziko, že někdo chyby zneužije. Skrývání služeb jako SSH navíc zabrání útokům na uživatelské jméno a heslo hrubou silou.
Jsou ale i další důvody, proč skrýt nějakou službu: v určitých jurisdikcích může být nelegální nebo může příliš přitahovat pozornost danou službu provozovat. Lidé provozující mosty do Toru nebo jiné služby zaměřené na ochranu soukromí mohou narazit na blacklist poskytovatelů připojení provozovaných vládou – nebo se dočkat návštěvy nějaké tajné služby.
Stávající řešení pro port knocking obecně buď monitorují logy firewallu nebo zachytávají pakety v uživatelském prostoru a pak upraví firewall tak, aby při správném poklepání došlo k otevření portu. Projekt Knock – součást projektu GNUnet – to chce předělat. Pomocí patche o několika stovkách řádků se jeho autoři snaží o přesun logiky port knockingu do síťové vrstvy Linuxu. To by klientům a serverům umožnilo komunikovat při současném ukrývání za zaklepáním díky nové volbě pro setsockopt() nazvané TCP_STEALTH. Pokud by byl kód široce dostupný na linuxových jádrech, pak by se uživatelé mohli spolehnout na dostupnost této funkce místo nastavování jiného řešení.
Knock se od jiných řešení několika způsoby odlišuje. Především má být pro útočníka man-in-the-middle nezjistitelný. Vypadá to jako běžné spojení na konkrétní port – neobjevují se žádné dodatečné sekvence nebo spojení na jiný port nebo další zaklepání. Využívá se technika „tichého zaklepání“, pro kterou je nutné mít určitý tajný údaj společný pro server a klienta. Tento údaj je použit k vypočítání sekvenčního čísla počátečního paketu SYN, který je odeslán pro zahájení třícestného navázání spojení, kterým se TCP spojení uvozují. Jakýkoliv SYN se špatným sekvenčním číslem dostane odpověď RST; což přesně odpovídá zavřenému portu.
Možnost TCP_STEALTH_INTEGRITY navíc umožní ochranu prvních bajtů přenášených dat pomocí HMAC, což účinně zamezí útočníkům převzít spojení po jeho navázání. Vyšších 16 bitů sekvenčního čísla v SYN paketu odpovídá HMAC, zatímco spodních 16 bitů je autentizační kód, který pochází z MD5 tajného údaje.
32bitový autentizační kód je pro režim pouhého utajení vypočítán jednou aplikací MD5 za použití tajného údaje, cílové IP adresy a portu. V režimu utajení a integrity se klient a server musejí shodnout na počtu přenášených bajtů, které se mají ochránit pomocí HMAC, které také používá MD5. Krátký dokument o Knocku říká, že používání MD5 může být překvapivé, ale jádro jej už používá pro výpočet počátečního sekvenčního čísla TCP, stejně tak pro SYN cookies. Jacob Appelbaum (který se podílel na návrhu Knocku) není s MD5 stejně spokojený:
Pokud věříme tomu, že MD5 není bezpečné, pak bychom ho neměli používat. To, že ho ostatní používají, není dobrý důvod. Všichni by měli přestat MD5 používat – hlavně pak zkrácené MD5 :)
Režim pouhého utajení je náchylný k replay útokům, protože man in the middle může vysledovat správné sekvenční číslo pro odemčení portu a zopakovat jej ve svých vlastních paketech (aniž by tajný údaj znal). Navíc je náchylný k útokům hrubou silou (vyzkoušení všech sekvenčních čísel), ale to by mohlo být náročné na čas a není to zrovna nenápadné, takže by útok mohl být zaznamenán. Režim utajení a ověření integrity je odolnější, jelikož bajty chráněné pomocí HMAC by bylo možné použít pro přenesení veřejného klíče určeného pro šifrování zbytku dat.
Během diskuze byly odhaleny další nevýhody této techniky. Například implementace NATu, které mění sekvenční číslo, nebudou s touto technikou vůbec fungovat. David Miller upozornil, že i netfilter toto číslo mění, a to při sledování protokolů FTP a SIP a pro vyvažování zátěže virtuálních serverů.
Jiní byli toho názoru, že implementace tohoto typu port knockingu (nebo jakéhokoliv jiného typu) by mělo být uděláno mimo implementaci TCP – v uživatelském prostoru. Stephen Hemminger i Andi Kleen říkají, že právě uživatelský prostor by byl lepším domovem. Grothoff, který se pod patch podepsal (sign off) a poslal jej, byl tímto přístupem překvapen: Kdyby to byl patch pro GNU Hurd, tak bych aspoň chápal snahu mít vše v uživatelském prostoru. Kleen ale upozornil, že zachování port knockingu v uživatelském prostoru znamená, že riziko zavlečení zneužitelných chyb do jádra bude [značně] nižší.
I Eric Dumazet nápad kritizoval. Navrhl, že by uživatelský prostor mohl implementovat části protokolu TCP, což by pomohlo i jiným návrhům (jako TCP Minion).
Vzhledem ke všem možným návrhům (jako TCP minion) je možná lepší přidat možnost implementovat části TCP stacku v uživatelském prostoru. (Nechat skládání v jádře a přeposílat surové příchozí pakety do uživatelského prostoru, kde bude možné s nimi dělat šílené věci bez upravování jádra.)
Dumazet má také obavy, že opakované používání stejného počátečního sekvenčního čísla ztíží odhalování duplicitních paketů. Sice to nezmínil, ale opakování těchto čísel by mohlo útočníkovi poradit, že se používá port knocking. Celkově vzato měl Dumazet pocit, že dokument s popisem je příliš krátký na to, aby plně pokryl tuto myšlenku: Pro úplnou analýzu všech výhod a nevýhod tohoto nápadu je opravdu potřeba víc než 3 stránky.
Navíc poukázal na určitý způsob, jak by se Knock mohl dostat do jádra: TCP fast open je trochu podobné a do jádra se dostalo. Pokud by Knock byl víc jako fast open, nebo jej přímo používal, pak by byla šance, že se dostane do síťového kódu, větší. Obavy, které má Dumazet a jiní, jsou způsobené složitostí kódu, v němž je mnoho pohyblivých částí, které musejí fungovat správně. To je to, proč chtějí nechat věci jako port knocking na uživatelském prostoru.
Na druhou stranu není Grothoff přesvědčený, že ten malý patch, který poslal, může opodstatnit přesun TCP do uživatelského prostoru. Chladné přijetí od hlavních vývojářů síťové vrstvy ale znamená, že je dosti nepravděpodobné, že se patch kdy do jádra dostane. Práce na způsobech, jak buď přesunout některé části TCP do uživatelského prostoru, nebo rozšíření netfilteru, aby umožňoval port knocking i ochranu dat, by asi bylo nejlepším způsobem, jak postupovat dál. Jde o zajímavý nápad, i když není dokonalý, jenže protlačit jej do jádra by bylo velkým soubojem.
15.1.2014 05:16
Jendа | skóre: 78
| blog: Jenda
| JO70FB
by patch také nabízel jistý způsob, jak zmařit útoky typu man-in-the-middle, protože se útočníkovi nepodaří připojit se na tyto skryté portyHuh? Podívám se na handshake a až pak do komunikace vstoupím.
K "běžnému" port knockingu; kdyby někdo hledal lepší alternativu ke starému knockd, zkuste pknock xtables match, z xtables-addons, které v dnešní době balí už docela dost distribucí.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.