Windows cached logons

[leo_sosnine]

По-умолчанию практически любая винда (от NT4 до 2008) кэширует 10 последних логонов/паролей.

Несмотря на зашкаливающую в других аспектах паранойю по безопасности, в этом случае Майкрософт угождает пользователям: если домен недоступен, то юзер тем не менее может залогониться, если этот юзер за этой машиной хотя бы раз логонился, и после этого события логонилось не более 9 других юзеров, то система юзера впустит.

Хэши логон неймов/паролей хранятся в файлике %windir%\system32\config\security, который подгружается, ктстаи, как ветка реестра, но доступен только для NT Authority\SYSTEM, он же COMPUTERNAME$.

И, соответственно, обладая правами локального админа на этой машинке, эти хэши нетрудно слить, а дома, в спокойной обстановке, подобрать их на видюхе, ну или зааутсорсить подбор.

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

Таким образом, задача получения шпиёном пароля доменного админа сводится к следующему нехитрому алгоритму:

1) Устроиться на работу к конкуренту, получить в управление комп;
2) Пароль доменного админа в кэше наверняка уже есть, но если нужно обеспечить его гарантированное наличие, то всё что нужно это создать ситуацию, которая потребует от админа залогониться за выданным компом;
3) Сбросить пароль локального админа, загрузиться под ним (для этого потребуется загрузиться с сидюка или флэшки);
4) Утянуть MSCache соотв. утилитками;
5) Дома спокойно подобрать админский пароль.

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

Теперь как с этим бороться.

1) Создаём отдельную группу с учётками, для которых требуются административные права на локальных машинах. Как правило это служба хэлпдеска. Через рестриктед гроупс заносим только что созданную группу в локальные администраторы и подписываем у шефа служебку, обязующую всех сотрудников службы ИТ ходить по локальным машинам только по учёткам из этой группы, которые не имеют админских прав на домен. По-крайней мере, так мы спасём доменного админа.

2) Групповыми политиками ограничиваем количество кэшируемых логонов на машинках домена единичкой. Это приведёт к тому, что после логона на локальной машине админа для выполнения административных задач, залогонится юзер и его кэш затрёт админский кэш, поэтому максимум, что юзер сможет унести, так это свой собственный кэш, хехе. Тут важно соблюдать процедуру -- всегда после административной работы заставлять юзера залогониться.

Ну и полные параноики могут вообще установить количество кэшируемых логонов в 0.

Comments

[mayevski.livejournal.com]

Так тогда выходит, что кеш нужно отключать в любом случае: для офисных компьютеров упадение сети или DC - авральная ситуация, а для ноутов он архивреден с т.з. безопасности. И вопрос "как тренировать админов, чтобы использовать кеш и при этом чтобы было безопасно" стоять не будет.

[leo-sosnine.livejournal.com]

Это с т.з. безопасности -- да. Но безопасность на втором месте после эффективности бизнес-процесса. Т.е. нельзя из соображений безопасности доводить ситуацию, когда людям работать становится сложно и производительность падает.

Что делать с ноутбучниками, которые частично работают в офисе, частично дома (через ВПН), частично вообще в оффлайнах? Для них нужен кэш.

[mayevski.livejournal.com]

Ну это кто с какой колокольни смотрит на вопрос :). Что делать с ноутбучниками я не совсем знаю, поскольку мне очевидно, что локальные credentials должны не только "физически" отличаться (т.е. не кеши, а отдельный логин), но и не совпадать по сути (имя пользователя и пароль должны быть различны у локального и доменного логинов). Но, да, это усложняет администрирование.