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

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

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

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

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

Наконец, то, что вы могли бы сделать действительно грубым, но в то же время действительно эффективным, похоже на то, что я написал ранее. По сути, это был небольшой инструмент, который отслеживает файлы журналов на предмет повторяющихся запросов с одного и того же IP-адреса. Допустим, 10 запросов к /Home в течение 2 секунд от 1.2.3.4. Если это было обнаружено, правило брандмауэра (в расширенном брандмауэре Windows, добавленное с помощью команд оболочки) будет добавлено для блокировки запросов с этого IP-адреса, а затем правило может быть удалено через 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 Server, чтобы увидеть преимущества асинхронных методов при высокой нагрузке».

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

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

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

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