Jednoho krásného jarního večera, kdy se mi nechtělo jít domů, a neukojitelná touha žít a poznávat mě svrběla a pálila jako rozpálené železo, vznikl nápad pohrabat se v lákavé novince na firewallu nazvané „IP DOS policy«.
Po úvodních přípravách a prostudování manuálu jsem nastavil režim Pass-and-Log, abych se podíval, jaký bude výstup a pochybná užitečnost tohoto nastavení.
Po pár dnech (aby se statistiky nashromáždily, samozřejmě, a ne proto, že bych zapomněl) jsem se podíval do logů a tleskal jsem, skákaje na místě — byly tam záznamy až až. Zdálo by se, že co může být jednodušší — zapni pravidlo v režimu blokování všech, kteří floodují, skenují, zakládají half-open sestavy s banem na hodinu a můžeš spát v klidu s vědomím, že hranice je pod zámkem. Ale třicátý čtvrtý rok života přetlačil mladistvý maximalismus a kdesi na zátylku se ozval jemný hlásek: „A co říkáš na to, podívat se, které adresy náš milovaný firewall rozpoznal jako zločinné floodery? No, tak pro jistotu.“
Začínáme analyzovat získané údaje se seznamem anomálií. Procházím adresy skrze jednoduchý skript Powershell a oči narážejí na známá písmena google.
Třu si oči, mrkám pět minut, abych se ujistil, že se mi to nezdá — ve skutečnosti je na seznamu těch, které firewall považoval za zločinné floodery, typ útoku — udp flood, adresy patřící korporaci dobra.
Škrábu se na zátylku, zároveň nastavím na vnějším rozhraní zachytávání paketů pro následnou analýzu. V hlavě se mi rojí pestré myšlenky: „Jak je možné, že něco infikovaného je ve sféře Google? A to jsem objevil já? To je přece — odměny, pocty a červený koberec, a vlastní kasino s blackjackem a, no, rozumíte…“
Rozbírám získaný soubor Wireshark-em.
Ano, skutečně, z adresy ze sféry Google přicházejí UDP pakety z portu 443 na náhodný port na mém zařízení.
Ale, počkejte… Tady se protokol mění z UDP na GQUIC.
Semjon Semjonovič…
Okamžitě si vzpomínám na zprávu z HighLoad Alexandra Toboly «UDP proti TCP nebo budoucnost síťového zásobníku“ ().
Na jedné straně přichází mírné zklamání — ani laureáty, ani poct. Na druhou stranu, problém je jasný, zbývá pochopit, kam a kolik kopat.
Pár minut komunikace s Korporací Dobré — a všechno zapadne na svá místa. V pokusu o zlepšení rychlosti doručování obsahu společnost Google již v roce 2012 oznámila protokol QUIC, který umožňuje odstranit většinu nedostatků TCP (ano, ano, ano, v těchto článcích — a se hovoří o zcela revolučním přístupu, ale buďme upřímní, chtělo by to, aby se fotky koček načítaly rychleji, a ne ty vaše revoluce v myšlení a pokroku). Jak ukázal další výzkum, řada organizací nyní přechází na podobný způsob doručování obsahu.
Problém v mém a, jak si myslím, nejen mém případě byl v tom, že paketů nakonec jde opravdu hodně a firewall je vnímá jako flood.
Možností řešení bylo málo:
1. Přidat do seznamu výjimek pro DoS Policy na firewallu rozsah adres Google. Při pouhé myšlence na rozsah možných adres se mi začalo nervózně třást oko — myšlenka byla odložena jako bláznivá.
2. Zvednout prah pro aktivaci pro udp flood policy — také nekomilfo, a co když se někdo skutečně zlý prosmýkne.
3. Zakázat přístupy z vnitřní sítě po UDP na 443 portu ven.
Po dalším prostudování realizace a integrace QUIC v Google Chrome byla přijata jako pokyn k akci poslední varianta. Skutečnost je taková, že, milovaný všemi nekompromisně (nechápu proč, raději by se měla dostávat pokuta nastrkaná krásně oranžovou Firefox-ovou tváří za průběžně spotřebované gigabajty operační paměti), Google Chrome původně se pokouší navázat spojení pomocí svého trpělivě vybojovaného QUIC, ale pokud je zázrak neuskutečnen, vrací se k osvědčeným metodám, jako je TLS, i když se toho kvůli proviněným velice stydí.
Na firewallu vytváříme záznam pro službu QUIC:
Nastavujeme nové pravidlo a umisťujeme ho někam výše v řetězci.
Po aktivaci pravidla v seznamu anomálií ticho a klid, kromě opravdu zlovolných porušovatelů.
Děkuji všem za pozornost.
Použité zdroje:
1.
2.
3.
4.
Zdroj: habr.com
