Lastlog linux что это

Обновлено: 04.07.2024

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

Одним из самых известных случаев использования файлов протоколов для обнаружения вторжения злоумышленника является история поимки специалистом по компьютерной безопасности Тсуомо Шимомура знаменитого хакера Кевина Митника. Вот один абзац из статьи [1], описывающей, как это произошло.

"В Рождество, когда Шимомура поехал на каникулах покататься на лыжах в Неваду, кто-то (мы уже знаем, кто именно) проник в его суперзащищенный домашний компьютер в Солана Бич, Калифорния, и начал копировать его файлы - сотни засекреченных файлов. Один магистрант из Центра Суперкомпьютеров в Сан Диего, где работал Шимомура, заметил изменения в системных "журнальных" (log) файлах и быстро сообразил, что происходит. Все это оказалось возможным благодаря тому, что Шимомура установил на свой компьютер программу, автоматически копирующую "журнальные" записи на дублирующий компьютер в Сан Диего. Студент позвонил Шимомуре, и тот помчался домой, чтобы провести инвентаризацию украденного."

Я не буду рассказывать здесь всю эту историю, нам важно отметить только то, что анализ протоколов работы системы послужил основой для успеха проведенного расследования неправомерных действий. Более подробное описание того, как проводятся такие расследования, вы сможете найти в статье [2]. Но, чтобы суметь воспользоваться результатами протоколирования, надо понимать, как создаются протоколы, где они хранятся и что из них можно извлечь. Рассмотрению всех этих вопросов и посвящена настоящая статья.

Чтобы убедиться, что демоны syslogd и klogd запущены в вашей системе, выполните команду ps -ax | grep log. У меня эта команда дала следующий результат: Две первые строчки как раз и сообщают, что в системе запущены демоны протоколирования.

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

Прописные и строчные буквы в поле "selector" не различаются. Можно также использовать числа (см. /usr/include/syslog.h). Кроме перечисленных в таблице 1 категорий можно указывать mark (регулярные временные метки) и security (устаревший синоним для auth). Кроме перечисленных в таблице 2 значений приоритета можно использовать warn (синоним для warning), error (синоним для err), panic (синоним для emerg).

Файл протокола /var/log/messages

Примерно такую же структуру имеют и записи в других файлах протоколов, упоминаемых в файле /etc/syslog.conf.

Команды logger и tailf

Протоколирование в сети

Однако, для организации такого "сетевого протоколирования" необходимо предпринять некоторые дополнительные усилия.

Если в вашей сети имеется несколько доменов, которые обслуживаются одним сервером протоколирования, то не удивляйтесь тому, что в протоколе на сервере будут указаны полные имена клиентов (с указанием домена). Правда, при запуске syslogd можно использовать опции -s список_доменов или -l список_хостов, которые обеспечивают замену в протоколе полных имен хостов на их краткие имена (без указания домена).

Не забудьте после корректировки опций запуска и файла /etc/syslog.conf перезапустить демон, поскольку, в отличие от cron, sysklogd не перечитывает конфигурационные файлы автоматически.

Опции запуска демона syslogd

Раз уж мы коснулись в предыдущем подразделе вопроса задания параметров запуска демона syslogd, давайте рассмотрим этот вопрос подробнее. Как уже сказано, запускаются оба демона протоколирования на этапе инициализации системы, а конкретнее - посредством скрипта /etc/rc.d/init.d/syslog (для которого, как и для скриптов запуска других сервисов, создаются символьные ссылки в каталогах /etc/rc.d/rc?.d/). Однако для того, чтобы задать пераметры запуска, нет необходимости корректировать этот скрипт, потому что начиная с версии 7.2 в дистрибутиве Red Hat опции запуска обеих демонов считываются из отдельного конфигурационного файла /etc/sysconfig/syslog. Приведем краткий перечень возможных параметров для демона syslogd.

После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.

SIGHUP - перезапуск демона (реинициализация); все открытые файлы закрываются, демон стартует заново, перечитывая при этом свой конфигурационный файл.
SIGTERM - завершение работы.
SIGINT, SIGQUIT - если включен режим отладки (опция -d), сигналы игнорируются, в противном случае - завершение работы.
SIGUSR1 - включить/выключить режим отладки (работает только в том случае, если демон был запущен с ключом -d).

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

Файл dmesg и команда dmesg

Как уже говорилось, файлы протоколов, упоминаемые в файле /etc/syslog.conf обычно располагаются в каталоге /var/log и его подкаталогах. Но, если заглянуть в этот каталог, то мы обнаружим там несколько файлов, которые в /etc/syslog.conf не упоминались. Давайте рассмотрим их назначение. И начнем, пожалуй, с файла dmesg.

Файлы lastlog, wtmp и utmp

