Оптимизация приложения от syn-spoof ddos

Я не сис.админ, а простой линуксовый программист. Так что попробуй это: в /etc/sysctl.conf.d/10-synflood.conf положи

net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_synack_retries = 3

Еще могу посоветовать поставить сурикату, если ресурсы позволяют.

спасибо, но к сожалению это не решает проблему

спасибо, но к сожалению это не решает проблему

Глупый вопрос: а sysctl --system запускал после этого? Или эти параметры были включены задолго до?

Раньше тестировал эти параметры во время подобных атак, не помогало. Сейчас так же включил их, обновил конфиг командой sysctl -p

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

В чем заключается настройка iptables для такой атаки?

1. https://www.google.com/search?q=linux syn-spoof ddos mitigation

2. https://www.google.com/search?q=+DPDK user-mode tcp stack ddos mitigation

3. https://qrator.net/ru/

На всякий, я предполагаю что по ссылкам вы дойдете до https://people.netfilter.org/hawk/presentations/OpenSourceDays2017/XDP_DDoS_p... и т.п.

qrator от обычных атак то ели-ели защищает, вы про syn-spoof + я использую ddos guard, что на мой взгляд, более преспособлен к большинству атак. Суть syn-spoof в том, что это не флуд, чтобы фильтровать айпишники. Это такие же коннекты, как реальные клиенты, но они засоряют приложение

qrator от обычных атак то ели-ели защищает, вы про syn-spoof + я использую ddos guard, что на мой взгляд, более преспособлен к большинству атак. Суть syn-spoof в том, что это не флуд, чтобы фильтровать айпишники. Это такие же коннекты, как реальные клиенты, но они засоряют приложение

Ну так вы как-бы сами ответили на свой вопрос.

Т.е. вам в любом случае нужен акселерированная фильтрация по «black list», в который отбракованные IP-шники должны попадать из вашего приложения.

Если ориентироваться на готовые решения, то предлагаю смотреть в сторону Openflow. Например, вы можете запустить https://ru.wikipedia.org/wiki/Open_vSwitch на базе DPDK/XDP и управлять черным списком через Openflow.

Альтернативно можно взять подходящий «железный» коммутатор, использовать XDP-фильтрацию или что-то «навелосипедить» на DPDK.

Я бы попробовал позаписывать пакеты и посмотреть поля, используемые в p0f. Возможно получится выделить какую-то сигнатуру, по которой получится дропать пакеты.

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

А делают это обычно фаирволами. Во FreeBSD pf, например, есть SYN proxy. Это когда хэндшейком занимается firewall потребляя минимум ресурсов, и только если оный прошёл подключается приложение. Есть SYN cookies, не знаю как они работают. Ищи что-то похожее под свою систему.

18:43:03.808206 IP 175.106.17.18.39924 > 10.10.6.2.29000: Flags [P.], seq 3426970109:3426970194, ack 2618594369, win 229, options [nop,nop,TS val 7654412 ecr 4912993], length 85
18:43:03.808218 IP 92.50.45.74.45711 > 10.10.6.2.29000: Flags [P.], seq 2753063183:2753063268, ack 3392855582, win 913, options [nop,nop,TS val 477695584 ecr 4913019], length 85

Пример пакетов, единственное что совпадает у 90% коннектов - размер пакетов, но по нему фильтровать должно быть опасно для легальных клиентов (отфильтрует не тех)

Размер пакетов ничего не говорит. Есть hop_limit, ecn, есть инкапсуляция ipv6 в ipv6, различные флаги, tcp urgent, tcp push, window size. Посмотри поля из p0f.

[2019/07/13 15:59:51] mod=syn|cli=37.212.16.93/37518|srv=10.10.6.2/29000|subj=cli|os=Windows NT kernel 6.x|dist=13|params=generic fuzzy tos:0x30|raw_sig=4:51+13:0:1400:8192,0:mss,nop,ws,nop,nop,sok:df,id+:0

Вот например, слабо понимаю эти параметры, что они дают?

Идея в том, что пока атакующий не в курсе, то скорее всего по этим параметрам можно подобрать такую комбинацию, при которой процент false positive будет не такой высокий.