Глава 8. Реализация корпоративной безопасности

Содержание

В этой главе мы рассмотрим следующие рецепты:

Реализация JEA (Just Enough Administration)
Изучение журналов регистрации Приложений и Служб
Выявление событий входа в систему в журнале событий
Развёртывание Групповых политик PowerShell
Применение журнала Блока сценария PowerShell
Настройка политик паролей AD
Управление Антивирусом Windows Defender

Введение

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

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

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

JEA (Just Enough Administration, вполне достаточное администрирование) это функциональная возможность, которая позволяет вам реализовывать администрирование с тонкой настройкой, предоставляя пользователям вполне достаточную мощность чтобы позволять им выполнять их задания и ничего более. Основная цель JEA состоит в снижении числа пользователей, которые являются участниками групп с очень высокими полномочиями, включая группу Администраторов, Администраторов Домена и Корпоративных Администраторов.

В Windows почти все выполняющие что бы то ни было компоненты, регистрируют сведения в журналы событий Windows. Это включает в себя классические регистрации (впервые реализованные в Windows NT 3.1), плюс Журналы Приложений и Служб, добавленные Microsoft в Vista. Они предоставляют некий массив большого числа сведений в помощь вам управлять вашей системой. Одним из представляющих интерес событий это события входа в систему - кто зарегистрировался и когда. Вы можете применять эти сведения для отслеживания необычных или подозрительных входов в систему.

Вы можете управлять определёнными сторонами PowerShell 7, такими как Windows PowerShell, при помощи Групповой политики или вручную устанавливая ключи реестра политик. При всё возрастающем применении атак PowerShell без файлов, регистрация блока сценария это один из способов выявления подозрительного поведения. Вы можете пользоваться такими событиями журнала для выявления активности через развёртывание инструментария SIEM (Security Information and Event Management, Управления сведениями и событиями безопасности), например, SolarWinds Security Event Manager или RSA NetWitness. Либо вы можете сохранять эти события для просмотра вручную.

Важнейшим фактором безопасности для организации любого размера является политика ваших паролей. У вас имеется значительная гибкость относительно политик паролей Windows. Windows 10 и Windows Server 2022 обладают устанавливаемой по умолчанию политикой паролей, которую вы способны менять. Вы можете настроить установленную по умолчанию политику пролей когда вы желаете более длинные или более короткие пароли, либо более или менее сложные пароли. Для тех вариантов, когда вы желаете обладать различной политикой паролей для определённых пользователей, вы можете пользоваться функциональной возможностью тонкой регулировки AD, которая позволяет вам устанавливать некую политику паролей для Подразделения организации (OU, organizational unit).

Windows Server 2022 и Windows 10 поставляются со встроенным продуктом антивируса и противодействия вредоносному программному обеспечению, Microsoft Defender Antivirus или MDA. Изначально это был лишь Microsoft Defender. MDA это часть более разностороннего комплекта продуктов под общим зонтиком Microsoft Defender for Endpoint. Отсылаем за дополнительными сведениями к https://www.microsoft.com/microsoft-365/security/endpoint-defender. Windows 10 и Windows Server поставляются с модулем Defender в помощь вам управлять Defender в сервере.

Реализация Just Enough Administration (JEA)

Just Enough Administration, также именуемое как JEA, это инфраструктура безопасности предоставляющая вам возможность реализации делегирования администрирования с тонкой настройкой. При помощи JEA вы позволяет пользователю обладать достаточной мощности администрирования для выполнения их заданий и ничего более. JEA это боле безопасная альтернатива простому добавлению пользователей в группы Администрирования доменом или Администраторов Корпорации.

При помощи JEA вы способны, к примеру, снабжать младших администраторов необходимыми правами для доступа к вашим DC (domain controllers, Контроллерам домена) для администрирования установленной службы DNS в таком Контроллере домена. JEA позволяет вам принуждать то что ваш пользователь способен выполнять в вашем защищённом сервере. Например, вы можете позволять своему пользователю останавливать и запускать такую службу DNS (при помощи Stop-Service и Start-Service), но не иные службы.

JEA пользуется тремя объектами:

Файл возможностей роли JEA (.psrc): Этот файл определяет некую роль в терминах её возможностей. Вы будете настраивать роль JEA RKDnsAdmins для определения ограниченного набора командлетов, к которым у этой роли имеется доступ в вашем Контроллере домена, а именно, те, которые относятся к администрированию DNS в Контроллере домена.
Файл настроек сеанса JEA (.pssc): Этот файл определяет кто способен выполнять доступ к удалённому сеансу PowerShell и что они способны делать в рамках этого сеанса. Вы можете позволять кому угодно в группе безопасности домена RKDnsAdmins выполнять доступ к серверу при помощи конечной точки JEA. Такой файл настроек сеанса определяет необходимые действия сеанса JEA через ссылки на соответствующий файл возможностей роли. Некий защищённый JEA удалённый сеанс способен применяться только определёнными людьми, которые могут выполнять что-то из того, что диктуют возможности этой роли.
Удалённая конечная точка PowerShell: После того как вы получили созданными файл возможностей соответствующей роли и настроек сеанса, вы регистрируете такую конечную точку JEA в том сервере, который вы защищаете при помощи JEA.

После регистрации конечной точки JEA, пользователь, который является участником соответствующей группы безопасности домена, RKDnsAdmins, способен применять Invoke-Command или Enter-PSSession, определяя конкретный удалённый сервер и необходимые защищённые JEA конечные точки для доступа к такому защищённому серверу. Пребывая внутри такого удалённого сеанса, этот пользователь способен выполнять лишь те возможности, которые допускает установленный файл роли.

Ниже приводится схема всех компонентов JEA:

Рисунок 8-01

Компоненты JEA

Подготовка

Это рецепт пользуется DC1, Контроллером домена из домена Reskit.Org , в котором вы настраиваете JEA для входящих подключений. Вы устанавливаете DC1 в качестве Контроллера домена и настраиваете пользователей, группы и Подразделения организации (OU) согласно Главе 5, Изучаем .NET. Первую часть данного рецепта вы выполняете в DC1.

Обычно для доступа к Контроллеру домена для управления DNS в промышленной среде вы обычно пользуетесь каким- то компьютером клиента. Для данного рецепта добавление некоторого дополнительного хоста клиента заменяется применением DC1 для тестирования JEA без необходимости дополнительного хоста. Естественно, в промышленной среде вам надлежит проверять JEA в хосте клиента.

Как это сделать...

Создаём папку представления


New-Item -Path C:\JEATranscripts -ItemType Directory | 
  Out-Null

Создаём папку возможностей роли


$JEACF = "C:\JEACapabilities"
New-Item -Path $JEACF -ItemType Directory | 
  Out-Null

Создаём папку настроек сеанса JEA


$SCF = 'C:\JEASessionConfiguration'
New-Item -Path $SCF -ItemType Directory | 
  Out-Null

Создаём DNSAdminsJEA в качестве глобальной группы безопасности


$DNSGHT = @{
  Name          = 'DNSAdminsJEA'
  Description   = 'DNS Admins for JEA'
  GroupCategory = 'Security'
  GroupScope    = 'Global'
}
New-ADGroup @DNSGHT
Get-ADGroup -Identity 'DNSAdminsJEA' |
  Move-ADObject -TargetPath 'OU=IT, DC=Reskit, DC=Org'

