Comments 59
Да, именно так. Отвечая сразу же на вопрос "а зачем?" — в таком случае можно использовать встроенные возможности файрвола по отслеживанию и блокировке DoS атак типа udp flood, не переживая за то, что сервера Google попадут в бан.
и блокировке DoS атак типа udp floodМожет я ошибаюсь, но… Вы блокируете UDP у себя на роутере, но до роутера UDP-трафик в любом случае доходит и забивает канал. Получается, что заниматься у себя блокировкой DoS атак чуть более чем бессмысленно, это нужно делать на стороне провайдера.
Он-то в любом случае доходит, согласен, и канал подгружает. Но, я думаю, таковы нынешние реалии. Ведь по хорошему, если рассматривать сферического коня в вакууме, это должен делать вообще провайдер, к которому флудящий подключен, на точке вхождения в сеть.
P.S. Сам работал чуть больше года в провайдере (по корпоративным клиентам, ФОП и гос. структурам), бывал и такой тип DDoS как минимум 1 раз.
Далее я буду использовать терминологию MikroTik, наверно она подойдёт и для iptables, т.к. MikroTik на нём основан.
Смотрите, мы можем на основе каких-то признаков отловить ip флудера в ip firewall filter и занести его в лист, а затем уже в ip firewall raw сразу блокировать трафик от него. Тем самым мы отбрасываем флуд-трафик ещё до попадания его в connection tracker, т.е. трафик не обрабатывается connection tracker'ом и не проходит цепочку правил в файрволе, где бы он был заблокирован в «обычных» условиях. Тем самым в случае атаки можно довольно значительно снизить нагрузку на процессор.
Естественно здесь много переменных, как-то: ширина канала, мощность атаки, производительность процессора роутера. Однако в общем смысле мы таким приёмом можем сохранить работоспособность и контроль над самим роутером. Канал конечно все равно как был забит так и останется.
У автора поста судя по всему какой-то программный файрвол вряд ли допускающий настройку на таком уровне. Видимо вся блокировка будет происходить в тех же правилах файрвола, поэтому то что он сделал совершенно бессмысленная вещь. Только подпортил жизнь пользователям внутренней сети.
Файрвол не программный, а вполне себе аппаратный, только вот вариантов создания на нем адекватных динамических листов по принципу от уважаемого ua_lost_in_the_dark пока что не обнаружено. Завышать порог срабатывания на DoS политике, на мой взгляд, бессмысленно. Чем я по-Вашему подпортил жизнь пользователям внутренней сети?
Выше я написал как это происходит. Теперь главный вопрос — в используемом Вами решении где происходит блокировка флуд-трафика когда Вы включаете соответствующую настройку? Если это происходит где-то до обработки правил файрвола, тогда это имеет смысл (снижает нагрузку на процессор). Если в это происходит в самом файрволе, то не имеет. Потому что флуд-трафик и так осядет на граничном устройстве и дальше никуда не пойдёт. Сам канал Вы все равно не освободите что бы не делали (это у провайдера надо делать).
Плюс у нас остаётся открытым вопрос озвученный в соседнем комментарии — почему это решение не понимает, что трафик идёт в рамках законного соединения.
Жизнь пользователем подпортили отключив быстрый протокол QUIC. Это на самом деле не так страшно пока работает откат на TCP/TLS. По чеснаку сказать я сам UDP 443 на выход открыл полгода назад. Но это же не значит, что надо теперь его отключить ради очень сомнительных (в данном конкретном случае, на данном решении) способов защиты от флуда. К тому же грядёт HTTP/3 который, если я всё правильно помню, тоже будет работать на UDP.
Я ещё раз обращаю внимание, что я не призываю вовсе забить на защиту от флуда. Но надо делать это грамотно. Скажем на всё том же MikroTik'е реализуется и защита, и не надо при этом блокировать UDP 443.
По поводу "костыльности" данного решения я более чем с Вами согласен. Если удастся получить внятный ответ от вендора, почему так получается, буду рад сообщить. Срабатывание DoS политики происходит до обработки правил файрволом, то есть, отключив QUIC и переведя принудительно всех на TCP/TLS, я убираю возможность попадания в бан известных сервисов, вместе с тем закрывая периметр от других флудильщиков.
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 политику, я как раз и разгружаю систему от необходимости обработки ненужных пакетов политиками файрвола.
```Смотрите, мы можем на основе каких-то признаков отловить ip флудера в ip firewall filter и занести его в лист```
На самом деле это уже удел IDS/IPS систем. Хотя и их можно к тику прикрутить.
В подавляющем большинстве внедрений защита реализована на граничном роутере его встроенными средствами. Хотя признаемся честно — это хорошо если она хотя бы так реализована.
В любом случае я выше описал принцип работы. Можно отлавливать флудера в файрволе, можно средствами IDS/IPS на более высоком уровне. Смысл в том, что бы потом заблокировать этот трафик как можно раньше не пуская его по цепочке.
Малый и средний бизнес такое себе позволить не может, да и не нужно оно там прямо скажем.
Понятие малый и средний у всех разные, но в целом уже может.
Тот же pfsence имеет встроеные средства и бесплатные обновления раз в месяц вроде.
Для mikrotik люди используют SELKS обычно.
Это нужно не только от каких-то атак из вне, но и просмотр вещей внутри сети.
Но тут каждый решает сам, что как зачем и почему.
В качестве оффтопика скажу, что я наблюдаю окружающую обстановку и к сожалению могу констатировать удручающий факт — на фоне общего экономического упадка в стране работодателям это всё на хрен не нужно. Не готовы вкладываться в нормальную ИТ-инфраструктуру. Не готовы платить хорошую з/п квалифицированным кадрам. В принципе мало кто готов вообще вкладываться в бизнес с расчётом на долгую перспективу. Всем надо здесь и сейчас и что бы по быстрее и подешевле (идеально — бесплатно). От боссов только и слышишь «да что ты нам тут говоришь про перспективы 3-5 лет, делай на год, там может мы закроемся вообще».
Как нам все говорят — вкладывайтесь в своё образование, это самое выгодное вложение. Да конечно. Знаний полная голова, спроса на них нет.
Есть конечно организации где всё хорошо. В основном это те кто выкапывает полезные ископаемые и выдают кредиты. Но сколько таких организаций в процентном отношении по рабочим местам?
Это то что я вокруг себя наблюдаю. IDS/IPS им точно не нужны.
Сорян, что-то накатило.
Создать список:
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.
Дальше по этому списку можно разрешать ходить пакетам.
Лечим перхоть гильотиной
В теории это должно работать как часы, но на практике мы наткнёмся на то, что UDP может быть, например, запрещён на файрволе во избежание DDoS атак.Пам-пам
Предвижу, что Гугл отключит фоллбэк на TCP и такой провайдер как вы — будете отвечать в коллцентре на вопрос почему YouTube не работает.
Помимо Google этот протокол юзает Cloudflare, вообщем то непонятными идеями по безопасности вы ухудшаете ситуацию для своих пользователей, подтверждая основную идею:
что провайдер это труба и в трубе не должно быть никаких фаерволов, что клиент запросил или передал — должно доходить в неизменном виде.
А почему Вы вдруг решили, что я провайдер?
Тогда это ещё более странное действие, какой смысл у себя на роутере блокировать какие либо протоколы ?
Есть определенные моменты по безопасности. Есть ряд источников с которых идёт флуд по udp. А Вы у себя на пограничном все-все-все разрешаете?
Для домашней сети — не вижу причин делать ограничения, с учетом IPv6 проблема безопасности и ограничений — проблема конечных устройств, сейчас и так на каждом девайсе есть файрволл.
Да, но кроме полезного трафика от Гугла есть ещё ряд других товарищей, создающих именно бесполезный. И в контексте "ничего не делать, пусть весь трафик, включая ненужный пробегается по всем правилам и лишний раз нагружает железку ИЛИ переключить сервисы Гугла И НЕ ТОЛЬКО на использование TCP, остальных в бан" я выбрал второй путь. Ведь по такой логике и fail2ban не нужен.
Максимум что сейчас можно сделать конечному хосту, это включить syn_cookies и начинать копить бабло на готовые облачные решения. Пытаться самому генерить какие-то листы на основе наколеночной эвристики — это создать больше вреда бизнесу и пользователям, чем пользы.
на скрине ещё можно покрасить адреса *.1e100.net – это тоже сервера гугла…
Почему ваш файрвол считает флудом законный трафик который идёт в рамках установленного соединения? Да, я понимаю, что термин "установленное соединение" для UDP применять не совсем корректно, однако нормальный файрвол умеет понимать, что кто-то обращался по UDP и этот трафик льётся ему в ответ.
К тому же если у Вас NAT (а я понял, что так и есть), то весь пришедший к вам трафик, в случае если роутер не понимает для кого он, и так должен быть отброшен. В этом случае определять флудера имеет смысл только если блокировать его трафик где-то раньше по цепочке, тем самым понизив нагрузку на процессор в случае атаки. Если блочить флудера всё тем же файрволом, то смысла нет практически никакого, канал-то всё равно забит будет что так, что сяк.
Если не я где-то не прав, то более знающие товарищи поправьте.
Автор. Это не флуд. Это ложно-положительное срабатывание.
При одинаковом битрейте видео потока, TCP будет создавать чуть больше трафика. А загрузка видео, будет происходить чуть медленнее.
P.S. К слову, torrent у нас запрещен.
UDP Flood от Google или как не лишить всех Youtube