Одним прекрасным весенним вечером, когда идти домой не хотелось, а неуемное желание жить и познавать свербило и жгло аки каленым железом, возникла идея поковырять заманчивую приблуду фичу на файрволе под названием «IP DOS policy".
После предварительных ласок и ознакомления с мануалом настроил в режиме Pass-and-Log, чтобы посмотреть вообще на выхлоп и сомнительную полезность данной настройки.
Спустя пару дней (чтобы статистика набралась, конечно, а не потому что забыл) взглянул в логи и, пританцовывая на месте, захлопал в ладоши — записей набралось по самое не балуйся. Казалось бы, чего проще — включай политику в режим блокировки всех флудящих, сканящих, устанавливающих heal iepen сессии с баном на час и спи себе спокойно с осознанием того факта, что граница на замке. Но 34-ый год жизни преодолел юношеский максимализм и где-то на затылочном участке мозга прозвучал тоненький голосок:«А давай-ка поднимем веки и посмотрим, а чьи же адреса наш любимый файрвол распознал как злостных флудильщиков? Ну так, в порядке бреда.»
Начинаем анализировать полученные данные со списка аномалий. Прогоняю адреса через простенький скрипт Powershell и глаза натыкаются на знакомые буквы google.
Тру глаза, моргаю минут пять, дабы убедиться, что мне не почудилось — действительно в списке тех, кого файрвол посчитал злостным флудильщиком, тип атаки — udp flood, адреса, принадлежащие корпорации добра.
Чешу в затылке, попутно настраивая на внешнем интерфейсе захват пакетов для последующего анализа. В голове проносятся радужные мысли: «Как так, что-то инфицированное в скоупе Google? И это обнаружил я? Да это ж, это ж — награды, почести и красная ковровая дорожка, и свое казино с блекджеком и, ну вы поняли…»
Разбираю полученный файл Wireshark-om.
Да, действительно с адреса из скоупа Google фигачат пакеты UDP с 443 порта на рандомный порт на моем девайсе.
Но, постойте-ка… Вот протокол сменяется с UDP op GQUIC.
Семен Семеныч…
Сразу же вспоминается доклад с hege lading Александра Тоболя «UDP tsjin TCP или будущее сетевого стека»().
С одной стороны, наступает легкое разочарование — ни тебе, барин, лавров, ни почестей. С другой стороны, проблема ясна, осталось понять куда и сколько копать.
Пару минут общения с Корпорацией Добра — и все встает на свои места. В попытке улучшить скорость доставки контента компания Google еще в 2012 году анонсировала протокол QUIC, позволяющий убрать большую часть недостатков TCP (да-да-да, в этих статьях — и говорится о совершенно революционном подходе, но, будем откровенны, хочется, чтобы фоточки с котиками загружались побыстрее, а не вот эти вот все ваши революции сознания и прогресса). Как показало дальнейшее исследование, на подобный вариант доставки контента многие организации сейчас переходят.
Проблема в моем и, я думаю, не только в моем случае оказалась в том, что пакетов в итоге идет очень уж много и файрвол воспринимает их как флуд.
Вариантов решения оказалось немного:
1. Добавить в список исключения для DoS Policy на файрволе скоуп адресов Google. При одной только мысли о диапазоне возможных адресов глазик начал нервно дергаться — отложена идея как бредовая.
2. Повысить порог срабатывания для udp flood policy — тоже не комильфо, а вдруг кто действительно зловредный прошмыгнет.
3. Запретить обращения из внутренней сети по UDP op 443 порт наружу.
Почитав дополнительно про реализацию и интеграцию QUIC в Google Chrome был принят как указание к действию последний вариант. Дело в том, что, любимый всеми повсеместно и беспощадно(не пойму за что, уж лучше наглая рыжая Firefox-овская морда будет получать за отожранные гигабайты оперативки), Google Chrome изначально пытается установить соединение с использованием своего выстраданного QUIC, но если чуда не происходит, то он возвращается к проверенным методам типа TLS, хоть и стыдится этого дичайше.
Создаем на файрволе запись для сервиса QUIC:
Настраиваем новое правило и размещаем его где-нибудь повыше в цепочке.
После включения правила в списке аномалий тишь да гладь, за исключением действительно злостных нарушителей.
Спасибо всем за внимание.
Использованные ресурсы:
1.
2.
3.
4.
Boarne: www.habr.com