Защита от DDoS-атак для сайтов малого бизнеса

DDoS-атака (distributed denial of service, распределённый отказ в обслуживании) — это атака, при которой сайт или сервер одновременно заваливают трафиком из множества источников, чтобы сделать его медленным или недоступным для реальных посетителей. Малый бизнес сталкивается с теми же тремя основными категориями атак, что и крупные предприятия, но защита не требует затрат корпоративного уровня: CDN/прокси перед сайтом, разумное ограничение частоты запросов на сервере и план действий на случай, если что-то всё же прорвётся.

Что такое DDoS-атака на самом деле

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

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

Три типа DDoS-атак, с которыми вы столкнётесь

DDoS-атаки делятся на три категории: объёмные (volumetric), протокольные (protocol) и атаки уровня приложения (application-layer) — каждая исчерпывает свой ресурс, а значит, требует своей защиты.

Объёмные атаки

Объёмные атаки перегружают сетевой канал огромным объёмом трафика, используя такие техники, как UDP-флуд, ICMP-флуд и спуфинг или усиленные (amplified) пакетные флуды, — пока легитимный трафик просто не перестаёт помещаться в канал. Именно эта категория стоит за рекордными атаками, попадающими в заголовки новостей: Cloudflare сообщила об отражении флуда мощностью 6,5 терабита в секунду, а также — отдельно — самой интенсивной по количеству пакетов атаки за всю историю наблюдений, 4,8 миллиарда пакетов в секунду, обе — в 2025 году (Cloudflare, отчёты об угрозах DDoS за 2025 год). Канал сервера малого бизнеса даже близко не подходит к такому масштабу, и именно поэтому даже скромный объёмный флуд способен вывести его из строя.

Протокольные атаки

Протокольные атаки нацелены на то, как устанавливаются и поддерживаются соединения, — они расходуют ресурсы файрволов, балансировщиков нагрузки и таблиц соединений самого сервера, а не пропускную способность канала. Типичные примеры — TCP SYN-флуд, ACK-флуд и другие формы исчерпания состояния TCP-соединений, при которых атакующий открывает (или наполовину открывает) гораздо больше соединений, чем сервер способен отследить.

Атаки уровня приложения (Layer 7)

Атаки уровня приложения нацелены на само веб-приложение, обычно через HTTP, и их сложнее всего обнаружить, поскольку отдельные запросы выглядят легитимными. По данным исследователей безопасности, отслеживающих такие атаки, флуды уровня L7 исчерпывают серверные ресурсы — соединения с базой данных, воркеры PHP-FPM или процессор — за счёт большого количества запросов либо за счёт «медленного и тихого» (low and slow) истощения соединений, которое никогда не превышает простой порог по объёму. Именно в этой категории грань между «DDoS» и «агрессивным скрейпингом или credential stuffing» размывается, и именно она в наибольшей степени поддаётся защите на стороне сервера — с помощью ограничения частоты запросов и fail2ban.

Современные атаки всё чаще сочетают все три типа. В отчёте Cloudflare об угрозах за третий квартал 2025 года описан ботнет Aisuru, оцениваемый в один-четыре миллиона заражённых устройств, который регулярно проводил атаки мощностью более 1 терабита в секунду и 1 миллиарда пакетов в секунду, а также отдельные гипер-объёмные HTTP-флуды свыше 200 миллионов запросов в секунду (Cloudflare Radar, отчёт об угрозах DDoS за третий и четвёртый кварталы 2025 года). За весь 2025 год, по данным Cloudflare, объём DDoS-атак более чем удвоился по сравнению с предыдущим годом и достиг 47,1 миллиона атак — в среднем 5376 отражённых атак в час.

Как DDoS-атаки выглядят для малого бизнеса

Для малого бизнеса разрушительная DDoS-атака обычно составляет лишь малую долю от масштаба рекордных атак из заголовков новостей, потому что инфраструктура цели намного меньше сети крупного CDN. VPS с портом на 1 Гбит/с и базой данных, которая с трудом справляется даже с несколькими сотнями одновременных соединений, не нуждается в флуде на несколько терабит, чтобы «упасть»; часто достаточно нескольких сотен Мбит/с мусорного трафика или нескольких тысяч вредоносных запросов в секунду, направленных на медленный эндпоинт вроде страницы поиска или формы входа.

Реалистичные сценарии для малого бизнеса, как правило, укладываются в несколько шаблонов: ботнет, сканирующий широкие диапазоны IP-адресов, в которые случайно попадает и ваш, и атакующий открытый порт; конкурент или обиженная сторона, оплатившая дешёвый «booter»-сервис против вашего домена; скрейперы или инструменты credential stuffing, маскирующиеся под высокообъёмный «нормальный» трафик; либо побочный ущерб от атаки, направленной на другой сайт на общей инфраструктуре. NIST отмечает, что малым компаниям часто не хватает экспертизы или бюджета для разработки выделенной анти-DDoS стратегии (NIST, программа Advanced DDoS Mitigation Techniques), и именно поэтому базовые меры защиты, описанные ниже, важнее для малого бизнеса, чем экзотические.

