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