← Cloudflare Magic Transit / magic-transit / reference

Ochrana anti-replay

Pokud používáte Magic Transit a anycast U tunelů IPsec doporučujeme zakázat ochranu anti-replay. Cloudflare toto nastavení ve výchozím nastavení vypíná. Pro zařízení, která zákaz této funkce nepodporují, včetně Cisco Meraki, Velocloud a AWS VPN Gateway, ji však můžete povolit přes API nebo Cloudflare dashboard.

Viz Přidejte tunely kde zjistíte, jak nastavit ochranu proti opakování. Tato stránka vysvětluje útoky typu replay, důvody, proč Cloudflare doporučuje deaktivovat funkci IPsec anti-replay, a související aspekty.

K útokům opakováním dochází, když útočník zachytí a zaznamená paket ↗, a poté zaznamenaný paket znovu odešle do cílové sítě se záměrem, který útočníkovi prospívá.

Uvažujme špatně navržený otvírač garážových vrat pro internet věcí (IoT). Zařízení má jednoduchý protokol pro svůj provoz: paket User Datagram Protocol (UDP) obsahuje heslo od garážových vrat a buď open nebo shut ve svém datovém segmentu. Klíč od garážových vrat zašifruje datový segment a telefon majitele jej odešle, aby vrata otevřel nebo zavřel.

Útočník pravděpodobně nedokáže otevřít nebo zavřít vrata garáže pouhým uhodnutím šifrovacího klíče a hesla. Zašifrovaný obsah zachyceného paketu sice vidět nemůže, ale pokud má garáž na dohled, může se pokusit propojit si a uhodnout, které pakety mají na starosti otevírání vrat garáže. Až bude chtít vrata otevřít, odešle zaznamenaný open paket, a protože by zaznamenaný paket obsahoval heslo a už by byl zašifrovaný správným klíčem, tyto dveře by se otevřely.

Aby se tomuto útoku opakováním předešlo, mohl by uživatel ke každému příkazu zasílanému vratům garáže přidat číslo paketu. První by mohlo být packet 1, druhý packet 2 a tak dále, přičemž vrata garáže by pokaždé přijala pouze pakety obsahující další číslo v pořadí. Například poté, co vrata garáže přijmou packet 1, přijala by pouze paket 2, a pokud by útočník zkusil znovu přehrát packet 1, garážová vrata požadavek ignorují.

Ochrana anti-replay IPsec funguje podobně jako příklad prevence ve scénáři výše. Odesílatel přiřadí každému paketu IPsec sekvenční číslo. Příjemce sleduje, jaká sekvenční čísla už viděl, a přijímá pouze pakety spadající do malého okna kolem nejvyšší dosud přijaté hodnoty; toto okno má obvykle velikost 64 až 1024 paketů. IPsec používá okno místo přísného řazení, protože pakety se na internetu občas přeuspořádají nebo ztratí: rozsah přípustných sekvenčních čísel paketů pomáhá tyto problémy vyřešit.

Standardní ochrana anti-replay IPsec počítá s jediným odesílatelem a jediným příjemcem. Odesílatel uchovává sekvenční číslo v paměti a s každým paketem ho zvyšuje. Příjemce sleduje, jaká sekvenční čísla už zpracoval.

Architektura anycastu Cloudflare tomuto modelu neodpovídá. Magic Transit totiž využívá anycast, může kterýkoli paket zpracovat libovolný z tisíců serverů rozmístěných ve stovkách datových center. Právě toto distribuované zpracování dává Magic Transit jeho výkon a odolnost, znamená to však, že žádný jednotlivý server nemá úplný přehled o stavu sekvenčních čísel.

Pokud pro IPsec tunely Magic Transit povolíte ochranu anti-replay, Cloudflare směruje pakety pro jeden tunel na jediný server, který sleduje pořadové číslo. Tento mechanismus v daném režimu funguje správně, ale přicházíte o výhodu rozložení provozu mezi globální servery Cloudflare. Navíc funguje pouze jedním směrem, z Cloudflare do sítě zákazníka: Cloudflare nesměruje pakety ze sítě zákazníka na jediný server a v opačném směru ochranu anti-replay neuplatňuje.

Ochrana proti replay útokům (anti-replay protection) je pro transportní režim naprosto klíčová, tedy pro IPsec mezi jednotlivými hostiteli nebo dokonce mezi aplikacemi. V transportním režimu útočník poměrně snadno rozezná šifrovaný protokol a zjistí, které pakety lze zopakovat, pokud je daný protokol vůbec zranitelný vůči replay útokům. Magic Transit ovšem využívá tunelový režim, ve kterém je úspěšné provedení replay útoku podstatně obtížnější.

Existuje několik důvodů, proč jsou útoky typu replay v tunelovém režimu obtížné:

• IPsec šifruje celý vnitřní paket, takže útočník o zachyceném uživatelském paketu prakticky nic nezjistí a nemůže provést korelaci pro replay útok. Jediné, co útočník zjistí, je síť pobočky, která paket zašifrovala, síť pobočky, která ho přijala, a přibližná velikost paketu. Tyto informace však nestačí k identifikaci konkrétních toků vnitřních uživatelských paketů potřebných ke korelaci a přehrání.
• Útoky opakováním fungují pouze tehdy, pokud útočníci použijí stejné šifrovací klíče. Po rekeyingu router staré opakované pakety zahazuje.
• Většina protokolů není na úrovni paketů náchylná k útokům typu replay. Internet dokáže pakety duplikovat, a proto TCP a řada protokolů postavených na UDP už obsahuje pořadová čísla nebo podobný mechanismus pro zpracování duplicitních paketů. U těchto protokolů pak replay provoz vypadá jen jako duplicitní paket a cílové zařízení ho zpracuje správně.
• Ochranu anti-replay lze zajistit i ve vyšší vrstvě modelu OSI (Open Systems Interconnection). Řada moderních aplikací totiž k přenosu dat využívá zabezpečené komunikační protokoly, jako je Secure Sockets Layer/Transport Layer Security (SSL/TLS), Secure Shell (SSH) nebo SSH File Transfer Protocol (SFTP). Tyto protokoly, které pracují ve vyšší vrstvě OSI než síťová vrstva, podporují ochranu anti-replay nativně.
• Menší útočná plocha snižuje pravděpodobnost zachycení paketů. Tunely IPsec jsou site-to-site VPN tunely mezi routerem pobočky uživatele a globální sítí Cloudflare, vedené přes vyhrazená síťová připojení poskytovatele internetových služeb (ISP), která bývají velmi bezpečná. Anycast povaha implementace IPsec od Cloudflare navíc ukončuje tunel IPsec v jednom z více než 300 datových center Cloudflare nejbližších k hraničnímu routeru zákazníka, čímž se minimalizuje fyzická vzdálenost a rozsah, který musí šifrované pakety urazit.

Pokud se u vás projevuje nestabilita tunelu nebo ztráty paketů související s ochranou anti-replay, přejděte na Odstraňování problémů se stavem tunelu.