Как работает защита от DDoS на вашем сервере

Каждый сервер DediJet без дополнительной платы защищен постоянно включенной фильтрацией DDoS-атак на сетевом уровне. Ничего не нужно устанавливать или включать: атаки обнаруживаются автоматически и фильтруются выше по сети, еще до того как трафик достигнет порта вашего сервера. На этой странице описано, от чего защищает фильтрация, от чего нет и как сделать ваши собственные сервисы устойчивее к атакам.

Как работает фильтрация

Входящий в нашу сеть трафик анализируется непрерывно. Когда обнаруживается атака на один из ваших адресов, ее трафик фильтруется выше по сети: пакеты, соответствующие шаблонам атак, отбрасываются, а легитимные пакеты проходят к вашему серверу. Фильтрация включается автоматически — без тикета и каких-либо ручных действий.

Везде, где это возможно, мы фильтруем трафик, а не блокируем адрес через null route. Null route, при котором отбрасывается весь трафик на один IP-адрес, остается крайней мерой.

Что фильтруется

Фильтрация нацелена на атаки уровней 3 и 4, которые пытаются исчерпать пропускную способность канала или таблицы состояний соединений и распознаются по одним лишь характеристикам пакетов:

Что фильтрация не останавливает: HTTP-флуд

Атаки на уровне приложений (уровень 7) отправляют запросы, которые выглядят корректными: полноценные TCP-соединения и правильный HTTP, часто с множества реальных зараженных устройств. Сетевой фильтр не может отличить их от ваших посетителей, поэтому защита приложений — ваша ответственность, а атаки на уровне приложений исключены из SLA. Что помогает:

• Обратный прокси, CDN или WAF перед публичными сайтами. Когда он настроен, принимайте HTTP и HTTPS только из диапазонов адресов прокси, чтобы злоумышленники не могли обойти защиту, атакуя ваш IP напрямую.
• Кэширование, чтобы повторяющиеся запросы вообще не доходили до приложения и базы данных.
• Ограничение частоты запросов для каждого адреса клиента и короткие тайм-ауты против атак медленными запросами.

Пример базовой настройки для nginx. Определите зоны в контексте http, например в файле /etc/nginx/conf.d/limits.conf:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_req_status 429;
client_header_timeout 10s;
client_body_timeout 10s;

Затем примените их там, где нужно:

location / {
    limit_req zone=perip burst=20 nodelay;
    limit_conn connperip 20;
    proxy_pass http://127.0.0.1:8080;
}

Настройте rate и burst под ваш реальный трафик: странице, которая загружает 40 ресурсов, нужно большее значение burst, чем эндпоинту API. Если сервер стоит за CDN, сначала восстановите адрес посетителя с помощью модуля real IP (set_real_ip_from, real_ip_header); иначе все запросы будут выглядеть как пришедшие от прокси и лимиты ударят по всем сразу.

Что вы можете заметить во время атаки

Фильтрация работает автоматически и не требует от вас никаких действий. В начале атаки, пока включается фильтрация, вы можете заметить кратковременный рост задержки, а игроки на игровом сервере — короткий всплеск лагов. Перезагрузка или переустановка ОС не помогут: трафик направлен на ваш IP-адрес, а не на операционную систему.

Что делать при подозрении на атаку

1. Не перезагружайте сервер раз за разом. Перезагрузка не остановит трафик, направленный на ваш адрес: она лишь отключит легитимных пользователей и затруднит диагностику. Проверьте страницу статуса на наличие инцидентов во всей сети.

2. Проверьте маршрут снаружи. Запустите mtr со своего компьютера в сторону сервера и с сервера в сторону своего компьютера:

   Shell

   mtr -rwzc 100 203.0.113.10

   Потери, которые начинаются на одном хопе и сохраняются до последнего, — реальные. Потери только на промежуточном хопе обычно объясняются тем, что этот маршрутизатор ограничивает частоту ответов ICMP. Подробнее — в руководстве по тестированию сети.

3. Проверьте сам сервер. Нагруженное приложение может выглядеть как атака. Сравните нагрузку и количество соединений с обычными значениями:

   Shell

   uptime
   ss -s
   ss -tn state syn-recv | wc -l

4. Создайте тикет. Если сервер недоступен, отметьте тикет как критический: целевое время первого ответа по критическим проблемам — 30 минут. Укажите затронутые IP-адреса, время начала и окончания с часовым поясом (проще всего в UTC), что вы наблюдаете (потери, задержка, какие порты или сервисы затронуты), отчеты mtr в обоих направлениях и, если можете, короткий дамп трафика:

   Shell

   tcpdump -ni any -c 2000 -w /root/attack.pcap

Игровые серверы и UDP

Большинство игровых серверов работает по UDP, поэтому они часто становятся мишенью. UDP-флуд и атаки с усилением фильтруются на сетевом уровне до того, как достигнут вашего порта; остальное зависит от вашей конфигурации:

• Открывайте только те игровые порты, которые используете, а доступ к административным портам (RCON, веб-панели, базы данных) разрешайте только со своих адресов.
• Своевременно обновляйте серверное ПО: в свежих версиях популярных движков пакеты запросов проходят проверку типа challenge-response, поэтому их нельзя использовать для отраженных атак.
• Сообщая о лагах, указывайте время, адрес сервера и то, что видели игроки: сообщения без отметок времени трудно отследить.

Больше советов по хостингу игр — на странице Игровые серверы.

Не становитесь усилителем атак

Атаки с усилением используют неправильно настроенные серверы. Убедитесь, что ваш не из их числа: наши Правила допустимого использования запрещают оставлять открытые DNS-резолверы и NTP-серверы доступными из интернета.

• Выведите список процессов, слушающих UDP-порты, командой ss -ulpn и закройте все, что вы не обслуживаете намеренно.
• DNS: рекурсивный резолвер должен отвечать только вашим собственным сетям (access-control в Unbound, allow-recursion в BIND).
• NTP: chrony раздает время другим машинам только при наличии директивы allow; не добавляйте ее, если в этом нет необходимости.
• Memcached: привяжите его к 127.0.0.1 и оставьте UDP отключенным (-U 0).
• SSDP и CLDAP: медиасерверы с UPnP и контроллеры домена Active Directory никогда не должны отвечать на публичном адресе.

Все еще не получается?

• Сократите остальную поверхность атаки по руководству Защита нового сервера.
• Как устроена наша сеть, читайте на странице Сеть и защита от DDoS.
• Сервер под атакой, и вы не уверены, что происходит? Создайте тикет: фильтрация DDoS входит в зону ответственности поддержки 24/7.