Фильтрация пакетов, NAT, большой обьём трафик

Uranus

Добрый.

Как я понимаю вас на 9987\udp ддосят. Разрешение доступа к тимспик только с опред. адресов поможет отсеять поганцев, но вот с остальным :'(

Нельзя вот так просто взять и победить UDP flood (с) - https://www.linuxquestions.org/questions/linux-server-73/suggest-iptables-configuration-for-udp-flood-ddos-4175617845/

Про блокировку некоторых стран я уже писал выше (кстати заведу ещё одну тему чуть позже, есть непонятки с пробросом портов).
На счёт "UDP flood"…, для этого у меня и есть резервные каналы..., и на PF с UDP можно хоть как то работать и фильтровать в отличии скажем от Microtik.

@werter:

Диалог https://forum.teamspeak.com/threads/107581-Use-tcp-instead-udp и вариант решения (Mumble - https://github.com/mumble-voip/mumble)

Bla bla bla. Vent is TCP-only. Mumble has an option for TCP. I'm still maintaining a Vent demo server for talking to people with EDGE.

Я знаю про ограничения TS3.
Переход на что-то другое мне пока не интересен, станет скучно буду искать альтернативы, пока меня всё устраивает…

@werter:

Интересный проект по борьбе с ддос - https://www.linkedin.com/pulse/20141022190816-122785577-защита-от-ddos-атак-с-помощью-fastnetmon, https://github.com/pavel-odintsov/fastnetmon

Ну в моём случае определить DDOS можно простейшим пингом до удалённого хоста…, но спасибо за ссылку...

@werter:

Fallen_A
Дам ссылку. Для понимания. Бесплатно. Держите https://habrahabr.ru/company/pentestit/blog/252233/ Тем более, что пока от вас здесь только совет по замене сетевой.

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

p.s.
Fallen_A
За последние 2-3 дня не было ни одной сильно DDOS атаки, так что не могу пока 100% подтвердить что все мои предположения, настройки помогли, обычно я проверяю на 3 случаях, тут пока что был только один(успешный)…, как только всё проверю, отпишусь...

werter

@Fallen_A:

Что касается ваших советов, то где же правильный ответ в тему с моей проблемой?

Уточните. У вас 27 сообщений на данный момент. И перелопачивать их все желания особого нетути.

Fallen_A

@werter:

@Fallen_A:

Что касается ваших советов, то где же правильный ответ в тему с моей проблемой?

Уточните. У вас 27 сообщений на данный момент. И перелопачивать их все желания особого нетути.

Это был минутный сарказм. Не стоит принимать близко к сердцу.

werter

Добрый.
Нет. Это была ложь с вашей стороны, неуважаемый Fallen_A.
И оч. может случиться так, что на вашу просьбу помочь просто не обратят внимание. Как на "сарказм".

Fallen_A

@werter:

Добрый.
Нет. Это была ложь с вашей стороны, неуважаемый Fallen_A.
И оч. может случиться так, что на вашу просьбу помочь просто не обратят внимание. Как на "сарказм".

В чем ложь? В том, что вы даете советы зная, что ТС этого топика так не поступит? Это можно перечитать вам и понять еще раз.

Что касается моей последней темы - то вы не дали внятного ответа, а влезли все с тем же LEDE.

Так где ложь? Научитесь следить за темой разговора уже наконец.

Uranus

Господа, давайте не будет оффтопить!

По скольку у меня интеловская сетевая I350-T4, то по подсказке Fallen_A сделал оптимизацию этой сетевой для FreeBSD, а именно:
В файл /boot/loader.conf.local
добавил следующие строки

kern.ipc.nmbclusters="1500000"
hw.igb.rxd="4096"
hw.igb.txd="4096"
net.pf.states_hashsize=2097152
net.pf.source_nodes_hashsize=2097152
hw.igb.fc_setting=0
hw.igb.rx_process_limit="-1"
hw.igb.tx_process_limit="-1"
hw.igb.num_queues="0"
hw.igb.enable_aim="1"
net.isr.dispatch="direct"
net.isr.bindthreads="0"
net.isr.maxthreads="4"

и перезагрузил роутер.

