Комментарии 23
Важно понимать что настраивать политики аудита можно только на английском интерфейсе, ибо Read permission в русском языке называется "право на чтение", а должно "Чтение разрешений" или "Чтение прав". Неделю убил в свое время
Кстати, в различных версиях Windows политики еще и переведены по-разному.
Вот поэтому я благодарен людям которые 15 лет назад сказали мне что нужно использовать только английскую винду, тогда её купить в РФ было проблемой. Учите всю молодёжь что видите использовать любой профессиональный софт а английской локализации.
Тут аудит тоже не настроен. Раз так, то по идее никаких событий безопасности в журналах быть не должноТермин «Не настроен» относится не к самому аудиту, а к политике. Если политикой не задано конкретное значение, то действует значение по умолчанию. Это важно понимать.
По логике вещей значения по умолчанию должны быть отображены в интерфейсе в виде предустановленный данных.
Сущность «политика» существует безотносительно предустановленных данных, и даже безотносительно операционной системы. Одна и та же политика может применяться к разным ЭВМ, операционным системам, также она может переопределять другую политику. Понятие «значение по умолчанию» в общем случае к ней неприменимо.
НЛО прилетело и опубликовало эту надпись здесь
Потому что по умолчанию входящие подключения запрещены?
НЛО прилетело и опубликовало эту надпись здесь
Ниже выпадашки «Состояние брэндмауэра» есть переключатели «Входящие подключения: Блокировать (по умолчанию)» и «Исходящие подключения: Разрешить (по умолчанию)».
Вот тут
В случае получения злоумышленником полного доступа к ОС, врят ли можно будет провести расследование основываясь на локальных логах системы. Обычно существует централизованная система сбора и анализа логов. В этом случае получаем все плюсы автоматизации. "Анализ поведения" через логи. Выявление на раннем этапе всех действий злоумышленников. И т.п. Надо понимать что локальные логи в windows это только кирпичик в построении системы безопасности.
Любая централизованная система сбора логов, взять хотя бы тот же ELK, использует локальные логи, как источник информации.
По большому счету, тут, в качестве примера, и была рассмотрена ситуация, когда злоумышленники противостоят централизованному сбору. Если централизованного сбора и анализа нет, то и противодействовать никому не надо, все равно никто эти логи смотреть не будет.
По большому счету, тут, в качестве примера, и была рассмотрена ситуация, когда злоумышленники противостоят централизованному сбору. Если централизованного сбора и анализа нет, то и противодействовать никому не надо, все равно никто эти логи смотреть не будет.
Это вы еще не знаете про «чудеса» виндового коллектора.
А так да, согласен с автором вся эта подсистема логирования — историческое нагромождение говнокода в угоду обратной совместимости.
А так да, согласен с автором вся эта подсистема логирования — историческое нагромождение говнокода в угоду обратной совместимости.
Спасибо за статью! Было бы ещё интереснее, если бы в качестве примеров были рассмотрены машины в домене и с GPO, а не с локальными политиками. Все-таки, если строим систему безопасности, централизованное управление политиками — один из первых шагов.
Почти все проблемы, описанные в статье актуальны и для доменного варианта. Локальный вариант здесь рассмотрен в основном для наглядности.
С этим согласен, однако параметры из GPO не хранятся в указанном ключе реестра, вывод auditpol из примера 1 на доменной машине состоянием по-умолчанию после ввода в домен по крайней мере у меня отличается и т.д.
В любом случае, всего не опишешь, куда копать — из статьи понятно, так что статья — хороший инструмент для погружения в тематику.
В любом случае, всего не опишешь, куда копать — из статьи понятно, так что статья — хороший инструмент для погружения в тематику.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы в системе журналирования событий безопасности ОС Windows