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

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

Создаем на файрволе запись для сервиса QUIC:



Настраиваем новое правило и размещаем его где-нибудь повыше в цепочке.



После включения правила в списке аномалий тишь да гладь, за исключением действительно злостных нарушителей.



Спасибо всем за внимание.

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

Похожие публикации

Средняя зарплата в IT

113 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 10 037 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 59

    +4
    [off]
    Завязывали бы уже с этой своей «Корпорацией Добра» (да еще с большой буквы, блин).
    Никакого бобра уже давно нет, есть лишь банальное зарабатывание бабла без оглядки на что-либо.
    [/off]
      +11
      Я возможно неправильно понял, вы по сути запретили протокол quic для всей своей сети наружу?
        –3

        Да, именно так. Отвечая сразу же на вопрос "а зачем?" — в таком случае можно использовать встроенные возможности файрвола по отслеживанию и блокировке DoS атак типа udp flood, не переживая за то, что сервера Google попадут в бан.

          +5
          Так а не лучше было просто исключение в детектор атак добавить? Так себе воркэраунд вы конечно сделали
            –4

            Какое исключение? Скоуп Гугла?

            • НЛО прилетело и опубликовало эту надпись здесь
                +1

                Что Вы имеете в виду?

              +1
              и блокировке DoS атак типа udp flood
              Может я ошибаюсь, но… Вы блокируете UDP у себя на роутере, но до роутера UDP-трафик в любом случае доходит и забивает канал. Получается, что заниматься у себя блокировкой DoS атак чуть более чем бессмысленно, это нужно делать на стороне провайдера.
                0

                Он-то в любом случае доходит, согласен, и канал подгружает. Но, я думаю, таковы нынешние реалии. Ведь по хорошему, если рассматривать сферического коня в вакууме, это должен делать вообще провайдер, к которому флудящий подключен, на точке вхождения в сеть.

                  0
                  И при совсем злостной атаке упадет сам роутер?
                  P.S. Сам работал чуть больше года в провайдере (по корпоративным клиентам, ФОП и гос. структурам), бывал и такой тип DDoS как минимум 1 раз.
                    0
                    В целом это верно. Однако есть нюанс.
                    Далее я буду использовать терминологию MikroTik, наверно она подойдёт и для iptables, т.к. MikroTik на нём основан.
                    Смотрите, мы можем на основе каких-то признаков отловить ip флудера в ip firewall filter и занести его в лист, а затем уже в ip firewall raw сразу блокировать трафик от него. Тем самым мы отбрасываем флуд-трафик ещё до попадания его в connection tracker, т.е. трафик не обрабатывается connection tracker'ом и не проходит цепочку правил в файрволе, где бы он был заблокирован в «обычных» условиях. Тем самым в случае атаки можно довольно значительно снизить нагрузку на процессор.
                    Естественно здесь много переменных, как-то: ширина канала, мощность атаки, производительность процессора роутера. Однако в общем смысле мы таким приёмом можем сохранить работоспособность и контроль над самим роутером. Канал конечно все равно как был забит так и останется.
                    У автора поста судя по всему какой-то программный файрвол вряд ли допускающий настройку на таком уровне. Видимо вся блокировка будет происходить в тех же правилах файрвола, поэтому то что он сделал совершенно бессмысленная вещь. Только подпортил жизнь пользователям внутренней сети.
                      0

                      Файрвол не программный, а вполне себе аппаратный, только вот вариантов создания на нем адекватных динамических листов по принципу от уважаемого ua_lost_in_the_dark пока что не обнаружено. Завышать порог срабатывания на DoS политике, на мой взгляд, бессмысленно. Чем я по-Вашему подпортил жизнь пользователям внутренней сети?

                        0
                        Извиняюсь, я тут не корректно использовал термин «программный» (тот же MikroTik по сути тоже программный). Я имел в виду, что судя по всему (по скриншотам) это какое-то… как бы сказать?.. высокоуровневое решение. Т.е. мы тут тыкаем какие-то галочки, настраиваем правила, но при это логика работы, схема движения трафика и т.д. скрыта где-то внутри и мы не знаем как это работает.
                        Выше я написал как это происходит. Теперь главный вопрос — в используемом Вами решении где происходит блокировка флуд-трафика когда Вы включаете соответствующую настройку? Если это происходит где-то до обработки правил файрвола, тогда это имеет смысл (снижает нагрузку на процессор). Если в это происходит в самом файрволе, то не имеет. Потому что флуд-трафик и так осядет на граничном устройстве и дальше никуда не пойдёт. Сам канал Вы все равно не освободите что бы не делали (это у провайдера надо делать).
                        Плюс у нас остаётся открытым вопрос озвученный в соседнем комментарии — почему это решение не понимает, что трафик идёт в рамках законного соединения.
                        Жизнь пользователем подпортили отключив быстрый протокол QUIC. Это на самом деле не так страшно пока работает откат на TCP/TLS. По чеснаку сказать я сам UDP 443 на выход открыл полгода назад. Но это же не значит, что надо теперь его отключить ради очень сомнительных (в данном конкретном случае, на данном решении) способов защиты от флуда. К тому же грядёт HTTP/3 который, если я всё правильно помню, тоже будет работать на UDP.
                        Я ещё раз обращаю внимание, что я не призываю вовсе забить на защиту от флуда. Но надо делать это грамотно. Скажем на всё том же MikroTik'е реализуется и защита, и не надо при этом блокировать UDP 443.
                          0

                          По поводу "костыльности" данного решения я более чем с Вами согласен. Если удастся получить внятный ответ от вендора, почему так получается, буду рад сообщить. Срабатывание DoS политики происходит до обработки правил файрволом, то есть, отключив QUIC и переведя принудительно всех на TCP/TLS, я убираю возможность попадания в бан известных сервисов, вместе с тем закрывая периметр от других флудильщиков.

                            0
                            За одной небольшой но важной поправкой — Вы не периметр закрываете, а граничный роутер (и то даже так не корректно говорить). В периметр у Вас флуд-трафик и так не попадает. У вас же NAT. Вот пришел на ваш роутер флуд-трафик (не относящийся к уже установленному соединению). Роутер его с какой стати внутрь периметра отправит-то? У Вас же надеюсь нормально-закрытый файрвол, который внутрь периметра не пойми что не пропускает? Поэтому я повторяюсь — у Вас что так. что сяк флуд во внутреннюю сеть не попадёт. Тут просто вопрос на каком этапе мы его порубим.
                              0
                              Пересмотрел сейчас, что пишет вендор по этому поводу.
                              FortiOS applies DoS protection very early in its traffic processing sequence to minimize the effect of a DoS attack on FortiOS system performance. DoS protection is the first step for packets after they are received by a FortiGate interface. Potential DoS attacks are detected and blocked before the packets are sent to other FortiOS systems.

                              FortiOS also includes an access control list feature that is implemented next. This accelerated ACL technology uses NP6 processors to block traffic (including DoS attacks) by source and destination address and service again before the packets are sent to the FortiGate CPU

                              Таким образом, включая DoS политику, я как раз и разгружаю систему от необходимости обработки ненужных пакетов политиками файрвола.
                                0
                                Вот! Уже более менее понятно становится. Осталось научить эту штуку определять, что у нас трафик, проходящий в рамках уже установленного соединения, является легитимным и его источник не надо банить. Тогда всё станет прекрасно и можно будет открыть пользователям QUIC.
                                  0
                                  Если я правильно понял из описания технологии и логики — никак не получится, разве что узлы назначения добавлять в списки исключений для дос политики.
                                    0
                                    Это крайне странно как по мне. Думаю надо всё таки искать где это настраивается.
                                    В противном случае эту защиту лучше выключить и вернуть назад QUIC. От него толку больше чем от мифического снижения нагрузки на роутер в случае атаки (которой может и не быть никогда). Ну это моё мнение.
                        0
                        Mur81

                        ```Смотрите, мы можем на основе каких-то признаков отловить ip флудера в ip firewall filter и занести его в лист```

                        На самом деле это уже удел IDS/IPS систем. Хотя и их можно к тику прикрутить.
                          0
                          Эка Вы круто хватили. Вы же думаю не хуже меня понимаете, что IDS/IPS используются в крупных организациях, да и то вряд ли во всех. Малый и средний бизнес такое себе позволить не может, да и не нужно оно там прямо скажем.
                          В подавляющем большинстве внедрений защита реализована на граничном роутере его встроенными средствами. Хотя признаемся честно — это хорошо если она хотя бы так реализована.
                          В любом случае я выше описал принцип работы. Можно отлавливать флудера в файрволе, можно средствами IDS/IPS на более высоком уровне. Смысл в том, что бы потом заблокировать этот трафик как можно раньше не пуская его по цепочке.
                            0
                            Увы, встроенных сигнатур IPS не хватает для того, чтобы этот флуд пресечь, написать свои — ну пока еще не умею. И опять же логика моего фаервола такая, что ips цепляется на то или иное правило в цепочке. В результате, если отсекать через IPS, то пакет все равно будет попадать внутрь, а DoS политика обрубит его раньше, еще и в бан отправит.
                              0
                              Увы, встроенных сигнатур IPS не хватает для того, чтобы этот флуд пресечь, написать свои — ну пока еще не умею


                              Ну так лучше этот вопрос задать в комьюнити суриката например. Не думаю что вы первый встретили такие вещи.
                                0
                                Почему сурриката? А на вендорном форуме как раз вот это решение и описано. В конце статьи ссылка на KB от Fortinet
                                  0
                                  как пример не более. Шаблоны snort и suricata более мение стандартизированы
                                    0
                                    Да, фортигейт использует синтаксис снорта, будем поискать.
                              0
                              Малый и средний бизнес такое себе позволить не может, да и не нужно оно там прямо скажем.


                              Понятие малый и средний у всех разные, но в целом уже может.
                              Тот же pfsence имеет встроеные средства и бесплатные обновления раз в месяц вроде.

                              Для mikrotik люди используют SELKS обычно.
                              Это нужно не только от каких-то атак из вне, но и просмотр вещей внутри сети.
                              Но тут каждый решает сам, что как зачем и почему.
                                +1
                                Всё верно Вы конечно говорите.
                                В качестве оффтопика скажу, что я наблюдаю окружающую обстановку и к сожалению могу констатировать удручающий факт — на фоне общего экономического упадка в стране работодателям это всё на хрен не нужно. Не готовы вкладываться в нормальную ИТ-инфраструктуру. Не готовы платить хорошую з/п квалифицированным кадрам. В принципе мало кто готов вообще вкладываться в бизнес с расчётом на долгую перспективу. Всем надо здесь и сейчас и что бы по быстрее и подешевле (идеально — бесплатно). От боссов только и слышишь «да что ты нам тут говоришь про перспективы 3-5 лет, делай на год, там может мы закроемся вообще».
                                Как нам все говорят — вкладывайтесь в своё образование, это самое выгодное вложение. Да конечно. Знаний полная голова, спроса на них нет.
                                Есть конечно организации где всё хорошо. В основном это те кто выкапывает полезные ископаемые и выдают кредиты. Но сколько таких организаций в процентном отношении по рабочим местам?
                                Это то что я вокруг себя наблюдаю. IDS/IPS им точно не нужны.
                                Сорян, что-то накатило.
                    +4
                    О, сколько нам открытий чудных… готовит 2019 год. Художественных отсылок многовато, имхо.
                      +4
                      Почему нельзя исползовать например conntrack или правило на фаерволе, которое будет разрешать входящие udp пакеты с списка адресов.
                      Создать список:
                      ipset -N gquic_set nethash
                      Сам список адресов организовать с помощю ipset автоматическим добавлением в список правилом типа:

                      iptables -A FORWARD \
                      -p udp --dport 443 \
                      -s 10.0.0.0/8 \
                      -j SET --add-set gquic_set dst

                      Таким образом, хосты dst будут попадать в список, если клиент из внутреней сети 10.0.0.0/8 отослал пакет на 443 порт по udp.
                      Дальше по этому списку можно разрешать ходить пакетам.
                        +2

                        Конкретно в моем случае, Fortigate я не нашел возможности динамической генерации списка. Согласен, такой метод намного предпочтительней.

                        +7

                        Лечим перхоть гильотиной

                          +4
                          HTTP/3: разрушение основ и дивный новый мир
                          В теории это должно работать как часы, но на практике мы наткнёмся на то, что UDP может быть, например, запрещён на файрволе во избежание DDoS атак.
                          Пам-пам
                            +4

                            Предвижу, что Гугл отключит фоллбэк на TCP и такой провайдер как вы — будете отвечать в коллцентре на вопрос почему YouTube не работает.


                            Помимо Google этот протокол юзает Cloudflare, вообщем то непонятными идеями по безопасности вы ухудшаете ситуацию для своих пользователей, подтверждая основную идею:


                            что провайдер это труба и в трубе не должно быть никаких фаерволов, что клиент запросил или передал — должно доходить в неизменном виде.

                              0

                              А почему Вы вдруг решили, что я провайдер?

                                0

                                Тогда это ещё более странное действие, какой смысл у себя на роутере блокировать какие либо протоколы ?

                                  0

                                  Есть определенные моменты по безопасности. Есть ряд источников с которых идёт флуд по udp. А Вы у себя на пограничном все-все-все разрешаете?

                                    0

                                    Для домашней сети — не вижу причин делать ограничения, с учетом IPv6 проблема безопасности и ограничений — проблема конечных устройств, сейчас и так на каждом девайсе есть файрволл.

                                      +4
                                      А как udp пакеты влияют на безопасность? И что в вашем понимании флуд? Флуд — это же бесполезный трафик, а HTTP/3 это почти наступившее будущее, а для сервисов гугла уже давно настоящее.
                                        0

                                        Да, но кроме полезного трафика от Гугла есть ещё ряд других товарищей, создающих именно бесполезный. И в контексте "ничего не делать, пусть весь трафик, включая ненужный пробегается по всем правилам и лишний раз нагружает железку ИЛИ переключить сервисы Гугла И НЕ ТОЛЬКО на использование TCP, остальных в бан" я выбрал второй путь. Ведь по такой логике и fail2ban не нужен.

                                          0
                                          Современные реалии таковы, что самостоятельно блокировать дос-флуд на конечных узлах технически невозможно. Это должен делать или твой провайдер или соединяться с каким-то облаком безопасности, которое бы риал-тайм имело информацию о всех бот-сетях и проходящих атаках и автоматически конфигурировало бы ваши IPS-ки и файрволы. Но даже это лучше делать на стороне провайдера.
                                          Максимум что сейчас можно сделать конечному хосту, это включить syn_cookies и начинать копить бабло на готовые облачные решения. Пытаться самому генерить какие-то листы на основе наколеночной эвристики — это создать больше вреда бизнесу и пользователям, чем пользы.
                                0

                                на скрине ещё можно покрасить адреса *.1e100.net – это тоже сервера гугла…

                                  0

                                  Ага, я так, первые попавшиеся взял, спасибо большое за подсказку.

                                  0
                                  Никогда такого не было и вот опять. Вспоминаем стенания когда вышел протокол μTP. Ну а так, автор, с разморозкой! В 2019 году, увидя трафик от гугла по udp и не связать это с QUIC, о котором протрындели уже все уши последние пару лет, особенно, в англоязычном сегменте интерент. Ну я не знаю, на какие порталы вы подписаны и как отслеживаете, что происходит в инудстрии дикого (и не очень) веба.
                                    0
                                    Так про QUIC трындели 5-6 лет назад, а он разморозился чуть-чуть позже :)
                                      0
                                      Да, и то, что QUIC гугл тащил как http/2 стандарт, и что сейчас на его основе тот же гугл тащит http/3 )
                                        0
                                        Гугл постоянно что-то тащит, тема приелась уже :))
                                    +2

                                    Почему ваш файрвол считает флудом законный трафик который идёт в рамках установленного соединения? Да, я понимаю, что термин "установленное соединение" для UDP применять не совсем корректно, однако нормальный файрвол умеет понимать, что кто-то обращался по UDP и этот трафик льётся ему в ответ.
                                    К тому же если у Вас NAT (а я понял, что так и есть), то весь пришедший к вам трафик, в случае если роутер не понимает для кого он, и так должен быть отброшен. В этом случае определять флудера имеет смысл только если блокировать его трафик где-то раньше по цепочке, тем самым понизив нагрузку на процессор в случае атаки. Если блочить флудера всё тем же файрволом, то смысла нет практически никакого, канал-то всё равно забит будет что так, что сяк.
                                    Если не я где-то не прав, то более знающие товарищи поправьте.

                                      0
                                      Почему файрвол считает флудом трафик в рамках законного соединения — вопрос хороший, но скорее к вендору. Я продолжаю разбираться в причинах такого поведения, если будут результаты — будет апдейт статьи.
                                        0
                                        Просто производитель не знает о UDP hole punching, либо вы что-то выключили по незнанию.
                                          0
                                          И производитель знает, и я ничего не выключал лишнего. Вся загвоздка в том, что DoS Policy у этого вендора обрабатывает входящий трафик до попадания его в цепочку правил фарвола.
                                      +1

                                      Автор. Это не флуд. Это ложно-положительное срабатывание.
                                      При одинаковом битрейте видео потока, TCP будет создавать чуть больше трафика. А загрузка видео, будет происходить чуть медленнее.

                                        0
                                        Это как раз понятно, пока непонятно каким образом можно выйти из положения более кошерным образом, чем блокируя quic.
                                          0
                                          Знаете вы похожи на того чувака с 4pda, которому не понравилось, что роутер отправляет igmp3 запросы всем клиентам (о ужас) каждую минуту (о кошмар). Вот только, это запросы ПО СТАНДАРТУ. И без них отваливались торренты, телек, samba и т.д. Вы вообще в курсе, что если у вас много пиров в uttorrent (больше 300), то вас еще минут 50 после выключения uttorent будут бомбить, опрашивая порт? И по стандарту, как бы так и должно быть. И вообще, я не понимаю, тут современный канал до провайдера уже 1000 Мбит/с (у меня МГТС 500 mbit). А вам потока не хватает. И еще. Там на первом скриншоте. Везде, где есть 1е100 в домене, это тоже google. Так как он назван от числа с 100 нулями. И вообще PTR RR это хрень какая-то, надо автномную систему опрашивать с помощью AS WHOIS. Тогда вы точно будете уверены, откуда к вам стучатся.
                                            0
                                            Сударь, я же не навожу истерику по поводу того, что, Боже, о Ужас, QUIC работает — срочно заблокировать. Я прекрасно понимаю, что это стандартный и рабочий режим протокола. Я в статье пытался показать о варианте решения, когда необходимо включение DoS политики, но при этом не обрубив доступы к «правильным» сервисам.
                                            P.S. К слову, torrent у нас запрещен.
                                              0
                                              Это как это запрещен? Его нельзя запретить, не сломав весь интернет нафиг, я например, ubuntu когда iso качаю, с официального сайта беру torrent… включите шифрование в utorrent и будет работать.
                                                0
                                                Торрент запрещен внутри сети.
                                                  0
                                                  Ммм. Ну можно зайти в другую сеть (VPN) и оттуда все будет работать. Или вы на словах его запретили))))
                                                0
                                                И кстати, вы не ответили насчет ptr. Ведь у ip может и не быть ptr, а вот автономная система у него всегда есть. См. bgp.he.net

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое