Аудит системных событий в windows

Уровень сложностиСредний

Время на прочтение5 мин

Количество просмотров22K

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

В этой статье мы посмотрим, как можно организовать эффективный аудит узлов под управлением ОС Windows, а в следующей статье настроим централизованный сбор событий с нескольких узлов и попробуем с помощью Powershell автоматизировать обработку собранных событий.

Зачем нужно централизованное хранение

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

Да, при очистке лога будет создано событие ‘1102 Журнал аудита был очищен’, но от этого события тоже можно избавиться, просто заполнив лог большим количеством фиктивных событий. 

Так как, обычно EventLog пишется по принципу циклической записи, более старые события удаляются, и их заменяют более новые.

Ну а создать поддельные события можно с помощью того же PowerShell, используя командлет Write-EventLog.

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

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

Эффективный аудит

Мы разобрались с необходимостью централизованного мониторинга событий. Однако, еще необходимо разобраться с тем, какие именно события должны присутствовать в наших логах. С одной стороны в логах должны присутствовать важные события с точки зрения ИБ, а с другой, в нем не должно быть слишком много неинтересных событий, например постоянных обращений к каким-либо файлам или сообщений о запуске каких-либо процессов, не представляющих никакого интереса для ИБ. Таким образом, чтоб нам не потонуть в большом объеме ненужных событий и не потерять что-то действительно важное, нам необходимо грамотно настроить политики аудита.

 Для настройки откроем Политики аудита (Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Также нам потребуются расширенные политики аудита, которые можно открыть здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Отличием политики расширенного аудита является наличие подкатегорий и теперь мы можем управлять аудитом на уровне не только категорий, но и подкатегорий. Если сравнить Политики аудита и Расширенные политики аудита, то можно заметить, что разделы в обычных политиках в свою очередь разделены на подразделы в расширенных политиках, что позволяет нам настраивать более подробные категории аудита. Так, для группы  Вход учётной записи (Account Logon) мы можем настроить четыре проверки -Аудит проверки учётных данных, Аудит службы проверки подлинности Kerberos, Аудит операций с билетами службы Kerberos,   Аудит других событий входа учётных записей.

Для каждого типа аудита мы можем настроить аудит событий успеха или отказа. С событиями успеха нужно быть аккуратными. Так, для того же аудита входов в систему мы рискуем получить большое количество событий успешного входа, которые по факту не будут представлять никакой ценности. Также, не стоит включать в аудите доступа к объектам, аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста). В результате мы снова рискуем получить большое количество ненужных событий. В результате срабатывания настроек политик аудита, в журнале создаются события, каждое из которых имеет собственный код.

Для эффективного аудита нам необходим сбор следующих типов событий: 4624 (Успешный вход в систему), 4647 (Выход из системы), 4625 (Неудачный вход в систему), 4778/4779 (Соединение/разъединение по RDP), 4800/4801 (Блокировка/Разблокировка рабочей станции) и некоторые другие.

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

Посмотрим типы входа в систему:

2 – интерактивный

3 – сетевой (через сетевой диск)

4 – запуск по расписанию

5 – запуск сервиса

7 – разблокировка экрана

8 – сетевой (Basic Authentication в IIS)

10 – подключение по RDP

11 – вход по закешированным учетным данным

В приведенном ниже скриншоте у нас представлен вход в систему при запуске сервиса

И посмотрим, как мы можем узнать причину неудачного входа в систему

0xC0000064   — такого пользователя не существует

0xC000006A   — неверный пароль

0xC0000234   — пользователь заблокирован

0xC0000072   — пользователь отключен

0xC000006F   — пользователь попытался войти в систему вне установленных для него ограничений по дням недели или времени суток

0xC0000070   — ограничение рабочей станции или нарушение изолированной политики аутентификации (найдите идентификатор события 4820 на контроллере домена)

0xC0000193   — срок действия учетной записи истек

0xC0000071   — истек пароль

0xC0000133   — часы между DC и другим компьютером слишком сильно рассинхронизированы

0xC0000224   — пользователю необходимо сменить пароль при следующем входе в систему

0xc000015b    Пользователю не был предоставлен запрошенный тип входа в систему (он же право входа в систему) на этом компьютере

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

