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