Добавляем JerryG в эту группу Администраторов DNS


$ADGHT = @{
  Identity  = 'DNSAdminsJEA'
  Members   = 'JerryG'
}
Add-ADGroupMember @ADGHT

Создаём файл возможностей роли


$RCF = Join-Path -Path $JEACF -ChildPath "DnsAdmins.psrc"
$RCHT = @{
  Path            = $RCF
  Author          = 'Reskit Administration'
  CompanyName     = 'Reskit.Org' 
  Description     = 'DnsAdminsJEA role capabilities'
  AliasDefinition = @{Name='gh';Value='Get-Help'}
  ModulesToImport = 'Microsoft.PowerShell.Core','DnsServer'
  VisibleCmdlets  = (@{ Name        = "Restart-Computer"; 
                        Parameters  = @{Name = "ComputerName"}
                        ValidateSet = 'DC1, DC2'},
                       'DNSSERVER\*',
                     @{ Name        = "Stop-Service"; 
                        Parameters  = @{Name = "DNS"}},                  
                     @{ Name        = "Start-Service"; 
                        Parameters  = @{Name = "DNS"}}
                     )
  VisibleExternalCommands = ('C:\Windows\System32\whoami.exe',
                             'C:\Windows\System32\ipconfig.exe')
  VisibleFunctions = 'Get-HW'
  FunctionDefinitions = @{
    Name = 'Get-HW'
    Scriptblock = {'Hello JEA World'}}
}
New-PSRoleCapabilityFile @RCHT

Создаём файл настроек сеанса JEA


$P   = Join-Path -Path $SCF -ChildPath 'DnsAdmins.pssc'
$RDHT = @{
  'DnsAdminsJEA' = 
      @{'RoleCapabilityFiles' = 
        'C:\JEACapabilities\DnsAdmins.psrc'}
}
$PSCHT= @{
  Author              = 'DoctorDNS@Gmail.Com'
  Description         = 'Session Definition for DnsAdminsJEA'
  SessionType         = 'RestrictedRemoteServer'   # ie JEA!
  Path                = $P       # Role Capabilties file
  RunAsVirtualAccount = $true
  TranscriptDirectory = 'C:\JeaTranscripts'
  RoleDefinitions     = $RDHT     # tk role mapping
}
New-PSSessionConfigurationFile @PSCHT

Проверяем файл настроек сеанса
```
Test-PSSessionConfigurationFile -Path $P
		
```
Разрешаем в DC1 удалённый доступ
```
Enable-PSRemoting -Force | 
  Out-Null
		
```

Регистрируем настройки сеанса JEA удалённой конечной точки


$SCHT = @{
  Path  = $P
  Name  = 'DnsAdminsJEA' 
  Force =  $true 
}
Register-PSSessionConfiguration @SCHT

Просматриваем удалённые конечные точки


Get-PSSessionConfiguration  |
  Format-Table -Property NAME, PSVERSION, Run*Account

Проверяем что могут выполнять соответствующие пользователи


$SCHT = @{
  ConfigurationName = 'DnsAdminsJEA'
  Username          = 'Reskit\JerryG' 
}
Get-PSSessionCapability  @SCHT |
  Sort-Object -Property Module

Создаём полномочия для пользователя JerryG


$U    = 'JerryG@Reskit.Org'
$P    = ConvertTo-SecureString 'Pa$$w0rd' -AsPlainText -Force 
$Cred = [PSCredential]::New($U,$P)

Определение трёх блоков сценария и некой хэш таблицы вызовов сплаттинга


$SB1   = {Get-Command}
$SB2   = {Get-HW}
$SB3   = {Get-Command -Name  '*-DNSSERVER*'}
$ICMHT = @{
  ComputerName      = 'DC1.Reskit.Org'
  Credential        = $Cred 
  ConfigurationName = 'DnsAdminsJEA' 
}

Получение доступных внутри соответствующего сеанса JEA команд


Invoke-Command -ScriptBlock $SB1 @ICMHT |
  Sort-Object -Property Module |
    Select-Object -First 15

Активация определённой JEA функции в сеансе JEA от имени JerryG
```
Invoke-Command -ScriptBlock $SB2 @ICMHT
		
```

Получение доступных JerryG команд DNSServer


$C = Invoke-Command -ScriptBlock $SB3 @ICMHT
"$($C.Count) DNS commands available"

Изучаем содержимое папки представления
```
Get-ChildItem -Path $PSCHT.TranscriptDirectory
		
```

Изучаем представление


Get-ChildItem -Path $PSCHT.TranscriptDirectory | 
  Select-Object -First 1  |
    Get-Content

Как это работает...

На Шаге 1 вы создаёте новую папку, которую вы применяете для хранения представлений JEA. На Шаге 2 вы создаёте папку для хранения файлов возможностей роли. На Шаге 3 вы создаёте папку для хранения файлов настроек сеансов JEA. Эти три шага не производят вывод.

На Шаге 4 Вы создаёте глобальную группу безопасности, которую вы применяете с JEA и на Шаге 5 вы добавляете в эту группу пользователя JerryG. Никакой из этих шагов не предоставляет вывод. По умолчанию, Windows создаёт такую новую группу в своём AD в контейнере Users, что может быть далёким от идеала. Чтобы обеспечить такую учётную запись в правильном Подразделении организации (OU), вы пользуетесь Move-ADGroup для его перемещения в верное место.

На Шаге 6 вы создаёте файл возможностей роли и сохраняете его в соответствующей папке возможностей ролей, которую вы создали на Шаге 2. Такой файл возможностей роли содержит метаданные (включая автора и организацию), псевдонимы, с помощью которых может выполнять доступ пользователь, модули для импорта в соответствующий сеанс JEA, все видимые командлеты, команды консоли, а также функции, к которым способен выполнять доступ данные сервер JEA/

Файл роли JEA содержит, в данном рецепте, некую новую функцию, Get-HW. Эта достаточно простая функция показывает как вы можете определять для доступа своего пользователя JEA дополнительные функции, возможно, относящиеся к конкретно его роли.

На Шаге 7 вы создаёте файл настроек сеанса JEA, который вы сохраняете в той папке, которую вы создали на Шаге 3. Шаг 6 и Шаг 7 не производят вывод.

На Шаге 8 вы пользуетесь командой Test-PSSessionConfigurationFile для проверки своего файла настроек сеанса. Эта команда производит такой вывод:

Рисунок 8-02

Тестирование файла настроек сеанса

На Шаге 9 вы применяете команду Enable-PSRemoting чтобы убедится что вы настроили DC1 под удалённый доступ WinRM. Этот шаг не производит вывод.

На Шаге 10 вы завершаете настройку регистрируя настройку удалённой конечной точки сеанса JEA, что не производит вывод.

На Шаге 11 для просмотра доступных в DC1 удалённых конечных точек вы пользуетесь командой Get-PSSessionConfiguration со следующим выводом:

Рисунок 8-03

Просмотр доступных в DC1 удалённых конечных точек

На Шаге 12 вы проверяете те команды, которые доступны вашему пользователю JerryG в настройках сеанса JEA для доступа внутри соответствующей конечной точки DNSAdminsJEA, что вырабатывает следующий вывод:

Рисунок 8-04

Проверка того что может выполнять пользователь JerryG

На Шаге 13 вы создаёте объект полномочий PowerShell для JerryG. На Шаге 14 вы создаёте объект полномочий для JerryG@Reskit.Org. Эти шаги не производят вывод.

На Шаге 14 вы создаёте три блока сценария и некую таблицу хэшей вызова для применения в последующих шагах, что не производит вывод. На Шаге 15 вы вызываете блок сценария $SB1 внутри сеанса JEA со следующим выводом:

Рисунок 8-05

Получение доступных внутри соответствующего сеанса JEA команд

На Шаге 16 вы активируете блок сценария $SB2 для вызова определённой в файле возможностей роли функции Get-HW:

Рисунок 8-06

Вызов определённой в JEA функции в сеансе JEA от имени JerryG

На Шаге 17 вы активируете блок сценария $SB3, который подсчитывает число доступных в вашем модуле сервера DNS команд, для которых у пользователя JerryG имеются полномочия для выполнения. Вот вывод с этого шага:

Рисунок 8-07

Подсчёт числа доступных JerryG команд DNS

Когда вы настроили JEA, вы уведомляетесь что JEA должен создать некое представление для каждого сеанса JEA. На Шаге 18 вы изучаете такие представления в своей папке представлений со следующим выводом:

Рисунок 8-08

Изучение содержимого папок представления

На завершающем Шаге 19 вы изучаете самое первое представление в своей папке представлений с выводом (усечённом для публикации), который должен выглядеть как- то так:

Рисунок 8-09

Изучение представления

Есть кое- что ещё...

На Шаге 6 вы создаёте файл возможностей роли JEA. В этом файле вы определяете какие действия может выполнять пользователь внутри сеанса JEA. Они включают те команды, которые способен исполнять пользователь, модули, которые он може загружать, особые для сеанса JEA функции, к которым он может получать доступ. Например, вы можете определить, что такой пользователь JEA способен запускать некий командлет, который получает параметры, однако вы допускаете лишь определённые значения параметров. Короче говоря, файл возможностей роли позволяет вам в точности персонализировать что именно может выполнять соответствующий пользователь JEA в неком сеансе JEA. Для получения дополнительных сведений о возможностях роли JEA и файле возможностей роли отсылаем вас к https://docs.microsoft.com/powershell/scripting/learn/remoting/jea/role-capabilities.

Когда вы развёртываете JEA в неком предприятии, вы можете обладать множеством серверов и служб, управляемых сеансами JEA и несоизмеримой базой пользователей. В подобных ситуациях вы можете пожелать создавать некую платформу для своего развёртывания с целью упрощения создания необходимых определений ролей и вашего развёртывания JEA в целом.

На Шаге 9 вы пользуетесь командой Enable-PSRemoting. Эта команда гарантирует вам разрешение удалённого доступа WinRM и создаёт две стандартные конечные точки PowerShell 7. Дополнительно к той, которую вы создаёте на Шаге 10.

На Шаге 15 вы запускаете $SB1 в рамках некого сеанса JEA в DC1. Этот сценарий активирует Get-Command для перечисления всех тех команд, которые доступны любым участникам из группы DNSAdminsJEA. На рисунке вывод усечён чтобы занимать меньше места при публикации. Полный вывод перечисляет все доступные команды полностью.

На Шаге 16 вы пользуетесь функцией Get-HW, определённой в файле роли совместимости JEA. Данная функция существует только внутри такого сеанса JEA.

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

На заключительном Шаге 19 вы изучаете одно из представлений своего сеанса JEA. На Рисунке 8-09 вы видите представление, выработанное на Шаге 15. Вам также следует управлять своей папкой представлений, в том числе архивируя или удаляя более старые представления. Если вы намерены широко пользоваться JEA, вы можете пожелать разработать некоторые подводящие итог отчёты на основе содержимого каждого представления, в том числе какие именно пользователи применяли какой из сеансов JEA и когда.

Исследование регистраций приложений и служб

Начиная с самой первой версии Windows NT в 1993, всякий раз как что- то происходило в Windows, ответственные компоненты записывали подробности в некий журнал событий. В более ранних версиях Windows Server имелось четыре различных журнала Windows:

Application (Приложения): содержит события, относящиеся к тому программному обеспечению, которое установлено в вашем сервере
Security (Безопасность): содержит события, относящиеся к безопасности в вашем сервере
Setup (Установка): содержит относящиеся к установке KB Knowledge Base события и события, которые происходят в процессе установки
System (Система): содержит события, которые относятся к данной системе, такие как запуск системы и останов системы

Помимо этих журналов, прочие приложения и компоненты могут добавлять дополнительные журналы. Вы можете наблюдать как классические, так и дополнительные журналы при помощи командлета PowerShell Get-Eventlog.

Начиная с Window Vista, Microsoft внёс некоторые значительные улучшения в функциональные возможности регистрации событий. Значимые улучшения были добавлены в журналы Applications and Services (Приложений и Служб), который содержит более четырёх сотен индивидуальных журналов. Такие дополнительные журналы позволяют компонентам Windows записывать особые для приложений регистрационные записи вместо классических записей событий Applications and Services, упрощая поиск необходимых событий в заданном хосте. Имеются сотни таких журналов Applications and Services, которые предоставляют специфичные для приложения или службы записи событий, однако Windows не включает все журналы по умолчанию. При помощи PowerShell вы пользуетесь Get-WinEvent для работы со всеми такими журналами событий, включая и новые.

В этом рецепте мы изучим такие журналы и то, как получать подробности журналов событий.

Подготовка

Вы исполняете этот рецепт в SRV1, присоединённом к домену Windows Server. Вам также требуется работающий DC1, Контроллер домена в домене Reskit.Org. В каждой из систем у вас имеется установленным PowerShell 7 и Visual Studio Code.

Как это сделать...

Регистрируем поставщика журнала событий PowerShell
```
& $PSHOME\RegisterManifest.ps1
		
```
Выявляем классические журналы событий в SRV1
```
Get-EventLog -LogName *
		
```
Обнаруживаем и замеряем все журналы событий в этом хосте
```
$Logs = Get-WinEvent -ListLog *
"There are $($Logs.count) total event logs on SRV1"
		
```

Обнаруживаем и замеряем все журналы событий в DC1


$SB1 = {Get-WinEvent -ListLog *}
$LogsDC1 = Invoke-Command -ComputerName DC1 -ScriptBlock $SB1
"There are $($LogsDC1.count) total event logs on DC1"

Выявляем подробности участника журнала
```
$Logs | Get-Member
		
```

Замеряем включённые журналы в SRV1


$Logs | 
  Where-Object IsEnabled |
    Measure-Object |
      Select-Object -Property Count

Замеряем включённые журналы в DC1


$LogsDC1 | 
  Where-Object IsEnabled |
    Measure-Object |
      Select-Object -Property Count

Замеряем включённые журналы в SRV1, которые обладают записями


$Logs | 
  Where-Object IsEnabled |
    Where-Object Recordcount -gt 0 |
      Measure-Object |
        Select-Object -Property Count

Обнаруживаем относящиеся к PowerShell журналы
```
$Logs | 
  Where-Object LogName -match 'powershell'
		
```

Изучаем журнал событий PowerShellCore


Get-Winevent -LogName 'PowerShellCore/Operational' |
  Select-Object -First 10

Как это работает...

