Аудит безопасности в ОС Windows

Журнал аудита содержится в файле windows System32 Config secevent.evt, а доступ к нему осуществляется с помощью административной функции «Просмотр событий» Панели управления Windows.

o Вход пользователей в систему;

o доступ субъектов к объектам;

o доступ к службе каталогов Active Directory;

o изменение политики безопасности;

o использование привилегий;

o отслеживание процессов;

o системные события;

o попытки входа в систему;

o управление учетными записями пользователей и групп;

o доступ к глобальным системным объектам;

o использование прав на архивацию и восстановление объектов.

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

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

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

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

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

o перезагрузка операционной системы;

o завершение работы операционной системы;

o загрузка пакета аутентификации;

o запуск процесса входа (Winlogon);

o сбой при регистрации события в журнале аудита;

o очистка журнала аудита;

o загрузка пакета оповещения об изменении в списке пользователей.

Другие параметры аудита

o Максимальный размер журнала аудита.

o Реакция операционной системы на его переполнение:

n затирать старые события при необходимости;

n затирать старые события, которые произошли ранее установленного количества дней (в этом случае новые события не регистрируются, пока не истечет заданное количество дней с момента регистрации самого старого события) − реакция по умолчанию;

n не затирать события (очистка журнала вручную).

Аудит событий безопасности в ОС Unix

Системные журналы в Unix-системах сохраняются в каталогах /usr/adm (старые версии), /var/adm (более современные версии) или /var/log (некоторые версии Solaris, Linux и др.) в файлах:

o acct – регистрация команд, выполненных пользователем;

o loginlog – регистрация неудачных попыток входа;

o sulog – регистрация использования команды su;

o wtmp – регистрация входов и выходов пользователей, загрузки и завершения работы ОС;

o security – сообщения подсистемы безопасности;

o vold.log – регистрация ошибок внешних устройств и др.

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

– В других Unix-системах каждый файл системного журнала из каталога /var/log обновляется в соответствии со своим набором правил.

– Многие Unix-системы имеют средства централизованного сбора информации о событиях (сообщениях) безопасности (сервис syslog).

Сообщение аудита в ОС Unix:

o дата и время генерации сообщения;

o имя компьютера;

o имя программы, при выполнении которой было сгенерировано сообщение;

o источник сообщения (модуль операционной системы);

o приоритет (важность) сообщения;

o содержание сообщения.

Параметры аудита в ОС Unix:

Каждая строка конфигурационного файла /etc/syslog.conf состоит из двух частей, разделяемых символом табуляции:

o селектора, в котором указываются приоритеты и источники регистрируемых сообщений (например, все сообщения об ошибках или все отладочные сообщения ядра системы);

o описания действия, которое должно быть выполнено при поступлении сообщения указанного типа (например, записать в системный журнал или отослать на терминал указанного пользователя).

Пример параметра аудита:

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

Просмотр файлов аудита:

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Только сон приблежает студента к концу лекции. А чужой храп его отдаляет. 8828 – | 7536 – или читать все.

78.85.5.224 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)
очень нужно

Аудит -очень важный элемент системы безопасности, позволяющий регистрировать в специальных журналах события, связанные с действиями пользователей в системе. ОС Windows поддерживают систему аудита, позволяющую выбрать типы отслеживаемых событий и регистрировать их в системных журналах. Основной инструмент аудита в Windows – утилита Event Viewer (Просмотр событий). Запуск этой утилиты осуществляется из папки Administrative Tools (Администрирование) [16].

Рис.6.3. Внешний вид утилиты Event Viewer (Просмотр событий) Windows

Windows записывает события в три журнала:

• Системный журнал – (system log) содержит сообщения об ошибках, предупреждения и другую информацию, исходящую от операционной системы и компонентов сторонних производителей. Список событий, регистрируемых в этом журнале, предопределен операционной системой и компонентами сторонних производителей и не может быть изменен пользователем. Журнал находится в файле Sysevent.evt .
• Журнал безопасности – (Security Log) содержит информацию об успешных и неудачных попытках выполнения действий, регистрируемых средствами аудита. События, регистрируемые в этом журнале, определяются заданной администратором стратегией аудита. Журнал находится в файле Secevent.evt .
• Журнал приложений – (Application Log) содержит сообщения об ошибках, предупреждения и другую информацию, выдаваемую различными приложениями. Список событий, регистрируемых в этом журнале, определяется разработчиками приложений. Журнал находится в файле Appevent.evt .

