Фильтрация пакетов, NAT, большой обьём трафик
-
Похоже я немного поторопился с закрытием темы, но за то появились более-менее точные данные.
Смысл такой, когда на роутер на любой из 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 помогли, хоть и не до конца, потери на втором канале стали меньше
То, что вы поленились заглянуть в оф. вики за советом по настройке - ваши проблемы.
Атакуют вас с умом. Решить же вы пытаетесь без использования оного.
-
Вы путаете теплое с мягким. Ни pf, ни iptables в случае c UDP вам не помогут - нет механизма ограничения установления кол-ва соединений за ед. времени. С TCP же это решаемо.
Странно, для чего тогда у нас в PF есть state :)!
То, что вы поленились заглянуть в оф. вики за советом по настройке - ваши проблемы.
Да мои, с другой стороны вы предлагали что угодно, но не решение проблемы, на тех условиях которые меня устраивают…
Атакуют вас с умом. Решить же вы пытаетесь без использования оного.
Про решение проблем по вашему я написал в предыдущем посте, перечитайте начиная с "Уважаемый это скорее вы упрямы до безобразия" :)!
p.s.
Если вам нечего сказать по теме то попрошу вас больше не писать в эту тему, ваш сарказм тут не оценят… -
UDP packets don't have NEW,RELATED or ESTABLISHED connections. UDP is connection-less …
Вне зависимости от ваших "желаний".
-
UDP packets don't have NEW,RELATED or ESTABLISHED connections. UDP is connection-less …
Вне зависимости от ваших "желаний".
Мне достаточно просто кол-ва соединений UDP которые я вполне могу определить по state и в Advanced Options правила я могу это указать, и это прекрасно работает, проверенно уже не раз и не два, да, не так гибко можно настроить как с TCP, но всё же…
p.s.
Кстати это одна из причин моего перехода с Микротика на PFsense. -
https://goo.gl/q55ETW
https://www.openbsd.org/faq/pf/filter.html#udpstate
Keeping state for UDP
One will sometimes hear it said that "one cannot create state with UDP, as UDP is a stateless protocol!" While it is true that a UDP communication session does not have any concept of state (an explicit start and stop of communications), this does not have any impact on PF's ability to create state for a UDP session. In the case of protocols without "start" and "end" packets, PF simply keeps track of how long it has been since a matching packet has gone through. If the timeout is reached, the state is cleared. The timeout values can be set in the options section of the pf.conf file.То, что может помочь в ограничение кол-ва подключений относится только к TCP. Т.е. именно то, что надо вам. Но не в случае с (вашим) UDP.
 -