На Шаге 1 вы гарантируете что Windows обладает зарегистрированным поставщиком журнала событий PowerShell. Этот шаг не производит вывод.

На Шаге 2 для выявления классических журналов событий в SRV1 вы пользуетесь Get-EventLog со следующим выводом:

Рисунок 8-10

Обнаруживаем в SRV1 классические журналы событий

На Шаге 3 для выявления всех имеющихся в SRV1 журналов событий вы применяете командлет Get-WinEvent. Вот получаемый вывод:

Рисунок 8-11

Обнаруживаем и пересчитываем все журналы событий в SRV1

На Шаге 4 вы обнаруживаете и замеряете значение числа журналов событий в своём Контроллере домена DC1 с подобным приводимому ниже выводом:

Рисунок 8-12

Обнаруживаем и пересчитываем все журналы событий в DC1

На Шаге 5 для обнаружения всех свойств журналов событий, которые вы можете применять при запросах вы пользуетесь Get-Member. Вот вывод на этом шаге:

Рисунок 8-13

Выявляем подробности участников журналов

Windows не включет по умолчанию все журналы событий. На Шаге 6 вы выясняете все разрешённые журналы в SRV1. На этом шаге получается подобный следующему вывод:

Рисунок 8-14

Замеряем включённые в SRV1 журналы

На Шаге 7 вы измеряете все включённые в DC1 журналы событий с приводимым далее выводом:

Рисунок 8-15

Замеряем включённые в DC1 журналы

На Шаге 8 вы пересчитываете значение числа журналов событий, которые включены у вас в SRV1 и содержат записи журнала событий. Получается примерно такой вывод:

Рисунок 8-16

Замеряем обладающие записями включённые в SRV1 журналы

На Шаге 9 вы обнаруживаете какие журналы событий могут содержать события для Windows PowerShell или PowerShell 7 (ранее именовавшийся как PowerShell Core). Вот что мы получаем на выходе:

Рисунок 8-17

Выявляем относящиеся к PowerShell журналы

На своём заключительном шаге данного рецепта, на Шаге 10, вы изучаете журнал событий PowerShellCore с подобным приводимым ниже выводом:

Рисунок 8-18

Изучаем журналы событий PowerShell

Есть кое- что ещё...

На Шаге 3 и на Шаге 4 вы получаете счётчик общего числа журналов событий в SRV1 и DC1. Как вы можете видеть,значение числа журналов разнится. Различные компоненты и приложения Windows могут добавлять для вашего пользования дополнительные журналы событий. На Шаге 6 и на Шаге 7 вы также наблюдаете общее число включённых журналов в обеих системах. При помощи Шага 8 вы видите сколько включённых (в SRV1) журналов в реальности содержат записи журнала событий.

На Шаге 9 вы видите журналы событий из SRV1, относящиеся к PowerShell и PowerShell 7. Вы подробнее изучите журналы PowerShell Core в некоторых рецептах в этой главе.

Обнаружение событий регистрации в системе в журнале событий

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

В Windows имеются различные типы входа в систему. Регистрация с типом 2 указывает некий локальный вход с консоли (то есть, регистрацию в неком физическом хосте), в то время как вход с типом 10 указывает регистрацию поверх RDP. Прочие типы вода в систему содержат регистрацию службы (тип 5), пакетную или запланированную задачу (тип 4) и разблокировку консоли (тип 7).

С дополнительными сведениями вы можете ознакомиться в этой статье. Обратите внимание на то, что этот документ устарел и Microsoft не обновлял его для последних версий Windows, хотя все сведения в нём продолжают оставаться верными.

В данном рецепте мы воспользуемся PowerShell для изучения журнала событий Безопасности (Security) и рассмотрим вход в систему.

Подготовка

В данном рецепте вы запускаете DC1, Контроллер домена в вашем Лесу Reskit.Org.

Как это сделать...

Получаем события журнала Безопасности


$SecLog = Get-WinEvent -ListLog Security
"Security Event log entries:    [{0,10:N0}]" -f $Seclog.RecordCount

Получаем все подробности событий журнала Безопасности Windows
```
$SecEvents = Get-WinEvent -LogName Security
"Found $($SecEvents.count) security events on DC1"
		
```
Изучаем участников событий Безопасности журнала событий
```
$SecEvents | 
  Get-Member
		
```

Суммируем события безопасности по идентификатоу события


$SecEvents | 
  Sort-Object -Property Id | 
    Group-Object -Property ID | 
      Sort-Object -Property Name |
        Format-Table -Property Name, Count

Получаем в DC1 все успешные события входа в систему


$Logons = $SecEvents | Where-Object ID -eq 4624   # logon event
"Found $($Logons.Count) logon events on DC1"

Получаем из DC1 все события отказа на вход в систему


$FLogons = $SecEvents | Where-Object ID -eq 4625   # failed logon event
"Found $($FLogons.Count) failed logon events on DC1"

Создаём итоговый массив успешных событий входа в систему


$LogonEvents = @()
Foreach ($Logon in $Logons) {
  $XMLMSG = [xml] $Logon.ToXml()
  $Text = '#text'
  $HostName   = $XMLMSG.Event.EventData.data.$Text[1]
  $HostDomain = $XMLMSG.Event.EventData.data.$Text[2]
  $Account    = $XMLMSG.Event.EventData.data.$Text[5]
  $AcctDomain = $XMLMSG.Event.EventData.data.$Text[6]
  $LogonType  = $XMLMSG.Event.EventData.data.$Text[8]
  $LogonEvent = New-Object -Type PSCustomObject -Property @{
     Account   = "$AcctDomain\$Account"
     Host      = "$HostDomain\$Hostname"
     LogonType = $LogonType
     Time      = $Logon.TimeCreated
  }
  $LogonEvents += $logonEvent
}

Суммируем успешные события входа в систему для DC1


$LogonEvents | 
  Group-Object -Property LogonType |
    Sort-Object -Property Name |
      Format-Table Name, Count

Создаём итоговый массив событий отказа на вход в систему для DC1


$FLogonEvents = @()
Foreach ($FLogon in $FLogons) {
  $XMLMSG = [xml] $FLogon.ToXml()
  $Text = '#text'
  $HostName   = $XMLMSG.Event.EventData.data.$Text[1]
  $HostDomain = $XMLMSG.Event.EventData.data.$Text[2]
  $Account    = $XMLMSG.Event.EventData.data.$Text[5]
  $AcctDomain = $XMLMSG.Event.EventData.data.$Text[6]
  $LogonType  = $XMLMSG.Event.EventData.data.$Text[8]
  $LogonEvent = New-Object -Type PSCustomObject -Property @{
     Account   = "$AcctDomain\$Account"
     Host      = "$HostDomain\$Hostname"
     LogonType = $LogonType
     Time      = $FLogon.TimeCreated
  }
  $FLogonEvents += $LogonEvent
}

Суммируем события отказа на вход в систему для DC1


$FLogonEvents | 
  Group-Object -Property Account |
    Sort-Object -Property Name |
      Format-Table Name, Count

Как это работает...

На Шаге 1 вы пользуетесь командлетом Get-WinEvent для выборки подробностей относительно журнала Безопасности в DC1. Затем вы отображаете значение числа событий в этом журнале. Вот вывод для этого:

Рисунок 8-19

Получаем события журнала Безопасности

