var log btmp что это
Одминский блог
Блог о технологиях, технократии и методиках борьбы с граблями
Бинарные файлы журналирования подключений
Полез тут кой что подкрутить на своем простеньком хостинге, который я держу в Reg.ru под парсинг выдачи Яндекса и Wordstat.Yandex. Хостинг у Reg.ru надо заметить крайне надежный, в плане стабильности, и при этом весьма экономичный.
Держал бы у них даже некоторые свои проекты, если бы не мракобесие, творящееся в тырнетах, так что хостить проекты как то надежнее в бургонете.
Так вот, держу у них легкий Xen VPS крутящийся под Cent OS. Все удовольствие 360 рублей в месяц, за 512Mb RAM & 8Gb HDD.
И тут зачем то глянул занятость диска, а свободного пространства осталось всего 5%, при том что система от силы на гиг тянет.
Естественно первым делом в логи, и обнаруживаю занятный файл /var/log/btmp который и тянет на 5 гигов. Естественно что первым делом я его пнул через tail, после чего у меня заглючила консоль, так как листинг файла вывалил крякозябры, намекающие на то, что файл содержит не текстовую информацию, а бинарную.
Сам файл представляет из себя фиксацию неудачных попыток логина, так что по большому счету там преимущественно толкутся записи о брутфорс атаках на сервер.
test ssh:notty 222.85.90.245 Thu Feb 6 18:10 – 18:10 (00:00)
test ssh:notty 222.85.90.245 Thu Feb 6 18:09 – 18:10 (00:00)
test ssh:notty 222.85.90.245 Thu Feb 6 18:09 – 18:09 (00:00)
root ssh:notty 98.158.29.93 Thu Feb 6 18:07 – 18:09 (00:02)
root ssh:notty 98.158.29.93 Thu Feb 6 18:07 – 18:07 (00:00)
root ssh:notty 98.158.29.93 Thu Feb 6 18:07 – 18:07 (00:00)
root ssh:notty 98.158.29.93 Thu Feb 6 18:07 – 18:07 (00:00)
mysql ssh:notty 98.158.29.93 Thu Feb 6 18:07 – 18:07 (00:00)
mysql ssh:notty 98.158.29.93 Thu Feb 6 18:07 – 18:07 (00:00)
mysql ssh:notty 98.158.29.93 Thu Feb 6 18:07 – 18:07 (00:00)
mysql ssh:notty 98.158.29.93 Thu Feb 6 18:07 – 18:07 (00:00)
то есть на лицо запалившиеся голубцы и логины под которыми они и пытались проломиться.
Также можно использовать команду
# utmpdump /var/log/btmp
дающую несколько более полную информацию и более попсовый листинг
Теоретически, можно настроить механизм, чтобы любители брута отправлялись,после нескольких неудачных попытов, сразу же в бан через iptables, и тогда надо будет настраивать ротацию лога, в /etc/logrotate.conf подправив имеющееся выражение на это:
/var/log/btmp <
monthly
minsize 1M
create 0600 root utmp
rotate 1
>
Поскольку запариватся мне с ним не хотелось, то я его обнулил естественным путем
# cat /dev/null > /var/log/btmp
после чего перевесил демона sshd на пятизначный порт > 1024, что естественно выключило все попытки брута, о чем я как то давно уже писал.
*** Хозяйке на заметку:
В системе имеются еще два файла:
/var/log/wtmp в который пишутся все логины в систему
/var/run/utmp который показывает активные на данный момент сессии
синтаксис просмотра тот же самый, через команду utmpdump
Средства мониторинга Linux системы (часть 1?)
Короче, продолжаем. Теперь я для вас подготовил некую уже не маленькую статью, на тему мониторинга Linux систем. В некотором роде эта статья мне будет служить в качестве мини-справочника по необходимым командам, для того, чтобы можно было понимать, все ли нормально с системой. Поговорим об основных командах типа top/htop/uptime/ps, о том где какие логи лежат и что они означают и так далее. Короче, начнем..
Log-файлы (журналы)
Все логи по умолчанию хоронятся в директории /var/log/ (ну так принято по стандарту иерархии файловой системы) и эти файлы — сведения о происходящих процессах в системе. Кстати, если вы поддерживайте систему, которая может быть интересна взломщикам, то настоятельно рекомендуется обзавестись системой дублирования логов, например, на туже почту. Взломщик будет думать, что все «зачистил» за собой, но доказательства его пребывания в системе останутся. Но речь не об этом..
Рассмотрим пример стандартных файлов в директории /var/log/, на примере ОС Debian Linux 7:
Теперь приведем пример, что когда нам понадобится..
На этом про логи, я думаю, достаточно..
Правки в файлах
Более подробно поиск по различным временам описан тут.
Какова загрузка системы?(LoadAverage)
Вы наверное часто обращали внимание на такую строчку, как LoadAverage, которая показывает числа. Собственно эти числа отображают число блокирующих процессов на исполнение в определенный интервал времени, а именно 1 минута, 5 минут и 15 минут. Под блокирующим процессом подразумевается процесс, который ждет ресурсы для того, чтобы продолжить свою работу, а под ресурсами подразумевается ЦП, дисковая подсистема ввода вывода и сетевая подсистема ввода/вывода.
Не обязательно быть специалистом, чтобы понимать, что высокие показатели LA говорят о том, что система не справляется, например эти цифры могут говорить об аппаратных проблемах.
Чтобы посмотреть эти показания, достаточно воспользоваться командой top или uptime (о top мы поговорим несколько позднее)
Большинство (как и я ) будут думать, что чем меньше эти числа, тем лучше, но нужно понимать, когда бить тревогу, если значения этих цифр начнет расти.
Отличная аналогия «на машинках» о том, что эти цифры обозначают приведена в статье на хабре, поэтому приведу краткую выдержку от туда: представим, что одноядерный процессор это однополосный мост, а мы управляем движением на этом мосту. Если мост перегружен, то машины ждут (ну или стоят в пробке). Собственно количество машин в очереди это и есть то число, которое вы видите. Пример можно увидеть на этих картинках из этой прекрасной статьи:
load average = 0.50 
load average = 1.00 
load average = 1.70
Исходя из того, что мы видим, можно понять, что Load Average равный 1,00 — идеальное значение, но это не так. Идеальным значением для меня можно считать 0,50 ну или на худой конец 0,70, так как должен сохраняться какой-то запас на случай внезапной нагрузки или нештатного поведения той или иной программы.
И имейте в виду, пример выше это пример для одноядерного процессора. Если у вас четырехядерный процессор или два двухядерных процессора, то идеальным LA для вас будет 2,00 или 2,80.
Теперь подытожим эту тему,
Что происходит в системе (процессы)
Собственно. чтобы увидеть эти показатели, понять, где у нас есть проблемы, и вообще получить информацию о процессах воспользуемся утилитой top:
Рассмотрим по порядку, что есть что:
Что нам тут интересно? Да интересно почти все :). Например, статистика CPU: высокие значения (более 80%) параметра wa говорят о простое из-за ввода вывода, что может говорить о проблемах с HDD. Кстати, если сложить все эти значения, то у вас получится 100%.
Что мы там можем делать в утилите top?
Более подробнее о ключах top можно почитать в страницах man. Кстати, есть еще и отличный аналог утилиты top — htop:
ps — process status
Существует еще генератор снимков процессов ps. Подробнее о нем можно почитать его man, а ниже я приведу примеры использования этой команды:
Этого я думаю достаточно. Есть еще масса интересных примеров на просторах интернета, например тут.
В заключение…
начиная писать эту статью, я не думал что все получится на столько громоздко, поэтому еще будет как минимум вторая или третья часть средств мониторинга linux систем.
Системные журналы Linux (управление логированием)
Функция системного журналирования (т.н. «логи» или логирование) — это основной источник информации о работе системы и ошибках. Журналирование может осуществляться на локальной системе, а так же сообщения журналирования могут пересылаться на удаленную систему, кроме того, в конфигурационном файле /etc/syslog.conf (в некоторых новых дистрибутивах заменен на /etc/rsyslog.conf) возможна тонкая регулировка уровня журналирования. Журналирование осуществляется при помощи демона syslogd (rsyslogd — в некоторых новых дистрибутивах), который обычно получает входную информацию при помощи сокета /dev/log (локально) или с udp-порта 514 (с удаленных машин).
В случае локального журналирования главным файлом — хранителем информации, обычно является /var/log/messages, но в большинстве инсталляций используются и многие другие файлы, которые могут быть тщательно настроены с помощью вышеуказанного конфигурационного файла. Например, может возникнуть необходимость выделить в отдельный лог сообщения, рождаемые демоном электронной почты.
Управление типом и подробностью журналируемой информации
Конфигурационный файл syslog.conf
Получив сообщение для записи в журнал (от klogd, от локальной или удаленной программы), syslogd для каждого правила проверяет не подходит ли сообщение под шаблон, определяемый селектором. Если подходит, то выполняется указанное в правиле действие. Для одного сообщения м.б. выполнено произвольное количество действий (т.е. обработка сообщения не прекращается при первом успехе).
Сообщения с уровнем, равным или выше указанного в селекторе, и источником, равным указанному в селекторе, считается подходящим. Звездочка перед точкой соответствует любому источнику, после точки — любому уровню. Слово none после точки — никакому уровню для данного источника. Можно указывать несколько источников в одном селекторе (через запятую).
Источник (он же категория) может быть следующим:
Под приоритет (степени важности) сообщений заданы 8 уровней важности, которые кодируются числами от 0 до 7:
Согласно действию, указанному в правиле, сообщение может быть записано в следующие назначения:
Обычный файл
Задается полным путем, начиная со слеша (/). Поставьте перед ним дефис (-), чтобы отменить синхронизацию файла после каждой записи. Это может привести к потере информации, но повысить производительность.
Именованные каналы
Размещение перед именем файла символа канала (|) позволит использовать fifo (first in — first out, первый пришел — первый вышел) или именованный канал (named pipe) в качестве приемника для сообщений. Прежде чем запускать (или перезапускать) syslogd, необходимо создать fifo при помощи команды mkfifo. Иногда fifo используются для отладки.
Терминал и консоль
Терминал, такой как /dev/console.
Удаленная машина
Чтобы сообщения пересылались на другой хост, поместите перед именем хоста символ (@). Обратите внимание, что сообщения не пересылаются с принимающего хоста. (для работы данного назначения на клиенте и сервере в файле /etc/services должна быть прописана строчка syslog 514/udp, и открыт UTP-порт 514)
Список пользователей
Разделенный запятыми список пользователей, получающих сообщения (если пользователь зарегистрирован в системе). Сюда часто включается пользователь root.
Все зарегистрированные пользователи
Чтобы известить всех зарегистрированных пользователей при помощи команды wall, используйте символ звездочки (*).
Пример несложного syslog.conf:
Как и во многих конфигурационных файлах, синтаксис следующий:
Запуск демона syslogd
Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog, однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт — начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian).
Вот некоторые возможные параметры запуска демона syslogd:
После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.
можно послать демону syslogd один из следующих сигналов: SIGHUP — перезапуск демона; SIGTERM — завершение работы; SIGUSR1 — включить/выключить режим отладки.
Вообще-то в системе запускаются два демона протоколирования — syslogd и klogd. Оба демона входят в состав пакета sysklogd.
Демон klogd отвечает за журналирование событий, происходящих в ядре системы. Необходимость в отдельном демоне klogd объясняется тем, что ядро не может использовать стандартную функцию syslog. Дело в том, что стандартные библиотеки С (включая ту библиотеку, в которой находится функция syslog) предназначены для использования только обычными приложениями. Поскольку ядро тоже нуждается в функциях журналирования, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро использует свой собственный механизм генерации сообщений.
Демон klogd предназначен для организации обработки этих сообщений. В принципе он может производить такую обработку полностью самостоятельно и независимо от syslogd, например, записывая эти сообщения в файл, но в большинстве случаев используется принятая по умолчанию настройка klogd, при которой все сообщения от ядра пересылаются тому же демону syslogd.
Автоматическая ротация (обновление заполненных файлов) и архивирование журналов
Со временем, файл журнала имеет свойство увеличиваться, особенно при интенсивной работе какого-либо сервиса. Соответственно, необходимо иметь возможность контролировать размер журналов. Это делается при помощи команды logrotate, которая обычно выполняется демоном cron. О работе cron я расскажу в следующих статьях. Главная цель команды logrotate состоит в том, чтобы периодически создавать резервные копии журналов и создавать новые чистые журналы. Сохраняется несколько поколений журналов и, когда завершается срок жизни журнала последнего поколения, он может быть заархивирован (сжат). Результат может быть отправлен по почте, например, ответственному за ведение архивов.
Для определения порядка ротации и архивирования журналов используется конфигурационный файл /etc/logrotate.conf. Для разных журналов можно задать разную периодичность, например, ежедневно, еженедельно или ежемесячно, кроме того, можно регулировать количество накапливаемых поколений, а также указать, будут ли копии архивов отправляться ответственному за ведение архивов и, если будут, когда. Ниже показан пример файла /etc/logrotate.conf:
Глобальные опции размещаются в начале файла logrotate.conf. Они используются по умолчанию, если где-то в другом месте не задано ничего более определенного. В примере ротация журналов происходит еженедельно и резервные копии сохраняются в течение четырех недель. Как только производится ротация журнала, на месте старого журнала автоматически создается новый. Файл logrotate.conf может содержать спецификации из других файлов. Так, в него включаются все файлы из каталога /etc/logrotate.d.
В этом примере также содержатся специальные правила для /var/log/wtmp и /var/log/btmp (хранящие информацию о удачных и неудачных попытках входя в систему), ротация которых происходит ежемесячно. Если файлы отсутствуют, сообщение об ошибке не выдается. Создается новый файл и сохраняется только одна резервная копия.
В этом примере по достижении резервной копией последнего поколения она удаляется, поскольку не определено, что следует с ней делать.
Резервные копии журналов могут также создаваться, когда журналы достигают определенного размера, и могут быть созданы скрипты из наборов команд для выполнения до или после операции резервного копирования. Пример:
В этом примере ротация /var/log/messages производится по достижении им размера 100 КБ. Накапливается пять резервных копий, и когда истекает срок жизни самой старой резервной копии, она отсылается по почте на адрес logadmin@sysloger. Командное слово postrotate включает скрипт, перезапускающий демон syslogd после завершения ротации путем отправки сигнала HUP. Командное слово endscript необходимо для завершения скрипта, а также в случае, если имеется скрипт prerotate. Более полную информацию см. в страницах руководства man для logrotate.
Параметры, задаваемые в конфигурационном файле logrotate.conf:
Изучение и мониторинг журналов
Записи в журналах обычно содержат метку времени, имя хоста, на котором выполняется описываемый процесс, и имя процесса. Просматривать журналы можно при помощи программы постраничного вывода, например, less, искать определенные записи (например, сообщения ядра от определенного демона) можно при помощи команды grep:
Linux: логи (/var/log, dmesg, last, lastlog, lastb, history)
https://losst.ru/kak-posmotret-logi-v-linux – хорошая статья с указанием стандартных путей лог файлов
/var/log/syslog – системные (включает почти все другие логи)
/var/log/kern – логи ядра
/var/log/auth.log – аутентификационные, включая SUDO и заходы по SSH (включая неуспешные)
/var/log/boot.log – логи загрузки системы
/var/log/messages — содержит глобальные системные логи Linux, в том числе те, которые регистрируются при запуске системы. В этот лог записываются несколько типов сообщений: это почта, cron, различные сервисы, ядро, аутентификация и другие.
/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-скриптами).
Логгирование операций на CLI сервере возможно используя связку tee и logger.
Lastlog – крутая утилита на Ubuntu. Позволяет узнать когда последний раз юзер заходил на сервер. Утилита для этого смотрит в файлы /var/log/lastlog, /var/log/wtmp (можно посмотреть в man lastlog).
last |reboot| – команда показывает успешные подключения/отключения пользователей, сколько пользователь был подключен, какой tty использовал, с какого IP был подключен. Так же команда показывает перезагрузки системы (если такие были с создания файла) при этом, вместо tty указывается “system boot”, а вместо IP указывается версия ядра, которая была загружена. Если указать опцию reboot, то события пользователей будут исключены из вывода.
lastb – команда смотрит в файл /var/log/btmp, в котором храняться неуспешные подключения пользователей с логином/временем/tty/ip. Для использования нужны права root.
history – смотрим логи (историю) команд.
Кто же был на сервере?
Наступает момент, когда системному администратору необходимо определить дату последнего входа в систему каждого из пользователей, а также подготовить список тех аккаунтов, которые этого так и не сделали. Если б Вы ранее не знали команду lastlog, то удивились бы, насколько легко и быстро она может предоставить Вам эти данные.
Если же Вы все-таки задумались об этом, то не забывайте, что данная команда — это также один из хороших методов проверки безопасности, которую можно проводить на серверах под управлением Linux систем. Она поможет Вам установить потенциальные проблемы. Те аккаунты, которые были неактивны в течение долгого времени, например, может означать, что они больше не нужны и могут быть отключены. А вот аккаунты, которые были активны в то время, когда их пользователи должны были быть в отпуске где-нибудь на Багамах — могут намекать о проблемах с безопасностью на сервере.
Команда lastlog хранит информацию о последнем входе пользователя в систему, но он предоставит информацию только по тем логам, которые имеются в файле wtmp. Записи в данном файле делаются в двоичном формате, так что просматривать их можно только с помощью специальных команд. Думаю многие из Вас обращали внимание на то, что когда Вы авторизируетесь в консоли, на экране появляется примерно следующее сообщение:
Эта строка формируется утилитой 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 перечислены согласно идентификаторов пользователей (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 на некоторых компьютерах в определенных случаях может возникнуть впечатление, что команда «зависла». Это происходит в силу того, что даже если в системе зарегистрировано всего два пользователя (root и user), в файле /var/log/lastlog все равно отведено место для максимально возможного числа пользователей, которые могут работать в системе. Поэтому в файле /var/log/lastlog могут иметься большие промежутки между номерами идентификаторов работавших в системе пользователей. Поскольку при просмотре таких интервалов программа не выводит информацию на экран, и возникает впечатление «зависания». Потому не спешите нажимать кнопки и закрывать консоль, а дождитесь ответа команды.
Как мы с Вами установили, команда lastlog может быть очень полезна для проверки логов тех пользователей, поддержку которых Вы еще осуществляете, чтобы убедиться, что аккаунты в системе используются должным образом и они все еще актуальны. Также не забывайте проверять размер логов, а то может оказаться, что их объем уже значительно превышает общий размер Вашей системы.
Не пренебрегайте в своей работе применять довольно простые команды, и, естественно, используйте место с умом. Удачи!