Введение в лог-файлы Linux

Наконец сегодня вырвал из работы какое-то время, чтобы посвятить его очень полезной информации. Речь пойдет о системных логах-logs Ubuntu (журналах). Так как читкой логов занимаются в основном системные администраторы, то я эту статью размещаю в разделе «Администрирование Ubuntu » .

Выводы

В каталоге /var/log вы можете найти всю необходимую информацию о работе Linux. Из сегодняшней статьи вы достаточно узнали, чтобы знать где искать, и что искать. Теперь просмотр логов в Linux не вызовет у вас проблем. Если остались вопросы, задавайте в комментариях!

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

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

Подсистема идентификации

Подсистемой учётных записей пользуется подсистема идентификации, которая в Linux имеет модульную структуру и называется PAM (Pluggable Authentication Modules, т. е. Подключаемые Модули Идентификации). Идея PAM — в том, чтобы унифицировать и, вместе с тем, сделать более гибкой любые процедуры идентификации в системе — начиная от команды login и заканчивая доступом к файлам по протоколу, скажем, FTP. Для этого недостаточно просто написать «библиотеку идентификации» и заставить все программы её использовать. В зависимости от того, для чего производится идентификация, условия, при которых оня будет успешной, могут быть более или менее строгими, а если она прошла успешно, бывает нужно выполнить действия, связанные не с определением пользователя, а с настройкой системы.

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

[[email protected] root]# ls /etc/pam.d chpasswd groupdel other system-auth userdel chpasswd-newusers groupmod passwd system-auth-use_first_pass usermod crond login sshd user-group-mod groupadd newusers su useraddПример 8. Подключаемые Модули Идентификации (PAM)

В PAM определено четыре случая, требующие идентифкации: auth — собственно идентификация, определние, тот ли пользователь, за кого он себя выдаёт, account — определение, всё ли хорошо с учётной записью пользователя, password — изменение пароля в учётной записи, и session — дополнительные действия непосредственно перед или непосредственно после того, как пользователь получит доступ к затребованной услуге. Эти значения принимает первое поле любого файла настройки из pam.d, а в третьем поле записывается модуль, который проверяет какой-нибудь из аспектов идентификации. Второе поле определяет, как успех или неуспех проверки одного модуля влияет на общий успех или неуспех идентификации данного типа (например, required означает, что в случае неуспеха модуля проверка пройдена не будет). Четвёртое и последующие поля отведены под параметры модуля.

[[email protected] root]# cat /etc/pam.d/login auth include system-auth auth required pam_ account include system-auth password include system-auth session include system-auth session optional pam_ [[email protected] root]# cat /etc/pam.d/system-auth auth required pam_ shadow count=8 nullok account required pam_ shadow password required pam_ use_authtok shadow count=8 write_to=tcb session required pam_Пример 9. Настройка PAM для login

Такие настройки login обнаружил Мефодий на своём компьютере. Во всех четырёх случаях используется включаемый файл system-auth (к нему обращаются и другие службы), с некоторыми дополнениями: во время идентификации pam_ дополнительно проверяет, не запрещено ли пользователям регистрироваться вообще (как это бывает за несколько минут до перезагрузки системы), а перед входом в систему и после выхода из неё pam_ выполняет описанную в лекции Права доступа «передачу прав на владение устройствами» (и, соответственно, лишение пользователя этих прав).

Каталог /etc/pam.d — замечательный пример того, как профиль определяет поведение системы. В частности, четыре первых строки из system-auth показывают, что в этом дистрибутиве используется не просто «теневой» файл паролей, а схема TCB, описанная в лекции Права доступа. (Как уже известно Мефодию, в этой схеме вместо общего для всех /etc/shadow задействованы файлы вида /etc/tcb/входное_имя/shadow, причём права доступа к ним устроены таким образом, чтобы при выполнении команды passwd можно было обойтись без подмены пользовательского идентификатора на суперпользовательский).

Вывод лога доступа к файлам samba в отдельный файл