На Шаге 2 вы применяете Get-WinEvent для выборки всех событий из своего журнала Безопасности и отображения счётчика возвращаемых событий с подобным следующему выводом:

Рисунок 8-20

Получение подробностей событий журнала Безопасности Windows

Командлет Get-WinEvent возвращает объекты, которые содержат индивидуальные записи журнала событий. Каждый объект обладает типом System.Diagnostics.Eventing.Reader.EventLogRecord. На Шаге 3 вы просматриваете всех участников такого класса объекта .NET с подобным приводимому ниже выводом:

Рисунок 8-21

Получение подробностей событий журнала Безопасности Windows

После того как вы выбрали все события из своего журнала Безопасности, вы можете изучать различные типы событий безопасности, удерживаемые в значении поля идентификатора для каждой записи журнала. На Шаге 4 вы просматриваете и подсчитываете различные идентификаторы событий в своём журнале Безопасности, подобно следующему:

Рисунок 8-22

Суммируем событий безопасности по идентификаторам событий

Существует два относящихся ко входу в систему события, которые вы можете отслеживать. Записи регистрации с идентификатором события 4624 представляют события успешного входа, в то время как 4625 представляют отказы во входе. На Шаге 5 вы получаете ВСЕ события успешного входа с подобным приводимому ниже выводом:

Рисунок 8-23

Получаем все события успешного входа в DC1

На Шаге 6 вы подсчитываете значение числа отказов во входе в DC1, что выглядит как- то так:

Рисунок 8-24

Получаем все события отказа во входе для DC1

На Шаге 7 вы создаёте некий суммарный массив всех успешных входов. Этот шаг не производит никакого вывода. На Шаге 8 вы суммируете такие события входа и получаете следующий вывод:

Рисунок 8-25

Суммируем все события успешного входа в DC1

На Шаге 9 вы суммируете события отказа во входе для DC1. Вы отображаете подробности безуспешных входов на Шаге 10, что выглядит примерно так:

Рисунок 8-26

Суммируем все события отказа во входе для DC1

Есть кое- что ещё...

На Шаге 1 вы выполняете выборку суммы всех событий из своего журнала Безопасности и отображаете значение числа событий в этом журнале. На Шаге 2 вы выбираете и подсчитываете значение числа записей. Как вы можете видеть из приведённых выше снимков экрана, значения счётчиков не совпадают. Значения счётчика событий может отличаться, поскольку Windows постоянно регистрирует дополнительные события в своём журнале Безопасности. Такие дополнительные события это события, вырабатываемые фоновыми задачами или службами. Такое незначительное отличие не является неожиданным и безобидно.

На Шаге 3 вы просматриваете участников объектов журнала событий. Вы можете узнать дополнительно относительно участников соответствующего класса в https://docs.microsoft.com/dotnet/api/system.diagnostics.eventing.reader.eventlogrecord.

На Шаге 6 вы получаете события безуспешных входов. Для получения неудачных входов в систему вам требуется убедиться что вы попытались зарегистрироваться в DC1. но с неверными полномочиями. Как вы можете наблюдать на Шаге 10 из Рисунка 8-26, имеются два пользователя, которые были вовлечены в три неудачные попытки входа в DC1.

На Шаге 9 вы просматриваете такие отказы во входе. В зависимости от того какой пользователь предпринимал попытку войти в этот сервер (и получил отказ), получаемые результаты, которые вы наблюдаете на этом шаге могут отличаться от приведённых на снимке экрана.

Развёртывание Групповых политик PowerShell

Групповые политики это группы политик, которые вы можете развёртывать чтобы контролировать среду пользователей или компьютеров. Такие политики определяют что конкретный пользователь может и чего он не должен делать в заданном компьютере Windows. Например, вы можете создать некий GPO (Group Policy Object, объект Групповой политики) для настройки политик, которые задают как применять экранную заставку, позволять пользователям видеть Панель управления (Control Panel) или определять некую политику выполнения PowerShell по умолчанию. Существует более чем 2 500 индивидуальных настроек, которые вы можете развёртывать.

После того как вы создали некий GPO и определили эту политику для развёртывания, вы можете применить её к любому Подразделению организации (OU) в своём домене. Некое Подразделение организации это объект контейнера внутри AD, который способен содержать как прочие OU, так и объекты листьев, такие как пользователей, компьютеры или групповые объекты AD. Вы пользуетесь Подразделениями организации как для развёртывания GPO, так и для делегирования администрирования AD.

Вы можете применить GPO к некому OU, но также можете сделать это для самого домена или для некой площадки AD. Кроме того, вы можете определить будет ли политика внутри заданного GPO применяться к пользователям, к компьютерам, или и к тому и к другому. GPO предоставляет вам значительную гибкость в том как вы ограничиваете то что пользователи способны выполнять в некой рабочей станции или в сервере.

Начиная с Windows PowerShell 5.1, Microsoft включает набор из пяти настроек Групповой политики. Команда PowerShell расширила те политики, которые вы можете применять в PowerShell 7. По умолчанию, установка PowerShell 7, даже в Контроллере домена, не устанавливает необходимые файлы шаблонов административных GPO.

В домашней папке PowerShell ($PSHOME) вы можете найти такие файлы шаблонов политик и сценарий для их установки. После установки PowerShell в вашем Контроллере домена, вы запускаете сценарий установки в своей папке $PSHOME и устанавливаете необходимые определения политик. Вы осуществляете это во всех Контроллерах домена, либо в своём центральном хранилище политик, если вы пользуетесь таковым.

Для ознакомления с дополнительными сведениями относительно Групповых политик PowerShell 7 обращайтесь к https://docs.microsoft.com/dotnet/api/system.diagnostics.eventing.reader.eventlogrecord.

В этом рецепте вы обнаружите те файлы, которые необходимо добавить для поддержки GPO PowerShell 7, выполните установщик, затем создадите GPO для развёртывания набора относящихся к PowerShell политик.

Подготовка

Вы выполняете этот рецепт в DC1 после того как установили PowerShell 7 и Visual Studio. DC1 это Контроллер домена в вашем домене Reskit.Org, который вы применяли в предыдущих главах.

Как это сделать...

Выявляем относящиеся к GPO файлы


Get-ChildItem -Path $PSHOME -Filter *Core*Policy*

Устанавливаем файлы Групповой политики PowerShell 7


$LOC = 'C:\Program Files\PowerShell\7\' +         # $PSHome
       'InstallPSCorePolicyDefinitions.ps1'       # Script
& $LOC -VERBOSE

Создаём и отображаем новый GPO для своей группы ИТ
```
$PshGPO = New-GPO -Name 'PowerShell GPO for IT'
		
```

Включаем регистрацию модуля


$GPOKEY1 = 
  'HKCU\Software\Policies\Microsoft\PowerShellCore\ModuleLogging'
$GPOHT1 = @{
  DisplayName    = $PshGPO.DisplayName
  Key            = $GPOKEY1
  Type           = [Microsoft.Win32.RegistryValueKind]::DWord   
  ValueName      = 'EnableModuleLogging'
  Value          = 1
}
Set-GPRegistryValue @GPOHT1 | Out-Null

Настраиваем названия модулей для регистрации


$GPOHT2 = @{
  DisplayName    = $PshGPO.DisplayName
  Key            = "$GPOKEY1\ModuleNames"
  Type           = [Microsoft.Win32.RegistryValueKind]::String
  ValueName      = 'ITModule1', 'ITModule2'  
  Value          = 'ITModule1', 'ITModule2'
 }
