Комментарии 28
Всё-таки у Windows-админа должен быть в инструментах шаманский бубен.
В своё время обнаружил внимательно читая доки по внеднению PCIDSS. Чтобы соответствовать, этот параметр должен быть включён политикой
Когда на синем экране написано большими белыми буквами "STOP: C0000244 {Audit Failed}" сложно не догадаться, что произошло.
Заодно можно открыть для себя, что у Windows есть политика безопасности, один из параметров которой отвечает за описанное вами поведение
https://technet.microsoft.com/en-us/library/cc963220.aspx
Тогда и гуглить ключи реестра не придется.
https://technet.microsoft.com/en-us/library/cc963220.aspx
Тогда и гуглить ключи реестра не придется.
Напомнило, как однажды долго искал ключ реестра, который отвечает за сохранение атрибутов ACL файлов при копировании в сетевую папку через Проводник.
«А в новом безопасники решили выставить его в «1».» То есть либо безопасники решили, что так секурнее, не понимая, что именно делает ключ реестра, либо правая рука не знает, что делает левая.
Издержки производства. Безопасники, действительно, решили что так секьюрнее, а я не соотнёс пришедший в стек инцидент со списком из пары сотен изменений безопасности.
Но, так как проблема была решена, то, я думаю, нас можно простить:)
Но, так как проблема была решена, то, я думаю, нас можно простить:)
«А в новом безопасники решили выставить его в «1».
Выглядит как "раздали права админа всем направо и налево".
В нормальной структуре — хоть ты СЕО, СIO и черт на куличках — права администрирования только у авторизованных администраторов.
Не вижу особых проблем выдать группе СБ права на чтение логов аудита — либо вижу еще вариант "админов" которые не могут нормально настроить политики доступа/групповые политики.
А я и не говорю, что я увидел что-то хорошее. Интересное — да, хорошее — нет.
Я видимо очень косноязычен. Никаких прав админа у них нет. Я имел ввиду, что они решили выставить этот ключ в "1", в ходе подготовки нового серверного билда. Т.е. все наши 2012 R2 сервера были настроенны именно так. Просто на 2003 и 2008 раньше настройка была иная.
И я, как часть серверной команды, коненчо же получил документ с перечнем всех изменений и настроек нового билда. К сожалению, я не смог сразу же прикинуть все возможные осоложнения и, получив этот инцидент, вспомнить что в новом билде как раз менялся один ключик реестра, который мог такое поведение вызвать:)
И я, как часть серверной команды, коненчо же получил документ с перечнем всех изменений и настроек нового билда. К сожалению, я не смог сразу же прикинуть все возможные осоложнения и, получив этот инцидент, вспомнить что в новом билде как раз менялся один ключик реестра, который мог такое поведение вызвать:)
Простите, но каким боком безопасники относятся к построению "серверных билдов"?
Не, мне реально интересно.
Не, мне реально интересно.
Ммм. В операционной системе есть довольно большое колличество разнообразных настроек. В частности — настройки безопасности. В процессе создания нового серверного билда, команда занимающаясь Image Management совместно с заинтересованными сторонами определяет и документирует значение всех этих настроек. По моему, всё логично.
Я не пытался обидеть какую-то из команд. Понятно, что чем больше инфраструктура, тем сложнее в ней все процессы и это привносит свои издержки. Команда безопасников, вполне себе, разбирается в операционных системах. Их пожелание по этой настройке было обоснованным.
Я не пытался обидеть какую-то из команд. Понятно, что чем больше инфраструктура, тем сложнее в ней все процессы и это привносит свои издержки. Команда безопасников, вполне себе, разбирается в операционных системах. Их пожелание по этой настройке было обоснованным.
Отсюда мораль — если сервер упал в синий экран, посмотрите логи. Там чистым языком локализации написано о причине падения. Тогда и ковыряться несколько часов не пришлось бы. Для меня просто поразительно, насколько часто люди начинают чесать репу и вопрошать гугл в ситуации, когда достаточно просто заглянуть в лог.
Да я виноват, что увидев в логах инцидента, что сервер несколько дней назад падал в BSOD не полез смотреть crash dump. Но кто из нас без греха? А вот об этом ключе реестра я до этого инцидента не знал.
Кстати, я не уверен, что прочитав в логах что сервер упал изза переполнения Security Log, и убедившись, что сейчас в логе есть место, я бы решил, что проблемы с общим доступом связаны именно с тем падением. Когда ответ уже известен, всегда понятно, где можно было увидеть подсказки. А вот когда я был в процессе решения проблемы, всё было не так очевидно:)
Кстати, я не уверен, что прочитав в логах что сервер упал изза переполнения Security Log, и убедившись, что сейчас в логе есть место, я бы решил, что проблемы с общим доступом связаны именно с тем падением. Когда ответ уже известен, всегда понятно, где можно было увидеть подсказки. А вот когда я был в процессе решения проблемы, всё было не так очевидно:)
Ну с одной стороны задним умом все крепки, тут не поспоришь. :) С другой — всё-таки хороший пример того, почему надо сразу досконально выяснять обстоятельства возникновения проблемы, а не искать решения по поверхностным симптомам.
И хорошо бы заодно это стало уроком вашим безопасникам — они часто радостно хлопают в ладоши, обнаружив настройки вида "остановить сервер при переполнении лога" или "заблокировать учетку через N попыток входа", не отдавая себе отчета, что лобовое применение таких ограничений создает отличные возможности для атак, начисто парализующих инфраструктуру.
И хорошо бы заодно это стало уроком вашим безопасникам — они часто радостно хлопают в ладоши, обнаружив настройки вида "остановить сервер при переполнении лога" или "заблокировать учетку через N попыток входа", не отдавая себе отчета, что лобовое применение таких ограничений создает отличные возможности для атак, начисто парализующих инфраструктуру.
Это на самом деле спорный вопрос — кому там должен быть урок. Дело в том, что лог безопасности не должен переполняться. иначе это также открывает возможности для атак — переполнил лог, а потом вершишь тёмные дела. BSOD был вызван как раз тем, что был нарушен механизм очищения лога. Там использовался софт, который события из лога забирал и чистил.
Вся проблема возникла изза того, что в связи с появлением этой новой настройки мы не произвели одного важного действия, подняв сервер и почистив логи — не пеервели ключ реестра из этого заблокированного состояния обратно в режим ожидания ошибки.
Настройка то на самом деле не бесполезная.
Вся проблема возникла изза того, что в связи с появлением этой новой настройки мы не произвели одного важного действия, подняв сервер и почистив логи — не пеервели ключ реестра из этого заблокированного состояния обратно в режим ожидания ошибки.
Настройка то на самом деле не бесполезная.
Степень полезности/вредности настроек в первую очередь зависит от того, насколько продуманно они делаются. Вот кто-то что-то настроил и сидит такой радуется, как у него всё безопасно и соответствует параграфу Х инструкции Y. А потом злобный хакер запускает в сети скриптик, циклически логинящийся с произвольными неверными учетными данными на ваши сервера, в секунды переполняет логи и нагло ржёт, глядя на то, как несколькими нажатиями клавиш он парализовал всю работу. :)
Вот что значит "лог не должен переполняться"? Если у вас отключена ротация, он обязательно переполнится, это только вопрос времени. Значит, за ним надо следить. В итоге настройка этого параметра автоматически требует дополнительного мониторинга событий в логе безопасности и объема этого лога, с соответствующими алертами и специально выделенными людьми, которые на эти алерты обучены быстро и адекватно реагировать. Мне не доводилось работать в местах, где это было бы реально оправданно, и не хватало бы включенной ротации логов с форвардингом событий на другой сервер и их обработкой. Хотя верю, что такие места существуют.
Вот что значит "лог не должен переполняться"? Если у вас отключена ротация, он обязательно переполнится, это только вопрос времени. Значит, за ним надо следить. В итоге настройка этого параметра автоматически требует дополнительного мониторинга событий в логе безопасности и объема этого лога, с соответствующими алертами и специально выделенными людьми, которые на эти алерты обучены быстро и адекватно реагировать. Мне не доводилось работать в местах, где это было бы реально оправданно, и не хватало бы включенной ротации логов с форвардингом событий на другой сервер и их обработкой. Хотя верю, что такие места существуют.
А подскажите пожалуйста путь к этим логам.
Если четсно я сам до сих пор поражаюсь этому феномену. Я даже не забиваю голову кодами ошибок. Случился fail, открыл дамп, посмотрел код, открыл гугл и все. Чего в этом зазорного? У меня есть знакомый он за каждой ошибкой звонит мне и я его каждый раз отправляю в гугл. Вы знаете, но до него за эти 3 года так и не дошло что надо сначала открыть гугл, а потом если не нашел ответа, то позвонить. А я у него вроде как ярлыка для google.com… Так и тут, искал не знаю что не знаю где, а ларчик был открыт всю дорогу. Тем более искать причину BSOD не видя самого BSOD…
Я не искал причину BSOD. BSOD был предыдущим инцидентом, закрытым два дня назад. Инженер который его смотрел, как позже выяснилось проверил причину, почистил лог безопасности, проверил, что сервер нормально поднялся (ну он же админ, так что для него принтера заработали) и закрыл инцидент. Это была штатная процедура обработки таких инцидентов для наших предыдущих серверных билдов (2003 и 2008).
Я искал почему один пользователь у которого effective permissions позволяют получить доступ к общему принтеру этот доступ имеет, а другой нет. Иногда если начать изучение проблемы с неправильного вопроса, можно пойти к ответу очень окольным путём. Что и иллюстрирует данная история.
Я искал почему один пользователь у которого effective permissions позволяют получить доступ к общему принтеру этот доступ имеет, а другой нет. Иногда если начать изучение проблемы с неправильного вопроса, можно пойти к ответу очень окольным путём. Что и иллюстрирует данная история.
Вот тут и кроется Ваша проблема. Ведь пускать переставало именно после BSOD. Значит что-то перед ним случилось такое что увалило систему и что сейчас не пускает. Я понимаю если бы был 1 раз BSOD. Еще можно было бы как-то. Но у Вас подряд 2 BSOD и после ребута система не пускает. Я бы сразу задумался. А еще Вашему админу надо по шапке надавать. С какого такого великого разгона он чистит логи после BSOD?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблема с доступом и интересный ключ реестра Windows