🥇UDP Flood от Google или как не лишить всех Youtube

Одним прекрасным весенним вечером, когда идти домой не хотелось, а неуемное желание жить и познавать свербило и жгло аки каленым железом, возникла идея поковырять заманчивую приблуду фичу на файрволе под названием «IP DOS policy«.
После предварительных ласок и ознакомления с мануалом настроил в режиме 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, хоть и стыдится этого дичайше.