Рекомендации по обнаружению DOS-атак (отказ в обслуживании)?[закрыто]

Question

Я ищу лучшие практики для обнаружения и предотвращения DOS в реализации сервиса (не внешнего сетевого мониторинга).Служба обрабатывает запросы на получение информации о пользователях, группах и атрибутах.

Какой ваш любимый источник информации о работе с DOS?

Answer 1

Этот метод я нашел очень полезным..

Предотвращение атак типа "отказ в обслуживании" (DOS) в вашем веб-приложении

Answer 2

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

Если вы используете Linux, то вам следует прочитать эту статью:
Сценарий оболочки для предотвращения DoS-атак на основе правил (из Linux Gazette) В нем есть следующие разделы:

• Как обнаружить DoS-атаки из /var/log/ защищенного файла
• Как уменьшить количество обнаруженных избыточных IP-адресов из временного файла
• Как активировать /sbin/iptables
• Как установить предлагаемый shell-скрипт

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

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

Новичок в Linux?прочтите Дорожная карта перехода с Windows на Linux:Часть 5.Ведение журнала в Linux из IBM.

Удачи вам!

Answer 3

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

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

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

FWIW, временной интервал составлял 30 секунд, а максимальное количество звонков - 100.Это не совсем удовлетворительный подход, но он прост и практичен и был одобрен командой корпоративной безопасности (еще одно политическое соображение).