Защищаем Apache от DDOS атак - Часть 2

Собственно, речь пойдет о защите от SYN flood атак:

Очень популярная DoS атака заключается в посылке большого числа SYN пакетов на ваш сервер. При этом установка TCP связи не доводится до конца. Очередь полуоткрытых запросов соединений быстро заполняется, что мешает установке нормальных соединений. Так как соединение не должно быть обязательно завершено, такая атака не требует больших ресурсов от атакующей машины, поэтому её легко реализовать и контролировать.


Определить SYN атаку просто — команда netstat выдает огромный список полуоткрытых подключений:

netstat -n --tcp | grep SYN_RECV
tcp     0   0 xxx.xxx.xxx.xxx:80    yyy.yyy.yyy.yyy:1084    SYN_RECV   
tcp     0   0 xxx.xxx.xxx.xxx:80    yyy.yyy.yyy.yyy:1228    SYN_RECV   
tcp     0   0 xxx.xxx.xxx.xxx:80    yyy.yyy.yyy.yyy:2652    SYN_RECV   
tcp     0   0 xxx.xxx.xxx.xxx:80    yyy.yyy.yyy.yyy:3446    SYN_RECV


Можем просто подсчитать количество:

netstat -n --tcp | grep SYN_RECV | wc -l
238


Для начала — проверяем параметр tcp_syncookies — он должен быть равен 1:

cat /proc/sys/net/ipv4/tcp_syncookies
1


Так и оставляем. По умолчанию в новых дистрибутивах этот параметр всегда включен.

Если параметр tcp_syncookies установлен (доступен только когда ядро собрано с CONFIG_SYNCOOKIES), тогда ядро обрабатывает SYN пакеты TCP в обычном режиме до тех пор, пока очередь не заполнится. После заполнения очереди включается механизм SYN cookies.

SYN cookies вообще не использует очередь SYN. Вместо этого ядро отвечает на каждый SYN пакет, как обычно SYN|ACK, но туда будет включено специально сгенерированное число на основе IP адресов и портов источника и получателя, а также времени посылки пакета. Атакующий никогда не получит эти пакеты, а поэтому и не ответит на них. При нормальном соединении, будет послан третий пакет, содержащий число, а сервер проверит был ли это ответ на SYN cookie и, если да, то разрешит соединение даже в том случае, если в очереди SYN нет соответствующей записи.

Включение механизма SYN cookies является очень простым способом борьбы против атаки SYN флудом. При этом немного больше загружается процессор из-за необходимости создавать и сверять cookie. Так как альтернативным решением является отклонять все запросы на соединение, SYN cookies являются хорошим выбором.


Также нужно увеличить очередь полуоткрытых соединений — tcp_max_syn_backlog (в Debian Lenny по-умолчанию 1024 соединения):

cat /proc/sys/net/ipv4/tcp_max_syn_backlog
1024


Увеличиваем:

echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog


Кроме того, можем уменьшить время ожидания соединения tcp_synack_retries:

Целочисленное значение (1 байт) tcp_synack_retries определяет число попыток повтора передачи пакетов SYNACK для пассивных соединений TCP. Число попыток не должно превышать 255. Используемое по умолчанию значение 5 соответствует приблизительно 180 секундам на выполнение попыток организации соединения.


cat /proc/sys/net/ipv4/tcp_synack_retries
5


Уменьшаем до 1 (это примерно 9 секунд):

echo "1" > /proc/sys/net/ipv4/tcp_synack_retries


tcp_fin_timeout

Целое число в файле tcp_fin_timeout определяет время сохранения сокета в состоянии FIN-WAIT-2 после его закрытия локальной стороной. Партнер может не закрыть это соединение никогда, поэтому следует закрыть его по своей инициативе по истечении тайм-аута. По умолчанию тайм-аут составляет 60 секунд. В ядрах серии 2.2 обычно использовалось значение 180 секунд и вы можете сохранить это значение, но не следует забывать, что на загруженных WEB-серверах вы рискуете израсходовать много памяти на сохранение полуразорванных мертвых соединений. Сокеты в состоянии FIN-WAIT-2 менее опасны, нежели FIN-WAIT-1, поскольку поглощают не более 1,5 Кбайт памяти, но они могут существовать дольше.