На картинке ниже представлен неудачный интерактивный вход в систему, причиной которого стало указание неверного пароля.

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

Заключение

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

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

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

  1. Введение
  2. Знакомство с расширенным аудитом Windows
  3. Настройка политик аудита
  4. Усиление цифровой обороны
  5. Выводы

Введение

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

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

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

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Рисунок 1. Политика аудита

 

Политика аудита

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

 

Конфигурация расширенной политики аудита

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

 

Корреляция аудита и расширенного аудита

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

Категория (Category) Подкатегория (Subcategory)  
Вход учётной записи (Account Logon) Аудит проверки учётных данных (Audit Credential Validation)  
 
Аудит службы проверки подлинности Kerberos (Audit Kerberos Authentication Service)  
Аудит операций с билетами службы Kerberos (Audit Kerberos Service Ticket Operations)  
Аудит других событий входа учётных записей (Audit Other Account Logon Events)  
Управление учётными записями (Account Management) Аудит управления группами приложений (Audit Application Group Management)  
 
Аудит управления учётными записями компьютеров (Audit Computer Account Management)  
Аудит управления группами распространения (Audit Distribution Group Management)  
Аудит других событий управления учётными записями (Audit Other Account Management Events)  
Аудит управления группами безопасности (Audit Security Group Management)  
Аудит управления учётными записями пользователей (Audit User Account Management)  
Подробное отслеживание (Detailed Tracking) Аудит активности DPAPI (Audit DPAPI Activity)  
 
PNP-действие аудита (Audit PNP Activity)  
Аудит создания процессов (Audit Process Creation)  
Аудит завершения процессов (Audit Process Termination)  
Аудит событий RPC (Audit RPC Events)  
Проверка изменений прав маркера (Audit Token Right Adjusted) [Windows 10 / Server 2016 и выше]  
Доступ к службе каталогов DS (DS Access) Аудит подробной репликации службы каталогов (Audit Detailed Directory Service Replication)  
 
Аудит доступа к службе каталогов (Audit Directory Service Access)  
Аудит изменения службы каталогов (Audit Directory Services Changes)  
Аудит репликации службы каталогов (Audit Directory Service Replication)  
Вход / выход (Logon / Logoff) Аудит блокировки учётных записей (Audit Account Lockout)  
 
Аудит заявок пользователей или устройств на доступ (Audit User / Device Claims)  
Аудит расширенного режима IPsec (Audit IPsec Extended Mode)  
Аудит основного режима IPsec (Audit IPsec Main Mode)  
Аудит быстрого режима IPsec (Audit IPsec Quick Mode)  
Аудит выхода из системы (Audit Logoff)  
Аудит входа в систему (Audit Logon)  
Аудит сервера политики сети (Audit Network Policy Server)  
Аудит других событий входа и выхода (Audit Other Logon / Logoff Events)  
Аудит специального входа (Audit Special Logon)  
Доступ к объектам (Object Access) Аудит событий, создаваемых приложениями (Audit Application Generated)  
 
Аудит служб сертификации (Audit Certification Services)  
Аудит сведений об общем файловом ресурсе (Audit Detailed File Share)  
Аудит общего файлового ресурса (Audit File Share)  
Аудит файловой системы (Audit File System)  
Аудит подключения платформы фильтрации (Audit Filtering Platform Connection)  
Аудит отбрасывания пакетов платформой фильтрации (Audit Filtering Platform Packet Drop)  
Аудит работы с дескрипторами (Audit Handle Manipulation)  
Аудит объектов ядра (Audit Kernel Object)  
Аудит других событий доступа к объектам (Audit Other Object Access Events)  
Аудит реестра (Audit Registry)  
Аудит съёмного носителя (Audit Removable Storage)  
Аудит диспетчера учётных записей безопасности (Audit SAM)  
Аудит сверки с централизованной политикой доступа (Audit Central Access Policy Staging)  
Изменение политики (Policy Change) Аудит изменения политики аудита (Audit Policy Change)  
 
Аудит изменения политики проверки подлинности (Audit Authentication Policy Change)  
Аудит изменения политики авторизации (Audit Authorization Policy Change)  
Аудит изменения политики платформы фильтрации (Audit Filtering Platform Policy Change)  
Аудит изменения политики на уровне правил MPSSVC (Audit MPSSVC Rule-Level Policy Change)  
Аудит других событий изменения политики (Audit Other Policy Change Events)  
 
