Системный журнал astra linux

Администрирование систем Linux. Журналирование событий

Глава 17. Журналирование событий

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

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

Во-вторых, рассматривается процесс настройки демона syslog, а также его тестирования с помощью утилиты logger .

Последняя часть главы в основном посвящена механизму ротации фалов журналов , а также содержит пояснения относительно использования команд tail -f и watch для отслеживания изменений файлов журналов .

17.1. Журналирование входов в систему

С целью облегчения процесса отслеживания входов пользователей в систему Linux может записывать необходимые данные в файлы журналов /var/log/wtmp , /var/log/btmp , /var/run/utmp и /var/log/lastlog .

17.1.1. Файл журнала /var/run/utmp (who)

Используйте утилиту who для просмотра содержимого файла /var/run/utmp. Эта утилита выводит информацию о пользователях, осуществивших вход в систему и в данный момент работающих с ней. Обратите внимание на то, что файл utmp находится в директории /var/run, а не /var/log.

17.1.2. Файл журнала /var/log/wtmp (last)

Содержимое файла журнала /var/log/wtmp обновляется силами программы login . Используйте утилиту last для просмотра содержимого файла журнала /var/run/wtmp.

Утилита last также может использоваться и для получения информации о последних перезагрузках.

17.1.3. Файл журнала /var/log/lastlog (lastlog)

Используйте утилиту lastlog для просмотра содержимого файла /var/log/lastlog.

17.1.4. Файл журнала /var/log/btmp (lastb)

Также существует утилита lastb , предназначенная для вывода содержимого файла /var/log/btmp . Содержимое этого файла обновляется программой login при вводе некорректного пароля, следовательно, он содержит информацию о неудачных попытках входа в систему. В файловых системах множества компьютеров данный файл может отсутствовать, в результате чего неудачные попытки входа в систему не будут журналироваться.

Обычно данный файл удаляют по той причине, что пользователи иногда по ошибке вводят свой пароль вместо имени учетной записи, следовательно, читаемый всеми файл является потенциальной угрозой безопасности системы. Вы можете активировать механизм журналирования неудачных попыток входа в систему, просто создав файл с упомянутым именем. В этом случае исполнение команды chmod o-r /var/log/btmp позволит повысить защищенность системы.

Информация о попытках ввода некорректных паролей при использовании утилит ssh, rlogin или su не сохраняется в файле /var/log/btmp. В нем сохраняется исключительно информация о попытках ввода некорректного пароля при работе с терминалами.

17.1.5. Журналирование входов в систему с использованием утилит su и ssh

В зависимости от дистрибутива в файловой системе вашего компьютера вы также можете обнаружить файл /var/log/secure , который заполнен сообщениями от вспомогательных модулей auth и/или authpriv демона syslog. Этот файл журнала должен содержать информацию о неудачных попытках входа в систему с использованием утилиты su и/или ssh. В некоторых дистрибутивах данная информация сохраняется в файле /var/log/auth.log , поэтому следует проверить конфигурацию демона syslog.

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

17.2. Демон журналирования событий syslogd

17.2.1. О демоне syslogd

Стандартный метод журналирования событий в Linux связан с использованием демона syslogd . Демон syslogd был разработан Eric Allman для использования совместно с агентом передачи почты sendmail, но вскоре стал одним из множества стандартных приложений Unix, архитектура которого гораздо позднее была описана в рамках стандарта RFC 3164. Демон принимает сообщения от множества приложений (и системных утилит) по протоколу UDP на порту 514 и может дописывать сообщения в файлы журнала, выводить их, показывать сообщения в терминалах и передавать данные журнала другим демонам syslogd, работающим на других машинах. Конфигурация демона syslogd осуществляется с помощью файла /etc/syslog.conf .

17.2.2. О демоне rsyslogd

Новый демон журналирования событий носит имя rsyslogd (reliable and extended syslogd — надежный и расширяемый syslogd) и использует файл конфигурации /etc/rsyslogd.conf . Обратная совместимость синтаксиса данного файла конфигурации сохранена.