Set-GPRegistryValue @GPOHT2 | Out-Null

Разрешаем Регистрацию блока сценария (Script Block Logging)


$GPOKey3 = 
  'HKCU\Software\Policies\Microsoft\PowerShellCore\ScriptBlockLogging'
$GPOHT3  = @{
    DisplayName    = $PshGPO.DisplayName
    Key            = $GPOKEY3
    Type           = [Microsoft.Win32.RegistryValueKind]::DWord
    ValueName      = 'EnableScriptBlockLogging'  
    Value          = 1
   }
Set-GPRegistryValue @GPOHT3 | Out-Null

Включаем политику исполнения без ограничений


$GPOKey4 = 
  'HKCU\Software\Policies\Microsoft\PowerShellCore'
# create the key value to enable
$GPOHT4 =  @{
    DisplayName    = $PshGPO.DisplayName
    Key            = $GPOKEY4
    Type           = [Microsoft.Win32.RegistryValueKind]::DWord   
    ValueName      = 'EnableScripts'
    Value          = 1
  }
  Set-GPRegistryValue @GPOHT4 | Out-Null
# Set the default execution policy   
$GPOHT4 = @{
  DisplayName    = $PshGPO.DisplayName
  Key            = "$GPOKEY4"
  Type           = [Microsoft.Win32.RegistryValueKind]::String
  ValueName      = 'ExecutionPolicy'
  Value          = 'Unrestricted'
}
Set-GPRegistryValue @GPOHT4

Назначаем полученный GPO своему Подразделению организации ИТ


$Target = "OU=IT, DC=Reskit, DC=Org" 
New-GPLink -DisplayName $PshGPO.Displayname -Target $Target |
   Out-Null

Создаём отчёт RSOP


$RSOPHT = @{
  ReportType = 'HTML'
  Path       = 'C:\Foo\GPOReport.Html'
  User       = 'Reskit\JerryG'
}
Get-GPResultantSetOfPolicy @RSOPHT
& $RSOPHT.Path

Как это работает...

На Шаге 1 вы обнаруживаете файлы GPO PowerShell 7 с примерно таким выводом:

Рисунок 8-27

Выявляем необходимые файлы GPO

На Шаге 2 вы вначале создаёте строку, которая содержит значение местоположения своего файла установки GPO. Затем вы исполняете этот файл для установки необходимых файлов GPO, что выглядит следующим образом:

Рисунок 8-28

Устанавливаем файлы Групповой политики PowerShell 7

На Шаге 3 вы создаёте новый GPO, что создаёт такой вывод:

Рисунок 8-29

Получаем и отображаем новый GPO для своей группы ИТ

На Шаге 4 вы настраиваете свой GPO на разрешение регистрации модуля и на Шаге 5 вы настраиваете значения имён модулей для регистрации. На Шаге 6 вы включаете Регистрацию блока сценария (Script Block Logging), а на Шаге 7 вы настраиваете этот GPO на разрешение политики выполнения PowerShell без ограничений. Эти четыре шага не производят вывод.

На Шаге 8 вы назначаете этот GPO для своего Подразделения организации ИТ, что не вырабатывает вывод. На окончательном шаге, Шаге 9, вы создаёте и просматриваете отчёт по результатам множества политик, который выглядит следующим образом:

Рисунок 8-30

Отчёт политик

Есть кое- что ещё...

В этом рецепте вы создали новый GPO, настроили этот объект конкретными значениями политик и затем назначили его своему Подразделению организации ИТ в домене Reskit.Org. Когда некий пользователь из группы ИТ входит в систему, PowerShell выполняет предписанную регистрацию и пользуется политикой исполнения без ограничений. Вы можете наблюдать в своём отчёте RSOP, созданном на Шаге 9, какие установки политики PowerSell применены. Чтобы гарантировать что вы получите чувствительный вывод в своём отчёте RSOP, вам требуется обеспечить что ваш пользователь JerryG зарегистрирован в имеющемся Контроллере домена.

Применение ведения журнала блока сценария PowerShell

В нашем рецепте Развёртывание Групповых политик PowerShell вы увидели как вы можете развёртывать относящиеся к PowerShell 7 политики. Одна из таких политик, Регистрация блока сценария (Script Block Logging), вызывающую генерацию событий PowerShell 7 в журнале, всякий раз когда вы вызываете исполнение некого блока сценария, который заслуживает внимания PowerShell.

Дополнительно к применению Групповой политики для активации Регистрации блока сценария, вы также можете настраивать свой локальный реестр. По существу, это имитирует применение редактора Локальной Групповой политики. Применение такого редактора предоставляет привлекательный интерфейс для ваших политик, однако на практике вы не можете автоматизировать некий графический интерфейс. Когда вы выполняете единственное изменение в единственной политике, тогда такой графический интерфейс может оказаться очень удобным. Однако, если вы вносите изменения или создаёте большое число политик, более продуктивным будет применение некого сценария PowerShell.

Подготовка

Вы выполняете этот рецепт в DC1, контроллере домена в вашем домене Reskit.Org. Вам следует зарегистрироваться в качестве Reskit\Administrator, участнике группы Администраторов домена.

Как это сделать...

Создаём журнал работ PowerShell Core
```
WevtUtil cl 'PowerShellCore/Operational'
		
```

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


$SBLPath = 'HKCU:\Software\Policies\Microsoft\PowerShellCore' +
           '\ScriptBlockLogging'
if (-not (Test-Path $SBLPath))  {
        $null = New-Item $SBLPath -Force
    }
Set-ItemProperty $SBLPath -Name EnableScriptBlockLogging -Value '1'

Изучаем регистрацию события PowerShell Core для событий 4104


Get-Winevent -LogName 'PowerShellCore/Operational' |
  Where-Object Id -eq 4104

Изучаем подробности зарегистрированного события


Get-Winevent -LogName 'PowerShellCore/Operational' |
  Where-Object Id -eq 4104  | 
    Select-Object -First 1 |
      Format-List -Property ID, LogName, Message

Создаём другой блок сценария, который PowerShell не регистрирует


$SBtolog = {Get-CimInstance -Class Win32_ComputerSystem | Out-Null}   
$Before = Get-WinEvent -LogName 'PowerShellCore/Operational'
Invoke-Command -ScriptBlock $SBtolog
$After = Get-WinEvent -LogName 'PowerShellCore/Operational'

Сопоставляем имеющиеся события до и после активации соответствующей команды
```
"Before:  $($Before.Count) events"
"After :  $($After.Count) events"
		
```
Удаляем регистрацию записи политики
```
Remove-Item -Path $SBLPath
		
```

Как это работает...

На Шаге 1 вы пользуетесь консольным приложением wevtutil.exe для очистки рабочего журнала PowerShell Core. На Шаге 2 вы обновляете значение реестра текущего пользователя для разрешения Регистрации блока сценария (для вошедшего в данный момент в систему пользователя Reskit\Administrator) Эти шаги не производят вывод.

На Шаге 3 вы изучаете журнал PowerShell Core для событий 4104 со следующим выводом:

Рисунок 8-31

Изучаем журнал событий PowerShell Core для событий 4104

На Шаге 4 вы просматриваете подробности записи регистрации события, которое вы наблюдали на предыдущем шаге с выводом, подобным следующему:

Рисунок 8-32

Изучаем подробности зарегистрированных событий

На Шаге 5 вы создаёте и исполняете другой блок сценария, который Регистрация блоков сценария не трактует как достаточно важный для его регистрации. Этот шаг создаёт счётчик общего числа записей зарегистрированных событий до и после вызова такого блока сценария. Этот шаг не производит вывод, но на Шаге 6 вы просматриваете значения счётчиков до и после, подобно следующему:

Рисунок 8-33

Сопоставляем события до и после активации команды

На окончательном шаге, Шаге 7 , вы удаляете из своего реестра запись рассмотренной политики, что не создаёт вывод.

Есть кое- что ещё...

На Шаге 1 вы пользуетесь консольным приложением wevtutil.exe для очистки журнала событий. В Windows PowerShell у вас имеется командлет Clear-EventLog, который вы можете применять для очистки некого журнала событий. Этот командлет отсутствует в PowerShell и именно по этой причине вы пользуетесь указанным консольным приложением Win32 для очистки своего журнала.

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

Настройка политик паролей AD

Пароли существенны для безопасности, ибо они помогают гарантировать что некая персона, которая представляется с ним таковой и является и тем самым позволяет выполнять некое действие, такое как вход в хост или изменение файла. Политики паролей делают для нас возможным определение атрибутов ваших паролей, включая минимальную длину и будут ли требоваться сложные пароли. Вы также можете устанавливать число раз, которое некий пользователь может вводить неверный пароль прежде чем такой пользователь блокируется (а также продолжительность для разблокирования). Для получения дополнительных сведений по улучшению безопасности аутентификации обращайтесь к https://www.microsoftpressstore.com/articles/article.aspx?p=2224364&seqNum=2.

В AD вы можете применять установленную по умолчанию политику паролей домена.Эта политика применяется ко всем пользователям в вашем домене. В большинстве случаев это адекватно для вашей организации. Однако в некоторых ситуациях вы можете пожелать применять более сильные политики паролей для определённых пользователей или групп пользователей. Политика "тонкой настройки" это та, которую вы можете применять просто к отдельному пользователю в противоположность применения таковой ко всем пользователям в вашем домене.

Подготовка

Вы выполняете этот рецепт в DC1, контроллере домена вашего домена Reskit.Org. Вам следует зарегистрироваться в качестве Администратора домена.

Как это сделать...

Выясняем текущую политику паролей домена
```
Get-ADDefaultDomainPasswordPolicy
		
```
Выясняем имеется ли тонкая настройка политики паролей для JerryG
```
Get-ADFineGrainedPasswordPolicy -Identity 'JerryG'
		
```

Обновляем установленную по умолчанию политику паролей


$DPWPHT = [Ordered] @{
    LockoutDuration             = '00:45:00' 
    LockoutObservationWindow    = '00:30:00' 
    ComplexityEnabled           = $true
    ReversibleEncryptionEnabled = $false 
    MinPasswordLength           = 6
}
Get-ADDefaultDomainPasswordPolicy -Current LoggedOnUser |
  Set-ADDefaultDomainPasswordPolicy @DPWPHT

Проверяем обновлённую устанавливаемую по умолчанию политику паролей
```
Get-ADDefaultDomainPasswordPolicy
		
```

Создаём политику паролей тонкой настройки


$PD = 'DNS Admins Group Fine-grained Password Policy'
$FGPHT = @{
  Name                     = 'DNSPWP'
  Precedence               = 500 
  ComplexityEnabled        = $true 
  Description              = $PD
  DisplayName              = 'DNS Admins Password Policy'
  LockoutDuration          = '0.12:00:00'
  LockoutObservationWindow = '0.00:15:00'
  LockoutThreshold         = 4
}
New-ADFineGrainedPasswordPolicy @FGPHT

Назначаем такую политику Администраторам DNS


$DNSADmins = Get-ADGroup -Identity DNSAdmins
$ADDHT = @{
  Identity  = 'DNSPWP' 
  Subjects  = $DNSADmins
}
Add-ADFineGrainedPasswordPolicySubject  @ADDHT

Назначаем эту политику для JerryG


$Jerry = Get-ADUser -Identity JerryG
Add-ADFineGrainedPasswordPolicySubject -Identity DNSPWP -Subjects $Jerry

Проверяем применение политики для своей группы


Get-ADGroup 'DNSAdmins' -Properties * | 
  Select-Object -Property msDS-PSOApplied

Проверяем применение политики для отдельного пользователя
```
Get-ADUser JerryG -Properties * | 
  Select-Object -Property msDS-PSOApplied
		
```
Получаем политику Администраторов DNS
```
Get-ADFineGrainedPasswordPolicy -Identity DNSPWP
		
```
Проверяем установленную в результате политику паролей для JerryG
```
Get-ADUserResultantPasswordPolicy -Identity JerryG
		
```

Как это работает...

На Шаге 1 вы делаете выборку установленной по умолчанию политики паролей AD, что выглядит примерно так:

Рисунок 8-34

Выясняем текущую политику паролей домена

На Шаге 2 вы проверяете на предмет наличия тонко настраиваемых политик паролей для вашего пользователя JerryG со следующим выводом:

Рисунок 8-35

Проверяем наличие политик паролей с тонкой настройкой

На Шаге 3 вы обновляете устанавливаемую по умолчанию политику паролей для своего домена, изменяя несколько настроек. Это не производит вывод. На Шаге 4 вы просматриваете свою обновлённую политику паролей по умолчанию, что отображается ниже:

Рисунок 8-36

Проверяем обновление политик паролей по умолчанию

На Шаге 5 вы создаёте новую политику паролей тонкой настройки с некоторыми перекрытиями для вашей устанавливаемой по умолчанию политики паролей, которую мы видели выше. На Шаге 6 вы назначаете эту политику группе Администраторов DNS, а на Шаге 7 вы применяете данную политику в явном виде для своего пользователя JerryG. Эти три шага не производят вывод.

На Шаге 8 вы проверяете применение своей политики для группы Администраторов DNS, что отображается так:

Рисунок 8-37

Проверяем применение установленной политики для группы Администраторов DNS

На Шаге 9 вы проверяете политику паролей, применённую для вашего пользователя JerryG, которая выглядит следующим образом:

Рисунок 8-38

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

На Шаге 10 вы изучаете политику паролей своих Администраторов DNS с подобным выводом:

Рисунок 8-39

Получение политик паролей для Администраторов DNS

На Шаге 11 вы изучаете установленную в результате политику паролей для вашего пользователя JerryG, вот она:

Рисунок 8-40

Проверка установленной в результате для JerryG политики паролей

Есть кое- что ещё...

На Шаге 1 вы просматриваете имеющуюся политику паролей по умолчанию. Те настройки, которые вы наблюдаете на этом шаге, были созданы вашим процессом установки при выпонении установки Windows Server в DC1.

На Шаге 2 вы пытаетесь обнаружить политику паролей с тонкой настройкой, которая была бы применена для вашего пользователя JerryG и которая отсутствует.

На Шаге 5 вы создаёте новую политику паролей с тонкой настройкой, которую назначаете своей группе Администраторов DNS (на Шаге 6) и JerryG (на Шаге 7). Такие настройки гарантируют, что эта политика применяется для JerryG, причём вне зависимости от того является или нет он участником группы Администраторов DNS.

