Var log btmp что это

У меня большие файлы /var/log/btmp, /var/log/wtmp. Что это за файлы и что с ними делать?

Каждая попытка входа в систему протоколируется в специальный файл /var/log/wtmp. Обычно туда протоколируются попытки входа с консоли или по ssh, однако, могут протоколироваться и попытки входа и для других служб, например proftpd. Если вы видите, что файл вдруг начал расти, то очень похоже, что в вашу систему пытаются войти с неправильными учётными данными, например, пытаются подобрать пароль, т.е. увеличение размера /var/log/wtmp или /var/log/btmp (файл btmp является резеврной копией wtmp) является серьёзным звонком администратору, чтобы проверить всё ли в порядке.

Сами файлы хранят информацию в бинарном виде, но её легко посмотреть командой:

last -f /var/log/wtmp

last -f /var/log/btmp

Если вы всё просмотрели и вам всё понятно, но вам необходимо место, занятое этими файлами, вы можете преспокойно обнулить командой:

echo -n >/var/log/wtmp

Через какое-то время они снова начнут запонятся данными.

Есть ещё также файл /var/run/utmp, который содержит информацию об активных сессиях в данный момент времени. Эту же информацию выдаёт в собственном формате команда who, но вы можете просмотреть её командой:

last -f /var/run/utmp

Хочется ещё отметить команду utmpdump, которая также может применяться к любому из файлов /var/log/wtmp, /var/log/btmp и /var/run/utmp и которая выдаёт информацию в несколько более расширенном формате.

Команда last: кто, откуда и когда вошёл в систему?

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

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

Чтобы найти неудачные попытки:

Чтобы узнать, кто сейчас залогинен:

Весь список сессий входа в систему:

Но есть одно “но”. У этих файлов бинарный формат. И если попробовать просмотреть их с помощью cat, то на экране можно будет увидеть нечто подобное информационной каше. Что делать? Использовать утилиту last.

Как работает команда last?

Когда юзер пытается залогинится, запись его сеанса сохраняется в файл /var/log/wtmp. Утилита last читает файл wtmp и предоставляет данные о том, кто, когда и откуда логинился и выходил из системы. Эта команда отображает инфу в обратном хронологическом порядке.

Команда last может показать последних залогиненых пользователей, а также события reboot или shutdown.

# last
root pts/0 192.168.13.197 Sun Oct 23 22:45 still logged in

Чтобы посмотреть историю подключений каждого юзера системы:

# lastlog
Username Port From Latest
root pts/0 192.168.13.197 Sun Oct 23 22:45:11 +0300 2021

Если указали неверные учётные данные во время подключения, то инфу об этом можно найти с помощью lastb:

# lastb
user1 ssh:notty 192.168.13.197 Sun Oct 23 23:04 — 23:04 (00:00)

Данные о ваших подключениях хранятся в логе SSH. В RPM дистрибутивах это обычно /var/log/secure, в Deb — /var/log/auth.log.

Если нужно почистить следы за собой, то просто обнулите файлы:

# echo > /var/log/wtmp
# echo > /var/log/btmp
# echo > /var/log/lastlog
# echo > /var/log/secure

Важно! Организуйте удалённую передачу данных из этих файлов в нужное вам место, если следите за безопасностью. Это действие поможет анализировать инциденты атак.

Var log btmp что это

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

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

1. emerg — авария, наивысший приоритет;
2. alert — тревога;
3. crit — критическое событие;
4. err — ошибка;
5. warn — внимание;
6. notice — уведомление;
7. info — информационное сообщение;
8. debug — отладочная информация;

На сегодняшний день в Linux основными службами сбора логов являются rsyslog и systemd-journald, они работают независимо друг от друга и входят в состав большинства современных дистрибутивов.

rsyslog

