Как мы в RUVDS спасаем наших пользователей от брутфорса
В одной из статей я рассказывал о том, как скрипт кидди мешает жить нашим клиентам. В этой статье я хотел бы рассказать, про решения: как мы будем пытаться с этим бороться (если не прогорит).
Пока что без целиковых исходников, они будут в следующих статьях. Ну а пока, обо всем, что около.
Стандартные «решения»
Рассылать жалобы
Очень распространенный подход. При обнаружении вторжения в свою ИС занести атакующего в фаерволл (или не занести) и отправить автоматическую жалобу по почте, которую нашли во whois.
Мы получаем жалобы на наших клиентов от системы обнаружения вторжений разных банков, офисов, сайтов. Даже, вроде как, крупные организации просто накатывают fail2ban и на этом все.
Работать это все будет через раз, что, если атакующего не забанят? Да и неправильно это, давать возможность постучаться к себе в дверь, что, если кто-то установит пароль уровня solarwinds123 и его взломают с первой попытки?
Заставлять пользователей «делать правильно».
Можно сделать свою службу, почти малварь, как это сделали Godaddy, добавить еще одного пользователя под логином nydys и забыть отключить адимнистратора cloud-init, как это сделали Godaddy, установить в систему 8 лишних сертификатов, как это сделали Godaddy.
Еще можно блокировать AD и другие «небезопасные порты», как это делали некоторые другие хостинги и вот это вот все.
Читать дальше →
Источник: Хабрахабр
Похожие новости
- Быстрый старт в маскировании данных PostgreSQL с инструментом pg_anon
- [Перевод] Свой среди чужих: насколько токсична рабочая среда безопасника?
- [Перевод] Обход двухфакторной аутентификации в публичной баг-баунти программе: путь к $6000
- Кратко про XHTTP для VLESS: что, зачем и как
- [Перевод] Как я нашёл уязвимость в ядре Linux при помощи модели o3
- SelfCoerce для локального повышения привилегий на Windows 10
- Теория мертвого 2GIS
- Постквантовые криптостандарты США на алгоритмы электронной подписи на основе хеш-функций с сохранением состояния
- Новые возможности менеджера секретов Deckhouse Stronghold: пространства имён, резервные копии и репликация данных
- [Перевод] Single Sign-On c OpenAM и OpenIG: практические примеры реализации