Защита сайта от DDoS-атак в Москве

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

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

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

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

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

Первым делом включить усиленный режим фильтрации на CDN: он отсекает трафик жёстче. Дальше разбор источника и характера атаки. Правила настраиваются точечно, чтобы сайт не сидел на максимальных ограничениях дольше нужного.

Риск ниже, чем у крупного интернет-магазина, но не нулевой: атаки бывают направлены не только на крупный бизнес, а иногда просто по конкурентной причине. Базовая фильтрация через CDN недорога. Она оправдана почти везде, где потеря доступности бьёт по делу.

Нет, и обещать это было бы нечестно: у атаки может быть достаточно ресурсов, чтобы преодолеть любую конечную защиту. Задача защиты другая. Выдержать типичные атаки и большинство целевых. И сократить простой там, где избежать его нельзя.

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

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

Это попытка исчерпать ресурс, за счёт которого сайт работает. Атаки на сетевом уровне просто заливают канал мусорным трафиком — их видно сразу и отражают на стороне провайдера. Атаки на уровне приложения выглядят как обычные посетители: запросы к поиску, к фильтру каталога, к корзине, каждый из которых заставляет сервер работать. Вторые сложнее и опаснее: объём трафика может быть скромным, а сайт всё равно ложится.

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

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

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

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

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

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

Да, и для среднего сайта они вероятнее, чем большая сетевая атака. Это перебор паролей в панели, поток спама через формы, тяжёлые запросы к поиску и фильтру каталога, автоматический сбор содержимого, который создаёт нагрузку просто объёмом. Лечится не одной кнопкой, а набором: ограничение частоты обращений, защита формы, кеширование результатов поиска, ограничение выдачи. Это же снимает большую часть фонового мусора в аналитике.

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

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

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

Проверкой в контролируемых условиях. Смотрим, недоступен ли сервер напрямую в обход защиты. Ищем утечки его адреса в открытых источниках. Проверяем срабатывание правил ограничения частоты на тестовых запросах. Прогоняем управляемую нагрузку в согласованное окно. И проверяем, что поисковые роботы проходят, а сайт остаётся в индексе. Защита, которую ни разу не проверяли, — это предположение, а не защита.