The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Раздел полезных советов: Борьба с SYN-флудом при помощи ipta..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Борьба с SYN-флудом при помощи ipta..."  +/
Сообщение от auto_tips (ok), 14-Дек-15, 16:35 
Начиная с ядра Linux 3.12 и инструментария IPTables 1.4.21 в iptables доступна поддержка новой цели - SYNPROXY, позволяющей в десятки раз увеличить интенсивность обработки SYN-пакетов при противостоянии таким атакам, как SYN Flood, SYN-ACK Flood и ACK Flood.  Например, если в обычной конфигурации ядра сервер на базе CPU Xeon X5550 способен обработать приблизительно 200 тысяч SYN- или ACK-пакетов в секунду, то при включении SYNPROXY производительность возрастает до нескольких миллионов, чего достаточно для отражения небольших атак без привлечения специализированного оборудования.

Включаем в  /etc/sysctl.conf syncookies и timestamps, так как они необходимы для работы SYNPROXY:

   sysctl -w net/ipv4/tcp_syncookies=1
   sysctl -w net/ipv4/tcp_timestamps=1

Исключаем ACK-пакеты из обработки системой отслеживания соединений (отслеживаем только уже установленные соединения, ACK-пакеты снабжаются меткой INVALID), что помогает снизить нагрузку при ACK-флуде:

   sysctl -w net/netfilter/nf_conntrack_tcp_loose=0

Увеличивает размер хэша для отслеживания соединений:

   echo 2500000 > /sys/module/nf_conntrack/parameters/hashsize
   sysctl -w net/netfilter/nf_conntrack_max=2000000

Исключаем SYN-пакеты из обработки в системе отслеживания соединений (таблица raw обрабатывает соединений без их отслеживания, а опция "--notrack" позволяет обойти цель CT ("conntrack")):

   iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack

Выделяем SYN- и ACK-пакеты без отслеживания (UNTRACKED и INVALID), как в прошлом правиле и направляем их в цель SYNPROXY, в которой будет выполнена проверка syncookies и если всё нормально установлено TCP-соединение:

    iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460

Отбрасываем все остальные пакеты, не прошедшие проверку в прошлом правиле:

   iptables -A INPUT -m conntrack --ctstate INVALID -j DROP


Если необходимо обеспечить защиту для отдельного IP, правила можно изменить следующим образом (если атака ведётся только на 80 сетевой порт, можно добавить "--dport 80"):

   iptables -t raw -I PREROUTING -p tcp -m tcp -d 192.168.1.10 --syn -j CT --notrack
   iptables -I INPUT -p tcp -m tcp -d 192.168.1.10 -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
   iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Для просмотра статистики:

   iptables -t raw -vnL
   cat/proc/net/stat/synproxy


Если нужно на низком уровне заблокировать некоторые HTTP-запросы, явно связанные с проведением атаки, можно использовать следующее правило (маску можно выделить из логов или через "tcpdump -nnA dst host 192.168.1.10 and port http"):

   iptables -A INPUT -p tcp --dport 80 -m string --string "маска_блокировки" --algo bm -j DROP

URL: http://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood.../ https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Pro...
Обсуждается: http://www.opennet.me/tips/info/2928.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от pavlinux (ok), 14-Дек-15, 16:35   +/
>  sysctl -w net/ipv4/tcp_timestamps=1

То есть в редшляпе считают установку временных отметок - повышением производительности?! :\

> (маску можно выделить из логов или через "tcpdump -nnA dst host 192.168.1.10 and port http"):
> iptables -A INPUT -p tcp --dport 80 -m string --string "маска_блокировки" --algo bm -j DROP

Загадка "tcpdump флаг -n  и  -m string --string" Найдите общее.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #5

3. Сообщение от ку (?), 16-Дек-15, 17:27   +/
ничего, что это разные программы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

4. Сообщение от mumu (ok), 24-Дек-15, 01:31   +/
Вот тут лучше расписано: http://infoboxcloud.ru/community/blog/iaas/125.html
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от Аноним (-), 25-Дек-15, 07:38   +/
да забей, товаришь из redhat отрабатывает пиар бюджет. Надо же о себе постоянно напоминать - хоть бредом.. зато на слуху.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

6. Сообщение от DeerFriend (?), 26-Дек-15, 18:28   +/
rhel/centos 7 версии используют по-умолчанию firewalld, почему тут приводятся команды от iptables?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

7. Сообщение от имя (?), 28-Дек-15, 08:47   +/
ты оригинальную статью смотрел? а дату публикации видел? 2014/04/11 - причём тут rhel/centos 7, умник?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

8. Сообщение от AOlegemail (?), 03-Дек-16, 14:06   –1 +/
В моём случае не работали правила из-за бекэнда, пришлось добавить ! -s 127.0.0.1/32 иначе из-за своих же запросов он самозабанивался =\ некогда такого раньше не видел...
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от вадя (?), 29-Янв-21, 17:28   +/
Направляем в цель INVALID и потом его добивам. Супер !
Ответить | Правка | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру