Страница:
* задачи, связанные с надежностью
* требования к контрольному журналу
Задачи, связанные с производительностью
При оценке влияния подсистемы контроля на производитель-
ность системы важно продумать, какие действия должна выполнять
подсистема. Драйвер устройства подсистемы контроля - это главное
место сбора контрольных записей из всевозможных источников; он
отвечает за внесение этих записей в контрольный журнал. Драйвер
выполняет запись в файл сбора данных, совместно используемый
всеми процессами, контролируемыми в системе. Это напоминает сис-
тему резервирования мест на самолетах, где множество клерков вы-
полняют доступ к общей базе данных. Должны быть предусмотрены
механизмы блокировки, чтобы не допустить смешивания контрольных
записей и обеспечить совместимость базы данных. То же касается и
файлов сбора данных подсистемы контроля.
Механизм внутренней буферизации и стратегия записи (write-
behind) пытаются минимизировать воздействие многократной однов-
ременной записи на файлы сбора данных. Это позволяет подсистеме
обслуживать контрольные записи от процессов и прикладных прог-
рамм в то время, как параллельно идет запись в файлы сбора дан-
ных. Вы можете настроить этот механизм, учитывая, как интенсивно
используется буферизация и как часто идет запись в файл сбора
данных.
Задачи, связанные с надежностью
Так же, как и производительность системы, важна надежность
выдаваемого контрольного журнала. В традиционных системах UNIX
нет возможности сохранить целостность файловой системы в резуль-
тате фатального сбоя системы. Это вызвано тем фактом, что ввод-
-вывод выполняется с помощью пула буферов, в которые запись
(главным образом) ведется асинхронно. Так, изменения, внесенные
в файлы, на самом деле могут оказаться не записанными на диск
при фатальном сбое системы.
Это грустно, так как события, приводящие к фатальному сбою
системы, представляют для вас наибольший интерес с точки зрения
контроля. Очень хотелось бы минимизировать какую бы то ни было
потенциальную потерю данных из подсистемы контроля в результате
.
- 5-25 -
фатального сбоя системы. Для этого подсистема контроля использу-
ет механизм, называемый синхронным вводом-выводом, который вы-
полняет немедленное обновление буферов сбора данных контроля и
индексных дескрипторов файлов сбора данных, когда происходит их
изменение. Это сводит к минимуму возможные потери данных в ре-
зультате фатального сбоя системы.
Существует прямая связь между степенью надежности данных и
производительностью подсистемы контроля. Контрольные записи, ге-
нерируемые механизмом контроля ядра, надежными прикладными прог-
раммами и защищенными подсистемами, обычно имеют длину 40-60
байт. Если каждая запись пишется на диск синхронно, как только
она передана подсистеме, результатом будет низкая производитель-
ность; система ввода-вывода переполняется из-за высокой скорости
генерации записей. Выход состоит в том, чтобы буферизовать запи-
си и писать их в контрольный журнал вместе через назначенные ин-
тервалы времени. Эти интервалы можно определить по истекшему
времени или по пороговой величине накопленных данных. И здесь
также выбор зависит от вас.
Требования к контрольному журналу
И, наконец, последнее, что важно для административного уп-
равления подсистемой контроля, - определить, что именно нужно
контролировать. Можно использовать возможности предварительной
выборки при генерации записей, чтобы контрольный журнал скон-
центрировался на одном или нескольких событиях. Например, систе-
ма может использоваться всего лишь маленькой группой людей, а по
ночам простаивать. Кроме того, в нерабочее время предоставля-
ются несколько коммутируемых линий связи. Возможно, вас интере-
сует только учет того, кто и когда пользуется системой. В этом
случае предварительную выборку можно использовать только для от-
слеживания событий входа в систему и выхода из нее. Попытки про-
никновения в систему со стороны неавторизованных пользователей
будут зафиксированы как неудачные попытки регистрации.
Контроль можно также сосредоточить на конкретных пользова-
телях или группах пользователей. Это позволит вам сконцентриро-
ваться на лицах, подозреваемых в нарушении стратегии секретнос-
ти. Чем меньше запрошено контроля, тем меньше подсистема контро-
ля влияет на производительность системы. Полный контроль приво-
дит к созданию пространной и подробной записи о системных собы-
тиях, но он требует и больше ресурсов для работы. Однако чаще
оказывается удобнее зарегистрировать события и использовать
средства редукции, чтобы потом отбросить ненужные записи, чем
отказаться от сбора записей, действительно необходимых для ана-
лиза проблемы. Это решение зависит от степени секретности, кото-
рую вы намерены соблюсти.
Важно понять определение сессии контроля по отношению к
подсистеме. Предполагается, что сессия соответствует интервалу
времени с момента загрузки системы до момента ее выключения. Для
сокращения объема записываемых в контрольный журнал данных в ка-
честве одной из задач при проектировании подсистемы была уста-
новлена минимизация размера каждой контрольной записи. Следова-
тельно, состояние процесса определяется последовательностью
контрольных записей, а не указывается целиком в каждой записи.
.
- 5-26 -
При таком подходе экономия места и времени оказывается значи-
тельной, но это требует аккуратного административного управления
во избежание ловушек.
Если отключить подсистему контроля во время работы системы,
а затем вновь включить, будет создана новая сессия. Сессия опре-
деляется как последовательность файлов сбора данных и уплотнен-
ных файлов, содержащих контрольные записи, связанные с конкрет-
ным интервалом времени. Это может привести к созданию двух (а
возможно, и больше) наборов файлов контроля в одном жизненном
цикле системы. Некоторые процессы, контролируемые во второй или
последующей сессии, могут оказаться созданными во время первой
сессии. Следовательно, сессия может не содержать все соответс-
твующее состояние процесса, нужное для какого-либо процесса. В
свою очередь, это может вызвать неполную редукцию записей. Это
относится главным образом к именам файлов, причем как правило -
только к относительным именам файлов (а не абсолютным). Этого
можно избежать, если выключать контроль только после останова
системы.
Процедуры контроля
В данном разделе описывается, как устанавливать, иницииро-
вать, модифицировать и прекращать контроль системы. Доступ к
каждой из этих функций осуществляется через sysadmsh. Выход на
верхний уровень функций контроля производится выбором
System->Audit; это следующие функции:
Enable/Disable Инициирование и прекращение контроля
Collection Выбор критерия контроля
Формирование конфигурации подсистемы и управ-
ление контролируемыми событиями и пользовате-
лями. Кроме того, можно управлять параметрами
установки, влияющими на производительность и
надежность подсистемы и ее данные
Report Редукция данных контроля и составление отчетов
Создание и сохранение выборочных файлов ре-
дукции, редукция сессий контроля с помощью
файлов сбора данных и удаление сокращенных
файлов после того, как они становятся ненуж-
ными
Files Сопровождение файла контрольных записей
Проверка сессий контроля, накопленных в сис-
теме, архивирование сессий контроля на ре-
зервном носителе, восстановление ранее сохра-
ненных сессий контроля, удаление ненужных
сессий контроля, пуск и останов контроля по
мере надобности
.
- 5-27 -
Процедура контроля состоит из трех этапов, описанных в пос-
ледующих разделах:
1. Установка схемы сбора данных
2. Включение контроля
3. Генерация контрольных отчетов
Установка схемы сбора данных
Чтобы задать, какие данные следует собирать и где их следу-
ет хранить, сделайте в sysadmsh следующий выбор:
System->Audit->Collection
На экране появятся следующие элементы для выбора:
Directories Каталоги файлов сбора данных контроля и уп-
лотненных файлов
Events Системная маска типов событий
IDs Выбор контроля пользователя и группы
Parameters Параметры подсистемы контроля
Summary Распечатка статистики текущей сессии контроля
Выберите, какую информацию вы хотите поставлять; каждый вы-
бор описан в одном из последующих разделов. Информация о сборе
данных, заданная вами, записывается в файл параметров. Система
поставляется с файлом параметров, заданным по умолчанию, но вы
должны модифицировать его, чтобы он удовлетворял вашим требова-
ниям. Инициированная подсистема контролирует события в соответс-
твии с содержимым файла параметров до тех пор, пока параметры не
будут модифицированы, или до прекращения контроля, или до оста-
нова системы. Заметим, что некоторые параметры можно модифициро-
вать в ходе контроля, а другие действительны только в момент
инициирования контроля. По мере описания очередной области кон-
фигурации отмечаются статические и динамические величины.
Каталоги контроля
Файлы сбора данных, генерируемые подсистемой контроля, и
уплотненные файлы, генерируемые демоном контроля, записываются в
заданные вами каталоги. Сессия контроля может содержать файлы,
записанные во множество различных каталогов. К концу сессии ос-
таются только уплотненные файлы, так как файлы сбора данных уда-
ляются подсистемой, когда они прочитаны демоном контроля. Вам не
нужно отслеживать каталоги, в которые записываются файлы, пос-
кольку эта информация имеется в журнальном файле сессии.
Вы можете увеличить производительность системы, поместив
каталоги контроля в файловую систему, расположенную на отдельном
физическом устройстве от остальных файловых систем. Это уменьшит
соперничество за ресурсы диска. Кроме того, контроль требует
значительного пространства, даже с учетом уплотнения. Когда мес-
.
- 5-28 -
та на диске становится мало, подсистема выдает предупреждение;
если свободного пространства в файловой системе становится слиш-
ком мало, то подсистема выключает контроль. По этой причине под-
система и демон поддерживают несколько каталогов. При возникно-
вении ошибки во время записи в каталог или при исчерпании места
на диске подсистема и демон пытаются воспользоваться альтерна-
тивными каталогами, чтобы продолжить работу.
Каждое имя файла следует вводить с указанием абсолютного
имени пути. Число каталогов, которые вы можете определить, ничем
не ограничено. Если никакие каталоги не заданы, подсистема и де-
мон создают все файлы в корневой файловой системе, используя за-
резервированный каталог подсистемы контроля /tcb/audittmp. Такая
установка файлов конфигурации контроля делается по умолчанию.
Маска событий контроля
Как уже говорилось в разделе "Типы событий контроля", име-
ется некоторое число событий контроля, которые можно выбрать:
Таблица 5.5
События контроля
----------------------------------------------------------------
A. Startup/Shutdown B. Login/Logoff
C. Process Create/Delete D. Make Object Available
E. Map Object to Subject F. Object Modification
G. Make Object Unavailable H. Object Creation
I. Object Deletion J. DAC Changes
K. DAC Denials L. Admin/Operator Actions
M. Insufficient Privilege N. Resource Denials
O. IPC Functions P. Process Modifications
Q. Audit Subsystem Events R. Database Events
S. Subsystem Events T. Use of Privilege
----------------------------------------------------------------
A. Запуск/Останов B. Вход/Выход из системы
C. Создать/Удалить процесс D. Сделать объект доступным
E. Отобразить объект в субъект F. Модификация объекта
G. Сделать объект недоступным H. Создание объекта
I. Удаление объекта J. Изменения DAC
K. Отказы DAC L. Действия оператора/Админ.
M. Недостаточные привилегии N. Отказы ресурса
O. Функции IPC P. Модификации процесса
Q. События подсистемы контроля R. События базы данных
S. События подсистемы T. Использование привилегий
----------------------------------------------------------------
Каждый тип события выводится на экран и соответствует бук-
ве, находящейся в верхней части экрана. Для событий, подлежащих
контролю, тип события следует задать вместе с символом "Y". Типы
событий, не подлежащие контролю, исключаются опцией "N". Для пе-
реключения ввода с "Y" на "N" и обратно пользуйтесь клавишей
пробела. Для перехода от одного элемента к другому используйте
клавиши перемещения курсора. Данную маску событий можно модифи-
цировать и динамически изменять для текущей сессии контроля
и/или записывать в файл параметров для использования в последую-
щих сессиях контроля.
.
- 5-29 -
Выбор пользователя и группы
Поля User и Group можно использовать для динамического из-
менения выбора контроля в текущей сессии или для следующих сес-
сий. Выбор пользователей и групп можно производить многократно в
течение одной сессии. Если никакие пользователи и группы не выб-
раны, в результате все пользователи и группы будут исключены из
данного выбора. Это означает, что все процессы в системе подле-
жат контролю.
Параметры подсистемы контроля
Вы можете изменить некоторые параметры контроля, чтобы
настроить контроль в соответствии с требованиями системы. Неко-
торые из этих параметров связаны с проблемами компромисса между
производительностью и надежностью, обсуждавшимися выше. Теперь
это станет яснее. Имеются следующие параметры:
Write to disk... (Запись на диск)
Эти два параметра определяют частоту, с которой данные
контроля синхронно сбрасываются в файл сбора данных контро-
ля из внутренних буферов контроля. Сброс можно контролиро-
вать либо количеством данных, накопленных перед записью,
либо истечением заданного интервала времени. Последняя воз-
можность особенно полезна, когда генерируются небольшие
объемы данных и частота генерации записей размазана по вре-
мени. Можно задать сброс и по счетчику байтов, и по истече-
нию времени. Интервал времени всегда задается в секундах.
Плохой выбор этих величин может неблагоприятно повлиять
на производительность. Слишком частые операции записи за-
медляют работу системы при чрезмерном трафике ввода-вывода.
С другой стороны, когда эти значения слишком велики, растет
вероятность потери данных в случае фатального сбоя системы.
Рекомендуется при каждом заполнении одного внутреннего бу-
фера делать сброс. Таким образом, обычно достаточно задать
счетчик сброса равным 1024 (размер внутреннего буфера).
Wake up daemon... (Активизировать демон)
Данный параметр управляет демоном контроля. Этот демон пос-
тоянно читает с устройства контроля и получает записи, по-
мещенные в файлы сбора данных. Затем эти записи уплотняются
и записываются в уплотненные файлы, которые впоследствии
подвергаются редукции. Для получения максимальной эффектив-
ности алгоритма уплотнения демону следует читать блоки дан-
ных размером от 4К до 5К байт. Для этого нужна специальная
обработка в подсистеме, так как обычно операция чтения
возвращает управление, когда доступны какие-либо данные, а
не ждет, когда накопится определенный объем данных. Для
максимальной эффективности этот параметр должен лежать в
диапазоне от 4096 до 5120 байт. По умолчанию принимается
величина 4096 байт.
.
- 5-30 -
Collection buffers (Буферы сбора данных)
Этот параметр позволяет задать число буферов сбора данных,
используемых подсистемой. Она использует эти внутренние бу-
фера для сбора данных контроля, записываемых в файл сбора
данных. Для увеличения эффективности системы используется
несколько буферов, так как все процессы совместно использу-
ют буферное пространство при попытках занесения записи. При
наличии нескольких буферов процессы могут отложить записи
на хранение и продолжать выполнение без блокировки, даже
если на предыдущих буферах выполняется ввод-вывод. Нужно
как минимум два буфера. Большинство систем не могут эффек-
тивно использовать более 4-6 буферов без проблем с произво-
дительностью. Не существует вполне определенного способа
вычисления оптимального числа буферов. В общем случае зада-
вайте эту величину исходя из ожидаемой загрузки процессами
системы.
Collection/Audit output file switch...
(Переключение выходных файлов контроля/файлов сбора данных)
Эти два параметра позволяют задать максимальный размер, ко-
торого могут достигать файлы сбора данных и уплотненные
файлы перед созданием нового файла. Если для обоих парамет-
ров выбрать маленькие значения, это приведет к чрезмерному
числу переключений файлов. Так как уплотненные файлы явля-
ются постоянными, это также может вызвать обилие небольших
файлов в системе. Если выбрать слишком большие значения,
это создаст ситуацию, при которой файлы сбора данных конт-
роля будут использовать много места на диске, даже если они
будут частично считаны демоном контроля, что должно было бы
вызвать их удаление. Размером уплотненных файлов контроля
можно управлять потому, что эти файлы остаются в системе до
редукции или удаления. Желательно, чтобы эти файлы имели
размер, приемлемый для работы с ними, в том числе для их
легкого сохранения и восстановления. По умолчанию для фай-
лов сбора данных берется значение 50К байт, а для уплотнен-
ных файлов - 1 мегабайт. Убедитесь, что максимальный раз-
мер, выбранный для уплотненных файлов, не превышает уста-
новленной в системе величины ulimit, контролирующей макси-
мальный размер, допустимый для пользовательского файла.
Compacted audit output files
(Уплотненные выходные файлы контроля)
Эта опция предусмотрена на случай, если нужно иметь и неуп-
лотненные файлы контроля. Особой необходимости использовать
эту опцию нет, так как уплотнение не требует много дополни-
тельного времени на обработку, а итоговая экономия места на
диске обычно больше 60 процентов. Алгоритм уплотнения со-
держится в пользовательском процессе демона контроля, а не
выполняется в ядре подсистемы.
.
- 5-31 -
Enable audit on system startup
(Включить контроль при запуске системы)
Если ответ положительный, то в результате контроль будет
начинаться автоматически при каждой перезагрузке системы.
Это поле выходит на экран только через опцию View; оно ус-
танавливается в соответствии с тем, был ли контроль включен
или выключен. Если контроль был выключен, то при запуске он
будет отключаться.
Shutdown gracefully on disk full
(Выполнить постепенный останов при заполнении диска)
Эта опция позволяет системе выполнить автоматический оста-
нов, если она исчерпала пространство на диске; это помогает
избежать порчи данных.
Change parameters for this/future session
(Изменить параметры для данной/следующей сессии)
Последние две опции на экране позволят вам динамически из-
менять текущую сессию и/или вносить изменения в постоянную
часть файла параметров контроля для следующих сессий.
Текущая статистика
Последняя опция, предусмотренная в меню Collection, - это
получение статистики текущей сессии контроля. Сюда входит инфор-
мация о номере текущей сессии, количестве файлов сбора данных и
уплотненных файлов, количестве записей, созданных механизмом
контроля ядра, и записей, созданных прикладными программами, и
др. Если в данный момент контроль не действует, статистика не
выводится.
Пример распечатки Summary:
+---------------------------------------------------------------
| *** Audit Subsystem Statistics ***
| (Статистика подсистемы контроля)
| Current Audit Session-6 (Текущая сессия контроля - 6)
| Current Collection File Sequence Number-1488
| (Порядковый номер текущего файла сбора данных)
| Total count of audit data written: 7659433
| (Общий счетчик записанных данных контроля)
| Total count of audit records written: 156666
| (Общий счетчик записанных контрольных записей)
| Audit records written by applications: 81
| (Контрольные записи, сделанные прикладными программами)
| Audit records written by system calls: 155083
| (Контрольные записи, сделанные системными вызовами)
| System calls not selected for audit: 751889
| (Системные вызовы, не отобранные для контроля)
| Total number of audit device reads: 2977
| (Общее число операций чтения на устройстве контроля)
| Total number of audit device writes: 324
| (Общее число операций записи на устройстве контроля)
| Total number of collection files: 1489
| (Общее число файлов сбора данных)
|
.
- 5-32 -
Включение/выключение контроля
Чтобы включить или выключить контроль, используйте следую-
щие выборы в sysadmsh:
Функция включения, используя текущий файл параметров конт-
роля, выполняет инициализацию подсистемы. Функция выключения
доступна из того же меню и вызывает постепенный выход из контро-
ля (когда все файлы сбора данных прочитаны демоном и уплотнены).
Затем демон прекращает работу, оставляя лишь журнальный файл
сессии контроля и уплотненные файлы сессии.
Помните, что если выключить контроль, а затем вновь его
включить, не перезагрузив систему, то это может вызвать потерю
некоторых данных процесса, нужных для поддержания состояния про-
цесса. Если контроль прекращен для модификации некоторых пара-
метров, учтите, что большинство параметров подсистемы можно мо-
дифицировать и в процессе контроля. Для обеих функций - включе-
ния и выключения - предусмотрены экраны для подтверждения, кото-
рое нужно сделать до завершения функции в sysadmsh. Когда конт-
роль включается или выключается, на экран выходит сообщение о
состоянии контроля в момент перезагрузки; если контроль выклю-
чен, то при запуске системы он будет выключен, а если включен,
то он будет вновь включен.
Сопровождение файлов контроля
Функции сопровождения файлов контроля доступны в sysadmsh
при следующем выборе:
Доступны следующие файловые функции:
ном носителе
зервного носителя
Сессия контроля состоит из журнального файла сессии и груп-
пы уплотненных файлов, сгенерированных между моментами включени-
я и выключения подсистемы контроля. Каждый файл сбора данных и
уплотненный файл, созданный во время сессии, получает уникальный
номер от этой сессии. После завершения сессии остается только
журнальный файл и уплотненные файлы. Функции сопровождения фай-
лов проверяют, какие сессии еще имеются в системе, и дают воз-
можность удалить уже не нужные сессии.
.
- 5-33 -
Вывод списка контрольных записей
Этот выбор дает немедленный ответ: выводится список файлов,
доступных в каталогах контроля.
Дублирование контрольных записей
Поскольку сессии контроля требуют много места на диске,
часто оказывается необходимым внести данные контроля в архив, а
затем либо сократить их, либо восстановить на некоторый период
времени, если они нужны для анализа проблем, которые нельзя выя-
вить немедленно. Такую возможность дает интерфейс дублирова-
ния/восстановления. Опция Backup требует в качестве ввода номер
сессии. Его можно получить, сгенерировав контрольный отчет (см.
ниже). Выбрав дублирование, вы должны выбрать и выходное уст-
ройство для дублирования. Им может служить любой съемный носи-
тель, доступный в системе.
Замечание
Контроль требует очень много места на диске. В зависимости
от количества пользователей в системе и от количества контроли-
руемых событий, может потребоваться еженедельное дублирование и
удаление файлов сессий. Если имеется расписание дублирования, то
выбор опции дублирования контроля, вероятно, не потребуется.
Вновь заметим, что очень важно удалить файлы после того, как они
продублированы в свободном пространстве на диске.
Точно так же сессии, которые были продублированы на съемных
носителях с помощью программы интерфейса, могут быть восстанов-
лены опцией Restore. Для этого вставьте носитель с сохраненными
файлами сессии в устройство восстановления и задайте имя уст-
ройства.
Удаление файлов
Для удаления сессий контроля предусмотрен выбор Delete.
Сессии можно внести в архив на резервном носителе, а затем уда-
лить, чтобы освободить место в файловой системе для других фай-
лов контроля. Сессии удаляются по номеру сессии. Типичный сцена-
рий должен включать составление отчета (см. ниже) для определе-
ния, какие сессии существуют и которые из них можно удалить. За-
тем номер сессии предоставляется опции Delete, которая удаляет
все файлы, связанные с этой сессией.
.
- 5-34 -
Составление контрольных отчетов
Чтобы посмотреть контрольный журнал какой-либо сессии, вы-
берите в sysadmsh:
Доступны следующие опции:
* требования к контрольному журналу
Задачи, связанные с производительностью
При оценке влияния подсистемы контроля на производитель-
ность системы важно продумать, какие действия должна выполнять
подсистема. Драйвер устройства подсистемы контроля - это главное
место сбора контрольных записей из всевозможных источников; он
отвечает за внесение этих записей в контрольный журнал. Драйвер
выполняет запись в файл сбора данных, совместно используемый
всеми процессами, контролируемыми в системе. Это напоминает сис-
тему резервирования мест на самолетах, где множество клерков вы-
полняют доступ к общей базе данных. Должны быть предусмотрены
механизмы блокировки, чтобы не допустить смешивания контрольных
записей и обеспечить совместимость базы данных. То же касается и
файлов сбора данных подсистемы контроля.
Механизм внутренней буферизации и стратегия записи (write-
behind) пытаются минимизировать воздействие многократной однов-
ременной записи на файлы сбора данных. Это позволяет подсистеме
обслуживать контрольные записи от процессов и прикладных прог-
рамм в то время, как параллельно идет запись в файлы сбора дан-
ных. Вы можете настроить этот механизм, учитывая, как интенсивно
используется буферизация и как часто идет запись в файл сбора
данных.
Задачи, связанные с надежностью
Так же, как и производительность системы, важна надежность
выдаваемого контрольного журнала. В традиционных системах UNIX
нет возможности сохранить целостность файловой системы в резуль-
тате фатального сбоя системы. Это вызвано тем фактом, что ввод-
-вывод выполняется с помощью пула буферов, в которые запись
(главным образом) ведется асинхронно. Так, изменения, внесенные
в файлы, на самом деле могут оказаться не записанными на диск
при фатальном сбое системы.
Это грустно, так как события, приводящие к фатальному сбою
системы, представляют для вас наибольший интерес с точки зрения
контроля. Очень хотелось бы минимизировать какую бы то ни было
потенциальную потерю данных из подсистемы контроля в результате
.
- 5-25 -
фатального сбоя системы. Для этого подсистема контроля использу-
ет механизм, называемый синхронным вводом-выводом, который вы-
полняет немедленное обновление буферов сбора данных контроля и
индексных дескрипторов файлов сбора данных, когда происходит их
изменение. Это сводит к минимуму возможные потери данных в ре-
зультате фатального сбоя системы.
Существует прямая связь между степенью надежности данных и
производительностью подсистемы контроля. Контрольные записи, ге-
нерируемые механизмом контроля ядра, надежными прикладными прог-
раммами и защищенными подсистемами, обычно имеют длину 40-60
байт. Если каждая запись пишется на диск синхронно, как только
она передана подсистеме, результатом будет низкая производитель-
ность; система ввода-вывода переполняется из-за высокой скорости
генерации записей. Выход состоит в том, чтобы буферизовать запи-
си и писать их в контрольный журнал вместе через назначенные ин-
тервалы времени. Эти интервалы можно определить по истекшему
времени или по пороговой величине накопленных данных. И здесь
также выбор зависит от вас.
Требования к контрольному журналу
И, наконец, последнее, что важно для административного уп-
равления подсистемой контроля, - определить, что именно нужно
контролировать. Можно использовать возможности предварительной
выборки при генерации записей, чтобы контрольный журнал скон-
центрировался на одном или нескольких событиях. Например, систе-
ма может использоваться всего лишь маленькой группой людей, а по
ночам простаивать. Кроме того, в нерабочее время предоставля-
ются несколько коммутируемых линий связи. Возможно, вас интере-
сует только учет того, кто и когда пользуется системой. В этом
случае предварительную выборку можно использовать только для от-
слеживания событий входа в систему и выхода из нее. Попытки про-
никновения в систему со стороны неавторизованных пользователей
будут зафиксированы как неудачные попытки регистрации.
Контроль можно также сосредоточить на конкретных пользова-
телях или группах пользователей. Это позволит вам сконцентриро-
ваться на лицах, подозреваемых в нарушении стратегии секретнос-
ти. Чем меньше запрошено контроля, тем меньше подсистема контро-
ля влияет на производительность системы. Полный контроль приво-
дит к созданию пространной и подробной записи о системных собы-
тиях, но он требует и больше ресурсов для работы. Однако чаще
оказывается удобнее зарегистрировать события и использовать
средства редукции, чтобы потом отбросить ненужные записи, чем
отказаться от сбора записей, действительно необходимых для ана-
лиза проблемы. Это решение зависит от степени секретности, кото-
рую вы намерены соблюсти.
Важно понять определение сессии контроля по отношению к
подсистеме. Предполагается, что сессия соответствует интервалу
времени с момента загрузки системы до момента ее выключения. Для
сокращения объема записываемых в контрольный журнал данных в ка-
честве одной из задач при проектировании подсистемы была уста-
новлена минимизация размера каждой контрольной записи. Следова-
тельно, состояние процесса определяется последовательностью
контрольных записей, а не указывается целиком в каждой записи.
.
- 5-26 -
При таком подходе экономия места и времени оказывается значи-
тельной, но это требует аккуратного административного управления
во избежание ловушек.
Если отключить подсистему контроля во время работы системы,
а затем вновь включить, будет создана новая сессия. Сессия опре-
деляется как последовательность файлов сбора данных и уплотнен-
ных файлов, содержащих контрольные записи, связанные с конкрет-
ным интервалом времени. Это может привести к созданию двух (а
возможно, и больше) наборов файлов контроля в одном жизненном
цикле системы. Некоторые процессы, контролируемые во второй или
последующей сессии, могут оказаться созданными во время первой
сессии. Следовательно, сессия может не содержать все соответс-
твующее состояние процесса, нужное для какого-либо процесса. В
свою очередь, это может вызвать неполную редукцию записей. Это
относится главным образом к именам файлов, причем как правило -
только к относительным именам файлов (а не абсолютным). Этого
можно избежать, если выключать контроль только после останова
системы.
Процедуры контроля
В данном разделе описывается, как устанавливать, иницииро-
вать, модифицировать и прекращать контроль системы. Доступ к
каждой из этих функций осуществляется через sysadmsh. Выход на
верхний уровень функций контроля производится выбором
System->Audit; это следующие функции:
Enable/Disable Инициирование и прекращение контроля
Collection Выбор критерия контроля
Формирование конфигурации подсистемы и управ-
ление контролируемыми событиями и пользовате-
лями. Кроме того, можно управлять параметрами
установки, влияющими на производительность и
надежность подсистемы и ее данные
Report Редукция данных контроля и составление отчетов
Создание и сохранение выборочных файлов ре-
дукции, редукция сессий контроля с помощью
файлов сбора данных и удаление сокращенных
файлов после того, как они становятся ненуж-
ными
Files Сопровождение файла контрольных записей
Проверка сессий контроля, накопленных в сис-
теме, архивирование сессий контроля на ре-
зервном носителе, восстановление ранее сохра-
ненных сессий контроля, удаление ненужных
сессий контроля, пуск и останов контроля по
мере надобности
.
- 5-27 -
Процедура контроля состоит из трех этапов, описанных в пос-
ледующих разделах:
1. Установка схемы сбора данных
2. Включение контроля
3. Генерация контрольных отчетов
Установка схемы сбора данных
Чтобы задать, какие данные следует собирать и где их следу-
ет хранить, сделайте в sysadmsh следующий выбор:
System->Audit->Collection
На экране появятся следующие элементы для выбора:
Directories Каталоги файлов сбора данных контроля и уп-
лотненных файлов
Events Системная маска типов событий
IDs Выбор контроля пользователя и группы
Parameters Параметры подсистемы контроля
Summary Распечатка статистики текущей сессии контроля
Выберите, какую информацию вы хотите поставлять; каждый вы-
бор описан в одном из последующих разделов. Информация о сборе
данных, заданная вами, записывается в файл параметров. Система
поставляется с файлом параметров, заданным по умолчанию, но вы
должны модифицировать его, чтобы он удовлетворял вашим требова-
ниям. Инициированная подсистема контролирует события в соответс-
твии с содержимым файла параметров до тех пор, пока параметры не
будут модифицированы, или до прекращения контроля, или до оста-
нова системы. Заметим, что некоторые параметры можно модифициро-
вать в ходе контроля, а другие действительны только в момент
инициирования контроля. По мере описания очередной области кон-
фигурации отмечаются статические и динамические величины.
Каталоги контроля
Файлы сбора данных, генерируемые подсистемой контроля, и
уплотненные файлы, генерируемые демоном контроля, записываются в
заданные вами каталоги. Сессия контроля может содержать файлы,
записанные во множество различных каталогов. К концу сессии ос-
таются только уплотненные файлы, так как файлы сбора данных уда-
ляются подсистемой, когда они прочитаны демоном контроля. Вам не
нужно отслеживать каталоги, в которые записываются файлы, пос-
кольку эта информация имеется в журнальном файле сессии.
Вы можете увеличить производительность системы, поместив
каталоги контроля в файловую систему, расположенную на отдельном
физическом устройстве от остальных файловых систем. Это уменьшит
соперничество за ресурсы диска. Кроме того, контроль требует
значительного пространства, даже с учетом уплотнения. Когда мес-
.
- 5-28 -
та на диске становится мало, подсистема выдает предупреждение;
если свободного пространства в файловой системе становится слиш-
ком мало, то подсистема выключает контроль. По этой причине под-
система и демон поддерживают несколько каталогов. При возникно-
вении ошибки во время записи в каталог или при исчерпании места
на диске подсистема и демон пытаются воспользоваться альтерна-
тивными каталогами, чтобы продолжить работу.
Каждое имя файла следует вводить с указанием абсолютного
имени пути. Число каталогов, которые вы можете определить, ничем
не ограничено. Если никакие каталоги не заданы, подсистема и де-
мон создают все файлы в корневой файловой системе, используя за-
резервированный каталог подсистемы контроля /tcb/audittmp. Такая
установка файлов конфигурации контроля делается по умолчанию.
Маска событий контроля
Как уже говорилось в разделе "Типы событий контроля", име-
ется некоторое число событий контроля, которые можно выбрать:
Таблица 5.5
События контроля
----------------------------------------------------------------
A. Startup/Shutdown B. Login/Logoff
C. Process Create/Delete D. Make Object Available
E. Map Object to Subject F. Object Modification
G. Make Object Unavailable H. Object Creation
I. Object Deletion J. DAC Changes
K. DAC Denials L. Admin/Operator Actions
M. Insufficient Privilege N. Resource Denials
O. IPC Functions P. Process Modifications
Q. Audit Subsystem Events R. Database Events
S. Subsystem Events T. Use of Privilege
----------------------------------------------------------------
A. Запуск/Останов B. Вход/Выход из системы
C. Создать/Удалить процесс D. Сделать объект доступным
E. Отобразить объект в субъект F. Модификация объекта
G. Сделать объект недоступным H. Создание объекта
I. Удаление объекта J. Изменения DAC
K. Отказы DAC L. Действия оператора/Админ.
M. Недостаточные привилегии N. Отказы ресурса
O. Функции IPC P. Модификации процесса
Q. События подсистемы контроля R. События базы данных
S. События подсистемы T. Использование привилегий
----------------------------------------------------------------
Каждый тип события выводится на экран и соответствует бук-
ве, находящейся в верхней части экрана. Для событий, подлежащих
контролю, тип события следует задать вместе с символом "Y". Типы
событий, не подлежащие контролю, исключаются опцией "N". Для пе-
реключения ввода с "Y" на "N" и обратно пользуйтесь клавишей
пробела. Для перехода от одного элемента к другому используйте
клавиши перемещения курсора. Данную маску событий можно модифи-
цировать и динамически изменять для текущей сессии контроля
и/или записывать в файл параметров для использования в последую-
щих сессиях контроля.
.
- 5-29 -
Выбор пользователя и группы
Поля User и Group можно использовать для динамического из-
менения выбора контроля в текущей сессии или для следующих сес-
сий. Выбор пользователей и групп можно производить многократно в
течение одной сессии. Если никакие пользователи и группы не выб-
раны, в результате все пользователи и группы будут исключены из
данного выбора. Это означает, что все процессы в системе подле-
жат контролю.
Параметры подсистемы контроля
Вы можете изменить некоторые параметры контроля, чтобы
настроить контроль в соответствии с требованиями системы. Неко-
торые из этих параметров связаны с проблемами компромисса между
производительностью и надежностью, обсуждавшимися выше. Теперь
это станет яснее. Имеются следующие параметры:
Write to disk... (Запись на диск)
Эти два параметра определяют частоту, с которой данные
контроля синхронно сбрасываются в файл сбора данных контро-
ля из внутренних буферов контроля. Сброс можно контролиро-
вать либо количеством данных, накопленных перед записью,
либо истечением заданного интервала времени. Последняя воз-
можность особенно полезна, когда генерируются небольшие
объемы данных и частота генерации записей размазана по вре-
мени. Можно задать сброс и по счетчику байтов, и по истече-
нию времени. Интервал времени всегда задается в секундах.
Плохой выбор этих величин может неблагоприятно повлиять
на производительность. Слишком частые операции записи за-
медляют работу системы при чрезмерном трафике ввода-вывода.
С другой стороны, когда эти значения слишком велики, растет
вероятность потери данных в случае фатального сбоя системы.
Рекомендуется при каждом заполнении одного внутреннего бу-
фера делать сброс. Таким образом, обычно достаточно задать
счетчик сброса равным 1024 (размер внутреннего буфера).
Wake up daemon... (Активизировать демон)
Данный параметр управляет демоном контроля. Этот демон пос-
тоянно читает с устройства контроля и получает записи, по-
мещенные в файлы сбора данных. Затем эти записи уплотняются
и записываются в уплотненные файлы, которые впоследствии
подвергаются редукции. Для получения максимальной эффектив-
ности алгоритма уплотнения демону следует читать блоки дан-
ных размером от 4К до 5К байт. Для этого нужна специальная
обработка в подсистеме, так как обычно операция чтения
возвращает управление, когда доступны какие-либо данные, а
не ждет, когда накопится определенный объем данных. Для
максимальной эффективности этот параметр должен лежать в
диапазоне от 4096 до 5120 байт. По умолчанию принимается
величина 4096 байт.
.
- 5-30 -
Collection buffers (Буферы сбора данных)
Этот параметр позволяет задать число буферов сбора данных,
используемых подсистемой. Она использует эти внутренние бу-
фера для сбора данных контроля, записываемых в файл сбора
данных. Для увеличения эффективности системы используется
несколько буферов, так как все процессы совместно использу-
ют буферное пространство при попытках занесения записи. При
наличии нескольких буферов процессы могут отложить записи
на хранение и продолжать выполнение без блокировки, даже
если на предыдущих буферах выполняется ввод-вывод. Нужно
как минимум два буфера. Большинство систем не могут эффек-
тивно использовать более 4-6 буферов без проблем с произво-
дительностью. Не существует вполне определенного способа
вычисления оптимального числа буферов. В общем случае зада-
вайте эту величину исходя из ожидаемой загрузки процессами
системы.
Collection/Audit output file switch...
(Переключение выходных файлов контроля/файлов сбора данных)
Эти два параметра позволяют задать максимальный размер, ко-
торого могут достигать файлы сбора данных и уплотненные
файлы перед созданием нового файла. Если для обоих парамет-
ров выбрать маленькие значения, это приведет к чрезмерному
числу переключений файлов. Так как уплотненные файлы явля-
ются постоянными, это также может вызвать обилие небольших
файлов в системе. Если выбрать слишком большие значения,
это создаст ситуацию, при которой файлы сбора данных конт-
роля будут использовать много места на диске, даже если они
будут частично считаны демоном контроля, что должно было бы
вызвать их удаление. Размером уплотненных файлов контроля
можно управлять потому, что эти файлы остаются в системе до
редукции или удаления. Желательно, чтобы эти файлы имели
размер, приемлемый для работы с ними, в том числе для их
легкого сохранения и восстановления. По умолчанию для фай-
лов сбора данных берется значение 50К байт, а для уплотнен-
ных файлов - 1 мегабайт. Убедитесь, что максимальный раз-
мер, выбранный для уплотненных файлов, не превышает уста-
новленной в системе величины ulimit, контролирующей макси-
мальный размер, допустимый для пользовательского файла.
Compacted audit output files
(Уплотненные выходные файлы контроля)
Эта опция предусмотрена на случай, если нужно иметь и неуп-
лотненные файлы контроля. Особой необходимости использовать
эту опцию нет, так как уплотнение не требует много дополни-
тельного времени на обработку, а итоговая экономия места на
диске обычно больше 60 процентов. Алгоритм уплотнения со-
держится в пользовательском процессе демона контроля, а не
выполняется в ядре подсистемы.
.
- 5-31 -
Enable audit on system startup
(Включить контроль при запуске системы)
Если ответ положительный, то в результате контроль будет
начинаться автоматически при каждой перезагрузке системы.
Это поле выходит на экран только через опцию View; оно ус-
танавливается в соответствии с тем, был ли контроль включен
или выключен. Если контроль был выключен, то при запуске он
будет отключаться.
Shutdown gracefully on disk full
(Выполнить постепенный останов при заполнении диска)
Эта опция позволяет системе выполнить автоматический оста-
нов, если она исчерпала пространство на диске; это помогает
избежать порчи данных.
Change parameters for this/future session
(Изменить параметры для данной/следующей сессии)
Последние две опции на экране позволят вам динамически из-
менять текущую сессию и/или вносить изменения в постоянную
часть файла параметров контроля для следующих сессий.
Текущая статистика
Последняя опция, предусмотренная в меню Collection, - это
получение статистики текущей сессии контроля. Сюда входит инфор-
мация о номере текущей сессии, количестве файлов сбора данных и
уплотненных файлов, количестве записей, созданных механизмом
контроля ядра, и записей, созданных прикладными программами, и
др. Если в данный момент контроль не действует, статистика не
выводится.
Пример распечатки Summary:
+---------------------------------------------------------------
| *** Audit Subsystem Statistics ***
| (Статистика подсистемы контроля)
| Current Audit Session-6 (Текущая сессия контроля - 6)
| Current Collection File Sequence Number-1488
| (Порядковый номер текущего файла сбора данных)
| Total count of audit data written: 7659433
| (Общий счетчик записанных данных контроля)
| Total count of audit records written: 156666
| (Общий счетчик записанных контрольных записей)
| Audit records written by applications: 81
| (Контрольные записи, сделанные прикладными программами)
| Audit records written by system calls: 155083
| (Контрольные записи, сделанные системными вызовами)
| System calls not selected for audit: 751889
| (Системные вызовы, не отобранные для контроля)
| Total number of audit device reads: 2977
| (Общее число операций чтения на устройстве контроля)
| Total number of audit device writes: 324
| (Общее число операций записи на устройстве контроля)
| Total number of collection files: 1489
| (Общее число файлов сбора данных)
|
.
- 5-32 -
Включение/выключение контроля
Чтобы включить или выключить контроль, используйте следую-
щие выборы в sysadmsh:
Функция включения, используя текущий файл параметров конт-
роля, выполняет инициализацию подсистемы. Функция выключения
доступна из того же меню и вызывает постепенный выход из контро-
ля (когда все файлы сбора данных прочитаны демоном и уплотнены).
Затем демон прекращает работу, оставляя лишь журнальный файл
сессии контроля и уплотненные файлы сессии.
Помните, что если выключить контроль, а затем вновь его
включить, не перезагрузив систему, то это может вызвать потерю
некоторых данных процесса, нужных для поддержания состояния про-
цесса. Если контроль прекращен для модификации некоторых пара-
метров, учтите, что большинство параметров подсистемы можно мо-
дифицировать и в процессе контроля. Для обеих функций - включе-
ния и выключения - предусмотрены экраны для подтверждения, кото-
рое нужно сделать до завершения функции в sysadmsh. Когда конт-
роль включается или выключается, на экран выходит сообщение о
состоянии контроля в момент перезагрузки; если контроль выклю-
чен, то при запуске системы он будет выключен, а если включен,
то он будет вновь включен.
Сопровождение файлов контроля
Функции сопровождения файлов контроля доступны в sysadmsh
при следующем выборе:
Доступны следующие файловые функции:
ном носителе
зервного носителя
Сессия контроля состоит из журнального файла сессии и груп-
пы уплотненных файлов, сгенерированных между моментами включени-
я и выключения подсистемы контроля. Каждый файл сбора данных и
уплотненный файл, созданный во время сессии, получает уникальный
номер от этой сессии. После завершения сессии остается только
журнальный файл и уплотненные файлы. Функции сопровождения фай-
лов проверяют, какие сессии еще имеются в системе, и дают воз-
можность удалить уже не нужные сессии.
.
- 5-33 -
Вывод списка контрольных записей
Этот выбор дает немедленный ответ: выводится список файлов,
доступных в каталогах контроля.
Дублирование контрольных записей
Поскольку сессии контроля требуют много места на диске,
часто оказывается необходимым внести данные контроля в архив, а
затем либо сократить их, либо восстановить на некоторый период
времени, если они нужны для анализа проблем, которые нельзя выя-
вить немедленно. Такую возможность дает интерфейс дублирова-
ния/восстановления. Опция Backup требует в качестве ввода номер
сессии. Его можно получить, сгенерировав контрольный отчет (см.
ниже). Выбрав дублирование, вы должны выбрать и выходное уст-
ройство для дублирования. Им может служить любой съемный носи-
тель, доступный в системе.
Замечание
Контроль требует очень много места на диске. В зависимости
от количества пользователей в системе и от количества контроли-
руемых событий, может потребоваться еженедельное дублирование и
удаление файлов сессий. Если имеется расписание дублирования, то
выбор опции дублирования контроля, вероятно, не потребуется.
Вновь заметим, что очень важно удалить файлы после того, как они
продублированы в свободном пространстве на диске.
Точно так же сессии, которые были продублированы на съемных
носителях с помощью программы интерфейса, могут быть восстанов-
лены опцией Restore. Для этого вставьте носитель с сохраненными
файлами сессии в устройство восстановления и задайте имя уст-
ройства.
Удаление файлов
Для удаления сессий контроля предусмотрен выбор Delete.
Сессии можно внести в архив на резервном носителе, а затем уда-
лить, чтобы освободить место в файловой системе для других фай-
лов контроля. Сессии удаляются по номеру сессии. Типичный сцена-
рий должен включать составление отчета (см. ниже) для определе-
ния, какие сессии существуют и которые из них можно удалить. За-
тем номер сессии предоставляется опции Delete, которая удаляет
все файлы, связанные с этой сессией.
.
- 5-34 -
Составление контрольных отчетов
Чтобы посмотреть контрольный журнал какой-либо сессии, вы-
берите в sysadmsh:
Доступны следующие опции: