Защита от всплесков нагрузки для каналов Django

Есть ли что-то конкретное, что можно сделать, чтобы сделать сервер Django Channel менее восприимчивым к легкой или случайной атаке DDoS или увеличению общей нагрузки от клиентов websocket/HTTP? Поскольку каналы не являются по-настоящему асинхронными (все еще рабочие за кулисами), я чувствую, что было бы довольно легко удалить веб-сайт на основе каналов - даже с довольно простым оборудованием. В настоящее время я создаю приложение на каналах Django и позже запускаю некоторые тесты, чтобы увидеть, как он держится.

Есть ли какая-то форма дросселирования, встроенная в Дафни? Должен ли я реализовывать дросселирование на уровне приложения? Это все равно будет медленным, так как рабочий все еще обрабатывает дроссельный запрос, но запрос может быть намного быстрее. Есть ли что-нибудь еще, что я могу сделать, чтобы попытаться сорвать эти атаки?

Я думал, что всегда должен быть обеспечен рабочий, назначенный для определенных каналов. Таким образом, если канал websocket перегружается, HTTP все равно будет реагировать.

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

Я ищу конкретный ответ дафни/каналов - общие ответы об DDoS или общей загрузке не являются тем, что я ищу - есть много других вопросов по поводу этого.

Я мог бы также управлять дросселированием на основе того, кто вошел в систему, а кто нет - дроссель для пользователей, которые не вошли в систему, может помочь.

Изменить еще раз: прочитайте весь вопрос! Я не ищу общие рекомендации по смягчению DDoS или объяснения низкоуровневых подходов. Мне интересно, поддерживает ли Дафна что-то вроде:

Троттлинг
Динамическое назначение работника на основе размера очереди
Middleware для обеспечения приоритета аутентифицированных запросов

Или что-то в этом роде. Я также собираюсь обратиться к сообществу каналов прямо на это, так как SO не может быть лучшим местом для этого вопроса.

Ответ 1

Я получил ответ из Andrew Godwin. Он не использует StackOverflow, поэтому я отправляю его здесь от его имени.

Привет, Джейми,

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

Предоставление более совершенной защиты DoS или DDoS, вероятно, не является чем-то, что мы можем сделать в рамках самих каналов, но я хотел бы убедиться, что мы предоставляем соответствующие перехватчики. Были ли определенные вещи, которые, по вашему мнению, мы могли бы реализовать, помогут вам написать некоторые из вещей, которые вам нужны?

(Также стоит иметь в виду, что прямо сейчас мы меняем рабочий/потребительский план по существу как часть основной перезаписи, что будет означать разные соображения при масштабировании, поэтому я не хочу давать слишком точные совет еще)

Эндрю

Он также написал о миграции 2.0 в своем блоге .

Ответ 2