Кроме файла dmesg в каталоге /var/log/ есть еще два файла, не упоминавшихся в /etc/syslog.conf, но имеющих непосредственное отношение к протоколированию - это файлы lastlog и wtmp. Но заглядывать в них так же, как мы просматривали файл /var/log/messages не имеет смысла - вы ничего не поймете. Дело в том, что информация в эти файлы записывается в особом формате, и просматривать ее надо с помощью специальных программных средств. Но сначала надо сказать несколько слов о назначении этих файлов.

В отличие от файла /var/log/lastlog, который содержит записи о времени последнего входа в систему каждого пользователя, в файле /var/log/wtmp запоминаются все входы и выходы пользователей в систему с момента создания этого файла. Как и в файле lastlog, записи в /var/log/wtmp делаются в специальном формате, так что просматривать их можно только с помощью специальных команд. Но, прежде чем рассказывать об этих командах, скажем, что существует еще один файл, содержащий записи о логировании пользователей - это файл /var/run/utmp. Этот файл содержит информацию о том, кто из пользователей работает в системе в данный момент.

Вот теперь можно рассказать о том, как просматривать информацию о работающих или ранее работавших в системе пользователях. Основной командой для этого является команда last. Она выводит все записи из файла /var/log/wtmp, причем указывается имя пользователя, указание на терминал, с которого работал пользователь, время входа пользователя в систему и время выхода его из системы, а также продолжительность сеанса работы пользователя в системе. В случае, если работа пользователя прервалась только из-за отключения самой системы, вместо времени выхода пользователя стоит слово "down" (по этим строкам легко определить время остановки системы). Время повторного запуска отображается отдельными строками, начинающимися словом "reboot".

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

Команда lastlog форматирует и выводит содержание файла /var/log/lastlog. Будут выведены поля имя пользователя, имя терминала, с которого вошел пользователь и время последнего входа в систему. По умолчанию (когда команда введена без параметров) элементы файла /var/log/lastlog будут выводиться в порядке номеров идентификаторов пользователей. Если указать параметр -u login-name, будет выведена только информация о времени последнего входа указанного пользователя. Указав параметр -t days, Вы получите только записи за последние days дней. Если пользователь вообще пока не заходил в систему, то вместо имени терминала и времени последнего входа будет указана строка "**Never logged in**".

Для вывода информации о том, кто работает в текущий момент в системе, используются команды w, who и users. Команда users используется тогда, когда вы хотите только знать, кто из пользователей работает в данный момент в системе, но не интересуетесь тем, с какого терминала он подключился и что делает. Если вы хотите знать, кто с какого терминала вошел в систему, используйте команду who. Эта команда выводит информацию из файла /var/run/utmp. Можно заставить ее выводить данные из файла /var/log/wtmp (или любого другого файла, для которого это имеет смысл), если указать имя этого файла в командной строке. Но в выводе вы все равно увидите только имя пользователя, указание на терминал, с которого вошел пользователь, время входа и, в случае входа с удаленного компьютера, имя этого компьютера.

Как уже говорилось, команда w выводит информацию, сохраненную в файле utmp. Между прочим, руководство man утверждает, что простые пользователи должны быть лишены права записи в файл utmp, так как многие системные программы (по каким-то необъяснимым причинам) зависят от его целостности. Вы рискуете спутать системные файлы статистики и внести изменения в системные файлы, если Вы предоставите любому пользователю возможность производить записи в файл utmp .

Файлы протоколов других программ

Samba-сервер, кроме основного протокола работы сервера, создает в подкаталоге /var/log/samba целый ряд файлов протоколов на разные случаи, в частности отдельные файлы для каждого из пользователей, которым разрешено использовать ресурсы, предоставляемые этим сервером. Из одного такого файла и взяты следующие две записи: Приведенные примеры показывают, что если немного уметь читать по-английски и иметь некоторое представление о структуре записей, из файлов протоколов можно извлечь массу полезной информации. Только извлекать ее приходится из целых залежей "пустой породы" - огромных последовательных файлов протоколов, что представляет собой нетривиальную задачу. Поэтому были разработаны специальные программные средства для анализа протоколов.

Средства для обработки протоколов

Различных программ и скриптов для анализа протоколов разработано достаточно много. Я ограничусь краткой характеристикой двух таких средств: logwatch и swatch.

logwatch - это скрипт на языке Perl, входящий в стандартный дистрибутив Red Hat Linux. Как раз во время подготовки настоящей статьи на сайте разработчика (а им является Кирк Бауер) была выложена версия 4.1 этой программы [7].

Основной способ использования logwatch состоит во включении ссылки на основной скрипт (/etc/log.d/scripts/logwatch.pl) в директорию /etc/cron.daily, что вызывает ежедневное выполнение logwatch с параметрами по умолчанию. Ссылке дают имя, которое начинается с "00" (например, 00-logwatch), чтобы скрипт запускался до logrotate.