Все журналы размещены в папке %Systemroot%System32Config .

При выборе событий для проведения аудита следует учитывать возможность переполнения журнала. Для настройки каждого журнала можно использовать диалоговое окно Event Log Settings (Свойства журнала, рис. 6.4)

С помощью этого окна можно управлять:

• размером архивируемых журналов (размер по умолчанию – 512 Кбайт, можно изменить размер от 64 до 4 194 240 Кбайт.);
• методикой замещения устаревших записей журнала:

Затирать старые события по необходимости – в случае заполнения журнала при записи новых событий операционная система удаляет самые старые события;

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

Не затирать события – в случае заполнения журнала новые события не фиксируются. Очистка журнала производится вручную.

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

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

Администратор имеет возможность определять набор подлежащих аудиту событий. В WindowsХЗ это осуществляется в оснастке Политика аудита консоли Локальная политика безопасности Основные события, которые могут регистрироваться:

• Аудит событий входа в систему – Определяет, подлежит ли аудиту каждая попытка пользователя войти в систему или выйти из нее на другом компьютере, при условии, что данный компьютер используется для проверки подлинности учетной записи;
• Аудит управления учетными записями – определяет, подлежат ли аудиту все события, связанные с управлением учетными записями на компьютере;
• Аудит доступа к службе каталогов – определяет, подлежит ли аудиту событие доступа пользователя к объекту каталога Active Directory, для которого задана собственная системная таблица управления доступом (SACL);
• Аудит входа в систему – определяет, подлежит ли аудиту каждая попытка пользователя войти в систему или выйти из нее на данном компьютере, или подключиться к нему через сеть;
• Аудит доступа к объектам – определяет, подлежит ли аудиту событие попытки доступа пользователя к объекту (например, к файлу, папке, разделу реестра, принтеру и т.д.), для которого указан собственный список контроля системного доступа (SACL);
• Аудит изменения политики – определяет, подлежит ли аудиту каждый факт изменения политик назначения прав пользователей, политик аудита или политик доверительных отношений;
• Аудит использования привилегий – определяет, подлежит ли аудиту каждая попытка пользователя воспользоваться предоставленным ему правом;
• Аудит отслеживания процессов – определяет, подлежат ли аудиту такие события, как активизация программы, завершение процесса, повторение дескрипторов и косвенный доступ к объекту;
• Аудит системных событий – определяет, подлежат ли аудиту события перезагрузки или отключения компьютера, а также события, влияющие на системную безопасность или на журнал безопасности.

Настройка аудита доступа пользователей к тому или иному файлу или папке осуществляется в окне свойств этого объекта, закладка Безопасность-> Дополнительно-> Аудит. С помощью оконного интерфейса здесь можно определить события, связанные с файлом или папкой, возникновение которых должно отражаться в журнале системы. Список возможных событий отображен на рис. 6.5.

Рис.6.5. Определение событий, связанных с файлом, подлежащих аудиту

Журнал безопасности содержится в файле vindovs 5у51еш32СопГщ8есеуеп1.еу1, а доступ к нему осуществляется с помощью функции «Просмотр событий» панели управления yindows. На рис. 2.15 приведен пример просмотра одной записи журнала безопасности.

Значения параметров политики аудита могут быть заданы в окне задания значений параметров локальной политики безопасности (рис. 2.16), в специальном окне определения значений параметров аудита (рис. 2.17) и в окне свойств самого журнала аудита событий безопасности при его просмотре (рис. 2.18).

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

• • входа в систему;
• • доступа к объектам;
• • доступа к службе каталогов;

Рис. 2.15. Просмотр записи аудита

Рис. 2.16. Определение параметров безопасности

Рис. 2.17. Определение параметров аудита

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

Рис. 2.18. Свойства журнала безопасности

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

Для каждой категории регистрируемых событий администратор может указать тип события (успешное и (или) неудачное завершение) либо отменить его регистрацию в журнале аудита. Заметим, что при аудите использования привилегий регистрируются попытки использования не всех возможных привилегий, а лишь тех, которые считаются потенциально опасными с точки зрения разработчиков подсистемы безопасности Vindows (например, создание маркерного объекта или создание журналов безопасности). Следует отметить, что не все объективно опасные привилегии входят в этот список.

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

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