Я отвечаю только на первый вопрос. Поэтому в принципе невозможно защитить 100% от атак ddos, потому что это всегда сводится к битве ресурсов. Если ресурсы на стороне сервера больше ресурсов на стороне злоумышленника, сервер не будет опускаться (возможно, это может замедлить производительность), но если нет, сервер опустится [ссылка не требуется]. Почему вы не можете быть защищены на 100%, вы можете спросить. Таким образом, в основном ваш сервер "сбой", если люди не могут подключиться к нему [https://en.wikipedia.org/wiki/Crash_(computing)#Web_server_crashes --- веб-сервер выдает предложение 1.]. Поэтому, если вы попытаетесь защитить свой сервер, отключив его на 5 минут каждый раз, когда через секунду выполняется 10000 соединений, ddos удалось. Он "разбил" ваш сервер. Единственная защита ddos, о которой я знаю, должна работать Cloudfare (https://www.cloudflare.com/lp/ddos-b/?_bt=207028074666&_bk=%2Bddos%20%2Bprotection&_bm=b&_bn=g&gclid=EAIaIQobChMIu5qv4e-Z1QIVlyW9Ch2YGQdiEAAYASAAEgJbQ_D_BwE). Он поглощает воздействие атаки ddos с помощью магистральной сети 10 Тбит/с. Но даже он не предлагает 100% защиту ddos, потому что, когда его 10Tbps не работает, ваш сервер тоже снизится. Поэтому я надеюсь, что это помогло.

Ответ 3

DDoS = распределенный отказ в обслуживании

"Распределенная" часть - это ключ: вы не можете знать, что вас атакует "кто-то", в частности, потому что запросы поступают повсюду.

Ваш сервер будет принимать только определенное количество подключений. Если злоумышленнику удается создать так много соединений, с которыми никто не может подключиться, вы будете DDoS'ed.

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

Удачи вам в этом!

Защита DDoS действительно должна быть службой поставщика облачных вычислений на уровне балансировки нагрузки.

Компании, такие как OVH, используют сложные методы машинного обучения для обнаружения незаконного трафика и запрещения использования IP-адресов в квазиреальном времени. Для того, чтобы вы создали такой механизм обнаружения, это огромные инвестиции, которые, вероятно, не стоят вашего времени (если ваш веб-сайт не так критичен и потеряет миллионы долларов, если он немного снизится)

Ответ 4

Есть много вещей, которые вы не можете сделать с DDOS. Однако, если есть какие-то опрятные "трюки" в зависимости от того, сколько ресурсов у вас есть, и сколько кто-то хочет взять вас в автономном режиме.

Предлагаете ли вы общую публичную службу, которая требует прямого подключения к ресурсу, который вы пытаетесь защитить?

Если это так, вам просто нужно "впитать" DDOS с ресурсами, которые у вас есть, путем увеличения и уменьшения... или даже эластичного... в любом случае это будет стоить вам денег!

или усложнить использование злоумышленником ваших ресурсов. Существует множество способов сделать это.

Если для обслуживания требуется какая-то аутентификация, отделите свои службы проверки подлинности от ресурса, который вы пытаетесь защитить.

Многие приложения, аутентификация и "служба" работают на одном и том же оборудовании. это ожидаемая DOS.

Разрешать только пользователям, прошедшим проверку подлинности, доступ к ресурсам, которые вы пытаетесь защитить, с помощью правил фильтрации динамических брандмауэров. Если ваш аутентифицированный, то ворота к ресурсам откроются (с ограниченным QOS на месте)! Если ваши хорошо известные, долгосрочные доверенные пользователи, то обращайтесь к ресурсу на полном расстоянии.

У вас есть способ проверки поведения ресурсов пользователей (сети, памяти, процессора), если вы видите конкретные учетные записи, используя причудливые суммы, запрещаете их или устанавливаете лимит, что в конечном итоге приводит к политике переноса брандмауэра для их трафика.

Работа с провайдером, который может иметь системы на месте, которые могут отбросить трафик до вашей спецификации на границе ISP.... OVH - ваш лучший выбор. ISP, который предоставляет фильтр и трафик, отбрасываемый как API, я бы хотел, чтобы они существовали... в основном перемещая правила фильтрации брандмауэра на границу AS... niiiiice! (Фантастика)

Он не остановит DDOS, но предоставит вам несколько инструментов, чтобы ресурсы теряли потребление злоумышленников на управляемый уровень. DDOS должны обратиться к серверам аутентификации... (возможно) или скомпрометировать многие учетные записи пользователей.... у уже прошедших проверку подлинности пользователей все равно будет доступ: -)

Если ваш DDOS потребляет всю вашу пропускную способность интернет-провайдера, это сложнее, перейдите к более крупному интернет-провайдеру! или переместить провайдера...:-). Скройте свой основной ресурс, позвольте ему двигаться динамически, продолжайте движение!:-).

Разделите проблему на части... применяйте элементы управления DDOS на меньших частях.: -)

Я пробовал самый общий ответ, но есть много чего зависит, для каждого DDOS-смягчения требуется немного Skin, а не оловянный подход. На самом деле вам нужен анти-ddos ниндзя в вашей команде.; -)

Взгляните на распределенные протоколы.... DP, возможно, ответ для DDOS.

Получайте удовольствие.

Ответ 5

Позвольте применить некоторый анализ к вашему вопросу. DDoS похож на DoS, но с друзьями. Если вы хотите избежать DDoS-разведки, вам нужно минимизировать возможности DoS. Спасибо капитану очевидным.

Первое, что нужно сделать, это сделать список того, что происходит в вашей системе и какие ресурсы затронуты:

Выполняется рукопожатие tcp (затрагиваются SYN_COOKIES)
Ключ ssl приходит позже (энтропия, процессор)
Для слоя канала установлено соединение...

Затем контролируйте каждый ресурс и пытайтесь выполнить встречную меру:

Защитите SYN_FLOOD, настроив параметры ядра и брандмауэр.
Использование энтропийных генераторов
Настройте свой брандмауэр, чтобы ограничить открытое/закрытое соединение за короткое время (простой способ свести к минимуму ssl handshakes)
...

Отделите свою большую проблему (DDoS) во многих простых и простых задачах. Жесткая часть содержит подробный список шагов и ресурсов.

Извините мой плохой английский.