Доступные методы борьбы с DDoS-атаками для владельцев VDS серверов с Linux

Почему мы не используем традиционный и часто рекомендуемый лимит по подключениям с одного и того же ip адреса (limit_req_zone $binary_remote_addr ...)? Во-первых, под этот лимит попадут клиенты провайдеров, сидящие за nat’ом. Во-вторых, этот порог установить как-то универсально не возможно, потому что есть сайты с ajax и большим кол-вом js/css/картинок и у них в принципе на загрузку одной страницы может быть несколько десятков хитов, поэтому такой порог использовать можно, но только для каждого сайта индивидуально. В третьих, для т.н. “вялотекущих” DDoS-атак боты вообще не будут попадать под этот порог, их просто будет много, но каждый в отдельности бот будет делать не много запросов за короткий период времени, в результате мы ничего не сможем отфильтровать, а сайт при этом работать не будет.

Для того, чтобы воспользоваться нашим методом, конфигурационный файл nginx, при работе nginx в качестве reverse proxy для apache, должен выглядеть примерно следующим образом:

http {
     limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m;
     ...
     server {
               listen       1.2.3.4;
               server_name  domain.ru www.domain.ru;
               limit_req zone=hostreqlimit burst=2500 nodelay;
               location /
               {
                    proxy_pass http://127.0.0.1:80;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header Host $host;
               }
     }
}

В этом конфиге так же подразумевается, что apache у нас слушает на loopback интерфейсе на 127.0.0.1:80, а nginx на 80м порту на нашем внешнем ip-адресе (1.2.3.4) и на порту 8080 на 127.0.0.1.

Отфильтрованные nginx’ом хиты будут сопровождаться такой записью в error.log nginx’а:

2012/01/30 17:11:48 [error] 16862#0: *247484 limiting requests, excess: 2500.200 by zone "hostreqlimit", client: 92.255.185.237, 
server: domain.ru, request: "GET / HTTP/1.1", host: "domain.ru", referrer: "http://www.yahoo.com/"

Чтобы получить из error.log список всех блокировавшихся ip-адресов мы можем выполнить следующее:

cat error.log | awk '/hostreqlimit/ { gsub(", ", " "); print $14}' | sort | uniq -c | sort -n

Но мы с вами помним, что мы тут блокируем просто всех, кто обратился к сайту после того, как счетчик обращений насчитал 1500 раз в минуту, поэтому не все заблокированные - боты. Ботов же можно выделить, если провести какую-то условную черту по количеству блокировок. Как правило для такой черты выбирается значение в несколько сотен раз за 5-15 минут. Например, мы пополняем список ботов раз в 5 минут и считаем что все, кого nginx заблокировал более 200 раз - боты.

Теперь перед нами стоит две проблемы:

1. Как выбрать из лога период “последние 5 минут”
2. Как отсортировать только тех, кто был заблокирован более N раз 

Первую проблему решаем при помощи tail -c +OFFSET. Идея сводится к тому, что после разбора error.log мы записываем во вспомогательный файл его текущий размер в байтах (stat -c '%s' error.log > offset), а при следующем разборе отматываем error.log на последнюю просмотренную позицию (tail -c +$(cat offset)). Таким образом, запуская разбор логов раз в 5 минут, мы будем просматривать только ту часть лога, которая относится к последним 5 минутам.

Вторую проблему решаем при помощи скрипта на awk. В итоге получим (THRESHOLD - это тот самый лимит по количеству блокировок, после которого соответствующий IP-адрес считается принадлежащим атакующему нас боту):

touch offset; (test $(stat -c '%s' error.log) -lt $(cat offset) 2>/dev/null && echo 0 > offset) || echo 0 > offset; \
tail -c +$(cat offset) error.log | awk -v THRESHOLD=200 '/hostreqlimit/ { gsub(", ", " "); a[$14]++; } \
END { for (i in a) if (a[i]>THRESHOLD) printf "%s\n", i; }' ; stat -c '%s' error.log > offset

Подразумевается, что этот набор команд выполняется в той директории, где лежит error.log от nginx, то есть как правило это /var/log/nginx. Полученный в результате список мы можем отправить в firewall на блокировку (об этом ниже).

В качестве простого примера напишем правила firewall, которые разрешают подключение к серверу по ssh только из нашего офиса (с ip-адреса 1.2.3.4), а всем остальным доступ по ssh блокируют:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP
COMMIT

Эти строки можно записать в текстовый файл и загрузить в firewall с помощью: iptables-restore < firewall.txt, а сохранить текущее состояние firewall в файл: iptables-save > firewall.txt.

Работают эти правила следующим образом. Первая строка - разрешаем весь трафик для всех соединений, которые уже открыты (процедура handshake пройдена). Вторая строка - разрешаем любой трафик с ip-адреса 1.2.3.4 и помечаем комментарием, что это наш офис. На самом деле сюда доходят только пакеты, устанавливающие какое-либо соединение, то есть пакеты типа syn и ack, все остальные пакеты проходят только первую строку. Третья строка - запрещаем всем подключение по tcp на 22й порт. Сюда доходят попытки подключения (syn, ack) по ssh от всех, кроме нашего офиса.

