powershell лог выполнения скрипта

04/11/202304/05/2023 admin 0 Comments

about_Logging_Windows

Краткое описание

PowerShell регистрирует внутренние операции из подсистемы, поставщиков и командлетов в журнале событий Windows.

Подробное описание

PowerShell регистрирует сведения об операциях PowerShell, таких как запуск и остановка подсистемы и поставщиков, а также выполнение команд PowerShell.

Просмотр записей журнала событий PowerShell на Windows

Если включено ведение журнала блокировки сценариев, PowerShell регистрирует в журнале следующие события PowerShellCore/Operational :

Поле	Значение
EventId	4104 / 0x1008
Channel	Operational
Level	Verbose
Код операции	Create
Задача	CommandStart
Ключевое слово	Runspace

Регистрация поставщика событий PowerShell на Windows

в отличие от Linux или macOS, Windows требует регистрации поставщика событий, прежде чем события могут быть записаны в журнал событий. Чтобы включить поставщик событий PowerShell, выполните следующую команду в командной строке PowerShell с повышенными привилегиями.

Отмена регистрации поставщика событий PowerShell на Windows

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

Чтобы отменить регистрацию поставщика PowerShell, выполните следующую команду в командной строке PowerShell с повышенными привилегиями.

Включение ведения журнала блоков сценариев

При включении ведения журнала блока сценариев PowerShell записывает содержимое всех блоков сценариев, которые он обрабатывает. После включения все новые сеансы PowerShell регистрируют эти сведения.

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

Ведение журнала блока скрипта можно включить с помощью групповая политика или параметра реестра.

Использование групповой политики

Использование реестра

Выполните следующую функцию:

Ведение журнала защищенных событий

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

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

Содержимое журнала событий защищено с помощью стандартного синтаксиса сообщений (CMS) IETF. CMS использует шифрование с открытым ключом. Ключи, используемые для шифрования содержимого и расшифровки содержимого, хранятся отдельно.

Открытый ключ может быть общим и не конфиденциальным. Любое содержимое, зашифрованное с помощью этого открытого ключа, может быть расшифровано только закрытым ключом. Дополнительные сведения о шифровании с открытым ключом см. в статье о шифровании с открытым ключом Википедии.

Чтобы включить политику защищенного ведения журнала событий, разверните открытый ключ для всех компьютеров, которые содержат данные журнала событий для защиты. Соответствующий закрытый ключ используется для последующей обработки журналов событий в более безопасном расположении, например в центральном сборщике журналов событий или SIEM агрегаторе. Вы можете настроить SIEM в Azure. Дополнительные сведения см. в разделе Универсальная интеграция SIEM.

Включение ведения журнала защищенных событий с помощью групповая политика

Итоговый сертификат должен иметь Document Encryption в качестве расширенного использования ключа ( 1.3.6.1.4.1.311.80.1 ), а Data Encipherment также значение или Key Encipherment Использование ключей.

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

Расшифровка сообщений журнала защищенных событий

Следующий сценарий будет получен и расшифрован, предполагая, что у вас есть закрытый ключ:

Источник

Как логировать запуск команд в Powershell?

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

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

Далее в нем можно описать какие-либо свои команды или функции. Ими можно будет пользоваться сразу после запуска консоли без необходимости их объявления при каждом запуске. Потому что они уже будут проиницализированы при старте консоли.

Реализация логирования

В центре нашего внимания будет такой командлет как Start-Transcript. Его функция заключается в протоколировании всего, что происходит в рамках сеанса и сохранении результата в файл. Весь текст, который появляется в консоли, будет фиксироваться в файле.

Создадим шару

В качестве примера файловой шары буду использовать папку на моем ПК

Настройка файловой шары

В этом примере я выдал права на изменение для группы “Все”. Не забывайте о том, чтобы не было противоречий с разрешениями на уровне NTFS. Если на вкладке безопасность для группы “Все” будет стоять запрет, логировать запуск команд не получится. В результате этих нехитрых действий папка доступна по пути – \\Vedroid\Share. В качестве сервера файловой шары конечно же может использоваться и удаленный сервер. Главное – это наличие сетевого доступа по протоколу SMB и наличие разрешений на запись.

Настроим протоколирование

Редактируем Profile-скрипт и пишем следующий код:

