root@localhost:~# iptables -t raw -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2779 145K DROP 0 -- * * 181.191.0.0/16 0.0.0.0/0
10519 547K DROP 0 -- * * 177.93.0.0/16 0.0.0.0/0
Видно же что команды не сработали. Буду полагать что вы сами ничего крупного туда не добавляли.
Пики до 100% от чего? от процессов или ядра? Если остановить докер?
Да, проверял на своём сервере, который тоже попал под флуд-атаку (в подарок со своими активными клиентами, которые хотят посмотреть ютуб). Писал-крутил настройки 1.5 часа, применил, никто не пожаловался… От 4600+ TCP запросов до 1600 максимум…
В любом случае надо поискать более рациональное решение, чтобы не загрязнять iptables…
Обычно у хостера есть графики нагрузки на CPU и загрузки канала связи. Покажите их за последние сутки.
И покажите вывод top -o %CPU в пиках
непонятно кому ответ и про что, мне вы так и не ответили и не показали сколько у вас срабатываний на этом правиле.
совершенно непонятно о чём речь
Проблема решилась переустановкой Docker и 3X-UI. SYN Flood никуда не делся, но загрузка CPU скакать перестала
Узнал у ребят и Hostkey, CPU не ведут подсчет, канал почти не загружен:
А вот как это выглядело, постоянные скачки загрузки CPU до 100% с оповещением в тг-бот о превышении допустимого предела загрузки:
root@localhost:~# top -o %CPU
top - 21:13:23 up 1 day, 22:10, 1 user, load average: 1.19, 0.70, 0.64
Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.2 us, 5.4 sy, 0.0 ni, 45.4 id, 0.0 wa, 0.0 hi, 7.2 si, 37.9 st
MiB Mem : 892.3 total, 68.2 free, 544.2 used, 414.9 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 348.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14 root 20 0 0 0 0 S 16.4 0.0 30:40.15 ksoftirqd/0
1157 root 20 0 1257540 64864 22656 S 16.1 7.1 158:09.34 xray-linux-amd6
20331 root 20 0 0 0 0 I 4.0 0.0 0:01.57 kworker/0:2-events
1114 root 20 0 1284696 71512 32580 S 3.8 7.8 46:40.03 x-ui
19846 root 20 0 17996 11220 9280 S 1.6 1.2 0:05.10 sshd
20084 root 20 0 11684 5172 3040 R 1.6 0.6 0:25.20 top
628 root 20 0 1204988 47200 27256 S 0.4 5.2 4:51.98 containerd
15 root 20 0 0 0 0 I 0.2 0.0 1:56.23 rcu_preempt
28 root 20 0 0 0 0 S 0.2 0.0 0:17.58 kcompactd0
20225 root 20 0 0 0 0 I 0.2 0.0 0:00.53 kworker/u32:2-events_unbound
1 root 20 0 102156 11560 8444 S 0.0 1.3 0:04.60 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.30 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
10 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_kthread
12 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_kthread
13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace_kthread
16 root rt 0 0 0 0 S 0.0 0.0 0:04.00 migration/0
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
21 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 inet_frag_wq
22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd
23 root 20 0 0 0 0 S 0.0 0.0 0:00.19 khungtaskd
24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
27 root 0 -20 0 0 0 I 0.0 0.0 0:00.02 writeback
29 root 25 5 0 0 0 S 0.0 0.0 0:00.00 ksmd
30 root 39 19 0 0 0 S 0.0 0.0 0:29.47 khugepaged
31 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kintegrityd
32 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd
33 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 blkcg_punt_bio
34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 tpm_dev_wq
35 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 edac-poller
36 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 devfreq_wq
37 root 0 -20 0 0 0 I 0.0 0.0 0:23.03 kworker/0:1H-kblockd
38 root 20 0 0 0 0 S 0.0 0.0 0:00.73 kswapd0
44 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kthrotld
46 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/24-aerdrv
47 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/25-aerdrv
48 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/26-aerdrv
49 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/27-aerdrv
50 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/28-aerdrv
51 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/29-aerdrv
52 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/30-aerdrv
53 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/31-aerdrv
54 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/32-aerdrv
55 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/33-aerdrv
56 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/34-aerdrv
57 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/35-aerdrv
58 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/36-aerdrv
59 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/37-aerdrv
60 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/38-aerdrv
61 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/39-aerdrv
От флуда помогла вот эта инструкция:
-
Активация SYN cookies
SYN cookies — это механизм, который позволяет серверу не хранить состояние полуоткрытого соединения, а вместо этого кодирует информацию о соединении в самом пакете SYN/ACK. Когда клиент отвечает ACK, сервер проверяет эту информацию и восстанавливает соединение. Для активации SYN cookies выполните команду:
sysctl -w net.ipv4.tcp_syncookies=1
Чтобы изменения сохранились после перезагрузки системы, добавьте строку в файл /etc/sysctl.conf:
net.ipv4.tcp_syncookies = 1 -
Настройка параметров TCP-стека
Вы также можете настроить параметры TCP-стека для управления поведением сервера при атаках Syn flood. Эти настройки уменьшают время ожидания полуоткрытых соединений и увеличивают размер очереди для обработки новых запросов:
- Уменьшение таймаута для полуоткрытых соединений
sysctl -w net.ipv4.tcp_fin_timeout=30 - Увеличение размера очереди для входящих соединений
sysctl -w net.ipv4.tcp_max_syn_backlog=4096 - Ограничение количества попыток повторной отправки SYN+ACK
sysctl -w net.ipv4.tcp_synack_retries=2
Chat-gpt?
Рабочий чат с бородатыми ойтишнегами )
100% ChatGPT “Вы также можете настроить параметры”, “Эти настройки уменьшают время ожидания полуоткрытых соединений и увеличивают размер очереди для обработки новых запросов:”
Люди так писать не будут)
1 Like
Видать вам в чате рабочем скинули ответ нейронки)
кажется единственный нормальный совет в теме, первый может быть почти полностью бесполезен, но пусть будет, а tcp_synack_retries=2 может действительно помочь (у меня при тесте выше он таким и был, не из-за syn-flood, а для удобства, поэтому забыл упомянуть)
Вполне, вполне )
Что за софт?
Возможно с “бразильскими ботами” продолжение:
В проекте Fedora из-за запросов ИИ-индексаторов наблюдаются сбои с работой платформы совместной разработки Pagure. В процессе противостояния с ИИ-ботами пришлось заблокировать множество подсетей, включая весь диапазон IP-адресов Бразилии, что привело к блокировке и некоторых пользователей.
Источник
На vps так же перестали бразильские ip отсвечивать.
2 Likes