Использование привилегий (Privilege Use) Аудит использования привилегий, не затрагивающих конфиденциальные данные (Audit Non Sensitive Privilege Use)  
 
Аудит других событий использования привилегий (Audit Other Privilege Use Events)  
Аудит использования привилегий, затрагивающих конфиденциальные данные (Audit Sensitive Privilege Use)  
Система (System) Аудит драйвера IPsec (Audit IPsec Driver)  
 
Аудит других системных событий (Audit Other System Events)  
Аудит изменения состояния безопасности (Audit Security State Change)  
Аудит расширения системы безопасности (Audit Security System Extension)  
Аудит целостности системы (Audit System Integrity)  
Аудит доступа к глобальным объектам (Global Object Access Auditing) Файловая система (File system)  
 
Реестр (Registry)  

Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста), которые к тому же лучше отслеживать на специализированном оборудовании, таком как межсетевые экраны, маршрутизаторы, прокси- и DNS-серверы.

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

 

Пример настройки аудита доступа к объектам через подкатегории

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

 

Аудит создания процессов регистрирует успешные события

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Рисунок 6. Вкладка с описанием политики

 

Вкладка с описанием политики

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

 

Настройка SACL

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Рисунок 8. Принудительное переопределение параметров политики аудита

 

Принудительное переопределение параметров политики аудита

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

 

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

Настройка политик аудита

Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

Категория Подкатегория Включить Хост (DC, сервер, АРМ) Категория (успех / отказ)
Account Logon Audit Credential Validation + DC, сервер, АРМ Успех и отказ
Audit Kerberos Authentication Service + DC Успех и отказ
Audit Kerberos Service Ticket Operations + DC Успех и отказ
Audit Other Account Logon Events    
Account Management Audit Application Group Management + DC Успех и отказ
Audit Computer Account Management + DC Успех
Audit Distribution Group Management + DC Успех
Audit Other Account Management Events + DC, сервер, АРМ Успех
Audit Security Group Management + DC, сервер, АРМ Успех
Audit User Account Management + DC, сервер, АРМ Успех и отказ
Detailed Tracking Audit DPAPI Activity + DC, сервер, АРМ Успех и отказ
Audit PNP Activity + DC, сервер, АРМ Успех и отказ
Audit Process Creation + DC, сервер, АРМ Успех
Audit Process Termination    
Audit RPC Events    
Audit Token Right Adjusted    
DS Access Audit Detailed Directory Service Replication + DC Успех и отказ
Audit Directory Service Access + DC Успех и отказ
Audit Directory Services Changes + DC Успех и отказ
Audit Directory Service Replication + DC Успех и отказ
Logon/Logoff Audit Account Lockout + DC, сервер, АРМ Отказ
Audit User / Device Claims    
Audit IPsec Extended Mode    
Audit IPsec Main Mode    
Audit IPsec Quick Mode    
Audit Logoff + DC, сервер, АРМ Успех
Audit Logon + DC, сервер, АРМ Успех и отказ
Audit Network Policy Server    
Audit Other Logon / Logoff Events + DC, сервер, АРМ Успех и отказ
Audit Special Logon + DC, сервер, АРМ Успех
Object Access Audit Application Generated    
Audit Certification Services    
Audit Detailed File Share    
Audit File Share    
Audit File System + DC, сервер, АРМ Успех и отказ
Audit Filtering Platform Connection    
Audit Filtering Platform Packet Drop    
Audit Handle Manipulation    
Audit Kernel Object    
Audit Other Object Access Events + DC, сервер, АРМ Успех и отказ
Audit Registry + DC, сервер, АРМ Успех и отказ
Audit Removable Storage + DC, сервер, АРМ Успех и отказ
Audit SAM    
Audit Central Access Policy Staging    
Policy Change Audit Policy Change + DC, сервер, АРМ Успех
Audit Authentication Policy Change + DC, сервер, АРМ Успех
Audit Authorization Policy Change + DC, сервер, АРМ Успех
Audit Filtering Platform Policy Change    
Audit MPSSVC Rule-Level Policy Change + DC, сервер, АРМ Успех и отказ
Audit Other Policy Change Events    
Privilege Use Audit Non Sensitive Privilege Use + DC, сервер, АРМ Успех и отказ
Audit Other Privilege Use Events    
Audit Sensitive Privilege Use + DC, сервер, АРМ Успех и отказ
System Audit IPsec Driver    
Audit Other System Events + DC, сервер, АРМ Успех и отказ
Audit Security State Change + DC, сервер, АРМ Успех
Audit Security System Extension + DC, сервер, АРМ Успех
Audit System Integrity    
Global Object Access Auditing File system    
Registry    

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

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Рисунок 10. Журналирование командной строки процесса

 

