Когда вы только что обнаружили, что ваш веб-сайт в настоящее время подвергается хакерской атаке, которая пытается проникнуть на ваш веб-сайт, я не включаю отказ в обслуживании в свой вопрос, что вы делаете? Есть ли рекомендации по передовой практике?
Я нашел много сообщений о том, что вы делаете после взлома, но что вы делаете, когда вас атакуют, не совсем понятно.
В первую очередь я говорю о сайтах IIS и ASP.net, но этот вопрос актуален для всех сайтов с выходом в Интернет.
Предположим, что сайт находится за брандмауэром, и все запросы и информация регистрируются.
Мои мысли:
Есть ли другие рекомендуемые действия или передовая практика?
Когда вы атакованы, вы не можете ничего сделать, кроме как попытаться заблокировать источники атаки, что обычно бесполезно, поскольку они являются движущейся целью. Такие атаки обычно проводятся с использованием скомпрометированных систем, количество которых составляет от нескольких тысяч до многих миллионов. Блокировать их - все равно что убивать мух летом: на место каждого, кого вы останавливаете, приходит множество других.
Жизнь слишком коротка, чтобы просматривать веб-журналы, если вы не ищете что-то конкретное. Однако вы можете попытаться заблокировать строки атаки в URL-адресах или ограничить доступ к таким вещам, как вход в систему или другим потенциально уязвимым страницам. Как только это будет сделано, лучше всего потратить время на то, чтобы подготовить надежную резервную копию и надеяться, что атака не удастся.
Один из моих сайтов подвергался атакам в течение последних 3-4 недель. Это простая попытка входа в систему с использованием распределенных систем. Сама атака с самого начала была обречена на провал, поскольку на моих сайтах нет учетной записи по умолчанию. Однако, чтобы немного снизить нагрузку на веб-сервер, любая попытка получить доступ к странице входа с IP-адреса, отличного от моего домашнего, теперь приводит к ошибке 404. Я не могу остановить атаку, но могу сделать ее неэффективной.
Прежде всего - возьмите большой лист бумаги и несколько ручек - записывайте все, что бросается в глаза, каждое ваше действие. Если возможно, запишите свой экран
-> Вы внесете много изменений, некоторые из которых нужно будет откатить. -> Вам нужно будет доказать, что вы не несете ответственности за сбои, возможно, позже будут рассмотрены судебные дела.
Во-вторых: не паникуйте - дважды подумайте, прежде чем предпринимать какие-либо действия - схватитесь за любого коллегу, который находится поблизости, и обсудите действия
В-третьих: собирайте любые данные, просматривайте их и переосмысливайте, прежде чем принимать меры. Попробуйте заблокировать IP, сеть, пользователя и т. Д.
Отключение сервера всегда является крайней мерой.
Если кажется, что атака усиливается, подумайте о том, чтобы вызвать внешнюю помощь (например, CERT вашего провайдера).
Последнее: когда атака закончится, проверьте все имеющиеся у вас данные, определите проблемы безопасности, которые привели к атаке, и ИХ ИСПОЛЬЗУЙТЕ !!!
tsg
В случае одного источника (или ограниченного числа источников) определите адреса источников и заблокируйте их на брандмауэре. В случае распределенной атаки обратитесь к вашему провайдеру. Перевод веб-сайта в автономный режим может быть временной мерой противодействия непосредственным угрозам до тех пор, пока уязвимость не будет устранена, но это, конечно, не постоянное решение.
В зависимости от типа атаки вы можете даже игнорировать ее в некоторых ситуациях, например когда ваше веб-приложение находится за брандмауэром веб-приложения (например, ModSecurity), который разрешает только заведомо исправный трафик. В случае запуска подбора пароля может быть эффективным ограничение скорости соединений для каждого адреса источника.