Комментарии 30
Компания с 500+ компьютерами. Год-два назад запустил Wireshark, накачал 2гб траффика и начал искать интересное. По словам "administrator" нашел, что ИТ придумали такое: раз в 6-8 часов запускается visual-basic скрипт, который лезет на ftp, скачивает с него key-value файлик, где для каждой рабочей станции свой вполне сепьюрный пароль локального админа. Пошел ручками скачал файлик проверил что все ко всем подходит, отписал ребятам. После чего они перешли на LAPS. Вспомнилось вот :)
Мы создали учетную запись, которая имеет очень ограниченные полномочия в домене, но добавили ее в группу локальных администраторов рабочих станций и выключили локального админа вообще. Меняем пароль по расписанию и я пока не сталкивался с ситуацией, когда нам нужно было что-то дополнительно.
Локальная учетка администратора нужна если ПК по какой-либо причине не может связаться с контроллером домена. Во всех остальных случаях используются доменные учетные записи с правами администратора ПК. При вашем подходе, при смене пароля вам необходимо обойти все компьютеры в организации и войти с этой учеткой для того чтобы закэшировать новый пароль.
А кэширование учетных данных на рабочих станциях при этом включено или выключено? Если выключено, то у вас нет аварийного входа в случае, если нет связи с доменом. Если включено, то креативный пользователь mimikatz может натворить больших дел у вас в сети — см NotPetya.
Парни, философский вопрос назрел, не по теме администратора, но по паролям. Берем СЕО (CFO), короче шишку компании, которому по барабану все ИТ-политики и прочее и который вам говорит — мне не нужны эти 30,60,90- дневные пароли, хочет чтобы не истекало. Как бороться с такими «опасными» типами? Если для таких случаев решение по установке такого типа Идетификатора, который удовлетворил бы потребностям пользователя и условиям ИБ?
Авторизация по ключу?
SMART?
Вообще вопрос скорее организационный, чем технический. Бороться беседами с предоставлением примерного варианта развития событий при компрометации пароля. Просто есть вероятность, что такой человек и к токенам-смарткартам будет относиться так же несерьёзно, так что в любом случае ликбез не помешает.
ДФА. Например сделать вход по ОТП-токену или SMART карте.
Windows Hello for Business вам в помощь.
и который вам говорит — мне не нужны эти 30,60,90- дневные пароли, хочет чтобы не истекало. Как бороться с такими «опасными» типами?
«Опасным» является тот, кто эту политику завел и считает, что увеличивает безопасность.
На самом деле — частая смена паролей приводит к тому, что их невозможно запомнить.
А уже поэтому пароли начинают записывать и держать под рукой, вплоть до бумажки с паролем на мониторе.
Подскажите, после внедрения LAPS мониторили ли вы трафик на предмет извлечения от туда паролей в момент смены?
Какая-то «буханка-троллейбус.jpg»
Зачем ставить какого-то агента, если есть ADSI провайдер WinNT.
Пример урезан, оставлено только самое необходимое.
То же самое пишется на любом удобном вам языке, на том же PowerShell.
Пароли генерируем и храним любым удобным (а главное безопасным) способом, например так в статье — в атрибуте объекта AD (это уже через провайдера LDAP).
Естественно, у учетки из под которой запущен скрипт, должно хватать прав, на изменение пароля.
Через провайдера WinNT также можно переименовать локального админа, например, чтобы на всех машинах он звался одинаково, можно проверить, нет ли в группе локальных администраторов «левых» учеток (не всегда и не у всех ИБ на должном уровне).
Помимо смены «протухших» паролей, необходимо регулярно проверять, не был ли пароль изменён (подходит ли сохранённый).
Зачем ставить какого-то агента, если есть ADSI провайдер WinNT.
# python 3.6
import struct
import win32com.client
def set_password(computername, password):
# подключаемся к компьютеру
computer = win32com.client.GetObject(f"WinNT://{computername}")
# перебираем все его объекты (пользователи, группы)
for obj in computer:
# игнорируем всё, кроме пользователей
if obj.Class != "User":
continue
# вычисляем админа по SID
sid = bytes(obj.objectSid)
if struct.unpack("i", sid[-4:])[0] == 500:
admin = obj
break
else:
raise WindowsError(
f"На компьютере {computername}"
f" не найдена учетная запись администратора!"
)
# DONT_EXPIRE_PASSWD + NORMAL_ACCOUNT + PASSWD_CANT_CHANGE
admin.userflags = 66112
# устанавливаем пароль
admin.SetPassword(password)
# сохраняем все изменения
admin.SetInfo()
if __name__ == "__main__":
set_password("QWERTY-123", "40_Thousand_Monkeys")
Пример урезан, оставлено только самое необходимое.
То же самое пишется на любом удобном вам языке, на том же PowerShell.
Пароли генерируем и храним любым удобным (а главное безопасным) способом, например так в статье — в атрибуте объекта AD (это уже через провайдера LDAP).
Естественно, у учетки из под которой запущен скрипт, должно хватать прав, на изменение пароля.
Через провайдера WinNT также можно переименовать локального админа, например, чтобы на всех машинах он звался одинаково, можно проверить, нет ли в группе локальных администраторов «левых» учеток (не всегда и не у всех ИБ на должном уровне).
Помимо смены «протухших» паролей, необходимо регулярно проверять, не был ли пароль изменён (подходит ли сохранённый).
Только не забудьте защитить атрибут объекта, в котором пароль будете хранить, а то обычные поля компьютерных объектов по умолчанию весь домен может читать. А после этого сделать какой-то тул для просмотра этого атрибута, потому что в ADUC его видно не будет.
А еще что-то придумать для клиентов, которые не постоянно онлайн, чтобы не пропускали время запуска скрипта.
А также не забудьте открыть везде порты, чтобы COM-RPC работал с сервера, на котором скрипт запускается, к клиентам — а то по умолчанию, например, клиенты общаются с контроллером домена только в режиме pull.
Ну и как следует защитить учетную запись, от которой запускается скрипт — прав у нее в сети будет немало.
Или можно вместо всей этой головной боли использовать LAPS, официальное и поддерживаемое (бесплатное) решение от Microsoft.
А еще что-то придумать для клиентов, которые не постоянно онлайн, чтобы не пропускали время запуска скрипта.
А также не забудьте открыть везде порты, чтобы COM-RPC работал с сервера, на котором скрипт запускается, к клиентам — а то по умолчанию, например, клиенты общаются с контроллером домена только в режиме pull.
Ну и как следует защитить учетную запись, от которой запускается скрипт — прав у нее в сети будет немало.
Или можно вместо всей этой головной боли использовать LAPS, официальное и поддерживаемое (бесплатное) решение от Microsoft.
Не нужно так делать.
1. Про права на чтение сказали ниже.
2. А rename отлично делается через GPP/GPO.
1. Про права на чтение сказали ниже.
2. А rename отлично делается через GPP/GPO.
Недавно вышла ещё одна бесплатная штука для гранулярной настройки политики паролей с чёрными списками и инструкцией в трёх частях: Lithnet Password Protection
Опасные вы вещи говорите — все ведь ровно наоборот.
Именно потому что привилегии локального админа сравнительно легко достижимы, они должны быть изолированы в пределах одной рабочей станции. Иначе повысившись на одной станции можно по всей сети расползтись — что наглядно всем желающим и продемонстрировал NotPetya еще полтора года назад.
Именно потому что привилегии локального админа сравнительно легко достижимы, они должны быть изолированы в пределах одной рабочей станции. Иначе повысившись на одной станции можно по всей сети расползтись — что наглядно всем желающим и продемонстрировал NotPetya еще полтора года назад.
NotPetya помимо эксплойта EternalBlue использовал mimikatz чтобы вытащить из памяти lsass lm-хэши локальных администраторов, и дальше пробовал с ними ходить по сети. Например, вот здесь есть об этом.
А чем плох встроенный администратор? Тривиально ведь найти на машине всех остальных. Разве что UAC у него выключен по умолчанию. Так ведь включить можно, да и вообще согласно Microsoft «UAC is not a security feature».
А чем плох встроенный администратор? Тривиально ведь найти на машине всех остальных. Разве что UAC у него выключен по умолчанию. Так ведь включить можно, да и вообще согласно Microsoft «UAC is not a security feature».
Под доменным админом на рабочие станции пользователей? За такое руки надо отрубать (и не только тем, кто ходит, но и тем, кто это допустил). И какая вообще зависимость между LAPS и тем, что люди используют доменного админа где попало?
И вы хотите сказать, что пароли не меняете?
И вы хотите сказать, что пароли не меняете?
Не, я не из идеального мира, но из мира людей, применяющих политики назначения прав пользователей, чтобы доменные админы не заходили случайно куда не следует.
Первую часть не понял. Петя собирает все что есть в lsass, а дальше если у вас из этого списка кто-то вхож на другие рабочие станции как админ, то Петя приезжает и на них тоже.
Хорошая, старая штука. Конечно, вызывает некоторые неудобства, но как и вся безопасность тут либо удобнее, либо безопаснее. На вскидку вспомню несколько кейсов.
1. Например, удаление УЗ подменного компьютера из АД, когда подменный компьютер долго не находится в сети. Т.е. стоит в принципе забыть об удалении УЗ компьютеров, только блокировка.
2. После внедрения пришлось подтюнить MDT, чтобы он использовал staging OU, иначе деплой фейлился после очередного обновления GP.
3. Стоит внимательнее относится к политикам паролей, т.е. настроив для LAPS пароли вида «SDFAHO23DFJSSDFK6» необходимо убедиться в том, что локальная политика безопасности даст использовать такие «простые» пароли.
Да в принципе это и не проблемы, просто нюансы, которые сразу вспомнились.
1. Например, удаление УЗ подменного компьютера из АД, когда подменный компьютер долго не находится в сети. Т.е. стоит в принципе забыть об удалении УЗ компьютеров, только блокировка.
2. После внедрения пришлось подтюнить MDT, чтобы он использовал staging OU, иначе деплой фейлился после очередного обновления GP.
3. Стоит внимательнее относится к политикам паролей, т.е. настроив для LAPS пароли вида «SDFAHO23DFJSSDFK6» необходимо убедиться в том, что локальная политика безопасности даст использовать такие «простые» пароли.
Да в принципе это и не проблемы, просто нюансы, которые сразу вспомнились.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управляем паролем локального администратора с помощью LAPS