В каждой строке файла конфигурации используется идентификатор системы (facility) для определения источника сообщения. Также она содержит описание приоритета (priority) для определения важности сообщения и описание действия (action) для принятия решения о том, что нужно сделать с данным сообщением.

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

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

17.2.4. Идентификаторы систем (facilities)

На странице руководства, доступной после исполнения команды man rsyslog.conf , можно найти информацию о различных стандартных идентификаторах систем для классификации сообщений от определенных демонов, таких, как mail, lpr, news и kern(el). Идентификаторы систем local0 и local7 могут использоваться для классификации сообщений от системных утилит (или любых подключенных к сети устройств, которые поддерживают механизм сообщений демона syslogd). Ниже приведен список всех идентификаторов систем из файла конфигурации rsyslog.conf версии 1.3. Ключевое слово security является устаревшим.

17.2.5. Описания приоритетов (priorities)

Наиболее важное сообщение может иметь описание приоритета emerg , вслед за которыми идут описания приоритетов alert и crit . Сообщения с наиболее низкими приоритетами имеют описания приоритетов info и debug . При указании минимального приоритета для журналирования сообщений будет осуществляться журналирование сообщений и с более высоким приоритетом. Вы можете использовать префикс = перед описанием приоритета для получения только тех сообщений, которые соответствуют этому описанию. Также вы можете использовать описание приоритета .none для предотвращения выполнения определенного действия при приеме любого сообщения с определенным идентификатором системы.

Ниже приведен список приоритетов в порядке возрастания. Ключевые слова warn, error и panic являются устаревшими.

17.2.6. Действия (actions)

Стандартным действием является отправка сообщения пользователю, имя которого записано в качестве действия. Если в качестве действия приводится строка с префиксом / , демон rsyslogd будет отправлять сообщение в файл (который может быть как обычным файлом, так и файлом устройства принтера или терминала). Префикс @ позволяет осуществлять отправку сообщения другому серверу с исполняющимся на нем демоном syslogd. Ниже приведен список всех возможных действий.

root,user1 передача сообщений пользователям с именами из списка, разделенными с помощью запятой

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

Ниже приведен пример фрагмента файла конфигурации /etc/rsyslog.conf для обработки нестандартных сообщений с идентификатором системы local4.

17.2.8. Перезапуск демона rsyslogd

Не забудьте перезапустить демон после модификации его файла конфигурации.

17.3. Утилита logger

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

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

17.4. Просмотр журналов событий

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

Также вы можете автоматически повторять вызовы утилит, размещая перед ними вызов утилиты watch . Примером может служить следующая команда:

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

17.5. Ротация журналов событий

Размер большинства файлов журналов событий неуклонно растет. Для ограничения размеров этих файлов может использоваться утилита logrotate , предназначенная для ротации, сжатия, удаления и отправки по электронной почте файлов журналов событий. Дополнительная информация об утилите logrotate может быть получена из основного файла конфигурации /etc/logrotate.conf . Отдельные файлы конфигурации могут находиться в директории /etc/logrotate.d/ .

Ниже приведено содержимое стандартного файла конфигурации logrotate.conf из состава дистрибутива Red Hat.

17.6. Практическое задание: журналирование событий

1. Выведите содержимое файла журнала /var/run/utmp с помощью специально предназначенной для этой цели утилиты (без использования утилиты cat или текстового редактора vi).

2. Выведите аналогичным образом содержимое файла журнала /var/log/wtmp.

3. Используйте утилиты lastlog и lastb и сделайте вывод о различии этих утилит.

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

5. Настройте демон журналирования событий syslogd таким образом, чтобы сообщения с идентификатором системы и приоритетом local4.error и сообщения с более высокими приоритетами и этим же идентификатором системы размещались в файле журнала /var/log/l4e.log, а сообщения с идентификатором системы и исключительным приоритетом local4.info — в файле журнала /var/log/l4i.log. Проверьте корректность настройки с помощью утилиты logger!