Нам нужно отредактировать файл конфигурации rsyslog для направления вывода лога самбы в отдельный файл. В CentOS 7 открываем файл /etc/ и добавляем в самый конец такую строку:

# mcedit /etc/

-/var/log/samba/

Этим параметром мы направили вывод логов аудита посещений в отдельный файл Если все оставить как есть, то информация о посещениях будет писаться как в отдельный файл, так и в общий системный. Чтобы в общий не писалось, редактируем еще одну строку, добавляя туда выделенный фрагмент:

*.info;;;; /var/log/messages

Сохраняем файл и перезапускаем rsyslog.

# systemctl restart rsyslog

Теперь все нормально. Все логи посещений шары на samba будут складываться в отдельный файл и только туда. Если у вас есть желание хранить логи на удаленном сервере, то воспользуйтесь моей статье на эту тему — настройка syslog-ng для удаленного сбора логов. Это сделать быстро и просто. Зачастую это может быть оправданно и удобно, особенно с точки зрения безопасности и не только логов от самбы.

Читайте также:  Apple выпустили первую бета-версию iOS 12.2 beta 1 для разработчиков

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

# mcedit /etc/logrotate.d/samba

/var/log/samba/ { daily notifempty olddir /var/log/samba/old missingok sharedscripts copytruncate rotate 90 compress }

Я храню логи за последние 90 дней, ротацию делаю раз в день и складываю старые логи в отдельную папку. Если у вас в конфигурации есть параметр с маской, который захватывает сразу все файлы в директории /var/log/samba, например вот так:

/var/log/samba/*

То либо вынесите лог-файл с аудитом в отдельную директорию, либо измените маску.

Создание правил

Для добавления и настройки правил используется команда auditctl. Вот список её опций:

  • -l — вывести список имеющихся правил;
  • -а — добавить новое правило;
  • -d — удалить правило из списка;
  • -D — удалить все имеющиеся правила.

Чтобы создать новое правило, нужно выполнить команду вида:

$ auditctl -a <список>, <действие> -S <имя системного вызова> -F <фильтры>

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

  • task — события, связанные с созданием новых процессов;
  • entry — события, которые имеют место при входе в системный вызов;
  • exit — события, которые имеют место при выходе из системного вызова;
  • user — события, использующие параметры пользовательского пространства;
  • exclude — используется для исключения событий.

Затем указывается, что нужно делать после наступления события. Здесь возможны два варианта: always (события будут записываться в журнал) и never (не будут).

После опции -S идёт имя системного вызова, при котором событие нужно перехватить (open, close и т.п.).

После опции -F указываются дополнительные параметры фильтрации. Например, если нам требуется вести аудит обращений к файлам из каталога /etc, правило будет выглядеть так:

$ auditctl -a exit,always -S open -F path =/etc/

Можно установить и дополнительный фильтр:

$ auditctl -a exit,always -S open -F path =/etc/ -F perm = aw

Аббревиатура aw означает следующее: а — изменение атрибута (attribute change), w — запись (write). Формулировка perm = aw указывает, что для директории /etc нужно отслеживать все факты изменения атрибутов (а — attribute change) и w (w — write).

Читайте также:  Как я обхожу любые блокировки в интернете

При настройке слежения за отдельными файлами можно опустить опцию -S, например:

$ auditctl -a exit,always -F path =/etc/ -F perm = aw

Ротация логов

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

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

Можно изменить частоту замены журнала, отредактировав файл /etc/

Ниже показан пример записей из файла :

#rotate log files weekly

#keep 4 weeks worth of log files

create new log files after rotating

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

При замене файла журнала на его месте создается новый файл.

Каждое приложение может иметь свою собственную политику ротации. Это, определенно, полезно, потому что файл системного журнала будет расти быстрее, чем файл журнала cups.

Политики ротации хранятся в /etc/logrotate.d. У каждого приложения, для которого требуется собственная политика ротации, в папке с приложением будет храниться файл конфигурации.

Например, инструмент apt содержит файл в папке logrotate.d со следующим содержанием:

/var/log/apt/ { rotate 12 monthly compress missingok notifempty }

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

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

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

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

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

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