Журналы службы находятся в директории “/var/log/” в виде обычных текстовых файлов. В зависимости от типа события, сообщения записываются в разные файлы. Например файл “/var/log/auth.log” содержит информацию о входе пользователей в систему, а в файл “/var/log/kern.log” записываются сообщения ядра. В разных дистрибутивах названия файлов могут отличаться, поэтому для точного понимания куда именно происходит запись сообщений рассмотрим файл конфигурации “/etc/rsyslog.d/50-default.conf”.

Правила описывают место хранения логов в зависимости от типа сообщения. В левой части строки указан тип сообщения в формате “[Источник].[Приоритет]”, а в правой части имя файла журнала. При записи типа сообщения можно применять символ “*”, обозначающий любое значение или параметр “none”, обозначающий исключение из списка. Рассмотрим более подробно первые два правила.

“auth,authpriv.* /var/log/auth.log”
“*.*;auth,authpriv.none -/var/log/syslog”

Первое правило означает, что все сообщения принятые от механизма авторизации будут записаны в файл “/var/log/auth.log”. В этом файле будут зарегистрированы все попытки входа пользователей в систему, как удачные так и не удачные. Второе правило говорит о том, что все сообщения, кроме тех, которые связаны с авторизацией будут записаны в файл “/var/log/syslog”. Именно к этим файлам приходится обращаться наиболее часто. Следующие правила определяют место хранения журналов ядра “kern.*” и почтовой службы “mail.*”

Журналы логов можно открыть любой утилитой для просмотра текста, например less, cat, tail. Откроем файл “/var/log/auth.log”

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

1. Дата и время регистрации сообщения — “Feb 12 06:18:33”
2. Имя компьютера, с которого пришло сообщение — “vds”
3. Имя программы или службы, к которой относится сообщение — “sshd”
4. Идентификатор процесса, отправившего сообщение — [653]
5. Текст сообщения — “Accepted password for mihail from 188.19.42.165 port 2849 ssh2”

Это был пример успешного подключения по ssh.
А так выглядит неудачная попытка:

В этом файле также фиксируется выполнение команд с повышенными правами.

Откроем файл /var/log/syslog

На скриншоте выделено сообщение о выключении сетевого интерфейса.

Для поиска нужной информации в больших текстовых файлах можно использовать утилиту grep. Найдем все сообщения от службы pptpd в файле “/var/log/syslog”

grep ‘pptpd’ /var/log/syslog

Во время диагностики можно использовать утилиту tail, которая выводит последние строки в файле. Команда “tail -f /var/log/syslog” позволит наблюдать запись логов в реальном времени.

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

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

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

Новые правила можно записывать в основной файл конфигурации, но более правильным будет создание отдельного файла в директории “/etc/logrotate.d/” По умолчанию в директории уже содержится несколько файлов.

Рассмотрим файл “/etc/logrotate.d/rsyslog”, который содержит правила ротации для журналов службы rsyslog.

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

• rotate 7 — необходимо постоянно хранить 7 файлов
• daily — ежедневно будет создаваться новый файл
• compress — старые файлы необходимо архивировать.

На скриншоте видно, что в каталоге “/var/log/” находится основной журнал “syslog” и семь архивов, что соответствует правилам ротации.

Более подробное описание по настройке утилиты logrotate можно найти в мануале, выполнив команду “man logrotate”

journald

Служба сбора логов systemd-journald является частью системы инициализации systemd. Файлы журнал хранятся в директории “/var/log/journal/” в специальном формате и могут быть открыты с помощью утилиты journalctl. Формат записей такой же как у службы rsyslog.

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

• вывод записей с момента последней загрузки
  journalctl -b
• вывод записей за определенный период времени
  journalctl -S «2020-02-17 12:00» -U «2020-02-17 12:10»
• вывод записей, принятых от определенной службы
  journalctl -u pptpd
• вывод сообщений ядра
  journalctl -k
• вывод сообщений с определенным приоритетом, в данном случае будут выведены ошибки и более высокие приоритеты(crit, alert, emerg).
  journalctl -p err
• вывод сообщений в реальном времени
  journalctl -f