В операционной системе Windows Vista и старше к числу параметров аудита (см. рис. 2.17) добавлен параметр «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (ОС Windows Vista или более поздние версии)». ОС Windows Vista и более поздние версии Windows позволяют точнее управлять политикой аудита при помощи подкатегорий политики аудита. Установка политики аудита на уровне категории переопределит новую функцию политики аудита подкатегории. Существующие категории параметров аудита сохранились, но разбиты на подкатегории, каждую из которых можно активизировать для регистрации удачного и/или неудачного события.

Например, категория «Аудит доступа к объектам» включает в себя следующие подкатегории:

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

Категория «Аудит входа в систему» включает следующие подкатегории:

• • аудит входа в систему;
• • аудит выхода из системы;
• • аудит блокировки учетной записи;
• • аудит основного режима IPsec;
• • аудит быстрого режима IPsec;
• • аудит расширенного режима IPsec;
• • аудит специального входа;
• • аудит других событий входа и выхода;
• • аудит сервера сетевых политик.

В ОС Windows 7 и старше расширенные политики аудита можно настроить и развернуть с помощью групповой политики домена или с помощью утилиты командной строки auditpol.

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

• • переписывать события при необходимости (сначала старые события);
• • архивировать журнал при заполнении, не перезаписывать события;
• • не переписывать события (очистить журнал вручную).

При выборе одного из двух последних вариантов реакции и

возникновении ситуации переполнения журнала аудита используется значение параметра безопасности «Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности». Если этот параметр включен, то перезагрузка операционной системы становится невозможной для всех пользователей, кроме администратора. Он должен будет очистить журнал аудита, восстановить значение параметра реакции системы на переполнение журнала аудита и перезагрузить операционную систему. Если эти действия не будут выполнены, регистрация новых событий в журнале аудита станет невозможной.

Для регистрации попыток доступа субъекта к объекту в дескрипторе безопасности объекта предусмотрен системный список контроля доступа SACL (см. парагр. 2.3), содержимое которого формируется администратором системы (рис. 2.19). Элементы АСЕ списка SACL имеют один и тот же тип SYSTEM_ AUDIT_ACE и содержат заголовок АСЕ, маску регистрируемых в журнале аудита прав доступа и SID пользователя или группы, чьи попытки доступа к объекту должны регистрироваться (если в АСЕ не указан SID, то регистрируются попытки доступа к объекту всех пользователей). Еще один тип элементов АСЕ списка SACL — SYSTEM ALARM ACE — зарезервирован для дальнейшего использования.

В заголовке АСЕ списка SACL могут использоваться два дополнительных флага — FAILED ACCESS ACE FLAG (будут регистрироваться неудачные попытки получения доступа к объекту) и SUCCESSFUL_ACCESS_ACE_FLAG (будут регистрироваться успешные попытки получить доступ к объекту).

Существует специальное право доступа к объекту ACCESS_ SYSTEM SECURITY, в соответствии с которым субъект может

Рис. 2.19. Редактирование системного списка управления доступом

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

Добавление записей в журнал аудита производится с помощью вызовов системных функций из набора Windows API: ObjectOpenAuditAlarm (генерация события аудита при попытке открытия или создания нового объекта), ObjectCloseAuditAlarm (генерация события аудита при закрытии объекта), Object- DeleteAuditAlarm (генерация события аудита при удалении объекта), ObjectPrivilegeAuditAlarm (генерация события аудита при попытке субъекта применить привилегии при доступе к уже открытому объекту), PrivilegedServiceAuditAlarm (генерация события аудита при попытке использования субъектом привилегий), AccessCheckAndAuditAlarm (проверка прав доступа к объекту с регистрацией соответствующего события аудита) и др.

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

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

• • попытки входа, вход и выход пользователей;
• • доступ к объектам с конфиденциальной информацией со стороны пользователей, в отношении которых имеются обоснованные подозрения о попытках несанкционированного доступа;
• • изменения в списке зарегистрированных пользователей и политике безопасности КС;
• • запуск и завершение процессов при наличии обоснованных подозрений о заражении системных программ вредоносным кодом.

По умолчанию в серверных операционных системах Windows, начиная с Windows Server 2003, на контроллерах домена включен аудит всех событий, кроме доступа к объектам и использования привилегий, а на остальных серверах — только событий входа.

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

