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

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

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

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

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

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

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

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

  • Регулирование
  • Динамическое назначение работников в зависимости от размера очереди
  • Промежуточное ПО для обеспечения приоритета аутентифицированных запросов

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


python django websocket django-channels
person Jamie Counsell    schedule 15.07.2017    source источник
comment
Защита от DDOS программным брандмауэром? Мое мнение - трепетная идея! Чтение 60-байтовых заголовков пакетов при каждом запросе. Сработала дополнительная функция для отклонения-сброса-замораживания - system resource проблема. Задержка foregone conclusion. Вы можете добиться успеха в атаках с низкой стоимостью, но как обрабатывать системные ресурсы? Невозможно использовать какую-либо процедуру хранения на брандмауэре, это означает, что запросы good_user vs bad_user. Вы не можете защитить себя, если приняли нежелательные запросы! Недешево, если пакет достиг обратной связи (lo).   -  person dsgdfg    schedule 21.07.2017

Ответы (5)


arrow_upward
5
arrow_downward

Я получил ответ от Эндрю Годвин. Он не использует StackOverflow, поэтому я публикую его здесь от его имени.

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

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

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

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

Эндрю

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

person Jamie Counsell    schedule 10.08.2017

arrow_upward
0
arrow_downward

Я отвечаю только на первый вопрос. Так что практически невозможно быть на 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, потому что, как только его 10 Тбит / с выйдут из строя, ваш сервер тоже выйдет из строя. Итак, я надеюсь, что это помогло.

person Evgeny    schedule 21.07.2017
comment
Спасибо за ответ, @Evgeny, но на самом деле он не отвечает на вопрос. Я понимаю, как работают DDoS-атаки, и понимаю, что вы никогда не можете быть в безопасности. Я также знаю, что существуют такие варианты, как Cloudflare, но их эффективность резко ограничена для атак через веб-сокеты, потому что они не могут предложить приемлемые для пользователя стратегии смягчения, такие как CAPTCHA. Я специально спрашиваю о лучших практиках при создании сайта Django Channels с сервером Daphne ASGI. - person Jamie Counsell; 21.07.2017

arrow_upward
0
arrow_downward

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

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

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

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

Удачи с этим!

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

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

person MrE    schedule 23.07.2017
comment
Привет @MrE, конечно. Я полностью понимаю, что защита на уровне облака лучше, но я также спрашиваю о случайных проблемах с нагрузкой. Что-то вроде дросселирования, которое уменьшит количество воздействия на запрос, или что-то конкретное для каналов, которое может помочь, например, разрешение Дафни масштабировать один канал вниз, чтобы компенсировать другой канал. Проблема с веб-сокетами в том, что их сложно защитить. Я обновлю свой вопрос, чтобы он был более ясным. - person Jamie Counsell; 24.07.2017
comment
объем трафика в одном веб-сокете действительно зависит от вашего приложения, если вы ожидаете низкий трафик (например, канал чата), тогда да, дроссель - хорошее решение: приостановите или выгните любого, кто отправляет слишком много сообщений. Для других вещей, таких как данные IoT, у вас также должна быть ожидаемая скорость передачи данных. В целом троттлинг кажется хорошей идеей. - person MrE; 24.07.2017
comment
но лучший способ обрабатывать неизвестный трафик - это не обрабатывать ничего с помощью вашего сервера api websocket, а, скорее, напрямую отправлять сообщения в очередь сообщений (например, Kafka, RabbitMQ), которая затем может обрабатывать пики и отправлять сообщения в процесс, который на самом деле обрабатывать обработку. - person MrE; 24.07.2017
comment
... вот что делают каналы. Опять же, @MrE. Я действительно ищу здесь информацию от сообщества Django Channels. - person Jamie Counsell; 24.07.2017

arrow_upward
0
arrow_downward

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

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

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

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

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

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

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

Имейте способ аудита поведения ресурсов пользователей (сеть, память, ЦП), если вы видите, что определенные учетные записи используют необычные суммы, запретите их или наложите ограничение, что в конечном итоге приведет к политике отбрасывания их трафика брандмауэром.

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

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

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

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

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

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

Повеселись.

person The Unix Janitor    schedule 27.07.2017

arrow_upward
0
arrow_downward

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

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

  • Выполняется рукопожатие tcp (затронуты SYN_COOKIES)
  • Подтверждение ssl приходит позже (энтропия, процессор)
  • Устанавливается соединение с канальным уровнем ...

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

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

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

Простите за плохой английский.

person lasizoillo    schedule 08.08.2017
comment
капитан? капитан? - person Pang; 08.08.2017
comment
Привет, @lasizoillo, спасибо за ответ. Как я уже упоминал в других ответах, я действительно ищу информацию о том, что Дафна поддерживает для такого рода вещей. Способ обрабатывать большие очереди, изящно создавать больше рабочих для определенного канала или даже какое-то регулирование. Я понимаю, что настоящая защита от DDoS-атак осуществляется на гораздо более низком уровне, но я ищу информацию о поддержке уровня приложений Daphne и Django Channels (подумайте что-то вроде дросселирования DRF). - person Jamie Counsell; 08.08.2017