Фильтрация пакетов, NAT, большой обьём трафик
-
добавил следующие строки
Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.
-
добавил следующие строки
Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.
Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)
-
добавил следующие строки
Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.
Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)
;)
Чтобы не редактировать /boot/loader.conf.local и иметь возможность сохранять свои настройки в бэкапе и восстанавливать\переносить их - лучше добавлять всё вSystem-Advanced-System Tunables
-
@oleg1969:
Несколько ссылок по DDOS
http://salf-net.ru/?p=494
http://pfsensesetup.com/tag/ddos/
https://ok.ru/video/782372406Я всё это читал, только на других сайтах, по поводу Snort, если бы вы прочитали всю ветку то увидели бы что у меня установлена Suricata, но при DDOS атаке она только мешает, по той простой причине что потребляет кучу ресурсов, обычной DDOS атакой на 100 mb вы запросто с помощью Сурикаты загрузите процессор роутера на 100%, и только ухудшите ситуацию, нужно чтобы у вас Суриката устанавливалась на оборудование с несколькими процессорами у которых будет несколько ядер, тогда есть шанс что она не уронит ваш роутер при DDOS.
И так же поскольку Суриката встраивается систему таким образом что весь трафик сначала идёт через неё, то мы даже не можем уменьшить трафик заблокировав скажем некоторые страны.Так же как я и писал, в теории Суриката может работать с CUDA от Nvidia, так что мы могли бы использовать мощности видеокарты для фильтрации, но проблема в том что на FreeBSD нет нормального порта CUDA, а без этого порт Сурикаты для PFsense компилируется без поддержки CUDA.
Так что при DDOS, на большинстве компов Суриката или Снорт только помеха.
-
добавил следующие строки
Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.
Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)
;)
Чтобы не редактировать /boot/loader.conf.local и иметь возможность сохранять свои настройки в бэкапе и восстанавливать\переносить их - лучше добавлять всё вSystem-Advanced-System Tunables
То есть вы хотите сказать что это полный аналог /boot/loader.conf.local ?
А перезагружать роутер всё равно нужно или нет ? -
Кстати…, возможно я не прав, но всё же не смотря на все настройки лучше на всякий случай второй и так далее каналы подключать на отдельную сетевую карту, так сказать во избежание случайностей.
-
То есть вы хотите сказать что это полный аналог /boot/loader.conf.local ?
Я вносил настройки сетевой карты именно в System Tunables
В приведенной вам ссылке
https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Adding_as_a_System_Tunable
Такой вариант и указан.А перезагружать роутер всё равно нужно или нет ?
перезагрузка не помешает.лучше на всякий случай второй и так далее каналы подключать на отдельную сетевую карту, так сказать во избежание случайностей.
В вашем случае все порты I350T4 обслуживались одним драйвером igb. Отдельная сетевая плата могла обслуживаться другим драйвером, либо не нуждающимся в тюнинге, либо требующим своих настроек. Как вариант для интел - драйвер от igb I350T4 мог бы совпасть с драйвером новой карты.
P.S.
Кстати, в пылу дискуссии все забыли, что вопрос ТС была не о защите его приложения от DDOS в чистом виде, а в обеспечении работоспособности pfSense на резервном канале при высокой нагрузке на основной. -
Там в правилах fw сперва разобраться надо https://forum.pfsense.org/index.php?topic=144597.0
-
То есть вы хотите сказать что это полный аналог /boot/loader.conf.local ?
Я вносил настройки сетевой карты именно в System Tunables
В приведенной вам ссылке
https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Adding_as_a_System_Tunable
Такой вариант и указан.А перезагружать роутер всё равно нужно или нет ?
перезагрузка не помешает.лучше на всякий случай второй и так далее каналы подключать на отдельную сетевую карту, так сказать во избежание случайностей.
В вашем случае все порты I350T4 обслуживались одним драйвером igb. Отдельная сетевая плата могла обслуживаться другим драйвером, либо не нуждающимся в тюнинге, либо требующим своих настроек. Как вариант для интел - драйвер от igb I350T4 мог бы совпасть с драйвером новой карты.
P.S.
Кстати, в пылу дискуссии все забыли, что вопрос ТС была не о защите его приложения от DDOS в чистом виде, а в обеспечении работоспособности pfSense на резервном канале при высокой нагрузке на основной.Так я и написал что практически решил проблему, хотя тестов конечно проведено маловато и требуется ещё проверять различные варианты, как то отдельные сетевые на все каналы и различные варианты тюнинга, просто для полноты картины.
-
Там в правилах fw сперва разобраться надо https://forum.pfsense.org/index.php?topic=144597.0
Вот вы мне ответьте если на меня периодически идёт DDOS атака с повторяющимся шаблоном, банально с одно и того же порта на разные порты на моём компе, не лучше ли будет её блокировать сразу во Float, чем пускать по всей цепочке прохождения трафика и ждать когда в конце этой цепочки PF дропнет ненужное сам, Drop пакета это Drop пакета, единственное что дропать лучше раньше, так чем плохи мои правила во Float которые в большинстве случаев как раз для этого и написаны (хотя конечно не все).
-
Если вы уберете все из float и развесите это на WAN, то с точки зрения затрат на фильтрацию пакетов ничего не изменится, зато картина и вам и нам станет яснее. Floating rules, да, обрабатываются первыми, но если их нет, то переход к обработке обычных правил происходит мгновенно, без потери производительности.
Фактичеки для pf нет никакой разницы, он не знает о том, что в pfSense есть какие-то floating rules -
Если вы уберете все из float и развесите это на WAN, то с точки зрения затрат на фильтрацию пакетов ничего не изменится, зато картина и вам и нам станет яснее. Floating rules, да, обрабатываются первыми, но если их нет, то переход к обработке обычных правил происходит мгновенно, без потери производительности.
Фактичеки для pf нет никакой разницы, он не знает о том, что в pfSense есть какие-то floating rulesЭто понятно, но только то вот настройки которые я предоставил мои и сделаны для меня и как мне удобней, да и вообще насколько я понял господин werter и я спорили не о непонятности правил, он это сюда вообще притащил из другой ветки, и проблема там обсуждается совсем другая и эти правила для решения той проблемы не мешают.
-
Ну, не факт, что не мешают. В то время как обычные правила понятны из скриншота, плавающие имеют столько опций, которых на скриншотах не видно, что понять ничего нельзя.
Посмотреть весь ruleset (в том числе и "магию", добавляемую pfSense) можно через 'pfctl -sn && pfctl -sr' в Diagnostics > Command Prompt -
Ну, не факт, что не мешают. В то время как обычные правила понятны из скриншота, плавающие имеют столько опций, которых на скриншотах не видно, что понять ничего нельзя.
Посмотреть весь ruleset (в том числе и "магию", добавляемую pfSense) можно через 'pfctl -sn && pfctl -sr' в Diagnostics > Command PromptИменно что факт, я же всё же не идиот и если какой то IP не может зайти, то сначала проверяю тех кого блокирую персонально в Float правилах, да и к тому же было же написано в первом посте той ветки что если я убираю в прокидывании портов ограничение на страны то сразу всё начинает работать, одно это уже указывает что проблема как то связанна именно со списком разрешённых стран в тех правилах, мы даже пытались поменять список, точнее создать новый из другого источника…, проблема осталась.
Прокидывание портов автоматически создаёт правила, но в Firewall-Rules-Wan, а не в Firewall-Rules-Float, так что смотреть Float по логике было избыточно и не нужно, вот если бы этот IP вообще не мог зайти тогда да, нужно было глянуть.Кстати спасибо за команду, проверю вечером как с работы вернусь.
-
Похоже я немного поторопился с закрытием темы, но за то появились более-менее точные данные.
Смысл такой, когда на роутер на любой из Wan-ов валятся фрагментированные пакеты в большом кол-ве то в консоли появляются записи типа pf frag entries limit reached
что означает что у нас переполнен буфер размер которого мы указываем в System - Advanced - Firewall & NAT - Firewall Maximum Fragment Entries.
По умолчанию он вообще всего 5000, но его увеличение мало что нам даёт, достаточно чуть больше продлиться DDOS атаке и его опять переполняет.Я так понимаю что тут проблема в работе scrub который нормализует пакеты и собирает фрагментированные пакеты в один пакет, при сборе фрагментированных пакетов он использует тот самый буфер который указан выше, он просто хранит там пакеты которые собирается использовать для сборки, но если при DDOS атаке идёт большое кол-во фрагментированных пакетов с фальсифицировнными заголовками то scrub никогда не сможет их собрать и буфер будет переполнен.
После переполнения буфера начинаются потери пакетов не только на атакуемом wan, но и на всех остальных wan-ах, хотя и в меньших пропорциях.
Как вариант нужно найти способ как-то очищать этот буфер, по команде pfctl -sm мы может увидеть размер этого буфера (frags), а по команде pfctl -st (frag, 30 секунд) как я думаю это таймаут его очистки, если это так то как это время уменьшить?
Или может у кого есть другие идеи как можно решить эту проблему?!
-
Тут года 3 назад был мегасрач в английской ветке по поводу несильного DOS каким-то OVH-скриптом, от которого pfSense валится на раз. Позиция разработчика заключается в том, что pfSense - это ни разу не DDOS Mitigation решение, это firewall. Если вы так уж привержены этому дистрибутиву, ставьте еще один pfSense мостом-посредником на проблемном канале, тут в такие дебри вряд ли кто залезал и кроме man pfctl что-то предложить сложно.
-
Тут года 3 назад был мегасрач в английской ветке по поводу несильного DOS каким-то OVH-скриптом, от которого pfSense валится на раз. Позиция разработчика заключается в том, что pfSense - это ни разу не DDOS Mitigation решение, это firewall. Если вы так уж привержены этому дистрибутиву, ставьте еще один pfSense мостом-посредником на проблемном канале, тут в такие дебри вряд ли кто залезал и кроме man pfctl что-то предложить сложно.
Просто интересно, а что вы можете предложить из других (наверно более хороших) дистрибутивов…?
И да, пока что я просто собираю информацию, можно ли решить эту проблему без фильтрующих PFsense, если ничего не выйдет придётся ставить второй PF, вопрос только как лучше будет..., для фильтра поставить один как бридж и через него уже трафик прогонять с атакуемого канала, который потом пойдёт на основной Pfsense..., так же обдумываю возможность сделать всё это на виртуалках, не знаю правда на сколько это реально...
-
Добрый.
Похоже я немного поторопился с закрытием темы, но за то появились более-менее точные данные.
Надо же. Вот неожиданность. Ув. Fallen_A, ау, с нетерпением ждем ваших "советов"
по компилированию кде под бсд.Смысл такой, когда на роутер на любой из Wan-ов валятся фрагментированные пакеты в большом кол-ве то в консоли появляются записи типа pf frag entries limit reached
что означает что у нас переполнен буфер размер которого мы указываем в System - Advanced - Firewall & NAT - Firewall Maximum Fragment Entries.
По умолчанию он вообще всего 5000, но его увеличение мало что нам даёт, достаточно чуть больше продлиться DDOS атаке и его опять переполняет.Или может у кого есть другие идеи как можно решить эту проблему?!
Поставить галку на Disable Firewall Scrub. И снять с Clear invalid DF bits instead of dropping the packets. Также "поиграть" с Firewall Optimization Options (выставить Aggressive, напр.).
Позиция разработчика заключается в том, что pfSense - это ни разу не DDOS Mitigation решение, это firewall.
1. ТС это никак не поймет. ТС упрям. До безобразия.
2. Было ж предложено альтернативу тому ПО, что он пользует, к-ая умеет TCP only (http://ccm.net/faq/26187-mumble-force-tcp-mode) и ничем не хуже TS - https://wiki.mumble.info/wiki/1.3.0 . В чем проблема развернуть и потестить в том же VBox-е? Но… см. п.1 -
Добрый.
Надо же. Вот неожиданность. Ув. Fallen_A, ау, с нетерпением ждем ваших "советов"по компилированию кде под бсд.Фууу, уважаемый, как некрасиво.., и потом, вы были не правы тогда, как и не правы сейчас, советы Fallen_A помогли, хоть и не до конца, потери на втором канале стали меньше, хотя, как выяснилось, и не пропали полностью…
Поставить галку на Disable Firewall Scrub. И снять с Clear invalid DF bits instead of dropping the packets. Также "поиграть" с Firewall Optimization Options (выставить Aggressive, напр.).
Боюсь при отключении Scrub я могу получить другие проблемы, и кроме того если я не ошибаюсь он нужен для нормальной работы NAT.
Clear invalid DF bits instead of dropping the packets - что с ним что без него разницы нет, уже проверял.
Firewall Optimization Options меняет не все таймауты, я проверял командой pfctl -st, без разницы какой режим ставишь таймаут Frag не изменяется, потому и спросил может есть ещё какой вариант изменить его?!1. ТС это никак не поймет. ТС упрям. До безобразия.
2. Было ж предложено альтернативу тому ПО, что он пользует, к-ая умеет TCP only (http://ccm.net/faq/26187-mumble-force-tcp-mode) и ничем не хуже TS - https://wiki.mumble.info/wiki/1.3.0 . В чем проблема развернуть и потестить в том же VBox-е? Но… см. п.1Уважаемый это скорее вы упрямы до безобразия, вам же сказали каковы условия задачи, причём сказали несколько раз, вот с этими условиями её и надо решать, а не изменять так как вам легче, задачу ставлю я, на тех условиях которые подходят мне, и решать её я буду исходя из них…
Ваш же подход можно описать одной фразой: "Нет человека, нет проблемы!", вы предпочитаете не лечить человека, а просто пристрелить его, потому что лечить сложно, а мёртвые не болеют! :D -
Вы путаете теплое с мягким. Ни pf, ни iptables в случае c UDP вам не помогут - нет механизма ограничения установления кол-ва соединений за ед. времени. С TCP же это решаемо.
советы Fallen_A помогли, хоть и не до конца, потери на втором канале стали меньше
То, что вы поленились заглянуть в оф. вики за советом по настройке - ваши проблемы.
Атакуют вас с умом. Решить же вы пытаетесь без использования оного.
