syn flood spoofing ip

http://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood-attacks-with-red...

Пробовал.

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

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

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

Сори. Секунд.

Первая же ссылка в гугл: https://www.ndchost.com/wiki/server-administration/hardening-tcpip-syn-flood
Только net.ipv4.tcp_synack_retries, попробуй поставить два.

Находил и тестил тоже.

Меняй ip и вставай на CDN.

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

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

CDN ляжет как нефиг делать.

Да сходил по ссылке. ТС, оставь данные как с тобой связаться.

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

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

Отправил

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

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

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

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

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

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

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

Перестает отвечать на новые соединения. Старые отваливаются. Подробная информация по ссылке в первом посте.

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

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

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

Значение 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).

В /var/logs/messages и /var/logs/syslog никаких ошибок
Только сообщения, что отправляются syn куки.

Я нашёл несколько одинаковых статей про 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 - не многовато ли?

Чаще всего атакуют спуфом через 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млн пакетов в секунду, вы ляжете все ровно, и вас не спасёт ничего:)

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

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

?

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

вот бан по 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 - в реальной жизни не встречается :) по этому можно спокойно банить

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

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

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

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

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

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

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

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

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

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

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

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

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

# 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 теперь моментально фильтрует эту атаку.

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.

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

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

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

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

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

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