Для более гибкого поиска опции можно совмещать. Выведем все ошибки службы pptpd

journalctl -u pptpd -p err

Если в качестве аргумента указать путь к исполняемому файлу, утилита выведет все сообщения, отправленные этим файлом. Выведем сообщения, отправленные файлом “/usr/bin/sudo” начиная с 04:15 18-го февраля 2020 года. Фактически будут выведены все команды, выполненные с повышенными правами.

journalctl -S «2020-02-18 04:15» /usr/bin/sudo

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

Для ограничения объема журнала размером 1Gb выполним команду

Открытие бинарных файлов

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

/var/log/wtmp — содержит информацию об успешном входе пользователей в систему, для открытия используется утилита last

/var/log/btmp — в файле регистрируются все неудачные попытки входа в систему, открывается командой lastb с повышенными правами. Параметр -n определяет количество выводимых строк начиная с конца файла.

/var/log/lastlog — содержит время последнего входа для каждой учетной записи, может быть открыт одноименной утилитой lastlog

Linux: логи (/var/log, dmesg, last, lastlog, lastb, history)

/var/log/dmesg – kernel log (ring buffer) с момента загрузки ядра ОС в память компьютера. Сюда kernel пишет лог в случае разных системных сбоев (напр. невозможность драйвером аллоцировать память, работа oom-killer – кого убил и за что �� ) с подробным traceback. Проще смотреть через утилиту с опцией -T – она добавляет дату и времени лога в привычном формате. Так же можно посмотреть через файл /proc/kmsg.

dmesg -T
dmesg | grep oom-killer
cat /proc/kmsg

/var/log/messages — содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.

/var/log/btmp – лог файл Linux содержит информацию о неудачных попытках входа. Для просмотра файла удобно использовать команду last -f /var/log/btmp

/var/log/apache2/access.log – логи по доступу на apache

/var/log/apache2/error.log – логи ошибок на apache

/var/www/cacti/log/cacti.log – логи кагти

/var/log/mysql/error.log – логи mysql ошибок

Log rotation (logrotate) – чтобы система не замусоривалась лог файлами, она использует log rotation. Хорошая статья. Он удаляет “старые” логи, архивирует и сжимает “не слишком старые” и держит в чистом виде “новые”. Так же для этой задачи может использоваться утилита tmpwatch. Утилита древняя – с начала 2000х и заточена именно под задачу ротации логов. Можно конечно делать костыли и для других вещей, но выглядеть это может страшно напр. нужно сохранять первые N строк одного файла, а остальное ротировать или нужно удалять все старые файлы, но актуальным не менять имя – эти задачи проще решить другими способами (напр. sh-скриптами).

logrotate 3.14.0 - Copyright (C) 1995-2001 Red Hat, Inc.

# тестирование logrotate
logrotate -d /etc/logrotate.d/test_temp_lg_rotate.conf

Логгирование операций на CLI сервере возможно используя связку tee и logger.

32115 0.0 0.0 103408 852 pts/98 S+ 12:23 0:00 tee -a /home//.bash_history
32116 0.0 0.0 100904 780 pts/98 S+ 12:23 0:00 logger -p local6.info -t [26465]

Lastlog – крутая утилита на Ubuntu. Позволяет узнать когда последний раз юзер заходил на сервер. Утилита для этого смотрит в файлы /var/log/lastlog, /var/log/wtmp (можно посмотреть в man lastlog).

~$ lastlog | grep pts root pts/1 Tue Aug 9 12:20:04 +0300 2016 redkin_p pts/2 1.1.1.1 Thu Aug 11 23:48:44 +0300 2016 admin pts/1 1.1.1.1 Mon Aug 22 11:30:30 +0300 2016

last |reboot| – команда показывает успешные подключения/отключения пользователей, сколько пользователь был подключен, какой tty использовал, с какого IP был подключен. Так же команда показывает перезагрузки системы (если такие были с создания файла) при этом, вместо tty указывается “system boot”, а вместо IP указывается версия ядра, которая была загружена. Если указать опцию reboot, то события пользователей будут исключены из вывода.

