Защита от DDoS: что можно настроить на уровне своего сервера

DDoS — это не одна атака, а как минимум два разных сценария

Когда сайт вдруг перестаёт отвечать, а в панели мониторинга видна аномальная нагрузка на сеть или на процессор, первая мысль почти всегда одна и та же — «нас DDoS-ят». За этой короткой фразой на практике скрываются два принципиально разных типа атак, которые по-разному ведут себя технически и совершенно по-разному поддаются самостоятельной защите на уровне собственного сервера.

Атаки уровня L3/L4 (сетевой и транспортный уровни модели OSI) — это грубая сила: атакующий пытается забить пропускную способность сетевого канала или исчерпать ресурсы сетевого стека огромным объёмом трафика, зачастую даже не пытаясь установить полноценное HTTP-соединение с сайтом. Атаки уровня L7 (уровень приложения) устроены хитрее: множество запросов, которые внешне выглядят как обычный HTTP-трафик от реальных посетителей, генерируются в объёме, рассчитанном на исчерпание ресурсов конкретно веб-сервера, PHP-процессов или базы данных.

Разница между этими двумя типами принципиальна для того, что вообще можно сделать в ответ. Против объёмной атаки первого типа сервер, каким бы мощным он ни был, беспомощен по чисто физическим причинам — подробно об этом дальше. Против атак второго типа правильно настроенный сервер способен если не полностью остановить атаку, то заметно снизить её эффективность и продержаться до момента, когда подключатся дополнительные меры защиты.

Эта статья честно разбирает, что реально можно настроить на уровне своего VPS или выделенного сервера, а что требует вмешательства на уровне сети провайдера или специализированного сервиса — без понимания этой границы легко потратить время на бесполезную настройку там, где помочь может только апстрим-защита, и наоборот пропустить меры, которые действительно работают на своём уровне.

L3/L4: объёмные атаки, которые забивают канал раньше, чем достигают сайта

Классические примеры объёмной атаки — SYN flood (шквал запросов на установку TCP-соединения без завершения рукопожатия, из-за чего сервер копит полуоткрытые соединения), UDP flood (поток UDP-пакетов на случайные порты, вынуждающий сервер тратить ресурсы на генерацию ответов «порт недоступен») и amplification-атаки через открытые DNS-, NTP- или memcached-серверы, где короткий запрос с подделанным обратным адресом жертвы порождает ответ, в десятки и сотни раз превышающий его по объёму.

Ключевая особенность всех этих сценариев — трафик забивает физический канал связи или сетевой интерфейс сервера ещё до того, как пакеты вообще доходят до userspace-процессов вроде Nginx или PHP-FPM. Если у сервера канал в 1 Гбит/с, а атака генерирует 10, 50 или 200 Гбит/с трафика, то любая настройка firewall или веб-сервера физически бессильна: канал уже перегружен на уровне сетевого оборудования, и никакие правила iptables на самом сервере эту перегрузку не разгрузят, потому что проблема возникает раньше, чем трафик доходит до сервера как такового.

ss -s

Именно поэтому классический совет «настройте iptables получше» не работает против объёмной атаки — правило iptables отбрасывает пакет уже после того, как он занял место в очереди сетевой карты иканала, а при потоке в десятки гигабит в секунду очередь переполняется значительно раньше, чем сервер успевает применить хоть какую-то логику фильтрации. Реальные значения мощности подобных атак в интернете регулярно измеряются сотнями гигабит и даже терабитами в секунду — это на порядки превышает канал практически любого VPS или даже выделенного сервера.

L7: атаки на уровне приложения — здесь сервер действительно может постоять за себя

HTTP flood — самый распространённый сценарий L7-атаки: большое число запросов, каждый из которых выглядит как совершенно легитимный GET или POST, направлено на страницы, требующие заметных вычислительных ресурсов — поиск по каталогу, фильтрацию товаров, генерацию PDF, страницу авторизации. В отличие от объёмной атаки, здесь важен не объём трафика в мегабитах, а число одновременных запросов, каждый из которых занимает отдельный процесс PHP-FPM или соединение с базой данных.

Slowloris — более коварный вариант: атакующий открывает множество соединений и намеренно передаёт HTTP-заголовки очень медленно, по одному байту за раз, удерживая соединение открытым как можно дольше и не позволяя серверу освободить связанный с ним рабочий процесс. При достаточном числе таких «зависших» соединений сервер быстро исчерпывает лимит одновременных обработчиков, и новым, уже легитимным посетителям просто не достаётся свободного процесса.

Оба сценария объединяет одно: они эксплуатируют не сетевой канал, а конечность конкретного ресурса на самом сервере — числа процессов PHP-FPM, соединений с базой данных, файловых дескрипторов. Именно поэтому здесь настройки самого веб-сервера и приложения работают: если ограничить, сколько запросов в секунду и сколько одновременных соединений может держать один источник, атака упирается в этот потолок значительно раньше, чем успевает исчерпать ресурсы сервера целиком.

limit_req: ограничение частоты запросов с одного IP-адреса в Nginx

Модуль ngx_http_limit_req_module в Nginx реализует алгоритм «дырявого ведра» (leaky bucket): для каждого клиента ведётся счётчик запросов, и если частота превышает заданный порог, лишние запросы либо ставятся в очередь с задержкой, либо сразу отклоняются с ошибкой. Это первая и самая практичная линия обороны против HTTP flood на уровне самого веб-сервера, не требующая установки дополнительного ПО.

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
}

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
        limit_req_status 429;
    }
}

Директива limit_req_zone задаёт зону памяти на 10 мегабайт (этого достаточно для отслеживания около 160 тысяч уникальных IP-адресов) и лимит в 10 запросов в секунду на каждый адрес — это значение стоит выбирать исходя из реального профиля посещаемости конкретного сайта, а не копировать бездумно: слишком строгий лимит рискует зацепить пользователей за NAT крупного офиса или мобильного оператора, у которых на один внешний IP приходится множество разных людей.

Параметр burst=20 разрешает кратковременный всплеск до 20 запросов сверх базового лимита — без него любая страница с десятком отдельных ресурсов (стили, скрипты, изображения), загружаемых почти одновременно при обычном открытии сайта, рискует упереться в ограничение уже на первом заходе обычного посетителя. Параметр nodelay обрабатывает всплеск сразу, без искусственной задержки, что важно для отзывчивости сайта при легитимной пиковой нагрузке.

На практике разумнее не применять один общий жёсткий лимит ко всему сайту, а выделить отдельную, более строгую зону для конкретных тяжёлых точек — формы поиска, страницы авторизации, оформления заказа — оставив основной трафик статики и обычных страниц под более мягким или вовсе отсутствующим ограничением. Так атака на конкретный дорогой по ресурсам эндпоинт гасится, не задевая обычных посетителей, листающих каталог.

limit_conn: ограничение числа одновременных соединений с одного адреса

Модуль ngx_http_limit_conn_module решает смежную, но другую задачу — не частоту запросов во времени, а число одновременно открытых соединений с одним и тем же IP-адресом. Это именно та мера, которая напрямую противостоит атакам вроде slowloris, где ценность атаки как раз в удержании множества параллельных «зависших» соединений.

http {
    limit_conn_zone $binary_remote_addr zone=addr:10m;
}

server {
    limit_conn addr 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 10s;
}

Директивы client_body_timeout и client_header_timeout ограничивают время, в течение которого Nginx готов ждать, пока клиент допередаст тело запроса или заголовки — именно этот механизм напрямую обезвреживает классический slowloris, поскольку сервер принудительно разрывает соединение, которое передаёт данные подозрительно медленно, вместо того чтобы ждать его бесконечно.

Важно понимать, что современный Nginx в базовой конфигурации уже заметно устойчивее к slowloris, чем классический Apache с моделью prefork, где каждое соединение занимало отдельный тяжёлый процесс — событийная архитектура Nginx сама по себе снижает эффективность подобной атаки. Явно заданные тайм-ауты и limit_conn формализуют эту защиту и делают её предсказуемой, а не полагаются только на архитектурное везение.

fail2ban: автоматическая блокировка по паттерну в логах

fail2ban — инструмент, который читает лог-файлы (например, лог ошибок Nginx или access-лог) и автоматически добавляет временное правило блокировки в firewall для IP-адреса, если тот за короткое время совершил слишком много подозрительных действий — неудачных попыток входа, запросов, отклонённых по limit_req с кодом 429, или обращений к несуществующим страницам в характерном для сканеров темпе.

В отличие от limit_req и limit_conn, которые ограничивают клиента «мягко» (замедляя или временно отклоняя запросы), fail2ban реагирует жёстче — полностью блокирует IP-адрес на заданное время после превышения порога нарушений, что снижает и без того минимальную нагрузку от повторных попыток того же источника. Базовая установка и настройка fail2ban для защиты SSH подробно разобрана в статье о защите SSH — тот же инструмент несложно расширить собственным jail, который следит именно за логом Nginx и статусом 429 от limit_req, а не только за попытками входа по SSH.

