Ну synflood, synflood-у рознь. И собстно с чего вы решили что это именно synflood?
1. Правильное решение. Пишите прову, ему с его толстой трубой гораздо легче решить эту проблему.
2. Попробовать справиться самому. Если не так что бы «ооочень распределенная» атака, то iptables модуль connlimit с DROP по превышению.

Задолбали вихри яростных атак

http лучше через fail2ban

В netstat 40к записей с WAIT_TIME или 40к SYN_RECV

Все IP уникальные с SYN_RECV или WAIT_TIME

Cloudflare заюзай.

А вот тут и проблема. Мой проект использует WebSocket, где скорость должна быть без задержек. Любые прокси сервера между клиентом и сервером замедляют работу вебсокета

У тебя он сейчас вообще не работает если его реально дедосят.

Работает, но очень лагает

Любые прокси сервера между клиентом и сервером замедляют работу вебсокета

Ты мерял?

Да, в первый раз у меня стоял прокси, но из-за него у меня скорость websocket падала, сообщентя доходили в 2-3 раза дольше

Cloudflare?

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

TCP/UDP blackhole and LAST_ACK DoS preventin

Я уже пытался менять конфигурацию ядра, но ничего не получается.

CONFIG_GRKERNSEC_BLACKHOLE=y

Related sysctl variables:

kernel.grsecurity.ip_blackhole

kernel.grsecurity.lastack_retries

If you say Y here, neither TCP resets nor ICMP
destination-unreachable packets will be sent in response to packets
sent to ports for which no associated listening process exists.
This feature supports both IPV4 and IPV6 and exempts the 
loopback interface from blackholing.  Enabling this feature 
makes a host more resilient to DoS attacks and reduces network
visibility against scanners.

The blackhole feature as-implemented is equivalent to the FreeBSD
blackhole feature, as it prevents RST responses to all packets, not
just SYNs.  Under most application behavior this causes no
problems, but applications (like haproxy) may not close certain
connections in a way that cleanly terminates them on the remote
end, leaving the remote host in LAST_ACK state.  Because of this
side-effect and to prevent intentional LAST_ACK DoSes, this
feature also adds automatic mitigation against such attacks.
The mitigation drastically reduces the amount of time a socket
can spend in LAST_ACK state.  If you're using haproxy and not
all servers it connects to have this option enabled, consider
disabling this feature on the haproxy host.

If the sysctl option is enabled, two sysctl options with names
«ip_blackhole» and «lastack_retries» will be created.
While «ip_blackhole» takes the standard zero/non-zero on/off
toggle, «lastack_retries» uses the same kinds of values as
«tcp_retries1» and «tcp_retries2».  The default value of 4
prevents a socket from lasting more than 45 seconds in LAST_ACK
state.

Исходя из темы, посмею предположить что у вас в обычной жизни 100500 пользаков одновременно не ломятся. Попробуйте использовать модуль limit для iptables обязательно с -j DROP. Бывали случаи успеха, когда этого хватало за глаза причем на каналах 2-10 мбит/с. Хороший успех возможно будет в случае если каждый ip флудит в овер 65535 tcp соединеий с ожиданием ответа. Бывали случаи. Я как-то протестил, в цикле без всяких sleep зафигачиваем с одной машинки дофига syn пакетов, а в ответ тишина, атакующая система просто колом встает, даже на клаву не реагирует. Но это правда лет 10 назад было.
Если это не поможет, то к прову, у него хтруба толще. Или не заморачиваясь сразу к прову.

ЗЫ Вот ещё вспомнилось несколько случаев. Вынужденным учиться на удаленке (тогда ещё нет) какерам подарили готовый скрипт с подписью аля «с помощью этой программы вы внатуре взломаете другой кампутер и будити крутым я у мамы хакером». Сама прога тупой флудер, так вот в самом пакете содержалась «волшебная строка». Хватило модуля string что бы дропать пакеты. Какеры отваливались пачками.

Не, прокси, который предоставил провайдер

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

я тут придумал кое-что. Мой проект - это дочерний проект огромного проекта. Перед тем, как подключиться к серверу - человек должен произвести действие на огромном проекте.

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

А вы варианты, что клиент подключается с мобильного инета вообще не рассматриваете?

Они не профессионалы. Пользуйся серьезными сервисами. Или хотя бы тестируй.

А какие особенности есть у мобильного интернета?

Новая конфигурация не помогла

У меня порт ssh заменён. У меня расставлены ловушки на портах. При подключении на порты - бан. Но SYN FLOOD вроде как идёт на 443 порт. Я не успеваю посмотреть просто. Жду, пока мне дадут доступ к VNC

Кому интересно, вот конфигурация, которую я ставил:

net.ipv6.conf.all.disable_ipv6=1

net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0

net.ipv4.tcp_rfc1337 = 1

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 1000
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_max_orphans = 65536
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_syn_retries = 1

net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_time = 15
net.ipv4.tcp_keepalive_probes = 5

net.core.somaxconn = 60000

net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_no_metrics_save = 1

net.ipv4.ip_local_port_range = 1024 65535

Соединение разрывается, ip меняется.

а, я видел, что айпи отличаются, типа 123.123.123.123 и 123.123.123.124 Я могу просто по более большому диапазону разрешать доступ

Ну тогда уж 0/0, что бы точно. Вы же не в курсе что там с сетями у опсоса.

Я смотрю за пользователями. По моим наблюдениям айпи сильно не меняется, поэтому на первое время можно сделать так.

Бросайте это дело, первое сентября скоро. Извините, но после вот этого:

По моим наблюдениям айпи сильно не меняется

не смог удержаться.
«Ваши наблюдения» стоят ровно «ничего». Если бы вы написали, я потратил год на тестирование, в круглосуточном режиме, на разных территориях, с разными опсосами и то оно ничего бы не стоило, так как ровно на следующий день после ваших исследований опсос внесет изменения, ичсх вам он об этом сообщить «забудет».
Парочка зарисовок с полей. Дано, стационарное место, время(суток) работы приблизительно одинаковое с погрешностью на один час. «Обычно» ip меняется от 0 до 5 раз. Но периодически бывают случаи, что может быть и несколько десятков разных ip.
Роуминг. Обычно девайс получает ip от гостевой сети и до определенного времени я думал что оно всегда так. Пока как-то не столкнулся с опсосом маленького, но очень гордого княжества известного на весь мир. Так вот они раздавали ip из своих сетей вне зависимости от локации подключения абонента и при переподключении адрес менялся ну ооочень рандомно, а переподключалось оно часто :)

поэтому на первое время можно сделать так.

Вы уверенны что занимаетесь тем, что вам по силам? То, что рождено с костылями никогда не научиться ходить. Или, ничего не бывает постояннее временного.

О! Прямо свежак в тему ip адреса и роуминга. Аппарат с симкой опсоса из USA, сейчас в европе, стабильно получал ip из европейской гостевой сети, и вот внезапно получил из подсетки своего родного заокеанского опсоса.

Забань в iptables всю сеть 45.0.0.1/255.0.0.0

Легче дышать будет. Я серьезно.

Вы немного не поняли. У меня сессия в проекте живёт не более 15 минут.(если ничего не делать). А так за 1 минуту сессия создаётся и удаляется. Я не думаю, что за 1 минуту айпи успеет поменяться.

Как создаётся сессия, так и будет добавляться в iptables запись о разрешении запросов от этого ip, по удалении сессии будет и айпи удаляться.

Сессия создаётся только по запросу главного сайта.

Без сессии подключаться к серверу бесполезно. А разрешения по ip решат проблему с ддосом.