Как снизить нагрузку на серверную часть, создаваемую вредоносным трафиком
Я хочу уменьшить или смягчить последствия вредоносного трафика уровня 7 (целевые атаки, стандартное злонамеренное автоматическое сканирование), который достигает моего бэкэнда, что делает его очень медленным и даже недоступным. Это относится к атакам на основе нагрузки, как описано в https://serverfault.com/a/531942/1816
Предположим, что:
- Я использую не очень быструю внутреннюю часть / CMS (например, TTFB ~ 1500 мс для каждого динамически генерируемая страница). Оптимизация невозможна или просто требует больших усилий.
- Я полностью увеличил масштаб, т. Е. Использую максимально возможную скорость H / W.
- Я не могу масштабироваться, то есть CMS не поддерживает репликацию от мастера к мастеру, поэтому он обслуживается только одним узлом.
- Я использую CDN перед серверной частью, достаточно мощный, чтобы обрабатывать любой трафик, который кэширует ответы на долгое время (например, 10 дней). Кешированные ответы (обращения) бывают быстрыми и больше не затрагивают мой сервер. Промахи, очевидно, дойдут до моего бэкэнда.
- IP-адрес моего бэкэнда неизвестен злоумышленникам / ботам.
- Некоторые варианты использования, например, запросы POST или пользователи, вошедшие в систему (небольшая часть от общего использования сайта), настроены на обход кеша CDN, поэтому они всегда попадают в серверную часть.
- Изменение чего-либо в URL таким образом, чтобы оно было новым / уникальным для CDN (например, добавление
& _ foo = 1247895239), всегда приводит к попаданию в серверную часть. - Злоумышленник, который сначала изучил систему, очень легко найдет очень медленные варианты использования (например, страницы с разбивкой на страницы до 10.000-го результата), которыми он сможет злоупотребить вместе со случайными параметрами # 7, чтобы довести бэкэнд до своего колени.
- Я не могу предсказать все известные и действительные URL-адреса и допустимые параметры моей серверной части в определенный момент времени, чтобы каким-то образом внести запросы в белый список или очистить URL-адреса в CDN, чтобы уменьшить количество ненужных запросов, достигающих серверной части. например,
/ search? q = somethingи/ search? foo = bar & q = somethingдадут 100% одинаковый результат, потому чтоfoo = bar- это не то, что я серверная часть использует, но я не могу очистить это на уровне CDN. - Некоторые атаки происходят с одного IP-адреса, другие - с нескольких IP-адресов (например, 2000 или более), которые невозможно угадать или легко отфильтровать по диапазонам IP-адресов.
- И провайдер CDN, и провайдер серверного хоста предлагают какую-то функцию DDoS-атак, но атаки, которые могут вывести из строя мой бэкэнд, очень малы (например, всего 10 запросов в секунду) и никогда не рассматриваются как DDoS-атаки со стороны этих провайдеров.
- У меня есть мониторинг и мгновенно получаю уведомления, когда серверная часть перегружена, но я не хочу вручную запрещать IP-адреса, потому что это нежизнеспособно (я могу спать, работать над чем-то другим, в отпуске или атака может быть с разных IP-адресов).
- Я не решаюсь вводить ограничение на количество подключений в секунду для каждого IP-адреса на сервере, поскольку в какой-то момент я откажу в доступе легальным пользователям. е.Представьте себе презентацию / семинар о моем сервисе в университете или крупной компании, где десятки или сотни браузеров почти одновременно будут использовать сервис с одного IP-адреса. Если они вошли в систему, они всегда будут доходить до моего сервера и не будут обслуживаться CDN. Другой случай - это пользователи государственного сектора, которые получают доступ к услуге с очень ограниченного количества IP-адресов (предоставленных государством). Таким образом, это запретит доступ законным пользователям и вообще не поможет атакам со многих IP-адресов, каждый из которых выполняет только пару запросов.
- Я не хочу постоянно заносить в черный список определенные большие диапазоны IP-адресов стран, которые иногда являются источниками атак (например, Китай, Восточная Европа), потому что это несправедливо, неправильно, будет отказывать в доступе законным пользователям из этих регионов и атакам из других места не пострадают.
Итак, что я могу сделать, чтобы справиться с этой ситуацией? Есть ли решение, которое я не учел в своих предположениях, которое могло бы помочь?
Я чувствую вашу боль - но перед вами стоит невыполнимая задача. Вы не можете съесть свой торт и съесть его.
Обычно я предлагаю fail2ban в качестве инструмента для решения этой проблемы (если ограничение скорости веб-сервера не является вариантом), однако вы не только прямо говорите, что не можете даже поддерживать временный запрет, поскольку ваш трафик идет через CDN, вам нужно будет создать множество функций, чтобы сообщить об адресе и применить блокировку.
У вас осталось только 2 варианта действий, которые я вижу:
1) превратить сайт в html-файлы и использовать их в качестве статического содержимого
2) найти работу где-нибудь еще
Я живу в похожей среде (я не управляю ею напрямую, но работаю с командой, которая этим занимается), и мы нашли два решения, которые хорошо работают вместе. В нашем случае мы сами размещаем приложение, поэтому у нас есть полный контроль над потоком трафика, но идея остается прежней.
Некоторые из ваших ограничений довольно сложны, и я бы сказал, что они противоречивы, но я думаю, что их можно обойти. Я не уверен, что такое ваш CDN, но я предполагаю, что это черный ящик, который вы на самом деле не контролируете.
Я бы предложил настроить перед вашим приложением еще один уровень (кэширующий) для контроля и изменения трафика, для этого мы используем Varnish — в основном для кэширования, но также и для смягчения вредоносного трафика. Я могу быть довольно маленьким, и мне не нужно кешировать так долго, как CDN, поскольку он должен видеть очень мало трафика.
- Дезинфекция URI перед предустановкой на серверную часть. Обычно вы не можете сделать это в CDN, но вы можете сделать это со своим человеком на среднем сервере. Разрешить только известные URI и параметры, остальные будут либо обрезаны, переданы в систему регулирования, либо немедленно отклонены (404, 500...).
- Промахи кэша приводят к регулированию или отсутствию обслуживания. В зависимости от вашего приложения, даже один промах кеша в секунду (вероятно, даже меньше) для каждого IP-адреса клиента может указывать на вредоносный трафик, особенно если вы видите только промахи кеша из CDN. Это требует, чтобы у вас было некоторое представление о реальных IP-адресах конечных пользователей, и вы, вероятно, можете ограничить его, чтобы исключить зарегистрированных пользователей или известные хорошие диапазоны IP-адресов (которые могут иметь более слабые правила регулирования или вообще не регулировать). CloudFront добавляет заголовки X-Forwarded-For, возможно, в вашей CDN есть что-то подобное.Например, есть 5 промахов кеша в течение 15 секунд на IP-адрес клиента, отклонение с ошибкой, которая не кэшируется в CDN (вероятно, 429) в течение 60 секунд. Большее количество промахов в течение более длительного периода приводит к более длительным банам. См. здесь https://github.com/varnish/varnish-modules/blob/master/docs/vmod_vsthrottle.rst