Предотвратить злонамеренные запросы - DOS-атаки
Я разрабатываю веб-приложение MVC asp.net, и у клиента есть запрос, чтобы мы постарались сделать его максимально устойчивым к атакам типа "отказ в обслуживании". Они обеспокоены тем, что сайт может получать вредоносные запросы большого объема с намерением замедлить / закрыть сайт.
Я обсуждал это с владельцем продукта, поскольку он действительно не отвечает требованиям реального веб-приложения. Я считаю, что ответственность за мониторинг трафика и реагирование на вредоносные запросы лежит на группе хостинга / сети.
Однако они непреклонны в том, что в приложение должны быть встроены некоторые меры предосторожности. Они не хотят внедрять CAPTCHA.
Было предложено ограничить количество запросов, которые могут быть сделаны для сеанса в течение определенного периода времени. Я думал о том, чтобы сделать что-то вроде этого Лучший способ реализовать регулирование запросов в ASP.NET MVC? Но использование идентификатора сеанса, а не IP-адреса клиента, поскольку это может вызвать проблемы у пользователей, приходящих из-за корпоративного брандмауэра, - все их IP-адреса будут одинаковыми.
Они также предложили добавить возможность отключения определенных областей сайта - предполагая, что пользователь-администратор может отключить области с интенсивным использованием базы данных... Однако это будет контролироваться через пользовательский интерфейс и, конечно, если он находится под атакой DOS, администратор пользователь не сможет добраться до него в любом случае.
У меня вопрос, стоит ли это делать? Конечно, настоящая атака DOS была бы намного более продвинутой?
Есть ли у вас другие предложения?
3 ответа
Атака "Отказ в обслуживании" может быть чем угодно, что может повлиять на стабильность вашего обслуживания для других людей. В этом случае вы говорите о DoS в сети, и, как уже говорилось, это обычно не происходит на уровне вашего приложения.
В идеале такого рода атаки должны быть смягчены на уровне сети. Для этого созданы специальные межсетевые экраны, такие как серия Cisco ASA 5500, которая работает от базовой защиты до снижения пропускной способности. Это довольно умные устройства, и я могу ручаться за их эффективность в блокировании атак такого типа, при условии, что используется правильная модель пропускной способности, которую вы получаете.
Конечно, если невозможно получить доступ к аппаратному брандмауэру, который делает это за вас, можно предпринять некоторые временные меры, чтобы помочь в защите от атак такого типа. Обратите внимание, что ни один из них не будет даже вдвое менее эффективным, чем выделенный брандмауэр.
Одним из таких примеров могут быть динамические ограничения IP модуля IIS, которые позволяют определить ограничение максимального числа одновременных запросов. Однако на практике это имеет недостаток, заключающийся в том, что он может начать блокировать законные запросы от браузеров с высокой пропускной способностью одновременных запросов на загрузку скриптов и изображений и т. Д.
Наконец, то, что вы могли бы сделать, это действительно грубо, но также очень эффективно, это то, что я написал ранее. По сути, это был небольшой инструмент, который отслеживает файлы журналов на наличие дублирующих запросов с одного и того же IP. Итак, скажем, 10 запросов /Home более 2 секунд с 1.2.3.4, Если это было обнаружено, то для блокировки запросов с этого IP-адреса будет добавлено правило брандмауэра (в Windows Advanced Firewall, добавленное с помощью команд оболочки), которое затем можно будет удалить примерно через 30 минут.
Как я уже сказал, это очень грубо, но если вам нужно сделать это на уровне сервера, у вас не так много разумных вариантов, потому что это не то, что нужно делать. Вы абсолютно правы в том, что ответственность в некоторой степени лежит на хостинг-провайдере.
Наконец, вы правы и в отношении CAPTCHA. Во всяком случае, это может помочь с DoS, выполняя генерацию изображений (которая может быть ресурсоемкой) снова и снова, тем самым истощая ваши ресурсы еще больше. Время, когда CAPTCHA будет эффективным, было бы, если бы ваш сайт был спамом от автоматических регистрационных ботов, но я уверен, что вы уже знали это.
Если вы действительно хотите что-то делать на уровне приложения, просто чтобы удовлетворить все имеющиеся возможности, реализация чего-либо в вашем приложении с использованием ограничений на основе IP-адресов является выполнимой, хотя и неэффективной на 90% (поскольку вам все равно придется обрабатывать запрос).
Вы можете реализовать это решение в облачных и масштабируемых серверах, если вам абсолютно необходимо быть в курсе, но это может дорого обойтись...
Другая идея заключается в регистрации IP-адресов зарегистрированных пользователей. В случае DOS ограничьте весь трафик запросами от "хороших" пользователей.
Предотвратить настоящую DoS-атаку на уровне приложения на самом деле невозможно, поскольку запросы, скорее всего, убьют ваш веб-сервер, прежде чем он убьет ваше приложение, из-за того, что ваше приложение связано с пулом приложений, который снова имеет максимум одновременных запросов определяется серверной технологией, которую вы используете.
В этой интересной статье http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45 говорится, что Windows 7, Windows Vista и Windows 8 имеют максимум 10 одновременных Запросы. Далее идет утверждение: "Вам понадобится серверная операционная система Windows, чтобы увидеть преимущества асинхронных методов при высокой нагрузке".
Вы можете увеличить предел очереди HTTP.sys для пула приложений, который связан с вашим приложением, чтобы увеличить количество запросов, которые будут поставлены в очередь (для более поздних вычислений, когда потоки будут готовы), что предотвратит стек протокола HTTP (HTTP).sys) от возврата ошибки Http 503, когда лимит превышен и рабочий процесс недоступен для обработки дальнейших запросов.
Вы упоминаете, что клиент требует, чтобы вы "постарались сделать все возможное, чтобы сделать его максимально устойчивым к атакам типа" отказ в обслуживании "". Мое предложение может быть неприменимым показателем в вашей ситуации, но вы могли бы рассмотреть реализацию асинхронного шаблона на основе задач (TAP), упомянутого в статье, чтобы удовлетворить требования клиентов.
Этот шаблон освобождает потоки во время выполнения длительных операций и делает потоки доступными для дальнейших запросов (таким образом, сохраняя вашу очередь HTTP.sys ниже), а также дает вашему приложению преимущество в увеличении общей производительности при множественных запросах к сторонним службам. или выполняется несколько интенсивных вычислений ввода-вывода.
Эта мера НЕ сделает ваше приложение устойчивым к DoS-атакам, но сделает приложение максимально ответственным за оборудование, на котором оно обслуживается.