Зависает pfSense при DDOS
-
На меня шла DDOS атака со скоростью в 1ГБ и при этом коробка c pfSense начинает дико "тормозить".
Не уверен, но как вариант - использовать Snort.
http://hubpages.com/hub/How-to-Set-Up-an-Intrusion-Detection-System-Using-Snort-on-pfSense-20
http://www.wedebugyou.com/2012/11/how-to-prevent-and-mitigate-ddos-part1/
-
Если у Вас правильно настроен файрвол, то при внешней DDos атаке таблица States не может расти. Она растет только за счет установленных соединений. Значит либо у Вас внешний DDos на проброшенные порты, либо идут внутренние соединения за счет вирусов или ПО типа Агент-майл-ру. Смотрите, чем забит States, и боритесь с причинами.
-
Привет, спасибо за ответы.
Ситуация в том, что за pfSense белая сеть, то есть там нету NAT и соответственно DDOS шел на открытый IP по UDP.
На разные порты с разных машин.То есть ни о каких вирусах речи тут не идет (атака шла на адрес веб-сервера под linux).
Вопрос еще в том, почему pfsense просто зависал и даже на консоле ничего сделать было невозможно?
-
[Altero]Maximus
Вам с такими вопросами лучше сюда. -
@[Altero:
Maximus link=topic=77132.msg420306#msg420306 date=1400402923]
Ситуация в том, что за pfSense белая сеть, то есть там нету NAT и соответственно DDOS шел на открытый IP по UDP.
На разные порты с разных машин.То есть ни о каких вирусах речи тут не идет (атака шла на адрес веб-сервера под linux).
Такое надо резать на подступах, а не пропускать внутрь. Судя по росту количества states, у вас доступ из инета к этому серверу открыт на все порты и протоколы. А зачем?
В pf state generation происходит после фильтра. Запретите доступ к linux-серверу по UDP правилами, и таблица перестанет расти. -
@ [Altero]Maximus
Покажите правила fw на LAN, WAN.
Я ж давал ссылку на ids snort + pfsense :
http://hubpages.com/hub/How-to-Set-Up-an-Intrusion-Detection-System-Using-Snort-on-pfSense-20 -
Спасибо за ответ.
Правила очень простые, показывать нет смысла их.
Спасибо за ссылки, буду изучать.
-
@ [Altero]Maximus
Встроенные карты - не эта ?
kernel: re0: <realtek 8111="" 8168="" b="" c="" cp="" d="" dp="" e="" f="" pcie="" gigabit="" ethernet="">kernel: rgephy0:</realtek> -
Привет!
нет, сетевушки Intel:
igb0: <intel(r) 1000="" pro="" network="" connection="" version="" -="" 2.3.1="">port 0x8020-0x803f mem 0xdf920000-0xdf93ffff,0xdf944000-0xdf947fff irq 27 at device 0.0 on pci2
igb1: <intel(r) 1000="" pro="" network="" connection="" version="" -="" 2.3.1="">port 0x8000-0x801f mem 0xdf900000-0xdf91ffff,0xdf940000-0xdf943fff irq 30 at device 0.1 on pci2</intel(r)></intel(r)> -
тут отднозначно нужно резать сторонней софтиной либо тюнить.
у меня на 5639 (6ядер 2.16ГГц)количество states 1225000 при 12гигах рамы (3 канала, палки по 4гига)
сетевухи 2порта igb(1Gb) и 2порта ix(10Gb)
тут скорее всего проблема в агрегации. покойпай в эту сторону.
если бы у тебя были отдельные сетевушки, то они сами бы разруливали и нагрузку на проц не давали.
а в варианте с агрегацией (программно) у тебя используется проц, причём один.
и тут очень много но и если выползает. HT NUMA и тд. читай про них. и лезь в биос вырубать всяку бяку. NUMA дак вообще с 9 ветки FreeBSD начала поддерживаться и то криво и через одно место.
и на кой чёрт тебе два проца. одним процом спокойно можно до 10г разрулить, и памяти столько не нать, максимум 3 палки на проц ( для использования 3ёх канального режима и увеличения пропускной способности), особенно если у тебя тупой роутинг даже без нат.
и в варианте с 2 головами нужно кучу всего жестко привязывать к своим горшкам. -
@[Altero:
Maximus link=topic=77132.msg420246#msg420246 date=1400360168]
На меня шла DDOS атака со скоростью в 1ГБ и при этом коробка c pfSense начинает дико "тормозить".
На КВМ там ничего не отвечает, по ssh туда просто не забраться, но если получается, то вижу следующую картинку:
Потери из LAN до GW(pfsense) 50 и более процентов.Давай логично рассуждать:
1. Через КВМ не отвечает, т.к проц на всю катушку забит! Смотри чем.
2. По сетке не ответит тебе даже если бы проц не был забит - у тебя нет ограничений на входящий канал - исчерпаны все доступные на файрволле состояния.
После устранения проблемы с перегрузкой проца поставь лимитер на входящий из мира канал не более 98% (или сколько хочешь). Т.е. оставь себе зазор. Если ты из локалки не можешь зайти - из локалки поставь зазор. А свой адрес поставь в исключения лимитера. Так ты обеспечишь себе состояние pfSense "всегда доступен для админа!" -
Позвольте понекропостить.
mazurik_tc
По поводу Вашего п.2:
ддос ддосу рознь. Можно шмалять 1Гб icmp пакетов, а можно делать умные атаки на конкретный софт.
Я само лично использовал перловый скрипт, который каналом в 1 мегабит, путём атаки на порт apache2 убивал сервер на 2х ксеонах. Причём не апач вешал сервер, а процы начинали работать с гиганским количеством интерруптов. Такие дела…По поводу причины - я думаю настроен проброс диапазона портов, или порты WAN не закрыты снаружи.
По моему опыту если автора топика действительно тревожит ддос (и это именно ддос, а не сетевой шторм), то лучше для защиты использовать сторонние решения. Жаль что 100% защиты никто не может гарантировать (по объективным причинам).
-
Я само лично использовал перловый скрипт, который каналом в 1 мегабит, путём атаки на порт apache2 убивал сервер на 2х ксеонах. Причём не апач вешал сервер, а процы начинали работать с гиганским количеством интерруптов. Такие дела…
Offtop :
Видимо все же апач вешал ваши машины. Ибо каждое обращение к порту , на к-ом слушал веб-сервер - это открытие нового соединения (расход ОЗУ, CPU etc., а "кушает" он будь здоров ). Не зря же в кач-ве frontend и используют мелкий и шустрый nginx, к-ый потребляет намнооооого меньше ресурсов. А если его "докрутить" (ограничение кол-во соединений в ед-цу времени с одного адреса и т.д.) - вообще красота будет. Но естественно , что это не панацея.
-
конечно апач.
Я имел ввиду, что например тот же элементарный top проблему по программе не показывал. Апач потребляет свои 0,02% - а сервер при этом даже толком не пингвинится….. Так то да: нет апача - нет проблемы.
PS: машины были не мои )))))