cat /proc/sys/net/ipv4/tcp_fin_timeout 
60


Меняем на 30:

echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout


tcp_keepalive_probes

Целочисленная переменная tcp_keepalive_probes задает число передач проб keepalive, после которого соединение считается разорванным. По умолчанию передается 9 проб.


cat /proc/sys/net/ipv4/tcp_keepalive_probes
9


Ставим 5:

echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes


tcp_keepalive_intvl

Целочисленная переменная tcp_keepalive_intvl определяет интервал передачи проб. Произведение tcp_keepalive_probes * tcp_keepalive_intvl определяет время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, т.е., время разрыва соединения при отсутствии откликов составит приблизительно 11 минут.


cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75


Ставим 15:

echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl


netdev_max_backlog

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

cat /proc/sys/net/core/netdev_max_backlog
1000


Увеличиваем:
echo "20000" > /proc/sys/net/core/netdev_max_backlog


somaxconn

Максимальное число открытых сокетов, ждущих соединения.

cat /proc/sys/net/core/somaxconn
1024


Увеличиваем:

echo "20000" > /proc/sys/net/core/somaxconn


Так как подобные изменения параметров ядра не сохранятся после перезагрузки — добавляем в /etc/rc.local:

echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo "1" > /proc/sys/net/ipv4/tcp_synack_retries
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout
echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes
echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo "20000" > /proc/sys/net/core/netdev_max_backlog
echo "20000" > /proc/sys/net/core/somaxconn


Кроме того, можно добавить ограничение числа SYN пакетов в единицу времени в iptables:

iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 500/s --limit-burst 1500 -j RETURN
iptables -A syn_flood -j DROP


Число новых SYN пакетов — максимум 500 в секунду, при превышении порога в 1500 — новые пакеты блокируются:

Более наглядно этот критерий можно представить себе как некоторую емкость с выпускным отверстием, через которое проходит определенное число пакетов за единицу времени (т.е. скорость «вытекания»). Скорость «вытекания» как раз и определяет величина --limit. Величина --limit-burst задает общий «объем емкости». А теперь представим себе правило --limit 3/minute --limit-burst 5, тогда после поступления 5 пакетов (за очень короткий промежуток времени), емкость «наполнится» и каждый последующий пакет будет вызывать «переполнение» емкости, т.е. «срабатывание» критерия. Через 20 секунд «уровень» в емкости будет понижен (в соответствии с величиной --limit), таким образом она готова будет принять еще один пакет, не вызывая «переполнения» емкости, т.е. срабатывания критерия.
  • +2
  • 16 сентября 2009, 09:26
  • Sergei_T

Комментарии (5)

RSS свернуть / развернуть
+
0
Уже десятки раз встречал фразу «Сокеты в состоянии FIN-WAIT-2 менее опасны, нежели FIN-WAIT-1», но нигде не нашёл как уменьшить время пребывания сокета в состоянии FIN-WAIT-1… Прямо загадка какая-то. Почему все пишут про FIN-WAIT-2 и никто про FIN-WAIT-1?
avatar

sysadm

  • 13 декабря 2012, 19:22
+
0
Это все давно я писал, сейчас я пришел к выводу что кроме аппаратной защиты по сути нет способов остановить DDOS, т.к. когда доходит до iptables канал уже забит.
avatar

Sergei_T

  • 14 декабря 2012, 14:35
+
0
Это не всегда так. Александр Лямин (гуру по DDoS-ам из highloadlab.com) в своем докладе «DDoS практическое руководство к выживанию» писал, что только 77 процентов атак ориентированы на забивание канала жертвы. Оставшиеся 23% ориентированы на приложение, когда сервис можно успешно положить и малым трафиком за счёт узких мест в логики приложения (например, атакующий может найти какой-то URL на сайте, обращение к которому приводит к высокой нагрузке на базу данных — и далее, обращаясь всего 1 раз в секунду к этому URL-у, успешно положить весь сайт).
avatar

sysadm

  • 14 декабря 2012, 19:04
+
0
ну это то да)
avatar

Sergei_T

  • 14 декабря 2012, 22:19
+
0
такие вещи несложно настроить, но от серьезных атак не помогут программные средства
avatar

Sergei_T

  • 14 декабря 2012, 22:26

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.