• 1) создать группу «Аудиторы» (см. парагр. 2.2) и включить в ее состав пользователей с соответствующими правами;
• 2) назначить владельцем файла аудита одного из членов группы аудиторов (см. парагр. 2.3);
• 3) разрешить полный доступ к файлу аудита членам группы «Аудиторы» и полный доступ псевдопользователю System, а всем другим пользователям доступ запретить;
• 4) назначить группе «Аудиторы» право управления аудитом и журналом безопасности, отменив использование этого права для членов группы «Администраторы»;
• 5) исключить свою учетную запись из состава группы «Администраторы».

После этого просматривать и очищать журнал аудита, а также управлять списками 8АСХ объектов доступа смогут только члены группы аудиторов КС. Полномочия на изменение значений параметров политики аудита при этом сохранятся у членов группы администраторов КС.

К недостаткам подсистемы аудита операционной системы Vindows следует отнести следующие:

• • защита от несанкционированного доступа к файлу аудита обеспечивается только средствами разграничения доступа без применения шифрования;
• • отсутствуют простые средства разделения полномочий администраторов и аудиторов КС;
• • некоторые важные события безопасности (например, запуск драйвера устройства) не могут регистрироваться в журнале аудита;
• • объекты КС, которые недоступны для стандартных программ администрирования (см. парагр. 2.3), имеют 8АСЦ что приводит к регистрации в файле аудита излишних событий.

В дополнение к средствам аудита в операционной системе Vindows для анализа защищенности могут применяться оснастки «Шаблоны безопасности» и «Анализ и настройка безопасности». С помощью оснастки «Шаблоны безопасности» (рис. 2.20) создаются наборы значений параметров безопасности, которые в дальнейшем могут быть использованы при анализе или настройке политики безопасности конкретного компьютера.

Рис. 2.20. Предопределенные шаблоны безопасности

Определены несколько предопределенных шаблонов безопасности:

• • шаблон SETUP SECURITY содержит используемые по умолчанию параметры безопасности;
• • шаблон COMPATWS ослабляет используемые по умолчанию разрешения доступа группы «Пользователи» к файлам и реестру таким образом, чтобы это соответствовало требованиям большинства несертифицированных приложений. Обычно следует использовать группу «Опытные пользователи» для работы с несертифицированными приложениями;
• • шаблон SECUREWS предоставляет расширенные политики для управления локальными учетными записями, ограничивает использование проверки подлинности LanManager, включает подписывание сообщений протокола SMB со стороны сервера, накладывает дальнейшие ограничения для анонимных пользователей. Для применения к входящим в домен компьютерам все контроллеры домена, хранящие учетные записи всех пользователей, которые могут выполнить вход на этот клиентский компьютер, должны работать под управлением Windows NT4 SP4 или более поздних систем;
• • шаблон HISECWS содержит охватывающий набор для SECUREWC. Накладывают дальнейшие ограничения на проверку подлинности LanManager и новые требования для шифрования и подписывания данных, передаваемых по безопасным каналам, и данных SMB. Чтобы применить HISECWC к входящим в домен компьютерам, все контроллеры домена, хранящие учетные записи всех пользователей, которые могут выполнить вход на этот клиентский компьютер, должны работать под управлением Windows NT4 SP4 или более поздних систем;
• • шаблон ROOTSEC обеспечивает применение стандартных корневых разрешений для раздела операционной системы и распространение их на дочерние объекты, наследующие разрешения от корня. Время распространения зависит от количества незащищенных дочерних объектов;
• • шаблон SECUREDC предоставляет расширенные политики для управления учетными записями в домене, ограничивает использование проверки подлинности LanManager, накладывает дальнейшие ограничения для анонимных пользователей. Если контроллер домена использует securedc, то пользователь с учетной записью в этом домене не сможет подключаться к рядовым серверам только с помощью клиента Lan Manager;
• • шаблон HISECDC содержит охватывающий набор для SECUREDC. Накладывает дальнейшие ограничения на проверку подлинности LanManager и новые требования для шифрования и подписывания данных, передаваемых по

Рис. 2.21. Результат анализа безопасности компьютера

Рис. 2.22. Просмотр журнала с результатами анализа безопасности безопасным каналам, и данных SMB. Чтобы применить HISECDC к контроллеру домена, все другие контроллеры в доверенных и доверяющих доменах должны работать под управлением Windows 2000 или более поздних систем.

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

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

Результаты анализа безопасности помещаются также в текстовый файл журнала с расширением log, который по умолчанию находится в папке SecurityLogs, находящейся в папке «Мои документы» профиля пользователя, проводившего анализ. Этот журнал можно также просмотреть с помощью оснастки «Анализ и настройка безопасности» (рис. 2.22).