Поглядите на Max. states - Maximum state entries this rule can create., могу вас заверить для UDP это работает, не всегда очень точно, но сам видел при DDOS атаке, и кстати почитайте как оно работает…
Так же помогает Max. src nodes которое тоже работает с UDP… -
https://www.packetmischief.ca/2011/02/17/hitting-the-pf-state-table-limit/
https://forum.pfsense.org/index.php?topic=68497.0
Max. states действует и на good и на bad guys, т.к. это общее правило по states.
Max. src nodes действует и на good и на bad guys, т.к. это общее правило по src nodes
Интереснее Max. src. states (Maximum state entries per host), но можно и не угадать и для good guys.
Итого. С большой долей вер-ти можно предположить, что вас немного выручают правила pfblocker-а по странам (просто и эффективно дропят вне зависимости от). Ибо вышеописанное c max states - рулетка в чистом виде в случае с UDP, т.е. может дропнуть линк и от хороших и от плохих парней.
Скрин того, как настроено это у вас. И механизм того, как вы высчитываете это значение.
-
https://www.packetmischief.ca/2011/02/17/hitting-the-pf-state-table-limit/
https://forum.pfsense.org/index.php?topic=68497.0
Max. states действует и на good и на bad guys, т.к. это общее правило по states.
Max. src nodes действует и на good и на bad guys, т.к. это общее правило по src nodes
Интереснее Max. src. states (Maximum state entries per host), но можно и не угадать и для good guys.
Итого. С большой долей вер-ти можно предположить, что вас немного выручают правила pfblocker-а по странам (просто и эффективно дропят вне зависимости от). Ибо вышеописанное c max states - рулетка в чистом виде в случае с UDP, т.е. может дропнуть линк и от хороших и от плохих парней.
Скрин того, как настроено это у вас. И механизм того, как вы высчитываете это значение.
Для меня главное остановить не нужный трафик на роутере, и какая разница Good или bad если канал и так забит, вы что думаете я себе какую-то антиддос систему делаю, которая разделяет хороший трафик от плохого…, вы вообще читали что я писал, для меня главное чтобы работал резервный канал и работал без сбоев, что там твориться на основном канале меня не волнует до тех пор пока он не мешает работать резервному, так что сортировкой трафика я и не думал заниматься, я его просто ограничиваю до той черты на которой он мне не мешает..., без обид, в который раз уже ловлю себя на мысли что вы не читаете что вам пишут или читаете так что видите там что-то своё... :)
-
У вас ведь проброс портов для TS имеется на обоих каналах? И народ подк. и к одному и ко второму ? И "плохой" народ тоже. Т.е. забив udp-пакетами один канал принимаются за другой.
Это так ?Скрин того, как настроено это у вас. И механизм того, как вы высчитываете это значение. Покажите. Объясните.
-
У вас ведь проброс портов для TS имеется на обоих каналах? И народ подк. и к одному и ко второму ? И "плохой" народ тоже. Т.е. забив udp-пакетами один канал принимаются за другой.
Это так ?Скрин того, как настроено это у вас. И механизм того, как вы высчитываете это значение. Покажите. Объясните.
Нет, про второй канал атакующие я думаю не знают, я его не свечу особо, атак на него не было.
Скрин как правило настроено, да просто в правиле которое автоматически создаётся при пробросе порта тимспика я добавляю несколько ограничений (пробрасываются же ещё не все страны):
Max. states - 600
Max. src nodes - 370
Max. src. states - 5Кроме того на это же правило проброса установлен лимитер ограничивающий обьём трафика который может передать один IP в секунду.
Это позволяет держать трафик который идёт с роутера даже по проброшенным портам в пределах нормы, остальное PF блокирует сам, просто иногда я ему немного помогаю и шаблонные атаки блокирую в Float, теми правилами которые вам так не понравились.
-
@oleg1969:
https://goo.gl/q55ETW
Хорошая ссылка !
–-------------------------
НО эта лучше
http://projectinformationsystem.com/venohostshare/download/dXBsb2Fkcy9lYm9vay9Qcm9ncmFtbWluZy9NYXN0ZXJpbmctcGZTZW5zZS5wZGY=/h/303f05eeebd764d37227c3f60514d97f
Полная Однако!
Спасибо уже прочитал, вы бы кстати перевели или выложили подробную статью о установке и настройке PFsense на вируталках, можно ли сделать так что на одном компе сделать две вируталки, одна будет фильтрующим бриджем, с которого трафик после определённого фильтра будет поступать на вторую виртуалку уже с обычным роутером, причём интересует возможность бриджа пропускать трафик сразу с двух провайдеров.
То есть 4 сетевые, два провайдера входят, фильтруются и выходят, а на втором роутере уже устанавливаются соединения PPPOE или что-то другое и выдаётся в локалку как обычно… -
Max. states - 600
Max. src nodes - 370
Max. src. states - 5Ок. Не спрашиваю. Но стиль "потому что гладиолус" прослеживается чОтко ;D
Кроме того на это же правило проброса установлен лимитер ограничивающий обьём трафика который может передать один IP в секунду.
Подробнее с этого места. Со скринами. Спасибо.
2 oleg1969
Спасибо. Но за такое тут могут и ай-ай-ай. Я бы убрал. Кому надо - в ЛС. -
Ок. Не спрашиваю. Но стиль "потому что гладиолус" прослеживается чОтко ;D
Подробнее с этого места. Со скринами. Спасибо.Господи какой же вы всё таки вредный и самоуверенный человек, все у вас гладиолусы, один вы админ на белом коне :)
Вот вам скрины, а я пошёл спать, мне завтра на работу с утреца, но вы не стесняйтесь, пишите свои комментарии, я с утра посмеюсь ;):
-
пишите свои комментарии, я с утра посмеюсь
Давайте посмеемся. Вместе.
На скринах :
Max states - 700 (общее кол-во)
Max. src nodes - 370
Max. src states - 5Max states = Max. src nodes X Max. src states , т.е. 370 X 5 = 1850 в "макс. комплектации". Можно немного меньше. Но никак не 700, т.к. это менее двух src states на один ip\ одного клиента. Или уменьшайте Max. src states. Но как при этом себя "голос" поведет - я хз. Сколько ему установленных udp-линков надо для одного звонка - 2-3? Уточните этот момент.
У вас на TS аж 370 человек? Пересчитайте все учетки на TS, умножьте и введите верные значения. Прим.: умножать на калькуляторе, потому как доверия уже нетУ :'(
Вот такие сейчас "математики".
По Лимитеру.
Скорее всего он неверно сконфигурирован\ правило fw не то (возможно, Лимитер нужно к правилу во Флоатинг рулез привязать, т.к. они работают первее правил на интерфейсах). Ибо не было бы на вас атак в сотню мегабит при 400 кбит\с на чел с такими настройками. Плюс 400 кбит\с для голоса явно избыточно.Вот вам скрины, а я пошёл спать, мне завтра на работу с утреца
И контакты начальника. Хотел бы с ним побеседовать. Если вы и он - it-ники. Если же он "бизнесмЭн" - считайте, что вам крупно повезло.
-
А где здесь криминал ?
Все найдено на просторах Инета , тем более ссылка в свободном доступе.Не все, что можно найти на просторах интернета законно, и то, что книгу ммм… выложил кто-то другой не делает ее бесплатной.
https://www.amazon.com/Mastering-pfSense-David-Zientara/dp/1786463431/ref=sr_1_1_sspa?ie=UTF8&qid=1520706884&sr=8-1-spons&keywords=Mastering+pfSense&psc=1Лучше ссылку все же удалить.
