Коротко: включите защиту у провайдера, разместите сайт за сетью доставки контента, активируйте веб-экран приложений, ограничьте частоту запросов и бережно закройте узкие места в коде. Добавьте мониторинг и чёткий план реагирования. Распределённая атака отказа в обслуживании (DDoS) гасится не одной кнопкой, а связкой мер — от сети до базы данных.
Что такое распределённая атака отказа в обслуживании и чем она бьёт по хостингу
Распределённая атака отказа в обслуживании — это искусственная перегрузка сайта и инфраструктуры множеством источников, из‑за чего легальные пользователи получают ошибки и задержки. Бьёт по каналу, по серверам, по приложению — в том порядке, где слабее.
Под капотом всё прозаичнее, чем кажется. Потоки запросов и пакетов приходят с десятков тысяч заражённых устройств, маскируются под «обычный» трафик и выбирают самое тонкое место: канал связи, таблицу соединений, пул воркеров веб‑сервера, тяжёлую страницу поиска или узкий индекс в базе. Отсюда — три семейства: объёмные атаки на пропускную способность, протокольные на сетевой и транспортный уровни и прикладные на уровень веб‑приложения. На общем хостинге сайт делит ресурсы с соседями, поэтому критический предел наступает раньше; на виртуальном и выделенном — позже, но цена ошибки выше, ведь простаивает уже своя железка. Последствия просты и неприятны: падение SLA, утечка пользователей к конкурентам, проблемы с поисковой оптимизацией (SEO) из‑за недоступности и, между прочим, рост счета за лишний трафик. Характерные признаки — скачок запросов к одной странице, всплеск ответов 502/504, рост времени до первого байта, исчерпание соединений в базе, поведение роботов подозрительно старательное.
| Тип атаки | Куда целится | Быстрый контрход |
|---|---|---|
| Объёмная | Канал и маршрутизаторы | Фильтрация у провайдера, сеть доставки контента, чёрные списки сетей |
| Протокольная | Соединения и стеки | Лимиты соединений, агрессивные таймауты, префильтр на уровне сети |
| Прикладная | Веб‑сервер и код | Веб‑экран приложений, кэш, ограничение частоты, защита авторизации |
Быстрые меры на уровне хостинга: что включить сегодня
Минимальный набор: попросить провайдера включить фильтрацию трафика, перевести сайт за сеть доставки контента (CDN), активировать веб‑экран приложений (WAF) и задать лимиты частоты и соединений. Плюс агрессивные таймауты и кэш статики — это дешёво и помогает сразу.
Первым делом имеет смысл проверить, какие опции уже входят в тариф: часто есть базовая фильтрация на периметре и возможность проксировать домен через защитные узлы. Переезд за сеть доставки контента снижает нагрузку на источник за счёт кэша на краях: картинки, стили, скрипты, даже целые HTML‑страницы с коротким сроком хранения. Веб‑экран приложений добавляет слои: поведенческие правила, блокировку частых повторов, принудительные проверки пользователя через лёгкие задачи в браузере. Дальше важны приземлённые мелочи: лимит активных соединений на IP, ограничение параллельных запросов к тяжёлым маршрутам, короткие таймауты keep‑alive. Не стесняемся гео‑ и ASN‑фильтров, если бизнес локальный. Система доменных имён (DNS) должна уметь быстро менять адрес на резервный фронт — проверьте заранее время жизни записей. И ещё одна быстрая и почти бесплатная вещь: принудительное сжатие, чтобы тратить меньше канала на ответы, когда это уместно.
- Подключить защитный тариф у провайдера и включить фильтры на периметре.
- Проксировать домен через сеть доставки контента и включить кэш HTML для анонимных пользователей.
- Активировать веб‑экран приложений и базовые правила для форм, входа, поиска.
- Ограничить частоту запросов и количество одновременных соединений на IP.
- Сократить таймауты, включить сжатие и кэш статики.
Куда ткнуть в панели, чтобы сработало завтра
В панели хостинга обычно доступны три вещи: переключатель «защита от атак» у сети, привязка домена к прокси‑узлам и раздел с правилами веб‑экрана. Начинаем с сети — включаем усиленную фильтрацию. Затем привязываем домен, включаем принудительный HTTPS и кэш. В веб‑экране добавляем правило: не более N запросов в минуту к /login, /search, /api. Наконец, в веб‑сервере выставляем лимит на соединения, чтобы один клиент не забивал очередь. Долго? Нет. На практике — 15–30 минут.
Настройки приложения и базы: как не стать лёгкой мишенью
Главные шаги: кэшировать всё, что можно, упрощать тяжёлые запросы, выносить статический контент за пределы сервера и строго ограничивать частоту «дорогих» действий. Защитить формы входа и регистрации, а при перегрузке включать режим «только чтение» для части функционала.
Начинаем с очевидного. Каталог, главная, карточки — для анонимных посетителей легко кэшируются даже на минуту‑две, и это уже кратно снижает нагрузку. Поисковой блок и фильтры — самый частый триггер прикладной атаки: добавляем агрегированные индексы, лимит на глубину пагинации, защиту от слишком широких запросов. В точках входа — защита от перебора: ограничение попыток по IP и по учётной записи, мягкая капча при пятикратной ошибке. Всё, что не нужно прямо сейчас пользователю, уходит в очередь задач: письма, перерасчёты, отчёты. Статические файлы — мимо приложения: прямой отдачей через сеть доставки контента. Под горячую фазу атаки готовится «режим бережливости»: отключаем тяжёлую аналитику, убираем несущественные виджеты, для гостей отвечаем заранее сформированными страницами. В базе — короткие транзакции, лимиты соединений для пулов, индексы под частые WHERE; если выбор между «упасть героически» и «дать простую страницу», выбираем второе, пользователи оценят честность.
| Узел | Что ограничивать | Практический порог | Эффект |
|---|---|---|---|
| Веб‑сервер | Частота и параллельность | 20–60 r/m на IP к «дорогим» маршрутам | Сбивает темп злоумышленников, не мешая людям |
| Приложение | Попытки входа, поиск | 3–5 ошибок входа, 10–20 запросов поиска/мин | Режет перебор и сканирование |
| База данных | Длина транзакций, пул | Таймаут 2–5 с, 50–200 коннектов | Не даёт очередям залипать |
| Статика | Срок кэша | 5–30 мин для медиа, 1–5 мин для HTML | Умножает пропускную способность |
Три частых ошибки, из‑за которых падают даже крепкие сайты
Первая — дорогостоящие, но «незаметные» виджеты: умные рекомендательные блоки, которые тянут десятки запросов без кэша. Вторая — открытая для всех подробная API‑функция, где забыли ограничение частоты, а она пересчитывает пол‑каталога. Третья — тяжёлая страница поиска, на которой можно запросить «всё и сразу», и приложение добросовестно пытается это сделать. Лечится всё это одинаково: кэш, лимиты, подготовленные агрегаты, а на крайний случай — временная деградация функциональности с честным сообщением пользователю.
Процедуры мониторинга и реагирования: кто, что и когда делает
Нужен план реагирования: понятные триггеры, роли и каналы связи, заранее подготовленные сценарии переключения и готовые правила фильтрации. Плюс автоматические оповещения и регулярные учебные тревоги, чтобы не растеряться в реальной атаке.
Картина атаки собирается из метрик. На периметре — скорость входящего трафика и неожиданные всплески соединений. На балансировщике — запросы в секунду, задержка до первого байта, рост очередей. В приложении — доля ответов 5xx, медиана и хвосты времени ответа. В базе — количество активных запросов, блокировки и медленные выборки. Всё это — с порогами и тихими ночными алертами в один‑два канала, без дублирования, иначе люди быстро привыкают и перестают реагировать. Ключевой организационный момент — кто принимает решение о включении «бережливого режима» и кто общается с пользователями: лучше иметь короткий шаблон сообщения и страницу‑заглушку, где честно объясняется ситуация. Раз в квартал полезно устраивать учения: имитацию наплыва трафика и проверку переключений домена, чтобы выяснить, где узкие места и кто забыл пароль от панели.
| Метрика | Норма | Тревога | Действие |
|---|---|---|---|
| Ответы 5xx | <1% | >5% 3 мин подряд | Включить кэш HTML, ослабить динамику |
| Время ответа P95 | <800 мс | >2 с | Сократить таймауты, урезать тяжёлые маршруты |
| RPS к /login, /search | Фоновая линия | x3 к базовой | Жёсткие лимиты, мягкая капча, белые списки |
| Активные запросы в БД | <60% пула | >90% 2 мин | Отключить тяжёлую аналитику, урезать N+1 |
Чеклист «за 15 минут», когда уже штормит
Порядок действий помогает не терять время и нервы. Держим краткий список под рукой и не спорим с ним в горячий момент.
- Включить усиленную фильтрацию у провайдера, проксировать трафик через сеть доставки контента.
- Активировать готовый профиль веб‑экрана: вход, поиск, API под ограничениями.
- Веб‑сервер: снизить keep‑alive, ограничить соединения на IP, прикрутить частотные лимиты.
- Приложение: включить кэш HTML и режим «бережливости», отключить дорогостоящие виджеты.
- База: сократить таймауты запросов, проверить блокировки, рестарт медленных воркеров.
- Коммуникация: включить страницу‑заглушку для части трафика, оповестить команду и пользователей.
Где посмотреть живые примеры и напоминания
Кстати, неплохая шпаргалка лежит по ссылке: Как защитить сайт от DDoS-атак на хостинге. Список мер короткий, но помогает не забыть базовые шаги — особенно в ночь на пятницу, когда внимание утекает быстрее, чем трафик льётся в лог.
Итоги: защита — это не стена, а набор дверей с правильными замками
Секрет устойчивости в слоистости. Периметр фильтрует лишнее, сеть доставки контента гасит всплески, веб‑экран прикрывает больные маршруты, приложение отвечает коротко и из кэша, база дышит ровно, а мониторинг заранее зовёт на помощь. Когда каждый слой делает своё скромное дело, суммарный эффект превышает усилия, и атака превращается в шум.
И да, универсальной «красной кнопки» не бывает. Зато работает дисциплина: готовые профили, списки правил, рутинные учения, внятные роли. Такой подход выдерживает и внезапный наплыв честных клиентов, и упрямый поток мусора. Плавность работы — следствие заранее принятых решений, не чудо удачи.