Аудит безопасности в ОС Windows

Журнал аудита содержится в файле windows System32 Config secevent.evt, а доступ к нему осуществляется с помощью административной функции «Просмотр событий» Панели управления Windows.

o Вход пользователей в систему;

o доступ субъектов к объектам;

o доступ к службе каталогов Active Directory;

o изменение политики безопасности;

o использование привилегий;

o отслеживание процессов;

o системные события;

o попытки входа в систему;

o управление учетными записями пользователей и групп;

o доступ к глобальным системным объектам;

o использование прав на архивацию и восстановление объектов.

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

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

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

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

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

o перезагрузка операционной системы;

o завершение работы операционной системы;

o загрузка пакета аутентификации;

o запуск процесса входа (Winlogon);

o сбой при регистрации события в журнале аудита;

o очистка журнала аудита;

o загрузка пакета оповещения об изменении в списке пользователей.

Другие параметры аудита

o Максимальный размер журнала аудита.

o Реакция операционной системы на его переполнение:

n затирать старые события при необходимости;

n затирать старые события, которые произошли ранее установленного количества дней (в этом случае новые события не регистрируются, пока не истечет заданное количество дней с момента регистрации самого старого события) − реакция по умолчанию;

n не затирать события (очистка журнала вручную).

Аудит событий безопасности в ОС Unix

Системные журналы в Unix-системах сохраняются в каталогах /usr/adm (старые версии), /var/adm (более современные версии) или /var/log (некоторые версии Solaris, Linux и др.) в файлах:

o acct – регистрация команд, выполненных пользователем;

o loginlog – регистрация неудачных попыток входа;

o sulog – регистрация использования команды su;

o wtmp – регистрация входов и выходов пользователей, загрузки и завершения работы ОС;

o security – сообщения подсистемы безопасности;

o vold.log – регистрация ошибок внешних устройств и др.

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

– В других Unix-системах каждый файл системного журнала из каталога /var/log обновляется в соответствии со своим набором правил.

– Многие Unix-системы имеют средства централизованного сбора информации о событиях (сообщениях) безопасности (сервис syslog).

Сообщение аудита в ОС Unix:

o дата и время генерации сообщения;

o имя компьютера;

o имя программы, при выполнении которой было сгенерировано сообщение;

o источник сообщения (модуль операционной системы);

o приоритет (важность) сообщения;

o содержание сообщения.

Параметры аудита в ОС Unix:

Каждая строка конфигурационного файла /etc/syslog.conf состоит из двух частей, разделяемых символом табуляции:

o селектора, в котором указываются приоритеты и источники регистрируемых сообщений (например, все сообщения об ошибках или все отладочные сообщения ядра системы);

o описания действия, которое должно быть выполнено при поступлении сообщения указанного типа (например, записать в системный журнал или отослать на терминал указанного пользователя).

Пример параметра аудита:

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

Просмотр файлов аудита:

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Только сон приблежает студента к концу лекции. А чужой храп его отдаляет. 8828 – | 7536 – или читать все.

78.85.5.224 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)
очень нужно

Аудит -очень важный элемент системы безопасности, позволяющий регистрировать в специальных журналах события, связанные с действиями пользователей в системе. ОС Windows поддерживают систему аудита, позволяющую выбрать типы отслеживаемых событий и регистрировать их в системных журналах. Основной инструмент аудита в Windows – утилита Event Viewer (Просмотр событий). Запуск этой утилиты осуществляется из папки Administrative Tools (Администрирование) [16].

Рис.6.3. Внешний вид утилиты Event Viewer (Просмотр событий) Windows

Windows записывает события в три журнала:

• Системный журнал – (system log) содержит сообщения об ошибках, предупреждения и другую информацию, исходящую от операционной системы и компонентов сторонних производителей. Список событий, регистрируемых в этом журнале, предопределен операционной системой и компонентами сторонних производителей и не может быть изменен пользователем. Журнал находится в файле Sysevent.evt .
• Журнал безопасности – (Security Log) содержит информацию об успешных и неудачных попытках выполнения действий, регистрируемых средствами аудита. События, регистрируемые в этом журнале, определяются заданной администратором стратегией аудита. Журнал находится в файле Secevent.evt .
• Журнал приложений – (Application Log) содержит сообщения об ошибках, предупреждения и другую информацию, выдаваемую различными приложениями. Список событий, регистрируемых в этом журнале, определяется разработчиками приложений. Журнал находится в файле Appevent.evt .

