Предотвращение вредоносных запросов - атаки DOS

Я разрабатываю веб-приложение asp.net MVC, и у клиента есть запрос, что мы стараемся сделать его максимально возможным для атак типа "отказ в обслуживании". Они обеспокоены тем, что сайт может получать злонамеренные запросы большого объема с намерением замедлить/удалить сайт.

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

Однако они непреклонны в том, что приложение должно содержать некоторые меры предосторожности. Однако они не хотят реализовывать CAPTCHA.

Было высказано предположение, что мы ограничиваем количество запросов, которые могут быть сделаны для сеанса в течение заданного периода времени. Я думал сделать что-то подобное Лучший способ реализовать настройку запроса в ASP.NET MVC? Но с использованием идентификатора сеанса не является IP-адрес клиента, так как это вызовет проблемы для пользователей, исходящих из-за корпоративного брандмауэра - их IP будет одинаковым.

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

Мой вопрос в том, стоит ли это делать? Неужели реальная атака DOS будет намного более продвинутой?

Есть ли у вас другие предложения?

Ответ 1

Атака "Отказ в обслуживании" может быть практически любой, что повлияет на стабильность вашего сервиса для других людей. В этом случае вы говорите о сетевой DoS и, как уже говорилось, обычно этого не будет на уровне вашего приложения.

В идеале такая атака будет смягчена на сетевом уровне. Для этого созданы специальные межсетевые экраны, такие как серия Cisco ASA 5500, которая работает от базовой защиты до высокой пропускной способности. Они довольно умные коробки, и я могу ручаться за их эффективность в блокировании этих типов атак, пока используется правильная модель для пропускной способности, которую вы получаете.

Конечно, если вам не удастся получить доступ к аппаратным брандмауэрам, который делает это за вас, есть несколько остановочных мер, которые вы можете применить для защиты от этих типов атак. Обратите внимание: ни одна из них не будет даже вдвое эффективнее, чем выделенный брандмауэр.

Одним из таких примеров может быть модуль IIS Dynamic IP Restrictions, который позволяет определить предел максимальных одновременных запросов. Однако на практике это имеет недостаток в том, что он может начать блокировать законные запросы от браузеров, которые имеют высокую пропускную способность параллельного запроса для загрузки скриптов и изображений и т.д.

Наконец, что-то, что вы могли бы сделать, действительно грубо, но также очень эффективно, похоже на то, что я написал ранее. В принципе, это был небольшой инструмент, который контролирует файлы журналов для дублирования запросов с одного и того же IP-адреса. Итак, скажем, 10 запросов /Home в течение 2 секунд от 1.2.3.4. Если это было обнаружено, правило брандмауэра (в Windows Advanced Firewall, добавленное с помощью команд оболочки) будет добавлено для блокировки запросов с этого IP-адреса, затем это правило можно будет удалить через 30 минут или около того.

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

Наконец, вы тоже правы в CAPTCHA. Во всяком случае, это может помочь с DoS, повторяя процесс генерации изображения (который может быть ресурсоемким) снова, таким образом, голодающие ваши ресурсы еще больше. Время, в течение которого CAPTCHA было бы эффективным, было бы, если бы ваш сайт должен был быть спамом автоматическими регистрационными ботами, но я уверен, что вы уже это знали.

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

Ответ 2

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

Еще одна идея - записать IP-адреса зарегистрированных пользователей. В случае, если DOS ограничивает весь трафик запросами от "хороших" пользователей.

Ответ 3

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

Эта интересная статья http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45 что Windows 7, Windows Vista и Windows 8 имеют не более 10 одновременных запросов. Далее идет утверждение, что "вам понадобится операционная система Windows Server, чтобы увидеть преимущества асинхронных методов при высокой нагрузке".

Вы можете увеличить ограничение очереди HTTP.sys пула приложений, связанного с вашим приложением, чтобы увеличить количество запросов, которые будут поставлены в очередь (для последующего вычисления, когда потоки будут готовы), что предотвратит HTTP-протокол Стек (HTTP.sys) от возврата Http-ошибки 503, когда предел превышен, и никакой рабочий процесс недоступен для обработки дальнейших запросов.

Вы упомянули, что клиент требует, чтобы вы попробовали [ваш], чтобы сделать его максимально устойчивым к атак типа "отказ в обслуживании" ". Мое предложение не может быть применимой мерой в вашей ситуации, но вы могли бы изучить реализацию Асинхронного шаблона на основе задач (TAP), упомянутого в статье, чтобы удовлетворить требования клиентов.

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

Эта мера НЕ сделает ваше приложение устойчивым к DoS-атакам, но это сделает ваше приложение как можно более ответственным на аппаратном обеспечении, на котором оно обслуживается.