Журналирование командной строки процесса

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Рисунок 11. Путь к аудиту создания процессов

 

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

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов» 

 

Настройка «Включать командную строку в события создания процессов»

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

 

Детектирование mimikatz

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2 SP1
  • Windows 8.1
  • Windows 8
  • Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Рисунок 14. Путь к аудиту Windows PowerShell

 

Путь к аудиту Windows PowerShell

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

 

Включить регистрацию блоков сценариев PowerShell

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

 

Пример регистрируемого события 4104

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

  • журнал «Установка» (Setup) — не менее 10 МБ,
  • журнал «Система» (System) — не менее 50 МБ,
  • журнал «Приложение» (Application) — не менее 50 МБ,
  • журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Рисунок 17. Настройка хранения журналов аудита

 

Настройка хранения журналов аудита

Выводы

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

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

Даже самое современное производство, небольшой офис или крупная компания сталкиваются с проблемой банальной человеческой ошибки. Бухгалтерия, экономический отдел, менеджеры, любые другие сотрудники – многие могут иметь доступ к определенным файлам. Поэтому очень важным является применение аудита Windows для отслеживания деятельности пользователей. Может получиться так, что кто-то из сотрудников удалил очень важный файл или данные, которые включены в общедоступные папки на файловом сервере. В результате плоды труда целой организации могут быть удалены или искажены, а системному администратору придется биться над этой проблемой самостоятельно. Но только не в том случае, если вы закажете услугу аудит Windows.

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

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

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

Включаем Audit на объекты файловой системы в Windows Server 2008 R2

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

Включение аудита на отдельном сервере происходит следующим образом. Следует открыть консоль управления для локальных вариантов Start -> … -> Local Security Policy. После этого развернуть дерево Local Policies, а затем выбрать Audit Policy. В правой части выбирают Audit Object Access, после чего выбирают события доступности к каждому файлу и в папки, которые необходимо фиксировать.

Выбор файлов и папок, доступ к которым будет фиксироваться

После того, как Audit на файловом сервере активирован, подобрать определенные объекты, по отношению к которым будет проводиться аудит доступа. Чтобы выполнить это, следует щелкнуть правой кнопкой и выбрать Свойства. Затем перейти в меню Безопасности (Security) и после этого нажать Advanced. Расширенные настройки безопасности открывают вкладку Аудит. Для настройки требуются права администратора. Чтобы настроить права использования, важно добавить запись в Add и указать имя пользователей. Позже указываются точные настройки, включая вход, создание/изменение или, при удалении файла, другие операции.