Чтобы это скрыть, мы используем командлет Out-Null. Таким образом транскрибирование запустится, но информация об этом не будет выведена в консоль.

Конечно, установка в значение Bypass не очень безопасна, т.к. позволяет запускать вредоносные скрипты powershell. Выходом из ситуации может быть подписание скрипта электронной подписью и установкой Execution Policy в AllSigned. Подробнее о политиках запуска скриптов можно узнать здесь. Или можно обратиться к справке.

Таким образом, если все готово, при запуске консоли в файловой шаре появляется лог файл. В котором мы можем наблюдать все действия и полученный вывод. Запустим консоль и выполним любую команду для теста.

Результат логирования команд

Конечно в такой конфигурации есть минус. Если пользователь выполнит команду Start-Transcript при уже запущенном транскрибировании, то получит соответствующее уведомление. И после выполнения Stop-Transcript логирование будет прекращено.

Так же есть риск в плане безопасности. Если злоумышленник имеет доступ в профиль пользователя, он может заменить код profile-скрипта. А если скрипта нет, то создать его. И этот код будет выполнен при запуске консоли от имени жертвы. Но такой риск существует всегда, не зависимо от темы текущей статьи. Охраняйте доступ к Вашему профилю!

Как масштабировать такую конфигурацию?

Для доставки скрипта на ПК пользователя в его профиль, можно использовать доменные групповые политики. Либо в образе ОС, если из него происходит установка ОС на новых ПК, добавить скрипт в дефолтный профиль. И после создания профиля нового пользователя на ПК, скрипт уже будет присутствовать в его профиле.

Игорь Чердаков

Мне 31 год. На текущий момент я являюсь администратором систем Microsoft в одной из крупнейших компаний в России. За моими плечами практически 7 лет опыта работы в IT, последние 3 из которых в администрировании. Сопровождая немалую инфраструктуру, в ежедневной деятельности я сталкиваюсь с необходимостью автоматизации рутинных процессов, в чем мне успешно помогает Powershell. Данный блог основывается на моем личном опыте и знаниях. Мои статьи не являются истиной в последней инстанции и я положительно отношусь к обоснованной и конструктивной критике. По этому я приглашаю Вас обсуждать волнующие нас вопросы, связанные с Powershell.

Источник

Используем лог-файлы для скриптов PowerShell

Вы можете использовать простые текстовые лог файлы для контроля запуска и отслеживания всех действий, которые выполняются при запуске PowerShell скриптов. Это удобно при отладке ошибок, для аудита выполненных скриптом действий. В этой статье мы рассмотрим несколько способов ведения текстовых лог-файлов для ваших PowerShell скриптов.

В самом простом случае, если вам нужно записать вывод информационного сообщения или результатов определенной PowerShell команды в текстовый лог файл, вы можете использовать один из следующих форматов перенаправления вывода в txt файл:

Во всех случаях команды добавляют в указанный текстовый файл новую строку c указанным вами текстом.

Главный недостаток такого метода – по такому лог файлу нельзя определить, когда была внесена та или иная запись в лог (произошло событие). Вы можете добавить в лог текущую метку даты, времени (timestamp). Это поможет легко идентифицировать время запуска скрипта и конкретного события в нем.

Для удобства можно создать в PowerShell скрипте отдельную функцию, которая будет сохранять переданные ей данные в лог файл и добавлять время записи информации.

Можно сделать функцию:

$Logfile = «C:\PS\Logs\proc_$env:computername.log»
function WriteLog
<
Param ([string]$LogString)

Теперь, чтобы записать что-то в лог файл, вам нужно вызвать функцию WriteLog.

WriteLog «Скрипт запущен”
WriteLog «Выполняю вычисления….»
Start-Sleep 20
WriteLog «Скрипт выполнен успешно»

Теперь в лог файле содержится время, когда была произведена запись.

В PowerShell также есть встроенная возможность сохранять в текстовый лог файл все команды и результаты, которые выводятся в консоль PS.

Чтобы начать запись текущей PowerShell сессии, используется командлет Start-Transcript.

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

Параметр –Append указывает, что нужно дописывать новые сессию в конец лог файла (не перезатирать его).

Выполните несколько PowerShell команд, которые выводят результаты в консоль. Например, выведем список тяжелых запущенных процессов, запущенных служб и состояние репликации в AD:

Завершите запись сессии для текущей сессии:

Теперь откройте текстовый файл с логом.