Но можно запустить скрипт и из командной строки. Конечно, если вы не меняли параметр вывода информации, то результат его работы надо искать в почтовом ящике суперпользователя. Если же вы хотите видеть эти результаты на экране, то необходимо задать в командной строке параметр --print - выдавать отчет на stdout.

Общий формат запуска скрипта:

/etc/log.d/scripts/logwatch.pl [--detail уровень] [--logfile группа-журналов] [--service имя-сервиса] [--print] [--mailto адрес] [--save имя-файла] [--archives] [--range интервал-дат]

LogDir - директория, относительно которой рассматриваются имена файлов;
MailTo - кому отправлять отчет;
Print - вместо посылки отчета по почте выдать его на stdout;
Save - вместо посылки отчета по почте сохранить его в указанном файле;
Archives - обрабатывать не только текущие версии журналов, но и созданные logrotate старые копии;
Range - обрабатывать указанный временной интервал: All, Today, Yesterday (вчерашние календарные сутки);
Detail - уровень подробности отчета: от 0 до 10 или Low, Med, High;
Service - All или имя фильтра из /etc/log.d/scripts/services/ (можно указывать несколько фильтров);
LogFile - All или имя группы журналов (можно указывать несколько групп).

Более подробную информацию о скрипте logwatch вы найдете в [8,9].

В статье [10] описан другой скрипт для обработки файлов протоколов, который входит в состав дистрибутива Mandrake Linux. Скрипт этот называется swatch ("Simple WATCHer") и тоже написан на Perl.

Управление работой swatch осуществляется с помощью единственного конфигурационного файла, по умолчанию $HOME/.swatchrc. Этот файл содержит образцы текста (в форме регулярных выражений), которые swatch будет искать в файлах протоколов. Вслед за каждым таким образцом указывается действие, которое swatch должен предпринять в том случае, если он обнаружит текст, соответствующий шаблону.

Ротация файлов протокола

Вы, конечно, понимаете, что если система интенсивно используется, то файлы протоколов быстро растут. Что влечет пустую трату дискового пространства. И возникает проблема "укрощения" протоколов. В Red Hat Linux эта проблема решается скриптои logrotate, который расположен в каталоге /etc/cron.daily, а, следовательно, запускается демоном cron ежедневно. Этот скрипт позволяет обрабатывать не только журналы системы syslog, но и любых других программ.

Перечень файлов для обработки скриптом logrotate и параметры этой обработки определяются конфигурационными файлами, которых может быть несколько. Имена конфигурационных файлов задаются в командной строке запуска скрипта (о параметрах запуска см. ниже). В Red Hat Linux по умолчанию в качестве конфигурационных файлов для logrotate используется файл /etc/logrotate.conf, который может иметь примерно такой вид:

В приведенном примере конфигурационного файла сначала описываются глобальные параметры, а затем в отдельной секции - параметры обработки файлов /var/log/wtmp и /var/log/lastlog. Кроме того, среди глобальных параметров дается ссылка на директорию /etc/logrotate.d, в которую каждый пакет записывает локальные параметры для своих журналов.

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

Если задан параметр compress, то старые версии сжимаются с помощью gzip, а если указано nocompress - то не сжимаются. Параметр compresscmd позволяет указать, какая программа сжатия будет использоваться (по умолчанию - gzip), а uncompresscmd задает программу разжатия (по умолчанию - ungzip). compressoptions задает параметры программы сжатия; по умолчанию - "-9", т.е. максимальное сжатие для gzip. С помощью параметра compressext можно изменить суффикс для сжатых файлов, а параметр extension суффикс задает суффикс, добавляемый к именам файлов при ротации (перед суффиксом сжатия).

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

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

-d - отладочный режим, реальных изменений не производится,
-f - производить изменения, даже если logrotate не видит необходимости - используется при изменениях в списке обрабатываемых журналов,
-s имя-файла-состояния - в этом файле (по умолчанию - /var/lib/logrotate.status) запоминаются имена файлов, которые были обработаны скриптом и даты, когда была произведена его обработка,

Дополнительные замечания

Во-первых, рассматривается механизм журналирования входов в систему: обсуждаются способы получения информации о том, кто, когда и с какого узла осуществил вход в систему. Также рассматриваются способы получения информации о том, кому не удалось осуществить вход в систему, кто не смог воспользоваться утилитой 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

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

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

17.2.1. О демоне syslogd

17.2.2. О демоне rsyslogd

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

17.2.3. Модули

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

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

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

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

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

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

17.2.7. Конфигурация

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

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

17.3. Утилита 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.

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

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

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

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

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

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

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

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

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