redkin.p@govnoserver:~$ last redkin.p pts/0 192.168.1.2 Wed Jul 27 16:26 still logged in redkin.p pts/1 192.168.1.2 Wed Jul 27 16:25 - 16:26 (00:00) redkin.p pts/1 192.168.1.2 Wed Jul 27 16:21 - 16:25 (00:04) redkin.p pts/0 192.168.1.2 Wed Jul 27 16:18 - 16:26 (00:07) igor tty1 Wed Jul 13 11:37 still logged in redkin tty1 Wed Jul 13 11:35 - 11:37 (00:01) reboot system boot 3.13.0-65-generi Wed Jul 13 11:22 - 18:26 (14+07:03) redkin.p pts/0 192.168.1.2 Fri Jul 1 12:47 - 16:25 (03:38) wtmp begins Fri Jul 1 12:47:28 2016 [root@host1 ~]# last | head -n 10 user1 pts/0 :1 Mon Aug 1 12:10 still logged in user1 :1 :1 Mon Aug 1 12:05 still logged in (unknown :1 :1 Mon Aug 1 12:05 - 12:05 (00:00) user1 pts/1 192.168.1.2 Mon Aug 1 11:04 still logged in user1 pts/1 192.168.1.2 Mon Aug 1 11:04 - 11:04 (00:00) user1 pts/0 :0 Mon Aug 1 10:48 - 12:05 (01:16) user1 :0 :0 Mon Aug 1 10:48 - 12:05 (01:16) (unknown :0 :0 Mon Aug 1 10:48 - 10:48 (00:00) reboot system boot 3.10.0-327.22.2. Mon Aug 1 10:47 - 18:54 (08:07) user1 pts/0 192.168.100.38 Sun Jul 31 14:46 - 00:00 (09:14) redkin.p@govnoserver:~$ last reboot reboot system boot 3.13.0-65-generi Wed Jul 13 11:22 - 18:27 (14+07:05) wtmp begins Fri Jul 1 12:47:28 2016 [root@host1 ~]# last reboot | head -n 5 reboot system boot 3.10.0-327.22.2. Mon Aug 1 10:47 - 19:03 (08:15) reboot system boot 3.10.0-327.22.2. Wed Jul 27 13:50 - 19:03 (5+05:12) reboot system boot 3.10.0-327.22.2. Wed Jul 27 13:46 - 13:50 (00:03) reboot system boot 3.10.0-327.22.2. Wed Jul 27 13:23 - 13:46 (00:22) reboot system boot 3.10.0-327.22.2. Wed Jul 27 13:18 - 13:46 (00:27)

lastb – команда смотрит в файл /var/log/btmp, в котором храняться неуспешные подключения пользователей с логином/временем/tty/ip. Для использования нужны права root.

redkin.p@govnoserver:~$ sudo lastb igor tty1 Wed Jul 13 11:35 - 11:35 (00:00) redkin tty1 Wed Jul 13 11:35 - 11:35 (00:00) [root@host1 ~]# sudo lastb | head -n 5 user1 ssh:notty 192.168.1.2 Mon Aug 1 19:01 - 19:01 (00:00) user1 ssh:notty 192.168.1.2 Mon Aug 1 19:01 - 19:01 (00:00) user1 ssh:notty 192.168.1.2 Mon Aug 1 19:00 - 19:00 (00:00) user1 ssh:notty 192.168.1.2 Mon Aug 1 19:00 - 19:00 (00:00) user1 :0 :0 Mon Aug 1 10:48 - 10:48 (00:00)

history – смотрим логи (историю) команд.

history 10 - последние 10
history -c - чистим историю

Добавляем в историю TIMESTAMP.

echo "export HISTTIMEFORMAT='%d.%m.%Y %H:%M:%S: '" >> ~/.bash_profile