После чего проблема вроде бы исчезла, по крайней мере даже при DDOS атаке от ~400 до ~800 mb нет потерь не на основном не втором канале, (проверял 3 раза, конечно это не 100% гарантия, но всё же) да канал забили, но сетевая справляется, если не будет вопросов, то топик закрою.

werter

@Fallen_A:

…
Что касается моей последней темы - то вы не дали внятного ответа, а влезли все с тем же LEDE.
Так где ложь? Научитесь следить за темой разговора уже наконец.

А на кой ляд вы мне тогда плюс в карму за совет с LEDE добавили? Определитесь уже.

Зы. А LEDE не надо вам. Лишнее это. Поломаете еще железо. Потом "претензии" выслушивать. Забудьте.

![2018-03-02 17_38_18-Re_ WAN TP-Link + LAN PfSense.png](/public/imported_attachments/1/2018-03-02 17_38_18-Re_ WAN TP-Link + LAN PfSense.png)
![2018-03-02 17_38_18-Re_ WAN TP-Link + LAN PfSense.png_thumb](/public/imported_attachments/1/2018-03-02 17_38_18-Re_ WAN TP-Link + LAN PfSense.png_thumb)

werter

Оптимизации эти висят в оф. вики пфсенса https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards

Uranus

@werter:

Оптимизации эти висят в оф. вики пфсенса https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards

Там не всё есть…

pigbrother

добавил следующие строки

Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.

Uranus

@pigbrother:

добавил следующие строки

Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.

Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)

pigbrother

@Uranus:

@pigbrother:

добавил следующие строки

Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.

Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)

;)
Чтобы не редактировать /boot/loader.conf.local и иметь возможность сохранять свои настройки в бэкапе и восстанавливать\переносить их - лучше добавлять всё в

System-Advanced-System Tunables

Uranus

@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, на большинстве компов Суриката или Снорт только помеха.

Uranus

@pigbrother:

@Uranus:

@pigbrother:

добавил следующие строки

Еще на первой странице обсуждения предлагалось рассмотреть тюнинг сетевой карты.

Да вы правы, но я как то в это не особо верил, а когда началась очередная DDOS атака просто решил да почему бы и нет, и проверил, если честно не думал что будет такой результат, так сказать от безысходности проверил :)

;)
Чтобы не редактировать /boot/loader.conf.local и иметь возможность сохранять свои настройки в бэкапе и восстанавливать\переносить их - лучше добавлять всё в

System-Advanced-System Tunables

То есть вы хотите сказать что это полный аналог /boot/loader.conf.local ?
А перезагружать роутер всё равно нужно или нет ?

Uranus

Кстати…, возможно я не прав, но всё же не смотря на все настройки лучше на всякий случай второй и так далее каналы подключать на отдельную сетевую карту, так сказать во избежание случайностей.

pigbrother

То есть вы хотите сказать что это полный аналог /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 на резервном канале при высокой нагрузке на основной.

werter

Там в правилах fw сперва разобраться надо https://forum.pfsense.org/index.php?topic=144597.0

Uranus

@pigbrother:

То есть вы хотите сказать что это полный аналог /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 на резервном канале при высокой нагрузке на основной.

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

Uranus

@werter:

Там в правилах fw сперва разобраться надо https://forum.pfsense.org/index.php?topic=144597.0

Вот вы мне ответьте если на меня периодически идёт DDOS атака с повторяющимся шаблоном, банально с одно и того же порта на разные порты на моём компе, не лучше ли будет её блокировать сразу во Float, чем пускать по всей цепочке прохождения трафика и ждать когда в конце этой цепочки PF дропнет ненужное сам, Drop пакета это Drop пакета, единственное что дропать лучше раньше, так чем плохи мои правила во Float которые в большинстве случаев как раз для этого и написаны (хотя конечно не все).

rubic

Если вы уберете все из float и развесите это на WAN, то с точки зрения затрат на фильтрацию пакетов ничего не изменится, зато картина и вам и нам станет яснее. Floating rules, да, обрабатываются первыми, но если их нет, то переход к обработке обычных правил происходит мгновенно, без потери производительности.
Фактичеки для pf нет никакой разницы, он не знает о том, что в pfSense есть какие-то floating rules