Наступает момент, когда системному администратору необходимо определить дату последнего входа в систему каждого из пользователей, а также подготовить список тех аккаунтов, которые этого так и не сделали. Если б Вы ранее не знали команду lastlog, то удивились бы, насколько легко и быстро она может предоставить Вам эти данные.

Если же Вы все-таки задумались об этом, то не забывайте, что данная команда — это также один из хороших методов проверки безопасности, которую можно проводить на серверах под управлением Linux систем. Она поможет Вам установить потенциальные проблемы. Те аккаунты, которые были неактивны в течение долгого времени, например, может означать, что они больше не нужны и могут быть отключены. А вот аккаунты, которые были активны в то время, когда их пользователи должны были быть в отпуске где-нибудь на Багамах — могут намекать о проблемах с безопасностью на сервере.

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

Что бы посмотреть данные по конкретному пользователю необходимо использовать следующую команду last xxx, где ххх — логин пользователя. А использование команды сортировки head с параметром 5 в свою очередь поможет Вам отобразить на экране только 5 последних результатов:

Как “глубоко” Вы можете просмотреть историю последних команд зависит от того как долго существует файл wtmp. Например, Вы можете использовать утилиту logrotate, которая следит за файлами протоколов и обеспечивает так называемую ротацию этих файлов в случае, если они превысили указанный размер (или по истечению указанного временного интервала). Также она позволяет поддерживать более одного wtmp файл и имеет запись в logrotate.conf наподобие этой:

Даже имея несколько файлов wtmp, данные некоторых Ваших пользователей могут просто не отобразиться. Если в результате индивидуальной проверки пользователя Вы никаких данных по нем не получили, то это означает, что записей по конкретному пользователю в файле wtmp нет. Чтобы узнать дату создания файла wtmp, следует ввести в консоли last mia:

Лучшим способом найти информацию о последнем входе в систему для каждого пользователя является использование команды lastlog. Если какой-либо из пользователей никогда не авторизировался в системе, то вместо имени терминала и времени последнего входа будет указана строка **Never logged in**. Если результат вывода будет состоять из большого количества строк, то можете использовать еще и команду more, которая в отличие от команды less, выведет содержимое файла на экран отдельными страницами. Результат будет выглядеть примерно так:

Многие из нас возможно будут удивлены, увидев, что bin, daemon, adm и другие служебные учетные записи никогда не авторизировались в системе. Это и в самом деле так, и означает лишь только то, что для оболочек, назначенных в момент регистрации пользователей (login shells), задан параметр /sbin/nologin, что делает авторизацию невозможной. Остальные данные по входам показывают дату и время системы, с которой была осуществлена авторизация.

Чтобы создать список всех учетных записей, которые никогда не входили в систему, стоит использовать следующий набор команд. С командой lastlog мы уже знакомы и я на ней подробно останавливаться не буду, дальше стоит добавить утилиту grep для поиска по ключевому слову, в нашем случаи это слово Never, а для того, чтобы выводился только первый столбец с данными, можно воспользоваться утилитой awk со следующим синтаксисом — '':

Записи в lastlog перечислены согласно идентификаторов пользователей (User identifier — UID) — от суперпользователя (root) до пользователя с самым большим значением UID в Вашем файле /etc/passwd. Это связано с форматом самого файла lastlog. В отличие от большинства лог-файл Unix, в файле lastlog для записи логов каждого пользователя резервируется отдельное место, и в свою очередь место каждой записи проиндексировано по UID. После этого файлы будут фиксированного размера, особенно если Ваша система имеет аккаунты с наивысшим лимитом своего возможного диапазона UID — такого как 16-битный UID 65536. Также при этом образуется большой объем неиспользуемого пространства, правда только в том случаи если Ваши идентификаторы не являются строго последовательными. Если же Ваша система поддерживает 32-битные UIDы, файл может быть очень большим и иметь 4 294 967 296 (232) различных значений идентификаторов.

Каждая запись в файле lastlog содержит имя пользователя, имя терминала, с которого вошел пользователь и время последнего входа в систему. Запись для суперпользователя (UID 0) в верхней части файла может иметь следующий вид:

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

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

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

Основные лог файлы

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

Большинство же лог файлов содержится в директории /var/log .

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

/var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
/var/log/emerge.log — Для ebuild -ов установленных из Portage с помощью emerge в Gentoo Linux.
/var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

/var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last .
/var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2 .
/var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
/var/log/utmp — Список входов пользователей в систему на данный момент.
/var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump .

И другие журналы

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

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

Чем просматривать — lnav

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

Навигатор журналов lnav понимает ряд форматов файлов.

Access_log веб сервера.
CUPS page_log
Syslog
glog
dpkg.log
strace
Произвольные записи с временными отметками
gzip, bzip
Журнал VMWare ESXi/vCenter

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

Программа умеет напрямую открывать архивный файл.

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

Читайте также: