LINUX.ORG.RU
ФорумAdmin

syn flood spoofing ip

 


3

2

Друзья, поделитесь, пожалуйста, опытом защиты от атаки syn flood spoofing ip.
Льется трафик с фейковых IP. Через 30-120 секунд после начала атаки - сервер становится недоступен.
Задача «переваривать трафик» 5-10 минут. Далее дата центр включает защиту и фильтрует сам.
Подозреваю, что можно это сделать за счет увеличения лимитов sysctl.
Если скопипастить все - то пост выйдет огромным. По ссылке полное описание проблемы и тесты.


какая-то нестыковочка получается

Через 30-120 минут после начала атаки - сервер становится недоступен.
Задача «переваривать трафик» 5-10 минут. Далее дата центр включает защиту и фильтрует сам.

Почему доходит до 30 минут? Почему сейчас ДЦ не включает защиту по истечению 10 минут?

anonymous ()

блокировать syn возможно только на сетевом оборудовании. Как показал опыт на самой машине это делать бессмысленно.

Вам просто забьют порт даже если не будете отвечать на соединения. Запросы все равно приходят на интерфейс

anonymous ()
Ответ на: комментарий от anonymous_sama

Зачем? Ведь можно в теме рассказать и поделиться опытом.
Заодно тем кто будет гуглить подобное - это поможет.
icq: 450420625, email: poiuty@lepus.su

poiuty ()
Ответ на: комментарий от anonymous

Порт 1Gbit/s. Вроде по графикам мы его не забили. Падает из-за pps
Кстати, вот ссылка на ips.log которые я поймал, все они фейковые.

poiuty ()
Последнее исправление: poiuty (всего исправлений: 1)
Ответ на: комментарий от anonymous_sama

Что за дела? Свободное сообщество, а решения насущных проблем происходят тайком. Отправляй сюда, чтоб всем польза была.

entefeed ☆☆☆ ()
Ответ на: комментарий от entefeed

Он спрашивал «как я тестил» - тестил с помощью vdos-s.com
Мы начинаем разводить оффтоп. Давайте все-таки по теме. Как переварить такое количество pps?
А если это невозможно, то все же хочется увидеть пруф + объяснение.

poiuty ()
Последнее исправление: poiuty (всего исправлений: 1)

Еще один интересный момент. Заливал трафик на KVM VPS. Сеть через bridge.
Нода не падала + другие VPS на ней работали вполне нормально.
По-этому мне кажется, что переварить можно, и возможно дело в лимитах sysctl.

Так же заливал просто на выделенный сервер (тоже OVH)
Ситуация повторялась аналогично как с KVM VPS: 30-120 секунд и падаем. Далее OVH фильтрует и все ок.

Почему если атака на VPS -> нода работает нормально?

poiuty ()
Ответ на: комментарий от poiuty

30-120 секунд и падаем

Kernel panic? Что на самом деле происходит сервером в эти 30-120 секунд. Почему он становится недоступен? Заканчивается память, процессор так занят разбором пакетов, что игнорирует ssh? Или просто провайдер временно отключает сервер от сети из-за пика активности?

anonymous ()
Ответ на: комментарий от poiuty

И никаких сообщений в системных логах? Логи/графики хотя бы потребления cpu/памяти до, во время, после атаки.

Единственный подозрительные момент - переполнение conntrack. Но в этом случае старые соединения не отваливаются.

/sys/module/nf_conntrack/parameters/hashsize не многовато ли? почему именно 1M? Мне, вот, 65536 хватило, но тоже не показатель. При недостаточно большом значении я наблюдал что-то подобное - потребление CPU ядром 100%, сеть недоступна (RHEL7).

anonymous ()
Ответ на: комментарий от anonymous

Значение hashsize брал из мануала по synproxy.
По htop CPU от одного потока 80~100%.
Вот top в момент атаки (был включен synproxy) https://poiuty.com/images/syn_flood_top.png

сonntrack можно выставить абсолютно любое значение. Он все равно будет полностью забит.
Сервер в данном случае атаковали 200k~300k фейковых ипов.
rp_filter - от spoofing ip не помогло.

Тестить это достаточно неудобно. На сбор данных и проверку есть 5-10 минут, далее на час включается защита(VAC OVH).

poiuty ()
Ответ на: комментарий от poiuty

Я нашёл несколько одинаковых статей про SYNPROXY. Везде ставят echo 2500000 > /sys/module/nf_conntrack/parameters/hashsize , т.е. в полтора раза больше.

сonntrack можно выставить абсолютно любое значение. Он все равно будет полностью забит.

conntrack видит эти все эти пакеты как попытки установить обычные соединения. Это там уже дальше какие-то выверты с его обходом, заворотом пакетов в SYNPROXY и прочее. Похоже, что иначе никак.

Здесь DROP вообще не срабатывает. Так как нас атакуют 220K ненастоящих IP.

iptables -A syn_flood -p tcp --dport 80 --syn -m hashlimit --hashlimit 10/sec --hashlimit-burst 15 --hashlimit-mode srcip --hashlimit-name syn --hashlimit-htable-size 2097152 --hashlimit-htable-max 262144 -j RETURN

10 в секунду + 15 в пике = 25 пакетов в секунду разрешено с одного IP - не многовато ли?

anonymous ()
Ответ на: комментарий от poiuty

Чаще всего атакуют спуфом через hping, и если атакующий дурак, то поможет строчка

(ковычки поправить)
iptables -t raw -A PREROUTING -m u32 --u32 «6&0xFF=0x6 && 32&0xFFFF=0x0200» -j DROP

она забанит по окну 512(стандартное при атаках через hping).
забанит в таблице raw, т.е. не доходя до conntrack
также чаще всего спуф идут с одной машины, имеет смысл банить по TTL
но для этого нужно хотябы глянуть дамп трафика(tcpdump -vv)

hashlimit использовать не рекомендую, он забьется и положит систему:( также может быть спасет выключение сервиса который атакуют, и выгрузка модулей коннтрака.

но вы должны понимать, если у вас линк в инет 1гбит, то если вам вольют больше 1млн пакетов в секунду, вы ляжете все ровно, и вас не спасёт ничего:)

kam ★★ ()
Последнее исправление: kam (всего исправлений: 2)
Ответ на: комментарий от kam

Скриншоты по ссылке из первого поста показывают `Win=0` для всех пакетов, значит как-то так:

iptables -t raw -A PREROUTING -m u32 --u32 "6&0xFF=0x6 && 32&0xFFFF=0x0000" -j DROP

?

anonymous ()
Ответ на: комментарий от anonymous

не посмотрел на дамп изначально, но раз там WIN=0, SEQ=0(а вот это непорядок, по этому можно легко банить сразу и это правило делать статичным)

kam ★★ ()
Ответ на: комментарий от anonymous

вот бан по SEQ=0
[code]iptables -t raw -A PREROUTING -m u32 --u32 «6&0xFF=0x6 && 4&0x1FFF=0x0000» -j DROP[/code]


а вот более точное правило(SEQ=0 && WIN=0)

[code]iptables -t raw -A PREROUTING -m u32 --u32 «6&0xFF=0x6 && 32&0xFFFF=0x0000 && 4&0x1FFF=0x0000» -j DROP[/code]



SEQ=0 и WIN=0 - в реальной жизни не встречается :) по этому можно спокойно банить

kam ★★ ()

глупый вопрос, но всё же..

..не может ли быть проблема на более прикладном уровне?

то есть — предположим что ядро-и-сетевой-стек — делают свою дело нормально, но само прикладное приложение (которое слушает порт) неэффективно принимает-и-отслеживает входящие соединения?

user_id_68054 ★★★★★ ()
Последнее исправление: user_id_68054 (всего исправлений: 2)
Ответ на: комментарий от user_id_68054

нет, при спуфе ложится ядро а не приложение, ksoftirq начинает сжирать процессор для обработки пакетов.
т.е. приходит тебе 100к пакетов в секунду, каждый с разного ип. ядро на каждый пакет пытается установить состояние в conntrack`е, и отправить им в ответ syn-ack, и если таймаут установки соединения ~30s итого мы получаем в коннтраке 100000*30=3000000(3млн), подвисших соединений.
а ему ведь еще надо искать по ним(при поступлении нового пакета он пробегает по всем 3млн записям и если не находит нужно добавить, а ведь еще по таймауту нужно удалять, а еще нужно делать дефрагментацию памяти и тд).

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

kam ★★ ()
Ответ на: комментарий от user_id_68054

Нужно по максимуму избавить прохождения этих пакетов по цепочкам фильтров, ибо каждый фильтр - это отдельная нагрузка на поиск по его сингнатурам внутри этого пакета.
по этому банить нужно в цепочке raw-PREROUTING, она сама ближайшая к сетевой карте. ну или писать свой модуль ядра для этих целей, который будет до netfilter работать и парсить напрямую skb

kam ★★ ()
Ответ на: комментарий от kam

SEQ=0 и WIN=0 - в реальной жизни не встречается :) по этому можно спокойно банить

Тоже как-то сразу насторожило.

Кстати, вот тут в разделе `Moving on to the TCP header` рекомендуют всякоразные проверки на фрагментацию пакета и его длину, но я в этом не силён, не знаю насколько это востребовано в данном случае.

anonymous ()
Ответ на: комментарий от anonymous

Кстати, вот тут в разделе `Moving on to the TCP header` рекомендуют всякоразные проверки на фрагментацию пакета и его длину, но я в этом не силён, не знаю насколько это востребовано в данном случае.

это чаще для фильтрации по содержимому пакета, дабы не выходить за пределы его.
но я через u32 обрабатываю только iphdr/tcphdr, а в нем чаще всего(если конечно пакет не битый) всегда всё в норме:)

kam ★★ ()

Друзья, спасибо за помощь.
Буду дальше тестировать. Результаты скину в эту тему.

poiuty ()

Советы в теме действительно помогли.

# iptables -t raw -L -v -n
Chain PREROUTING (policy ACCEPT 11M packets, 1718M bytes)
 pkts bytes target     prot opt in     out     source               destination
1317K   53M DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            u32 "0x6&0xff=0x6&&0x20&0xffff=0x0&&0x4&0x1fff=0x0"

Chain OUTPUT (policy ACCEPT 12M packets, 6646M bytes)
 pkts bytes target     prot opt in     out     source               destination

Пакеты уходят в DROP. Больше мы на них не отвечаем.
https://poiuty.com/images/syn_flood10.png

Кстати, ovh теперь моментально фильтрует эту атаку.

poiuty ()
Последнее исправление: poiuty (всего исправлений: 2)
Ответ на: комментарий от poiuty

We provide no guarantee that your stress test will cause the target to be down. If your target does not go offline then submit a ticket and we will have our power department investigate the target and do our best to cause it to go offline.

Не серьезные ребята. Сейчас еще заинтересовался и нашел их новый сайт. Но похоже у них просто отсутствуют бесплатные планы или временные планы.

anonymous_sama ★★★★★ ()
Ответ на: комментарий от poiuty

Советы в теме действительно помогли.

Что там с потреблениями ресурсов в момент атаки? Память кушаться не должна, а вот CPU? Особенно всякие softirq...

Кстати, ovh теперь моментально фильтрует эту атаку.

Просто утащили решение из этой темы. А как же тестрование нагрузочное теперь проводить? Может советы и не помогли вовсе?

anonymous ()
Ответ на: комментарий от anonymous

Помогли. Тестил на Hetzner без фильтрации. Все уходит в DROP.
Нагрузка 10% si.

poiuty ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.