В этом коротком посте я буду говорить, возможно, об очевидных вещах, но весьма важных.
Административная учетная запись зачастую может обладать разрушительными правами для ИС, и, как следствие, пользоваться ею следует аккуратно. Она не должна использоваться для серфинга по Интернет, а доступ к ее профилю должен быть строжайшим образом ограничен.
Как обычно, чтобы как сделать все хорошо и безопасно, необходимо понять чего мы боимся, т.е. описать риски.
Проблема №1: Запуск вредоносного кода с административными правами.
Пример атаки: посещая сайты Интернет (или используя любого другого клиента, например – почтового), посредством zero-day уязвимости клиента Интернет запускается вредоносный код. Поскольку учетная запись жертвы в нашем случае обладает административными правами, практически на любое действие вредоносного кода не будет получен отказ ввиду нехватки полномочий.
Путь минимизации риска: очевидно, административными правами необходимо пользоваться только в тех случаях, где без этого не обойтись, откуда следует, что администраторам следует иметь минимум две учетные записи: одна – для повседневной жизни: посещение сайтов Интернет, прием электронной почты, работа с различными IM, пр.
Проблема №2: Компрометация профиля административной учетной записи. Посещая различные серверы по долгу службы системны администратор на каждом из посещаемых серверов оставляет свой профиль, который может быть доступен в случае получения административного доступа на сервер, например, в случае его компрометации злоумышленником.
Пример атаки: Злоумышленник компрометирует компьютер, который когда-либо обслуживался администратором и, следовательно, оставил на файловой системе сервера свой профиль. Далее злоумышленник создает скрипт, в который помещает всю свою вредоносную деятельность. Ссылка на скрипт помещается в systemdrive\Documents and Settings\username\Start Menu\Programs\Startup (systemdrive \Documents and Settings\ username \Главное меню\Программы\Автозагрузка), username – имя административной учетной записи.
Что происходит: администратор заходит на сервер для выполнения своих должностных инструкций, срабатывает скрипт с его полномочиями.
Путь минимизации риска: использовать перемещаемые профили.
Полезные ссылки:
Windows XP Professional Resource Kit
How to Modify the List of Programs that Run When You Start Windows XP
6 comments:
The Administrator Accounts Security Planning Guide
http://go.microsoft.com/fwlink/?LinkId=41315
Перемещаемые профили не панацея, так как нарушитель может вставить запуск нужных программ ВСЕМ ПОЛЬЗОВАТЕЛЯМ компьютера.
Потом, даже если администратор входил на компьютер в прошлом, на нем остаются следы в виде:
а) адрес откуда входил администратор (время хранения ограничено)
б) кешированные пароли, которые можно попытаться расшифровать (время хранения ограничено)
в) история и ссылки на документы\инетернет-адреса и тп, которые интересовали администратора (время хранения не ограничено)
Я к чему клоню. Зона действия конкретной административной записи должна быть четко определена, причем чем выше права администратора в КИС, тем четче должна быть дисциплина и контроль.
В современных ОС общего пользования не контролируюя и не ограничивая административную запись оргмероприятиями ничего не сделать. Само существование записи уровня "всемогущий" - риск.
Значит ли это, что если скомпрометирован _любой_ сервер, на который иногда заходит доменный администратор, то аккаунт доменного администратора можно считать скомпрометированным? И никакие roaming profiles от этого не спасут?
Amiran Alavidze said: Значит ли это, что если скомпрометирован _любой_ сервер, на который иногда заходит доменный администратор, то аккаунт доменного администратора можно считать скомпрометированным?
Не, не значит, можно отключить использование startup вообще используя утилиту msconfig. Почитать, например, можно здесь:
How to configure Windows XP to start in a "clean boot" state
Ребята, нельзя доверять серверу, на котором с административными правами побывал кто-то. Можете обозвать меня параноиком.
То, о чем вспомнил Сергей, лишь полумера которая не остановит человека, желающего получить реквизиты вышестоящего администратора.
1. Не сказали что делать с кешем пароля.
2. А как быть с такой засадой: http://www.codeproject.com/useritems/GINA_SPY.asp .
Нештатные вещи, которыми нельзя управлять удобно и централизованно - не предлагать, т.к. мы все, прежде всего, лентяи.
Отсюда, нельзя чтобы на одном сервере пересекались зоны ответственности администраторов различных уровней.
Igor saidТо, о чем вспомнил Сергей, лишь полумера....
По большому счету любая мера безопасности - полумера. На самом деле - это заезженная мысль и уже куча писателей (экспертов по ИБ) сделали на ней кучу денег. Да, это так, поскольку, как правило, любая контрмера, как нам известно из IRM, не устраняет риск полностью, а пытается его как-то снизить. Эту замудренную фразу стоит понимать так, что надо сделать хоть что-то, желательно - все возможное, чем не делать ничего.
Так и в жизни, несмотря на то, что мы все умрем и в итоге нам всем будет все все равно и нет ответа на вопрос: "Зачем мне все это?", мы, тем не менее что-то пытаемся сделать, карабкаемся по отвесной и скользкой скале жизни.
Post a Comment