Все журналы размещены в папке %Systemroot%System32Config .

При выборе событий для проведения аудита следует учитывать возможность переполнения журнала. Для настройки каждого журнала можно использовать диалоговое окно Event Log Settings (Свойства журнала, рис. 6.4)

С помощью этого окна можно управлять:

• размером архивируемых журналов (размер по умолчанию – 512 Кбайт, можно изменить размер от 64 до 4 194 240 Кбайт.);
• методикой замещения устаревших записей журнала:

Затирать старые события по необходимости – в случае заполнения журнала при записи новых событий операционная система удаляет самые старые события;

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

Не затирать события – в случае заполнения журнала новые события не фиксируются. Очистка журнала производится вручную.

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

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

Администратор имеет возможность определять набор подлежащих аудиту событий. В WindowsХЗ это осуществляется в оснастке Политика аудита консоли Локальная политика безопасности Основные события, которые могут регистрироваться:

• Аудит событий входа в систему – Определяет, подлежит ли аудиту каждая попытка пользователя войти в систему или выйти из нее на другом компьютере, при условии, что данный компьютер используется для проверки подлинности учетной записи;
• Аудит управления учетными записями – определяет, подлежат ли аудиту все события, связанные с управлением учетными записями на компьютере;
• Аудит доступа к службе каталогов – определяет, подлежит ли аудиту событие доступа пользователя к объекту каталога Active Directory, для которого задана собственная системная таблица управления доступом (SACL);
• Аудит входа в систему – определяет, подлежит ли аудиту каждая попытка пользователя войти в систему или выйти из нее на данном компьютере, или подключиться к нему через сеть;
• Аудит доступа к объектам – определяет, подлежит ли аудиту событие попытки доступа пользователя к объекту (например, к файлу, папке, разделу реестра, принтеру и т.д.), для которого указан собственный список контроля системного доступа (SACL);
• Аудит изменения политики – определяет, подлежит ли аудиту каждый факт изменения политик назначения прав пользователей, политик аудита или политик доверительных отношений;
• Аудит использования привилегий – определяет, подлежит ли аудиту каждая попытка пользователя воспользоваться предоставленным ему правом;
• Аудит отслеживания процессов – определяет, подлежат ли аудиту такие события, как активизация программы, завершение процесса, повторение дескрипторов и косвенный доступ к объекту;
• Аудит системных событий – определяет, подлежат ли аудиту события перезагрузки или отключения компьютера, а также события, влияющие на системную безопасность или на журнал безопасности.

Настройка аудита доступа пользователей к тому или иному файлу или папке осуществляется в окне свойств этого объекта, закладка Безопасность-> Дополнительно-> Аудит. С помощью оконного интерфейса здесь можно определить события, связанные с файлом или папкой, возникновение которых должно отражаться в журнале системы. Список возможных событий отображен на рис. 6.5.

Рис.6.5. Определение событий, связанных с файлом, подлежащих аудиту

Журнал безопасности содержится в файле vindovs 5у51еш32СопГщ8есеуеп1.еу1, а доступ к нему осуществляется с помощью функции «Просмотр событий» панели управления yindows. На рис. 2.15 приведен пример просмотра одной записи журнала безопасности.

Значения параметров политики аудита могут быть заданы в окне задания значений параметров локальной политики безопасности (рис. 2.16), в специальном окне определения значений параметров аудита (рис. 2.17) и в окне свойств самого журнала аудита событий безопасности при его просмотре (рис. 2.18).

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

• • входа в систему;
• • доступа к объектам;
• • доступа к службе каталогов;

Рис. 2.15. Просмотр записи аудита

Рис. 2.16. Определение параметров безопасности

Рис. 2.17. Определение параметров аудита

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

Рис. 2.18. Свойства журнала безопасности

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

Для каждой категории регистрируемых событий администратор может указать тип события (успешное и (или) неудачное завершение) либо отменить его регистрацию в журнале аудита. Заметим, что при аудите использования привилегий регистрируются попытки использования не всех возможных привилегий, а лишь тех, которые считаются потенциально опасными с точки зрения разработчиков подсистемы безопасности Vindows (например, создание маркерного объекта или создание журналов безопасности). Следует отметить, что не все объективно опасные привилегии входят в этот список.

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

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