Как вы видите, в текстовом логе отображаются вся история PowerShell команд, которые запускались в скрипте и весь вывод, который выводился в консоль.

Вы можете использовать Start-Transcript/Stop-Transcript в своих PowerShell скриптах чтобы нативно логировать все действия и результаты.

Источник

Аудит удаления и доступа к файлам и запись событий в лог-файл средствами Powershell

Начнем.

Для начала включим к групповых политиках возможность аудита доступа к файлам и папкам.
Локальные политики безопасности->Конфигурация расширенной политики безопасности->Доступ к объектам
Включим «Аудит файловой системы» на успех и отказ.
После этого на необходимые нам папки необходимо настроить аудит.
Проходим в свойства папки общего доступа на файловом сервере, переходим в закладку «Безопасность», жмем «Дополнительно», переходим в закладку «Аудит», жмем «Изменить» и «Добавить». Выбираем пользователей для которых вести аудит. Рекомендую выбрать «Все», иначе бессмысленно. Уровень применения «Для этой папки и ее подпапок и файлов».
Выбираем действия над которыми мы хотим вести аудит. Я выбрал «Создание файлов/дозапись данных» Успех/Отказ, «Создание папок/дозапись данных» Успех/отказ, Удаление подпапок и файлов и просто удаление, так же на Успех/Отказ.
Жмем ОК. Ждем применения политик аудита на все файлы. После этого в журнале событий безопасности, будет появляться очень много событий доступа к файлам и папкам. Количество событий прямопропорционально зависит от количества работающих пользователей с общим ресурсом, и, конечно же, от активности использования.

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

А теперь очень интересный скрипт.

Скрипт пишет лог об удаленных файлах.

Как оказалось при удалении файлов и удалении дескрипторов создается одно и тоже событие в логе, под При этом в теле сообщения могут быть разные значения «Операции доступа»: Запись данных (или добавление файла), DELETE и т.д.
Конечно же нас интересует операция DELETE. Но и это еще не все. Самое интересное, то что, при обычном переименовании файла создается 2 события с ID 4663, первое с Операцией доступа: DELETE, а второе с операцией: Запись данных (или добавление файла). Значит если просто отбирать 4663 то мы будем иметь очень много недостоверной информации: куда попадут файлы и удаленные и просто переименованные.
Однако мной было замечено, что при явном удалении файла создается еще одно событие с ID 4660, в котором, если внимательно изучить тело сообщения, содержится имя пользователя и еще много всякой служебной информации, но нет имени файла. Зато есть код дескриптора.

Однако предшествующим данному событию было событие с ID 4663. Где как раз таки и указывается и имя файла, и имя пользователя и время, и операция как не странно там DELETE. И самое главное там имеется номер дескриптора, который соответствует номеру дескриптора из события выше (4660, помните? которое создается при явном удалении файла). Значит теперь, чтобы точно знать какие файлы удалены, необходимо просто найти все события с ID 4660, а так же предшествующие каждому этому событию, событие с кодом 4663, в котором будет содержаться номер нужного дескриптора.

Эти 2 события генерируются одновременно при удалении файла, но записываются последовательно, сначала 4663, потом 4660. При этом их порядковые номера различаются на один. У 4660 порядковый номер на единицу больше чем у 4663.
Именно по этому свойству и ищется нужное событие.

Т.е. не записываем информацию об удаленных временных файлах (.*tmp), файлах блокировок документов MS Office (.*lock), и временных файлах MS Office (.*

Для лога удаленных файлов я использую схему: один файл на один месяц с именем содержащим номер месяца и год). Т.к. удаленных файлов в разы меньше чем файлов к которым был доступ.

В итоге вместо бесконечного «рытья» логов в поисках правды, можно открыть лог-файл любым табличным редактором и просмотреть нужные нам данные по пользователю или файлу.

about_Logging

Краткое описание

PowerShell регистрирует внутренние операции из подсистемы, поставщиков и командлетов.

Подробное описание

Просмотр записей журнала событий PowerShell на Windows

Если включено ведение журнала блокировки сценариев, PowerShell регистрирует в журнале следующие события Microsoft-Windows-PowerShell/Operational :

Поле	Значение
EventId	4104 / 0x1008
Канал	Operational
Level	Verbose
Код операции	Create
Задача	CommandStart
Ключевое слово	Runspace