Интересно, что первую строчку можно смело удалить. Плюс наличия такой строки: для уже открытых соединений в firewall отработает всего одно правило, а пакеты в рамках уже открытых соединений - это подавляющее большинство принимаемых нами пакетов, то есть firewall с такой строкой в самом начале практически не будет вносить никаких дополнительных задержек в работу сетевого стека сервера. Минус: эта строка приводит к активации модуля conntrack, который держит в памяти копию таблицы всех установленных соединений. Что затратнее: держать копию таблицы соединений или необходимость обрабатывать несколько правил firewall на каждый пакет - это индивидуальный нюанс каждого сервера. Если firewall содержит всего несколько правил, на наш взгляд правильнее строить его правила так, чтобы модуль conntrack не активизировался.

В iptables можно создавать дополнительные цепочки, задаваемые пользователем. В каком-то смысле это выглядит как аналог вызова функций в языках программирования. Создаются новые цепочки просто: iptables -N chain_name. Используются создаваемые таким образом цепочки для того, чтобы разделять firewall на разные логически блоки. Об этом подробнее далее.

В терминах iptables это выглядит так:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:ddos - [0:0]
:friends - [0:0]
:whitelist - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP
-A INPUT -j whitelist
-A INPUT -j ddos
-A INPUT -j friends
-A INPUT -j DROP
-A whitelist -s 222.222.222.222 -j ACCEPT
-A whitelist -s 111.111.111.111 -j ACCEPT
-A ddos -s 4.3.2.0/24 -j DROP
-A friends -s 91.201.52.0/22 -j ACCEPT
COMMIT

Опять же, целесообразность наличия второй строки под вопросом и в зависимости от полного размера firewall она может как ускорять его работу, так и тормозить.

Заполняем таблицу friends:

for net in $(curl -s http://noc.masterhost.ru/allrunet/runet); do iptables -A friends -s $net -j ACCEPT; done

Проблема такого firewall в его монстроидальности: таблица friends в случае Рунета будет содержать порядка 5000 правил. Таблица ddos в случае более-менее среднего ddos’а будет содержать еще 1-2 тысячи записей. Итого firewall будет состоять из 5-7 тысяч строк. При этом все пакеты, прилетающие от заграничных отправителей, которые должны быть просто отброшены, на самом деле будут проходить все 5-7 тысяч правил, пока не доберутся до последнего: -A INPUT -j DROP Сам по себе такой firewall будет отъедать огромное количество ресурсов. 

Здесь последним параметром указывается тип создаваемой таблицы: nethash - это set для списка сетей, iphash - для отдельных ip адресов. Есть разные варианты таблиц, подробности в man ipset. Соответственно whitelist и friends - это таблицы типа nethash, а ddos - iphash.

Чтобы воспользоваться созданной таблицей ipset в firewall, достаточно одного правила (строки firewall), например:

-A INPUT -m set --match-set whitelist src -j ACCEPT
-A INPUT -m set --match-set ddos src -j DROP

Добвить какой-то ip-адрес во вновь созданную таблицу можно так:

ipset -A ddos 1.2.3.4

таким образом, весь наш firewall при использовании ipset сводится к:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP
-A INPUT -m set --match-set whitelist src -j ACCEPT
-A INPUT -m set --match-set ddos src -j DROP
-A INPUT -m set --match-set friends src -j ACCEPT
-A INPUT -j DROP
COMMIT

Заполняем set friends (тип nethash):

for net in $(curl -s http://noc.masterhost.ru/allrunet/runet); do ipset -A friends $net; done

заполняем set ddos из показанной ранее команды:

touch offset; (test $(stat -c '%s' error.log) -lt $(cat offset) 2>/dev/null && echo 0 > offset) || echo 0 > offset; \
for ip in $(tail -c +$(cat offset) error.log | awk -v THRESHOLD=300 \
'/hostreqlimit/ { gsub(", ", " "); a[$14]++; } END { for (i in a) if (a[i]>THRESHOLD) printf "%s\n", i; }' ; \
stat -c '%s' error.log > offset); do ipset -A ddos $ip; done

Параметры ядра, о которых пойдет речь, правятся с помощью команды sysctl:

sysctl [-w] option

Опция -w означает, что вы хотите записать новое значение в какой-то параметр, а ее отсутствие, что вы хотите прочитать текущее значение этого параметра. Рекомендуется поправить следующие параметры:

net.ipv4.tcp_syncookies=1
net.ipv4.ip_local_port_range = 1024 65535
net.core.netdev_max_backlog = 30000 
net.ipv4.tcp_max_syn_backlog = 4096
net.core.somaxconn = 4096
net.core.rmem_default = 124928
net.core.rmem_max = 124928
net.core.wmem_max = 124928
net.ipv4.tcp_rmem = 4096     8192     87380
net.ipv4.tcp_wmem = 4096     8192     65536

Параметр net.ipv4.tcp_syncookies отвечает за включение механизма syncookies; net.core.netdev_max_backlog определяет максимальное количество пакетов в очереди на обработку, если интерфейс получает пакеты быстрее, чем ядро может их обработать; net.ipv4.tcp_max_syn_backlog определяет максимальное число запоминаемых запросов на соединение, для которых не было получено подтверждения от подключающегося клиента; net.core.somaxconn максимальное число открытых сокетов, ждущих соединения. Последние 5 строк - это различные буферы для tcp-соединений.