Важная оговорка: fail2ban эффективен против атаки с ограниченного числа источников, но заметно теряет смысл против ботнета из тысяч или десятков тысяч уникальных IP-адресов — банить каждый адрес по отдельности при таком масштабе становится игрой в догонялки, где стоимость поддержания списка блокировок для сервера сопоставима с самой нагрузкой от атаки. Здесь fail2ban стоит воспринимать как дополнительный фильтр здравого смысла, а не как основной рубеж обороны.

Сокращение поверхности атаки: базовая сетевая гигиена

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

Базовая настройка firewall — закрытие всех портов, кроме реально нужных (SSH, HTTP, HTTPS), и ограничение доступа к административным интерфейсам и панелям мониторинга конкретными IP-адресами — подробно разобрана в статье про firewall на Linux. Это не остановит направленную атаку на сам веб-сайт, но резко сокращает число сервисов, которые вообще можно нагрузить или атаковать, и убирает случайный фоновый шум ботов, сканирующих весь диапазон портов подряд.

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

Ранее обнаружение: мониторинг вместо ожидания жалоб пользователей

Раннее обнаружение атаки заметно сокращает время простоя: чем быстрее замечен аномальный рост нагрузки, тем быстрее можно применить limit_req с более жёстким порогом, добавить IP в бан fail2ban или, при необходимости, обратиться в поддержку провайдера для включения сетевой защиты. Базовые метрики сервера — загрузка CPU, число соединений, использование сетевого канала — стоит отслеживать постоянно, а не только в момент, когда сайт уже недоступен; общий подход к такому мониторингу разобран в статье про базовый мониторинг сервера.

Помимо ресурсных метрик полезно периодически заглядывать непосредственно в access-лог Nginx в моменты подозрительной активности — характерный признак атаки на уровне приложения виден невооружённым глазом: множество запросов к одному и тому же URL за короткое время, подозрительно однообразный User-Agent или его полное отсутствие, запросы без характерных заголовков, которые отправляет обычный браузер.

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

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

Честные пределы самостоятельной защиты и когда действительно нужен CDN или anti-DDoS сервис

Всё описанное выше — limit_req, limit_conn, fail2ban, базовая гигиена firewall — эффективно против атак умеренного масштаба на уровне приложения, но не спасёт от по-настоящему крупной волюметрической атаки, которая измеряется десятками или сотнями гигабит в секунду. Канал даже щедрого выделенного сервера обычно ограничен единицами гигабит в секунду — против атаки, на порядок превышающей эту цифру, локальные настройки бессмысленны просто по законам физики сети.

Специализированные anti-DDoS сервисы и CDN с функцией защиты от атак решают эту проблему иначе — они принимают на себя весь входящий трафик на собственной, географически распределённой и заведомо избыточной по пропускной способности инфраструктуре, отфильтровывают вредоносный трафик там, и до вашего origin-сервера доходит уже только очищенный легитимный трафик. Принцип работы такой инфраструктуры и то, когда она оправдана для конкретного сайта, подробно разобраны в статье про CDN.

Практический ориентир: если сайт напрямую связан с бизнесом, где простой в пиковый час стоит реальных денег — интернет-магазин в сезон распродаж, сервис с оплатой подписки, — стоит заранее, до первой реальной атаки, подключить CDN или anti-DDoS защиту, а не полагаться на то, что настроек Nginx хватит на любой сценарий. Для небольшого сайта-визитки без истории атак настройки, описанные в этой статье, вместе с базовой сетевой защитой большинства современных провайдеров обычно оказываются достаточным и разумным по трудозатратам уровнем защиты.

Итог: что настроить в первую очередь

Начните с базовой гигиены: закройте firewall всё, что не обязано быть публично доступным, ограничьте административные интерфейсы по IP — это снижает поверхность атаки без каких-либо рисков сломать нормальную работу сайта. Добавьте limit_req на тяжёлые по ресурсам эндпоинты (поиск, авторизацию, оформление заказа) с разумным порогом и параметром burst, чтобы не задеть обычных посетителей.

Настройте limit_conn и явные тайм-ауты клиента в Nginx как защиту от атак типа slowloris, и подключите fail2ban с собственным jail для отслеживания повторных нарушений limit_req — это дополнительный, но не решающий слой защиты. Наладьте базовый мониторинг нагрузки и сетевого трафика, чтобы заметить атаку в первые минуты, а не по жалобам клиентов о недоступности сайта.

И самое важное — заранее, а не в момент реальной атаки, выясните, что именно предлагает ваш провайдер на случай объёмной атаки на канал, и оцените, нужен ли вашему проекту дополнительный CDN или anti-DDoS сервис уже сейчас, а не когда счёт пойдёт на минуты простоя. Если не уверены, какие меры нужны именно вашему проекту — опишите задачу в заявке внизу страницы, поможем настроить конкретную защиту под ваш стек и уровень риска.