holynet
Пользователь
- Сообщения
- 1
Авторизуйтесь для просмотра ссылок.
Сайт упал? Серверы недоступны? Знакомо, да?
Простой сервиса обходится в копеечку, а даунтайм подрывает доверие к сервису. Клиент сталкивается с проблемами и вы теряете то самое драгоценное удержание, а самое главное - прибыль.
Как же защититься? Как всё поднять? Если вы когда-либо сталкивались с этими вопросами или же планируете создать что-то своё, то вы должны это знать. Не нужно полагаться на простое русское “авось пронесёт”, сразу отвечу: не пронесёт.
Быстро по терминам
- Легит - обычный живой пользователь, не бот. Тот, ради кого всё и работает.
- CDN - сеть серверов-посредников между пользователем и сервером. Раздаёт контент, кэширует и может принимать на себя часть удара.
- Origin - настоящий сервер, который стоит за CDN. Его адрес нужно прятать.
- Даунтайм (Downtime) - время простоя, когда сервис недоступен. То, ради предотвращения чего вся статья.
- Митигация (Mitigation) - ослабление атаки, чтобы сервис продолжал жить.
- Интерфейс - точка взаимодействия: сайт, API, форма, кнопка, endpoint.
- WAF (Web Application Firewall) - фильтр на входе, который отсеивает подозрительные запросы по правилам.
- Блэкхол (Blackhole) - сброс трафика в никуда. Сервер как будто исчезает из сети. Крайняя мера: спасает не ваш сервис, а сеть вокруг.
- BGP - протокол, по которому сети договариваются, куда вести трафик.
Сам по себе DoS - это Denial of Service, или же простыми словами - “Отказ в обслуживании”. Это когда сервер заваливают запросами или нагрузкой так, что у него заканчиваются ресурсы (канал, процессор, память или даже число соединений) и он перестаёт отвечать обычным пользователям.
DDoS - это Distributed Denial of Service - то же, что и DoS, но идёт с большого количества источников (устройств). Нагрузка, в таких случаях, может идти с тысяч или даже сотен тысяч устройств. Отсюда мы можем понять, что в случае DDoS атаки, нагрузка окажется в разы больше, и заблокировать такую атаку путём бана 1 IP не выйдет. Именно DDoS - основная угроза, под которую и строят защиту.
Боттинг - это нагрузка, создаваемая большим количеством ботов, которые имитируют поведение легитимного пользователя. Используется как для атак, так и для автоматизации каких-либо массовых действий и используется повсеместно. Будь то онлайн игра по типу SA:MP, Minecraft или обычное приложение (сайт) и в основном для получения какой-либо выгоды. С виду - настоящий трафик: ходят по страницам, отправляют запросы, прикидываются реальным клиентом, но в сумме могут грузить сервер, базу, бэкенд и забивать ресурсы.
Чем отличаются по сути
Классический DDoS - это про объём, метод грубой силы: цель уронить здесь и сейчас. А боттинг обычно тише: трафик выглядит правдоподобно, нагрузка может быть маленькой, но постоянной и точечной. Цель не обязательно положить, может быть даже парсинг какого-либо контента, скликивание (к примеру рекламы), перебор, или просто создание точечной нагрузки. Сложность детекта в том, что он прячется в нормальном трафике.
Короткая карта атак
- L3 - сеть. просто забивают канал мусором. Защита: провайдер, anti-DDoS, фильтрация на магистрали.
- L4 - транспорт. флуд соединениями, сервер захлёбывается в полуоткрытых сессиях. Защита: anti-DDoS, файрвол.
- L7 - приложение. запросы к сайту и API, которые выглядят как от живых людей. Защита: WAF, rate limiting, антибот, кэш.
- Боттинг - бьют не по железу, а по функциям: регистрация, логин, поиск, парсинг. Защита: лимиты на ручки, антибот, поведенческие правила.
Итак, картинка ясная: угроза бывает самой разной - где-то грубый объём, где-то тихая маскировка под живых людей. Звучит страшно, но хорошая новость в том, что от этого всего можно защититься. Не одной волшебной кнопкой, а слоями. Дальше разберём оборону по уровням и видам: от сетевого, до уровня приложения. Разберём что такое система OSI уровней, как она работает и что из себя представляет. Плюс то, как подготовиться к первой атаке.
Что это такое - OSI?
Чтобы понять, как защищаться, надо понять, куда именно бьют. А для этого - пара слов о том, как вообще устроено сетевое общение.
Представьте модель OSI как многоэтажку из семи этажей. На нижних этажах “сырые” данные - провода, сигналы, пакеты. На верхних - уже понятные нам вещи: страницы сайта, запросы, кнопки и удобный и привычный всем интерфейс. Каждый этаж занят своим делом, и данные проходят их по очереди: снизу вверх.
Нам из всей этой высотки важны всего три этажа:
L3-L4 - сетевой и транспортный уровень. Это фундамент, по которому и течёт сам трафик. Сюда бьют объёмные атаки, задача которых - тупо забить канал и ресурсы, чтобы до сервера было не достучаться. Грубая сила в чистом виде.
L7 - уровень приложения. Самый верхний этаж, где и живёт твой сайт. Запросы сюда выглядят как настоящие: открыть страницу и даже отправить форму. Именно тут орудуют те самые “тихие” боты. Которые прикидываются живыми людьми и отличить их от реальных клиентов - отдельная головная боль.
Вывод простой: атаки приходят на разные этажи, поэтому защита нужна на каждом. Закрыл фундамент, а верхний этаж нараспашку - так что тебя всё равно достанут. Вот почему защита работает только слоями.
Кстати про самый нижний этаж - физический уровень (L1). Это уже физика: кабели, стойки, охрана, датацентр. В обычной защите приложения мы этот уровень почти не трогаем, поэтому спокойно оставляем его людям с пропусками, камерами и злым админом у стойки. Наша зона ответственности начинается выше.
Хотя и сам датацентр и сам не любит сетевые атаки. Когда по сети прилетает жирная атака, провайдер получает чужой мусорный трафик, который забивает их каналы и мешает соседям. Поэтому при серьёзном объёме датацентр может вмешаться: отфильтровать атаку на своей стороне, если есть мощности, или увести сервер в блэкхол (начать сбрасывать трафик, летящий к вашему серверу, пока атака не остановится), чтобы спасти остальных.
Слой первый: держим удар на сети
Первое и главное правило - не пытайтесь принять объёмный удар в одиночку. Свой сервер почти никогда не вывезет настоящую DDoS атаку: у него канал уже, чем тот поток, что на него обрушат. Это как закрывать собой прорванную плотину.
Поэтому удар принимают на себя посредники - CDN и провайдеры защиты (Cloudflare, Qrator, DDoS Guard и им подобные). Трафик идёт сначала к ним, на их огромные мощности, и только очищенный (на их взгляд) доходит до вас. Они фильтруют мусор на дальних подступах, поглощают объём и прячут реальный адрес вашего сервера, чтобы по нему нельзя было ударить напрямую. А сетевые атаки так вообще могут начинать фильтроваться ещё на магистрали.
А вот тут на сцену выходит BGP
Сам по себе BGP не отличает нормальный трафик от мусора. Он нужен для другого: сказать интернету, куда вести трафик до нужного адреса. Крупные провайдеры и операторы магистральных сетей (Ростелеком, TTK, тот же Qrator) видят трафик ещё на дальних подступах. Не когда он уже ломится в вашу дверь, а пока он только подъезжает к городу. Через BGP anti-DDoS-провайдер может увести поток к себе в центр очистки (scrubbing), отфильтровать мусор и уже чистый трафик вернуть к вам. А в крайнем случае можно объявить blackhole-маршрут - тогда трафик к цели просто сбрасывается, чтобы не положить соседей. Это и называется фильтрацией на стороне upstream-провайдера - один из самых тяжёлых калибров против объёмных атак. На этом и держатся сервисы вроде Qrator или Cloudflare: они не просто встают между вами и атакующим, а договариваются с провайдерами на уровне BGP и чистят трафик ещё до того как он войдёт в вашу сеть.
Да, звучит как идеальная броня, но это не так. Идеальной брони не бывает, вообще. Нет такого решения, которое закрывает всё и навсегда: атаки эволюционируют, и способы обхода появляются ровно так же быстро, как их успевают латать. BGP-фильтрация отлично выметает объёмный мусор, но против хитрого, замаскированного трафика, на уровне приложения она уже бессильна. Так что магистраль - это первый рубеж обороны. Важный, мощный, но не последний.
Слой второй: прячем настоящий сервер
И вот тут многие спотыкаются.
Подключают CDN, видят оранжевое облачко в панели и выдыхают с мыслями “всё, я в безопасности”. А вот и нет.
CDN работает щитом только в одном случае: если весь трафик реально идёт через него.
Но если атакующий знает настоящий IP вашего сервера, он просто обходит щит и бьёт напрямую. Это как поставить охрану на парадный вход, а заднюю дверь оставить нараспашку с табличкой “ну заходите”.
Поэтому origin, настоящий адрес сервера, надо прятать. На практике это значит: доступ к серверу разрешён только с адресов вашего CDN или защитного провайдера. Всё остальное мимо. Прошёл не от Cloudflare/Qrator? До свидания.
И отдельная боль, поддомены. Главная идёт через защиту, а
Авторизуйтесь для просмотра ссылок.
или
Авторизуйтесь для просмотра ссылок.
торчит напрямую, мимо щита. Всё, вы сами показали куда бить. Защита должна закрывать весь проект, а не только главную страницу. Если по старому IP уже прилетало, он мог утечь куда угодно: в DNS-историю, старые записи, логи, письма.Иногда проще выдать серверу новый адрес и сразу закрыть его нормально. С этим обычно просто: поможет обычное обращение к хостеру.
Слой третий: оборона на уровне приложения
Магистраль отсеяла грубый объём, а настоящий сервер мы спрятали. Но самое хитрое только начинается, потому что часть атак спокойно проходит фильтры объёма и стучится к вам как будто это обычные посетители. Тут в дело вступает защита на уровне самого приложения.
Rate limiting - ограничение частоты
Самый простой и при этом реально рабочий инструмент. Смысл: один источник не может слать больше N запросов за установленное количество времени (к примеру секунда/10 секунд/минута). Обычный человек открывает пару страниц в минуту. А бот долбит сотнями - вот его и режут. Настраивается прямо в nginx буквально несколькими строками. Это первый порог, через который мусор не пролезет так легко.
Чтобы не на словах, вот как rate limiting выглядит в nginx:
Код:
http {
limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;
server {
location /login {
limit_req zone=perip burst=10 nodelay;
}
location /api/ {
limit_req zone=perip burst=30;
}
}
}И важный нюанс: IP не всегда идеальный ключ. За одним IP может сидеть целый офис, школа или мобильный оператор с сотнями людей за NAT, а бот наоборот размажется по тысячам прокси. Поэтому нормальные лимиты часто считают не только по IP, но и по аккаунту, сессии, конкретной ручке или по комбинации признаков.
WAF - это фильтр для веб-приложения
Стоит на входе и проверяет запросы по правилам: подозрительный паттерн, странные заголовки, известные сигнатуры атак и отсекает их. Работает как фейс-контроль: явных нарушителей разворачивает ещё на пороге.
Капча - когда есть сомнения
Тот самый способ “ты человек или бот?”. Включать на всё подряд нельзя - живые люди будут злиться. Поэтому её обычно показывают точечно: только подозрительному трафику, когда поведение уже похоже на машинное.
Почему всё это работает только вместе
И сразу скажу: каждый из этих инструментов по отдельности обходится, рейт обходят с помощью обычных прокси. WAF - подбирая запросы, которые не попадают под правила. Капчу - автоматизированными вычислениями и действиями (та же кликалка) или же специальными сервисами распознавания. Поэтому они и работают только вместе, слоями, а не поодиночке.
Слой четвёртый: кэш - тихий спасатель
Есть простое правило: лучший запрос к серверу - тот, который до сервера вообще не дошёл.
Кэш как раз про это. Зачем дёргать origin каждый раз когда кто-то открывает картинку, стиль или статичную страницу? Пусть это отдаёт CDN со своей стороны. Пользователю быстрее, серверу легче, а обычный наплыв людей уже не так страшен.
Кэшировать стоит то, что не меняется каждую секунду:
- картинки
- скрипты и стили (CSS/JS)
- публичные страницы
- аватарки и медиа
- документация и файлы, которые редко меняются
- API
- личный кабинет и всё, где есть авторизация
- приватные данные
- ответы, которые зависят от конкретного пользователя
Кэш не волшебный щит и не спасёт от всего. Но в защите важна каждая мелочь, которая не даёт серверу умереть раньше времени.
Слой пятый: само приложение не должно быть из картона
А вот это самое неприятное и самое упускаемое.
Все думают: “поставлю Cloudflare и всё”. Но если приложение написано так, что один запрос способен положить базу - никакая внешняя защита не сделает его бессмертным.
Простой пример. Есть поиск по сайту: вводишь слово, сервер идёт в базу, ищет. Нормально. А теперь бот дёргает этот поиск сотни раз в секунду, да ещё и такими запросами, что база перелопачивает горы данных. Снаружи - обычные HTTP запросы, ничего криминального. Внутри - сервер уже на коленях.
Поэтому защита живёт и внутри кода:
- лимиты на тяжёлые операции
- таймауты, чтобы запрос не висел вечно
- ограничение размера загружаемых файлов
- потолок на число записей в ответе
- очереди для тяжёлых задач вместо того чтобы делать всё прямо сейчас
- отдельная броня на дорогие действия: поиск, регистрацию, восстановление пароля, отправку SMS и писем
Важно понять одну вещь: запросы стоят по-разному. Открыть статичную картинку дёшево. Запустить поиск по базе уже дорого. Сгенерировать отчёт дорого по процессору. Отправить SMS дорого ещё и деньгами. Загрузить файл бьёт по диску и памяти. Отсюда простое правило: чем дороже действие, тем жёстче лимит. Бессмысленно одинаково лимитировать главную страницу и отправку SMS, это разные зоны риска.
Это тоже защита от DDoS. Не такая зрелищная, как график “атака отбита”, но часто именно она решает, выживет проект или нет. Ведь тут всё зависит от качества подхода ко всем аспектам работы.
Слой шестой: мониторинг и план на чёрный день
Защититься и забыть не выйдет. Нужно видеть, что происходит.
Что смотреть:
- RPS, нагрузку на процессор и память
- время ответа (latency) и всплески ошибок 4xx/5xx
- нагрузку на базу и cache hit ratio
- число запросов на тяжёлые ручки: /login, /api, /search
- топ IP, стран и самых нагруженных endpoint
- Prometheus для сбора метрик и Grafana для графиков
- Netdata для простого старта, ставится в пару команд
- логи nginx и аналитика CDN/WAF
- алерты в Telegram, Discord или на почту
А ещё нужен план - заранее. Кто что делает, когда началось: включить усиленный режим защиты, прикрыть тяжёлые ручки, связаться с провайдером, проверить, не торчит ли origin. Потому что во время атаки поздно гуглить “что делать, если сайт лёг”. План пишется холодной головой, до того как всё загорелось.
Защита не должна резать легитов
И последнее, что часто забывают: защита не должна мешать живым людям сильнее, чем ботам. Капча на каждый клик, бан всех зарубежных IP без разбора, общий жёсткий лимит на весь сайт, всё это бьёт по обычным пользователям. Хорошая защита незаметна для легита и неудобна для атакующего, а не наоборот.
Частые ошибки новичков
- Оставили origin открытым: CDN есть, но сервер доступен напрямую, защита обходится за секунду.
- Закрыли только главный домен, а API и админка торчат отдельно.
- Нет rate limits: авторизацию и восстановление пароля можно дёргать бесконечно.
- Всё на одном сервере: упал он, упало всё.
- Нет мониторинга: про атаку узнают из сообщений “у вас сайт не грузится”, а не с графиков и уведомлений.
- Вера в одну волшебную кнопку: её нет, защита работает только слоями.
- CDN или anti-DDoS подключён, origin закрыт файрволом
- старые DNS-записи проверены, api/admin/dev не торчат мимо защиты
- rate limits стоят на логине, регистрации, поиске, API
- кэш включён для статики и публичных страниц
- есть мониторинг и алерты
- под рукой контакты хостера и план действий
- не паниковать, открыть графики и понять, какой слой страдает: канал, процессор, база
- включить усиленный режим у CDN/WAF, временно ужесточить лимиты
- прикрыть самые тяжёлые ручки
- проверить, не бьют ли напрямую по origin
- связаться с хостером или anti-DDoS
- после атаки разобрать логи и закрыть слабое место
Защита от DDoS - это не одна кнопка и не один сервис. Это слои.
Сначала вы не даёте забить канал. Потом прячете origin. Потом режете мусорные запросы. Потом ограничиваете дорогие операции внутри приложения. Потом следите за графиками и знаете, что делать, если всё-таки прилетело.
Стопроцентной брони не существует. Задача не в том, чтобы стать бессмертным.
Задача - сделать атаку дорогой, муторной и невыгодной.
Тогда вы перестаёте быть лёгкой добычей. И атака превращается не в конец света, а в неприятный день, к которому вы были готовы.
Спонсор статьи:
Авторизуйтесь для просмотра ссылок.
Это лучший агрегатор DDoS атак на рынке на текущий момент.