Реалистичные варианты защиты для бюджета малого бизнеса

Реалистичная и посильная по бюджету защита от DDoS для малого бизнеса строится по принципу многоуровневости: CDN/прокси поглощает объёмные и протокольные атаки ещё до того, как они достигнут сервера, а ограничение частоты запросов на сервере в паре с fail2ban справляется со злоупотреблениями уровня приложения, которые всё же прорываются.

CDN или обратный прокси перед сайтом

Размещение CDN/прокси-сервиса, такого как Cloudflare, перед вашим доменом — это самый эффективный шаг из доступных малому бизнесу, поскольку он скрывает IP-адрес исходного сервера и поглощает атаки сетевого уровня с помощью инфраструктуры, рассчитанной именно на эту задачу. На этом же уровне для приложений, размещённых в AWS, работают AWS Shield и AWS WAF: документация AWS описывает использование правила на основе частоты запросов (rate-based rule) в веб-ACL WAF как отправную точку для защиты от DDoS на уровне приложения — оно оценивает трафик за скользящее окно и автоматически блокирует IP-адреса, превышающие заданный порог (руководство разработчика AWS WAF, раздел «Configuring application layer DDoS protections»). Аналог у Cloudflare работает похожим образом на границе сети, ещё до того, как трафик достигнет вашего VPS.

Ограничение частоты запросов на веб-сервере

Директивы limit_req и limit_conn в nginx ограничивают количество запросов и соединений, которые один IP-адрес может сделать за заданный промежуток времени, — это закрывает предсказуемый, повседневный класс злоупотреблений: слишком много запросов из слишком малого числа источников к слишком малому числу эндпоинтов. Это контроль на стороне сервера, который работает независимо от того, используете вы CDN или нет, и его стоит дополнить разумными лимитами для страниц входа, эндпоинтов поиска и всего, что запускает запрос к базе данных, — это самые дешёвые для атакующего цели истощения ресурсов.

limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;

server {
    location /login {
        limit_req zone=general burst=5 nodelay;
    }
}

Более подробный разбор укрепления сервера помимо ограничения частоты запросов см. в нашем руководстве по лучшим практикам безопасности nginx.

fail2ban для борьбы со злоупотреблениями уровня приложения

Fail2ban читает журналы сервера в поисках таких закономерностей, как повторяющиеся неудачные попытки входа или срабатывания ограничения частоты запросов, а затем эскалирует постоянных нарушителей до бана IP на уровне файрвола, обычно постепенно увеличивая срок бана с коротких тайм-аутов до 24–48 часов для повторных нарушителей. У него есть встроенный фильтр специально для срабатываний rate-limit в nginx, поэтому он может автоматически превращать «этот IP постоянно упирается в лимит» в «этот IP теперь заблокирован файрволом». Fail2ban не остановит объёмный флуд, поскольку такой трафик никогда не доходит до той точки, где мог бы сгенерировать запись в журнале, на которую можно среагировать, но он действительно эффективен против брутфорса при входе, скрейпинга и низкообъёмных HTTP-злоупотреблений, составляющих большинство реальных инцидентов уровня приложения, с которыми сталкивается малый бизнес. Он работает как один из уровней в рамках более широкой настройки файрвола; см. наше руководство по файрволу в Linux о том, как он сочетается с iptables/nftables и политиками default-deny.

Фильтрация на стороне провайдера

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

Что переоценено, а что реалистично

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

Стоит также реалистично смотреть на масштаб. Маркетинговые материалы корпоративных DDoS-продуктов активно опираются на рекордные цифры — терабиты в секунду, миллиарды пакетов в секунду, — потому что эти цифры впечатляют. Малому бизнесу почти никогда не нужно напрямую защищаться от атак такого масштаба: CDN или провайдер поглощают атаки такого размера задолго до того, как они достигнут небольшого исходного сервера. От чего малому бизнесу действительно нужно защищаться, так это от гораздо меньших и гораздо более распространённых злоупотреблений уровня приложения и скромных объёмных флудов, целенаправленно бьющих по недостаточно обеспеченной ресурсами инфраструктуре, — а это совсем другая (и куда более достижимая) задача, чем «остановить атаку на несколько терабит».

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

Составление практического плана реагирования

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

Заранее выясните, есть ли у вашего CDN/прокси режим «под атакой» (under attack), добавляющий посетителям JavaScript-проверку или CAPTCHA, — временно включить его во время реальной атаки куда лучше, чем узнавать о существовании этой опции прямо посреди инцидента. Держите контакт для жалоб на злоупотребления или эскалации DDoS у вашего хостинг-провайдера в доступном месте, не зависящем от доступности пострадавшего сервера. И периодически пересматривайте пороги ограничения частоты запросов по мере роста трафика, поскольку лимиты, настроенные для небольшого сайта два года назад, сейчас могут блокировать легитимных клиентов или, что ещё хуже, стать настолько мягкими, что перестали работать вовсе.

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