UDP Flood от Google или как да не лишим всички от Youtube

В един прекрасен пролетен вечер, когато не ми се искаше да се прибирам, а неугасимото желание да живея и да опознавам се бе настанило в мен като горещо желязо, ми хрумна идеята да поразгледам завладяващата функция на защитната стена, наречена «IP DOS политика«.
След предварителни прегледи и запознаване с ръководството, настроих в режим Pass-and-Log, за да видя какъв е изходът и съмнителната полезност на тази настройка.
След няколко дни (за да се събере статистика, разбира се, а не защото съм забравил) погледнах в логовете и, подскачайки на място, заплясках с ръце — записите се натрупаха до ръба на разума. Изглеждаше, че нещата са лесни — включи политиката в режим на блокировка на всички спамъри, сканери, които установяват half-open сесии с бан за час и спи спокойно с осъзнаването, че границата е затворена. Но 34-ата ми година преодоля младостта и някъде в задната част на мозъка прозвуча тънък гласец: «А нека повдигнем клепачи и да видим, кои адреси нашият любим защитен механизъм е разпознал като лоши спамъри? Е, в реда на абсурда.»

Започваме да анализираме получените данни от списъка с аномалии. Пропускам адресите през простичък скрипт Powershell и очите ми се натъкват на познати букви google.

Търкам очи, мигая пет минути, за да се уверя, че не ми се е привидяло — наистина в списъка на тези, които защитната стена е сметнала за злостни спамъри, тип на атаката — udp flood, адреси, принадлежащи на корпорацията на доброто.

Чеша се в тила, междувременно настройвайки захващането на пакети на външния интерфейс за последващ анализ. В главата ми минават радостни мисли: «Как може нещо инфектирано да съществува в обхвата на Google? И това го открих аз? Аха, награди, почести и червен килим, и собствено казино с блекджек и, ами разбрахте…»

Разглеждам получения файл Wireshark-ом.
Да, наистина от адреса в обхвата Google изпращат UDP пакети от 443 порта на произволен порт на моето устройство.
Но, чакайте… Протоколът се променя от UDP на GQUIC.
Семен Семенович…

Веднага ми идва наум докладът от HighLoad Александър Тоболя «UDP срещу TCP или бъдещето на мрежовия стек»(link).
От една страна, настъпва леко разочарование — нито лаврови венци, нито почести. От друга страна, проблемът е ясен, остава само да разбера къде и колко да копа.
Няколко минути разговор с Корпорацията на доброто — и всичко поема своя ход. В опит да подобри скоростта на доставка на съдържание компанията Google още през 2012 г. анонсира протокол QUIC, който позволява да се отстранят повечето недостатъци на TCP (да-да-да, в тези статии — Ррраз и Две става дума за абсолютно революционен подход, но да бъдем откровени, искаме просто котешките снимки да се зареждат по-бързо, а не всички ваши революции на съзнанието и прогреса). Както показа последващото изследване, много организации сега преминават към подобен вариант на доставка на съдържание.
Проблемът в моя случай и, предполагам, не само в моя, се оказа, че пакетите накрая са твърде много и защитната стена ги възприема като флууд.
Вариантите за решение се оказаха малко:
1. Да добавим в списъка с изключения за DoS Policy на защитната стена обхвата на адресите Google. Само за една мисъл за диапазона на възможните адреси, окото ми започна да трепери — идеята беше отложена като ненормална.
2. Да увеличим прага на сработване за udp flood policy — също не е решение, ами какво ако наистина някой злонамерен прокраде.
3. Да забраним достъпите от вътрешната мрежа до UDP на 443 порт навън.
След като прочетох допълнително за реализиране и интеграция, QUIC в Google Chrome беше взето като указание за действие последното решение. Факт е, че, любим на всички навсякъде и безпощадно(не разбирам защо, по-добре нахалната рижа Firefox-овска муцуна да получава за изядените гигабайти оперативна памет), Google Chrome първоначално се опитва да установи свързаност, използвайки своя дългоочакван QUIC, но ако чудото не се случи, се връща към проверени методи като TLS, макар и да му е срам от това.

Създаваме запис на защитната стена за услугата QUIC:

Настройваме ново правило и го слагаме някъде по-нагоре в веригата.

След включването на правилото в списъка с аномалии, тихо и гладко, с изключение на наистина злостни нарушители.

Благодаря на всички за вниманието.

Използвани ресурси:
1.Доклад на Александър Тоболя
2.Описание на протокола QUIC от компания Инфопулс
3.Уикипедия
4. KB от Fortinet

Източник: habr.com