На Шаге 11 вы просматриваете настройки политики паролей для своего пользователя JerryG. Эти настройки проистекают из установленной по умолчанию политики паролей домена плюс те настройки, которые вы предписали в своей политике DNSPWP. Теоретически, вы можете обладать пользователем с действующими настройками политики паролей, поступающих из множества объектов политик (например, одного GPO для вашего домена, одного для Подразделения организации и тому подобного), хотя вам, скорее всего, следует избегать подобных сложностей.

Управление антивирусом Windows Defender

Microsoft Defender Antivirus это компонент защиты Microsoft Defender for Endpoint следующего поколения. Defender Antivirus предоставляет возможности антивируса и средства против вредоносного программного обеспечения (ПО). Этот продукт также выполняет некий анализ пакетов для выявления атак сетевого уровня.

Процесс установки Windows устанавливает по умолчанию Defender как для Windows 10, так и для Windows Server 2022, хотя вы можете удалить этот компонент, если пожелаете. Для получения дополнительных сведений по Defender в Windows Server обращайтесь к https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-antivirus/microsoft-defender-antivirus-on-windows-server-2016.

Тестирование всякого антивирусного и анти вредоносного приложения может быть затруднительным. Вы желаете убедиться что этот продукт, Defender, в данном случае работает. Однако в то же самое время вы не хотите заражать свой сервер. Одним из решений является создание некого тестового файла. Европейский институт компьютерных антивирусных исследований (European Institute for Computer Anti-Virus Research, EICAR) создал простой набор тестовых файлов. которые вы можете применять для гарантии того, что ваш антивирусный продукт работает. EICAR создал различные версии такого файла, включая как текстовый файл, так и исполняемый. Эти файлы безобидны, но, как вы обнаружите, включают Defender.

Подготовка

ВЫ исполняете этот рецепт в DC1, Контроллере домена в вашем домене Reskit.Org.

Как это сделать...

Убеждаемся что Defender и вязанные с ним инструменты установлены


$DHT = @{
  Name                   =  'Windows-Defender' 
  IncludeManagementTools = $true  
}
$Defender = Install-WindowsFeature @DHT
If ($Defender.RestartNeeded -eq 'Yes') {
  Restart-Computer
}

Выявляем имеющиеся командлеты в установленном модуле Defender
```
Import-Module -Name Defender
Get-Command -Module Defender
		
```
Проверяем значение состояния службы Defender
```
Get-Service -Name WinDefend
		
```
Проверяем рабочее состояние Defender в данном хосте
```
Get-MpComputerStatus
		
```

Получаем и подсчитываем каталог угроз


ThreatCatalog = Get-MpThreatCatalog
"There are $($ThreatCatalog.count) threats in the catalog"

Просматриваем пять угроз в имеющемся каталоге


$ThreatCatalog |
  Select-Object -First 5 |
    Format-Table -Property SeverityID, ThreatID, ThreatName

Устанавливаем ключевые настройки


# Enable real-time monitoring
Set-MpPreference -DisableRealtimeMonitoring 0
# Enable Cloud-DeliveredProtection
Set-MpPreference -MAPSReporting Advanced
# Enable sample submission
Set-MpPreference -SubmitSamplesConsent Always
# Enable checking signatures before scanning
Set-MpPreference -CheckForSignaturesBeforeRunningScan 1
# Enable email scanning
Set-MpPreference -DisableEmailScanning 0

Создаём ложноположительную угрозу


$TF = 'C:\Foo\FalsePositive1.Txt'
$FP = <X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-> +
      'STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
$FP | Out-File -FilePath $TF
Get-Content -Path $TF

Выполняем быстрое сканирование в C:\Foo


$ScanType = 'QuickScan'
Start-MpScan -ScanType $ScanType -ScanPath C:\Foo

Просматриваем выявленные угрозы
```
Get-MpThreat
		
```

Как это работает...

На Шаге 1 для того чтобы убедиться что вы установили и Defender и те инструменты, которыми вы можете управлять Defender, вы применяете Install-WindowsFeature. Этот шаг может потребовать перезагрузки. Если такое случится, этот шаг перезапустит DC1 без производства какого бы то ни было вывода.

На Шаге 2 вы взглянете на модуль Defender с целью определения тех командлетов, которые содержатся в этом модуле. Вывод этого шага выглядит как- то так:

Рисунок 8-41

Выявляем имеющиеся в модуле Defender командлеты

На Шаге 3 вы проверяете значение состояния вашей службы WinDefend. Вы должны обнаружить нечто подобное:

Рисунок 8-42

проверяем состояние службы Defender

Для получения состояния Defender в вашем локальном компьютере, на Шаге 4 вы пользуетесь командлетом Get-MpComputerstatus. Его вывод выглядит примерно так:

Рисунок 8-43

Проверяем состояние службы Defender

Defender пользуется подробностями индивидуальных угроз, которые хранятся в неком каталоге угроз. Windows Update постоянно обновляет этот каталог по мере необходимости. На Шаге 5 вы производите подсчёт числа угроз в своём каталоге, что выглядит примерно так:

Рисунок 8-44

Получаем каталог угроз и пересчитываем его

На Шаге 6 вы изучаете самые первые пять угроз из своего каталога угроз Defender, что отображено ниже:

Рисунок 8-45

Просматриваем первые пять угроз в своём каталоге

На Шаге 7 вы настраиваете четыре важных настройки Defender. Для настройки диапазона предпочтительных установок для сканирований Windows Defender и обновлений вы можете применять имеющийся командлет Set-MpPreference. Вы можете изменять исключения расширений названий файлов, путей или процессов и определять действие по умолчанию для высокого, среднего и низкого уровней угроз. С дополнительными подробностями вы можете ознакомиться в https://docs.microsoft.com/powershell/module/defender/set-mppreference.

На Шаге 8 вы пытаетесь создать некий файл, к которому Defender относится как к какой- то угрозе. Этот файл поступает от EICAR и, как вы можете видеть, это доброкачественный текстовый файл. Когда вы выполните этот этап, вы не получите никакого вывода, хотя вы сможете заметить, что Defender выдаст вам всплывающее предупреждение о том, что он обнаружил некую угрозу. Если вы выполните этот шаг в своей консоли PowerShell, вы должны будете получить некое сообщение об ошибке.

На Шаге 9 вы запускаете быстрое сканирование папки C:\Foo, в которой вы попытались создать свой проверочный файл угрозы. Этот шаг не производит вывод.

На Шаге 10 вы просматриваете все выявленные Defender угрозы, что выглядит примерно так:

Рисунок 8-46

Просматриваем все обнаруженные угрозы

Есть кое- что ещё...

На Шаге 5 вы получаете счётчик числа угроз, о которых осведомлён Defender на момент написания этих строк. Когда вы выполните этот шаг, вы должны обнаружить большее значение, что отразит вновь выявленные угрозы.

На Шаге 8 вы пытаетесь создать некий файл, который Defender распознаёт как угрозу. Этот файл является проверочным файлом EICAR, который безвреден, однако вы можете пользоваться им для проверки базовой функциональности Defender. На Шаге 10 вы просматриваете все выявленные угрозы и вы можете видеть, что этот файл идентифицирован как EICAR_Test_File.