В операционной системе Windows Vista и старше к числу параметров аудита (см. рис. 2.17) добавлен параметр «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (ОС Windows Vista или более поздние версии)». ОС Windows Vista и более поздние версии Windows позволяют точнее управлять политикой аудита при помощи подкатегорий политики аудита. Установка политики аудита на уровне категории переопределит новую функцию политики аудита подкатегории. Существующие категории параметров аудита сохранились, но разбиты на подкатегории, каждую из которых можно активизировать для регистрации удачного и/или неудачного события.

Например, категория «Аудит доступа к объектам» включает в себя следующие подкатегории:

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

Категория «Аудит входа в систему» включает следующие подкатегории:

• • аудит входа в систему;
• • аудит выхода из системы;
• • аудит блокировки учетной записи;
• • аудит основного режима IPsec;
• • аудит быстрого режима IPsec;
• • аудит расширенного режима IPsec;
• • аудит специального входа;
• • аудит других событий входа и выхода;
• • аудит сервера сетевых политик.

В ОС Windows 7 и старше расширенные политики аудита можно настроить и развернуть с помощью групповой политики домена или с помощью утилиты командной строки auditpol.

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

• • переписывать события при необходимости (сначала старые события);
• • архивировать журнал при заполнении, не перезаписывать события;
• • не переписывать события (очистить журнал вручную).

При выборе одного из двух последних вариантов реакции и

возникновении ситуации переполнения журнала аудита используется значение параметра безопасности «Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности». Если этот параметр включен, то перезагрузка операционной системы становится невозможной для всех пользователей, кроме администратора. Он должен будет очистить журнал аудита, восстановить значение параметра реакции системы на переполнение журнала аудита и перезагрузить операционную систему. Если эти действия не будут выполнены, регистрация новых событий в журнале аудита станет невозможной.

Для регистрации попыток доступа субъекта к объекту в дескрипторе безопасности объекта предусмотрен системный список контроля доступа SACL (см. парагр. 2.3), содержимое которого формируется администратором системы (рис. 2.19). Элементы АСЕ списка SACL имеют один и тот же тип SYSTEM_ AUDIT_ACE и содержат заголовок АСЕ, маску регистрируемых в журнале аудита прав доступа и SID пользователя или группы, чьи попытки доступа к объекту должны регистрироваться (если в АСЕ не указан SID, то регистрируются попытки доступа к объекту всех пользователей). Еще один тип элементов АСЕ списка SACL — SYSTEM ALARM ACE — зарезервирован для дальнейшего использования.

В заголовке АСЕ списка SACL могут использоваться два дополнительных флага — FAILED ACCESS ACE FLAG (будут регистрироваться неудачные попытки получения доступа к объекту) и SUCCESSFUL_ACCESS_ACE_FLAG (будут регистрироваться успешные попытки получить доступ к объекту).

Существует специальное право доступа к объекту ACCESS_ SYSTEM SECURITY, в соответствии с которым субъект может

Рис. 2.19. Редактирование системного списка управления доступом

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

Добавление записей в журнал аудита производится с помощью вызовов системных функций из набора Windows API: ObjectOpenAuditAlarm (генерация события аудита при попытке открытия или создания нового объекта), ObjectCloseAuditAlarm (генерация события аудита при закрытии объекта), Object- DeleteAuditAlarm (генерация события аудита при удалении объекта), ObjectPrivilegeAuditAlarm (генерация события аудита при попытке субъекта применить привилегии при доступе к уже открытому объекту), PrivilegedServiceAuditAlarm (генерация события аудита при попытке использования субъектом привилегий), AccessCheckAndAuditAlarm (проверка прав доступа к объекту с регистрацией соответствующего события аудита) и др.

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

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

• • попытки входа, вход и выход пользователей;
• • доступ к объектам с конфиденциальной информацией со стороны пользователей, в отношении которых имеются обоснованные подозрения о попытках несанкционированного доступа;
• • изменения в списке зарегистрированных пользователей и политике безопасности КС;
• • запуск и завершение процессов при наличии обоснованных подозрений о заражении системных программ вредоносным кодом.

По умолчанию в серверных операционных системах Windows, начиная с Windows Server 2003, на контроллерах домена включен аудит всех событий, кроме доступа к объектам и использования привилегий, а на остальных серверах — только событий входа.

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