6. Настройте демон журналирования событий syslogd таким образом, чтобы в файле журнала /var/log/Mysu.log размещались все сообщения, сгенерированные утилитой su в ходе получения привилегий пользователя root. Проверьте корректность настройки!

7. Настройте отправку сообщений с идентификатором системы local5 на сервер вашего соседа, на котором исполняется демон syslogd. Проверьте корректность настройки.

8. Разработайте сценарий, который будет вызывать утилиту logger для отправки сообщений с идентификатором системы local4 демону журналирования событий через каждые 15 секунд (текст сообщений должен отличаться). Используйте команду tail -f для отслеживания изменений ваших локальных файлов журналов событий.

17.7. Корректная процедура выполнения практического задания: журналирование событий

1. Выведите содержимое файла журнала /var/run/utmp с помощью специально предназначенной для этой цели утилиты (без использования утилиты cat или текстового редактора vi).

2. Выведите аналогичным образом содержимое файла журнала /var/log/wtmp.

3. Используйте утилиты lastlog и lastb и сделайте вывод о различии этих утилит.

lastlog : выводит информацию о последних входах пользователей в систему

lastb : выводит информацию о неудачных попытках входа в систему

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

Дистрибутивы Ubuntu 9.10 и Debian Lenny переведены на использование демона журналирования событий rsyslog.

5. Настройте демон журналирования событий syslogd таким образом, чтобы сообщения с идентификатором системы и приоритетом local4.error и сообщения с более высокими приоритетами и этим же идентификатором системы размещались в файле журнала /var/log/l4e.log, а сообщения с идентификатором системы и исключительным приоритетом local4.info — в файле журнала /var/log/l4i.log. Проверьте корректность настройки с помощью утилиты logger!

6. Настройте демон журналирования событий syslogd таким образом, чтобы в файле журнала /var/log/Mysu.log размещались все сообщения, сгенерированные утилитой su в ходе получения привилегий пользователя root. Проверьте корректность настройки!

Данная директива позволит записывать в файл журнала событий не только данные, касающиеся использования утилиты su .

7. Настройте отправку сообщений с идентификатором системы local5 на сервер вашего соседа, на котором исполняется демон syslogd. Проверьте корректность настройки.

В дистрибутиве RHEL5 следует отредактировать файл /etc/sysconfig/syslog для активации режима приема сообщений от удаленных узлов.

В дистрибутиве RHEL7 следует раскомментировать две следующие строки файла /etc/rsyslog.conf для ‘приема сообщений syslog с использованием протокола UDP’.

В Debian/Ubuntu следует отредактировать файл /etc/default/syslog или /etc/default/rsyslog .

На клиентском компьютере:

8. Разработайте сценарий, который будет вызывать утилиту logger для отправки сообщений с идентификатором системы local4 демону журналирования событий через каждые 15 секунд (текст сообщений должен отличаться). Используйте команду tail -f для отслеживания изменений ваших локальных файлов журналов событий.

Источник

Вы используете устаревшую версию браузера.
Обновите Ваш браузер для надежной и безопасной работы.

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

В данной статье описывается новый вариант реализации системного киоска в Astra Linux Special Edition, который в эксплуатационной документации называется kiosk2. Будут приведены основные особенности указанного решения и его место в комплексе средств защиты информации операционной системы

Операционная система Astra Linux позволяет реализовать многоуровневую модель защиты от эксплуатации уязвимостей за счет одновременного применения мандатного контроля целостности, замкнутой программной среды и ограничения программной среды посредством механизмов системного киоска (рис. 1).

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

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

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

Второй ключевой механизм контроля целостности – это подсистема замкнутой программной среды, реализованная посредством модуля ядра digsig_verif.

Инструменты замкнутой программной среды (ЗПС) предоставляют возможность внедрения цифровой подписи в исполняемые файлы формата ELF, входящие в состав устанавливаемого ПО и в расширенные атрибуты файловой системы. Механизм ЗПС позволяет реализовать запрет на открытие файлов и загрузки модулей ядра, поставленных на контроль, с неверной электронной подписью (ЭП) или без ЭП.