После этого в журнале Security (Computer Management -> Events Viewer) будет появляться при каждом входе соответствующая запись. Задачи можно отфильтровать PowerShell — Get-Event Log. Так, на операции с eventid 4660 придется выполнить Get-EventLog security | ?{$_.eventid -eq 4660.

Включаем расширенный аудит файлов и папок на файловых серверах

Аудит Windows Server 2008 R2 лучше проводить на тестовом главном устройстве. Файловый главный компьютер аудит доступа требует управления групповыми папками. Его проверка подразумевает создание нового GPO. Через Конфигурации компьютера необходимо перейти в Параметры безопасности. Там потребуется отрегулировать параметры Журнала и настроить сам аудит. Настраиваемые операции принято делать индивидуально. Обычно хватает 200 Мб, максимальное время хранения до 2 недель, поставить автоматическое сохранение по дням.

Чтобы настроить аудит файлового обслуживающего центра баз данных, потребуется использовать аудит файловой системы. Если выбрать вариант «Об общем файловом ресурсе», то запись будет вестись максимально подробно, и будут записываться любые сведения. Для оптимизации политики важно применить ее к главному аппаратному устройству. Лучше делать это на контроллере домена. Нажимают «Добавить», а в качестве объектов указывают «Компьютеры». Потом проводят контрольную проверку политики, сверяют результаты и уходят на файловый главный обслуживающий центр. Важно убедиться в том, что папка представлена с файловым доступом.

Теперь можно перейти во вкладку безопасности в раздел «Дополнительно». Затем добавляют SACL. Что касается типа, то это может быть Audit доступа к файлам, Audit удаления файлов, аудит изменения файлов – каждый механизм действия зависит от поставленных перед пользователем задач. Важно понимать, что для каждого отдельного предприятия такие задачи могут быть разными и по содержанию, и по объему.

Аудит доступа к файлам на Windows сервере

При удалении файла создаются одинаковые события под номером ID=4663. Причем в теле BodyL появляется запись данных или удаление файла DELETE. При переименовании появляется не одна запись ID=4663, а сразу две. В первом случае происходит удаление, во втором – запись данных. Нельзя обойти вариант сообщения 4660, в котором присутствует имя пользователя и другие служебные данные, в том числе и код дескриптора.

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

Соответственно, берут происходящие события с 4660. У них выделяется два свойства: время (Time) создания и порядковый номер. Позже в переменной $PrevEvent вносят номер операции, где содержатся данные об удаленном файле. Обязательно определяются временные рамки для поиска, при этом их нужно сократить до 2 с (с интервалом +- 1 с). Скорее всего, это дополнительное время (Time) потребуется для создания каждого выполненного задания отдельно.

Соответственно, аудит файлового сервера Windows Server 2008 R2 не записывает данные о временных доках, которые удалены (.*tmp). Не записываются документы блокировок (.*lock) и временные (.*~$*). Аналогично выбираются поля для переменной $BodyL, а после того, как будут найдены задачи, $BodyL записывается в Text файл лог.

Лог для Audit доступа к документам требует такой схемы: 1 файл на месяц с именем (Name), в котором содержится месяц и год. Дело в том, что удаленных элементов намного меньше, чем тех доков, при которых проводится аудит доступа. Именно поэтому вместо того, чтобы проверять каждый лог, открывается лог-файл в любой таблице и просматриваются данные по пользователю или самому содержимому документа.

Можно поделиться своим мнением по этому поводу и посмотреть другие комментарии (20):

….

Настройка аудита файловых серверов: подробная инструкция и шпаргалка (.pdf)

Аудит папки Windows Server 2008 осуществляется очень просто. Нужно открыть Start → Run → eventvwr.msc, далее журнал безопасности Security. Так как в нем присутствуют разные события, совершенно ненужные, то потребуется нажать View → Filter и отфильтровать события

Event Types:   Success Audit;

Event ID:     4663;

а также Category:     Object Access;

Event Source:   Security.

Превратно понимать удаления не нужно. Просто такая функция при операции Аудит Windows XP применима к обычной работе программ. В том числе большинство приложений при запуске сначала формируют временный файл, потом основной, а временный удаляют, когда происходит выход из программы. Бывает и так, что файл и целые папки (иногда – базы данных) удаляются со злым умыслом. Например, уволенный сотрудник решил навредить предприятию и удалить всю информацию. Но восстановить папки не составит труда и для обычного системного администратора. Совсем другое дело, когда можно сказать, когда и кто сделал подобное.

Аудит сетевой папки или аудит сетевых папок (как вам будет удобнее) начинается с настройки. Для этого нужно зайти в Свойства шары, зайти во вкладку безопасности и выделить «Advanced», далее вкладка Audit, где (where) нужно выбрать группу пользователей Everyone. Затем нужно выбрать Edit, и только после этого кликнуть присутствующие флажки как на скрине:

При этом список «Apply onto» должен содержать значение «This folder, subfolders…». А потом, как настройка будет завершена, следует кликнуть ОК.

Аудит Windows Server 2008 подразумевает настройку общей политики. Перед настройкой следует убедиться в том, что учетная запись есть в группе администраторов. Аудит сетевой папки Windows Server 2008 R2 Standart сравним с более ранними версиями. Но при этом сами разработчики советуют использовать расширенные возможности, а не папки или элементов(объектов), хотя с времен 2003 мало что поменялось. Поэтому искать какие-либо актуальные данные вряд ли стоит. Просто потребуется немного времени, чтобы настроить аудит Server 2008 для конкретных задач и в соответствии с теми требованиями, которые предъявляются для определенных бизнес-целей компании

Политики аудита файловой системы Windows позволяют отслеживать все события доступа к определенным файлам и папкам на диске. С помощью политик аудита вы можете выявить события создания, чтения, изменения, удаления файлов и папок на файловой системе NTFS в Windows. Чаще всего аудит файловой используется для контроля доступа и изменений в общих сетевых папках, к которым одновременно могут обращаться несколько пользователей.

Содержание:

  • Включить политику аудита доступа к объектам файловой системы Windows
  • Настройка аудита событий на файлах и папках Windows
  • Просмотр событий аудита доступа к файлам и папкам в Windows

Включить политику аудита доступа к объектам файловой системы Windows

По умолчанию в Windows отключен аудит событий доступа к файлам и папкам. Включить аудит можно с помощью групповой политики. На отдельностоящем сервере для настройки политика аудита используется консоль редактора локальной групповой политики (
gpedit.msc
). Если вам нужно включить аудит сразу на множестве компьютеров в домене AD, используйте консоль управления доменными GPO (
gpmc.msc
).

  1. Откройте редактор GPO и перейдите в раздел Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Object Access;
  2. Откройте политику Audit File System и укажите, что вы хотите сохранять в журнал только успешные события доступа к объектам файловой системы (Configure the following audit events -> Success);
    Включить политику аудита в Windows

  3. Сохраните изменения и обновите настройки локальной групповой политики с помощью команды
    gpupdate /force
    .

Можно включить локальную политику аудита файловой системы из командной строки. Вывести доступные категории аудита:

AuditPol.exe /list /subcategory:*

Включить аудит успешных событий доступа к объектам файловой системы:

AuditPol.exe /set /subcategory:"File System" /success:enable

Вывести настройки категории аудита:

AuditPol.exe /get /category:"Object Access"

AuditPol.exe включить аудит доступа к файловой системе

Настройка аудита событий на файлах и папках Windows

Несмотря на то, что в Windows включена политика аудита доступа к файлам и папкам, фактически событий в Event Viewer еще не попадают. Администратор должен вручную настроить параметры аудита на файлах и папках, которые нужно отслеживать.

К примеру, вы хотите отслеживать события чтения, изменения и создания файлов в каталоге C:\Docs.

  1. Откройте свойства папки и перейдите на вкладку Security -> Advanced -> Auditing;
    Настройка аудита папки в Windows

  2. Нажмите кнопку Add и в поле Principal выберите пользователя или группы, чью события доступа нужно отслеживать. Если нужно отслеживать доступ для всех пользователей, выберите Users (или Everyone, если нужно контролировать доступ системных процессов);
  3. В списке Type укажите, что нужно отслеживать только успешные событий (
    Success
    );
  4. В Applies to можно указать, нужно ли применить аудит для папки, файлов, вложенных объектов (по умолчанию выбрано This folder, subfolders and files);
  5. В списке Advanced permissions выберите только те действия с файлами и папками, которые вы хотите отправлять в журнал аудита. Например: события чтения (List folder/read data) и изменения файлов (Create files or folders / write or append data)
  6. Сохраните настройки аудита.

При настройке политик аудита файловой системы старайтесь включать аудит только для тех папок и файлов, которые вам нужны. Включайте аудит только для тех файлов и событий, который вам нужны. Большое количество объектов аудита файловой системы приводит к значительному росту журнала событий Event Viewer.

Можно включить аудит для каталога с помощью PowerShell:

$Path = "C:\Docs"
$AuditChangesRules = New-Object System.Security.AccessControl.FileSystemAuditRule('BUILTIN\Users', 'Delete,DeleteSubdirectoriesAndFiles', 'none', 'none', 'Success')
$Acl = Get-Acl -Path $Path
$Acl.AddAuditRule($AuditChangesRules)
Set-Acl -Path $Path -AclObject $Acl

Настройки аудита папки можно вывести с помощью PowerShell:

(Get-Acl "C:\Docs\" -Audit).Audit

Чтобы рекурсивно просканировать все каталоги и найти папки, на которых включен аудит файловой системы, воспользуйтесь таким скриптом:

$folders=Get-ChildItem "c:\docs" -Recurse |Where-Object {$_.PSIsContainer}
foreach ($folder in $folders)
{
$auditacl=(Get-Acl $folder.FullName -Audit).audit
if ($auditacl -ne "") {write-host $folder.FullName}
}

Просмотр событий аудита доступа к файлам и папкам в Windows

Теперь, если с файлами в указанной папке выполняются какие-то действия, политика аудита записывает их в Event Viewer. Чтобы просмотреть события:

    1. Запустите консоль Event Viewer (
      eventvwr.msc
      );
    2. Перейдите в раздел Windows Logs -> Security и отфильтруйте лог по источнику:
      Microsoft Windows security auditing
      , Task Category:
      File System
      ;

      Фильтр журнала Event Viewer

      .

    3. Откройте содержимое любого события. Например в событии с EventID 4663 (
      An attempt was made to access an object
      ) содержится информация:О пользователе, который произвел действие над фалйов:
      Subject: Account Name:

      Имя файла:
      Object Name:

      Тип операции (изменение файла в этом случае):
      Accesses: WriteData (or AddFile)

      Событие редактирование файла на файловой системе

Однако из за ограниченных возможностей фильтрации и поиска в событиях Event Viewer, использовать эту консоль для поиска всех операции с определенным файлом довольно неудобно.

Для вывода всех событий, связанных с определенным объектом лучше использовть PowerShell. Следующий PowerShell скрипт выведет все события доступа, связанные с указанным файлом (для получения списка событий исопльзуется производительный командлет Get-WinEvent):

$fileName = "C:\\docs\\13131.txt"
$results = Get-WinEvent -FilterHashtable @{logname='Security'; id=4663,4659} |`
Where-Object { $_.message -match $fileName -and $_.message -notmatch "Account Name:\s*machine$*"}`
foreach ($result in $results) {
    $Account = $result.properties[1].Value
    $objectName = $result.properties[6].Value
    $accessMask = $result.properties[8].Value
    if ( $accessMask -like "*00000000-*") { $accessMask=$result.properties[9].Value}  
    $accessMask2 = $result.properties[9].Value
        $fileOperation = ""
        switch -Wildcard ($accessMask) {
            "*%%1538*" { $fileOperation = "READ_CONTROL" }
            "*%%4416*" { $fileOperation = "ReadData (or ListDirectory)" }
            "*%%4417*" { $fileOperation = "WriteData (or AddFile)" }
            "*%%4418*" { $fileOperation = "AppendData (or AddSubdirectory or CreatePipeInstance)" }
            "*%%4419*" { $fileOperation = "ReadEA" }
            "*%%4420*" { $fileOperation = "WriteEA" }
            "*%%4423*" { $fileOperation = "ReadAttributes" }
            "*%%4424*" { $fileOperation = "WriteAttributes" }
            "*%%4426*" { $fileOperation = "Delete" }
            "*%%4428*" { $fileOperation = "ReadControl" }
            "*%%4429*" { $fileOperation = "WriteDAC" }
            "*%%4430*" { $fileOperation = "WriteOwner" }
            "*%%4432*" { $fileOperation = "Synchronize" }
            "*%%4433*" { $fileOperation = "AccessSystemSecurity" }
            "*%%4434*" { $fileOperation = "MaximumAllowed" }
            "*%%4436*" { $fileOperation = "GenericAll" }
            "*%%4437*" { $fileOperation = "GenericExecute" }
            "*%%4438*" { $fileOperation = "GenericWrite" }
            "*%%4439*" { $fileOperation = "GenericRead" }
            "*%%1537*" { $fileOperation = "DELETE" }
            default { $fileOperation = "Unknown" }
        }
        Write-Host   $result.Id  $result.TimeCreated  $Account $objectName $fileOperation  
} 

PowerShell скрипт для поиска всех действий с файлом в журнале аудита

Вы можете отправлять собранные события аудита в вашу систему сбора логов, базу данных, текстовый лог файл или отправлять email уведомление через Send-MailMessage при доступе/модификации отслеживаемого файла.

Локальная политика безопасности Windows 10

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

Политика аудита

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

Для запуска введите его название в строке поиска.

Как открыть локальную политику безопасности

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

События входа и выхода

Например, в категории «аудит входа в систему» можно включить фиксацию успешных или неудачных попыток входа в систему.

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

Аудит входа в систему

Проверим, как это работает.  Я включу оба типа событий.

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

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

Я ввел несколько раз неправильный пароль, пытаясь зайти под одной учетной записью, а затем зашел под своей учетной записью.

Для просмотра событий нужно открыть приложение просмотр событий.

Затем выбрать пункт меню журналы Windows –> Безопасность. В журнале будут отображены неудачные и удачные попытки входа в систему.

Приложение просмотр событий в Windows

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

Неудачные попытки входа в систему

Существуют следующие типы входов операционную систему Windows.

Тип Название Описание
0 Системный (System) Используется только учетной записью System, например при запуске системы.
2 Интерактивный (Interactive) Локальный вход пользователя на компьютер.
3 Сетевой (Network) Пользователь вошёл на данный компьютер через сеть.
4 Пакетный (Batch) Пакетный тип входа используется пакетными серверами
5 Служба (Service) Служба запущена Service Control Manager.
7 Разблокирование (Unlock) Эта рабочая станция разблокирована
8 Сетевой ввод пароля (NetworkCleartext) Пользователь вошёл на данный компьютер через сеть. Пароль пользователя передан в нехэшированной форме.
9 Новые полномочия (NewCredentials) Посетитель клонировал свой

текущий маркер и указал новые учётные записи для исходящих соединений

10 Удаленный интерактив (RemoteInteractive) Пользователь выполнил удалённый вход на этот компьютер, используя

службу терминалов или удаленный рабочий стол.

11 Кешированный интерактив (CachedInteractive) Пользователь вошёл на этот

компьютер с сетевыми учётными данными, которые хранились локально на компьютере.

12 Кешированный удаленный интерактив (CachedRemoteInteractive) Метод используется для внутреннего аудита, аналогичен типу 11.

События администрирования

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

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

Для примера я включил оба типа событий.

Аудит управления учетными записями в Windows

Затем я изменил тип учетной записи – сделал пользователя администратором.

Изменение учетной записи пользователя

В журнале безопасности появилась соответствующая запись.

Журнал безопасности Windows: аудит учетных записей

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

Аудит изменения политики

Данный параметр фиксирует события связанные с изменением политик аудита. Разберемся на примере. Я включил оба типа событий.

Аудит изменения политики

После чего я добавил пользователя Local use в свойства прав архивация файлов и каталогов.

Событие: назначение прав на архивацию файлов и каталогов

Теперь в журнале безопасности мы видим соответствующую запись об изменении прав пользователя.

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

Аудит использования привилегий

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

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

Измените системное время.

Изменение системного времени в Windows 10

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

Событие безопасности: изменение системного времени

Аудит событий операционной системы

Для аудита событий происходящих с операционной системой (например, отключение элементов безопасности системы) предназначен параметр аудит системных событий.

Я включу аудит событий с типом успех. Затем очищу журнал аудита событий.

Очистка журнала событий безопасности

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

Свойство события очистка журнала

Аудит доступа пользователя к объектам

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

Я включу аудит двух типов событий.

Этот вид аудита в операционной системе Windows доступен только для файловой системы NTFS. При этом аудит доступен, если включить его в самом объекте.

Аудит безопасности файлов

Для примера я создам текстовый фал. Для настройки нужно перейти в его свойства -> безопасность -> дополнительно -> аудит. Далее следует добавить субъект и разрешения.

Тип события: чтение и выполнение файла

Я установил тип успех на чтение и выполнение этого файла.

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

Управление журналом аудита

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

Ошибка доступа к журналу безопасности Windows

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

Добавить пользователя в журнал безопасности

При необходимости администратор может настроить вид журнала безопасности для определенного пользователя. Делается это с помощью меню фильтр текущего журнала.

Фильтр текущего журнала безопасности

На этом короткое руководство по аудиту событий безопасности в операционной системе Windows закончено.

Если у вас возникли вопросы – задавайте их в комментариях к данной заметке.

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Windows server 2016 set
  • Hp smart windows 4pda
  • Тема для windows 10 fallout 4
  • Назначение программных средств windows
  • Как поменять шрифт на ноутбуке windows 11