• 1) создать группу «Аудиторы» (см. парагр. 2.2) и включить в ее состав пользователей с соответствующими правами;
• 2) назначить владельцем файла аудита одного из членов группы аудиторов (см. парагр. 2.3);
• 3) разрешить полный доступ к файлу аудита членам группы «Аудиторы» и полный доступ псевдопользователю System, а всем другим пользователям доступ запретить;
• 4) назначить группе «Аудиторы» право управления аудитом и журналом безопасности, отменив использование этого права для членов группы «Администраторы»;
• 5) исключить свою учетную запись из состава группы «Администраторы».

После этого просматривать и очищать журнал аудита, а также управлять списками 8АСХ объектов доступа смогут только члены группы аудиторов КС. Полномочия на изменение значений параметров политики аудита при этом сохранятся у членов группы администраторов КС.

К недостаткам подсистемы аудита операционной системы Vindows следует отнести следующие:

• • защита от несанкционированного доступа к файлу аудита обеспечивается только средствами разграничения доступа без применения шифрования;
• • отсутствуют простые средства разделения полномочий администраторов и аудиторов КС;
• • некоторые важные события безопасности (например, запуск драйвера устройства) не могут регистрироваться в журнале аудита;
• • объекты КС, которые недоступны для стандартных программ администрирования (см. парагр. 2.3), имеют 8АСЦ что приводит к регистрации в файле аудита излишних событий.

В дополнение к средствам аудита в операционной системе Vindows для анализа защищенности могут применяться оснастки «Шаблоны безопасности» и «Анализ и настройка безопасности». С помощью оснастки «Шаблоны безопасности» (рис. 2.20) создаются наборы значений параметров безопасности, которые в дальнейшем могут быть использованы при анализе или настройке политики безопасности конкретного компьютера.

Рис. 2.20. Предопределенные шаблоны безопасности

Определены несколько предопределенных шаблонов безопасности:

• • шаблон SETUP SECURITY содержит используемые по умолчанию параметры безопасности;
• • шаблон COMPATWS ослабляет используемые по умолчанию разрешения доступа группы «Пользователи» к файлам и реестру таким образом, чтобы это соответствовало требованиям большинства несертифицированных приложений. Обычно следует использовать группу «Опытные пользователи» для работы с несертифицированными приложениями;
• • шаблон SECUREWS предоставляет расширенные политики для управления локальными учетными записями, ограничивает использование проверки подлинности LanManager, включает подписывание сообщений протокола SMB со стороны сервера, накладывает дальнейшие ограничения для анонимных пользователей. Для применения к входящим в домен компьютерам все контроллеры домена, хранящие учетные записи всех пользователей, которые могут выполнить вход на этот клиентский компьютер, должны работать под управлением Windows NT4 SP4 или более поздних систем;
• • шаблон HISECWS содержит охватывающий набор для SECUREWC. Накладывают дальнейшие ограничения на проверку подлинности LanManager и новые требования для шифрования и подписывания данных, передаваемых по безопасным каналам, и данных SMB. Чтобы применить HISECWC к входящим в домен компьютерам, все контроллеры домена, хранящие учетные записи всех пользователей, которые могут выполнить вход на этот клиентский компьютер, должны работать под управлением Windows NT4 SP4 или более поздних систем;
• • шаблон ROOTSEC обеспечивает применение стандартных корневых разрешений для раздела операционной системы и распространение их на дочерние объекты, наследующие разрешения от корня. Время распространения зависит от количества незащищенных дочерних объектов;
• • шаблон SECUREDC предоставляет расширенные политики для управления учетными записями в домене, ограничивает использование проверки подлинности LanManager, накладывает дальнейшие ограничения для анонимных пользователей. Если контроллер домена использует securedc, то пользователь с учетной записью в этом домене не сможет подключаться к рядовым серверам только с помощью клиента Lan Manager;
• • шаблон HISECDC содержит охватывающий набор для SECUREDC. Накладывает дальнейшие ограничения на проверку подлинности LanManager и новые требования для шифрования и подписывания данных, передаваемых по

Рис. 2.21. Результат анализа безопасности компьютера

Рис. 2.22. Просмотр журнала с результатами анализа безопасности безопасным каналам, и данных SMB. Чтобы применить HISECDC к контроллеру домена, все другие контроллеры в доверенных и доверяющих доменах должны работать под управлением Windows 2000 или более поздних систем.

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

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

Результаты анализа безопасности помещаются также в текстовый файл журнала с расширением log, который по умолчанию находится в папке SecurityLogs, находящейся в папке «Мои документы» профиля пользователя, проводившего анализ. Этот журнал можно также просмотреть с помощью оснастки «Анализ и настройка безопасности» (рис. 2.22).