+file r o: /usr/bin
+file wr ou: /dev/tty
+file r o: /etc/ld.so.cache
+file r o: /bin/bash
+file r o: /lib/terminfo/*/*
+link r o: /lib/x86_64-linux-gnu/libpthread.so.0
+file r o: /etc/init.d
+file r o: /etc/bash_completion.d/*
+file r o: /etc/profile

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

Таким образом, формируется доверенная программная среда.

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

Степень ограничений прав пользователей задается специально в создаваемом профиле киоска.

Инструментарий Astra Linux позволяет сформировать профиль в автоматическом режиме за счет:

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

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

Сам «системный киоск» работает по принципу конечного автомата.

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

При этом дальнейшая обработка правил осуществляется файловым фильтром в модуле ядра parsec.

«Файловый фильтр» в модуле ядра сопоставляет:

• комбинацию режима открытия файла (read/write/create);
• флага владения файлом (u=владелец o=остальные);
• имени файла со списком разрешенных режимов+имён для данного пользователя (uid).

В системе независимо и глобально переключаются настройки сигнализации о нарушении правил (complain) и предотвращения нарушения правил (enforce).

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

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

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

Включение контроля доступа	1. Включение контроля доступа с сохранением данного состояния до перезагрузки ОС: echo 1 | sudo tee /sys/module/parsec/parameters/uc_enforce
	2. Включение контроля доступа с сохранением данного состояния после перезагрузки ОС: echo 1 | sudo tee /etc/parsec/kiosk2_enforce
Отключение контроля доступа	1. Отключение контроля доступа с сохранением данного состояния до перезагрузки ОС: echo 0 | sudo tee /sys/module/parsec/parameters/uc_enforce
	2. Отключение контроля доступа с сохранением данного состояния после перезагрузки ОС: echo 0 | sudo tee /etc/parsec/kiosk2_enforce
Включение режима протоколирования	1. Включение протоколирования с сохранением данного состояния до перезагрузки ОС: echo 1 | sudo tee /sys/module/parsec/parameters/uc_complain
	2. Включение протоколирования с сохранением данного состояния после перезагрузки ОС: echo 1 | sudo tee /etc/parsec/kiosk2_complain
Отключение режима протоколирования	1. Отключение протоколирования с сохранением данного состояния до перезагрузки ОС: echo 0 | sudo tee /sys/module/parsec/parameters/uc_complain
	2. Отключение протоколирования с сохранением данного состояния после перезагрузки ОС: echo 0 | sudo tee /etc/parsec/kiosk2_complain

Таким образом мы последовательно:

• а) разделяем доверенную среду по уровням целостности (МКЦ);
• б) фиксируем доверенную среду (ЗПС);
• в) реализуем ограниченную программную среду для пользователя, от которого работает приложение для встроенного решения (киоск).

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

Из особенностей реализации системного киоска можно отразить следующие моменты:

• 1. Работает с шаблонами имён файлов, а не только с фиксированными именами. Это важно на фоне использования средства инициализации systemd, которое обращается при работе с пользователем к файлам с заранее неизвестными именами.
• 2. Предсказуемо реагирует на переименования файлов (при фильтрации учитывается только новое имя, разрешения не «прилипают» к inode файла и не сохраняются при переименовании).
• 3. Работает одинаково со всеми файловыми системами (в том числе proc, sysfs), не зависит от поддержки acl на файловой системе и от ее драйвера.
• 4. Позволяет фильтровать доступ к собственным файлам пользователя, сохраняя при этом общую работоспособность системы.
• 5. Не затрагивает процессы, не выполняющиеся от пользователей с ограниченной средой исполнения, например, системные сервисы под системными аккаунтами.

Для упрощения администрирования системного киоска разработчиками Astra Linux реализована графическая утилита fly-admin-kiosk, которая позволяет управлять системным киоском в графическом режиме, легко создавать и редактировать профили.

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

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

Источник: Журнал «Системный администратор»

Источник