Astra linux логи авторизации

Журналы работы системных служб

В Astra Linux Special Edition очередное обновление x.7 рекомендована к применению служба ведения журналов syslog-ng. В более ранних очередных обновлениях Astra Linux по умолчанию используется служба rsyslog. Служба syslog-ng:

  • устанавливается по умолчанию при установке оперативных обновлений Astra Linux x.7;
  • при установке замещает собой службу rsyslog. Служба rsyslog при этом полностью удаляется.

Дальнейшее использование службы rsyslog не соответствует поддерживаемым сценариям эксплуатации. Служба rsyslog более не поддерживается в составе основного репозитория Astra Linux Special Edition (доступна в составе расширенного репозитория). В находящихся в эксплуатации системах службу rsyslog необходимо заменить на службу syslog-ng.

Службы управления журналами

  • syslog-ng — служба управления журналами syslog-ng по умолчанию используется в Astra Linux Special Edition x.7, доступна в репозиториях более ранних очередных обновлений;
  • rsyslog — служба управления журналами rsyslog по умолчанию используется в Astra Linux Common Edition и Astra Linux Special Edition ранее очередного обновления x.7, доступна в основном репозитории Astra Linux Special Edition x.7 ;
  • syslog (sysklogd) — служба управления журналами syslog в настоящее время в Astra Linux не используется;
  • logrotate — служба архивирования и очистки (ротации) журналов.

Основные возможности служб:

  • Получение и передача сообщение по сетевым протоколам TCP/UDP/. с возможностью настройки IP-портов и IP-адресов;
  • Загрузка внешних модулей;
  • Фильтрация и перенаправление сообщений по имени программы, источнику, номеру процесса и т.д.;
  • Удаление ненужных сообщений;

Служба syslog-ng

Расположение файлов конфигурации

  • основной файл: /etc/syslog-ng/syslog-ng.conf;
  • дополнительные файлы .conf в каталоге /etc/syslog-ng/conf.d.

Базовые принципы функционирования

Служба syslog-ng получает системные сообщения из указанных источников и перенаправляет их в указанные приемники. Источниками могут быть файлы, удаленные хосты, системные сокеты и другие источники. Источники и приемники являются независимыми объектами и соединяются путями передачи (далее — путь). Путь состоит из одного или нескольких источников и одного или нескольких приемников. Дополнительно определение пути может содержать:

  • фильтры — правила, применяемые для селекции сообщений;
  • анализаторы (parsers) — правила для анализа и разбора сообщений;
  • модификаторы ( rewriting rules) — правила для модификации сообщений.

Базовые принципы конфигурации

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

  • тип объекта — один из типов:
    • source — источник;
    • destination — приемник;
    • log — путь;
    • filter — фильтр;
    • parser — анализатор;
    • rewrite rule — модификатор;
    • template — шаблон;
    • option — глобальные опции.

    Пример: определение объекта типа источник и именем s_internal:

    Пример: определение объекта типа приемник:

    Далее на определенные объекты можно ссылаться по его идентификатору, например в определении объекта «путь»:

    Параметры объектов могут иметь обязательные и необязательные опции. Обязательные опции являются позиционными и должны быть указаны в заданном порядке. Необязательные опции имеют формат
    () и могут указываться в любом порядке.

    Пример: Источник s_demo_stream имеет один параметр — драйвер источника unix-stream(), который имеет одну обязательную опцию — имя сокета, и необязательные опции — max_connection и group:

    source s_demo_stream1 < unix-stream("" max-connections(10) group(log)); >;
    • Объекты могут использоваться до их определения;
    • Объекты могут определяться при их использовании (inline), что полезно при однократном применении, например, фильтров;
    • Строки, начинающиеся с символа «#» считаются комментариями и игнорируются;

    Синтаксис определения пути:

    Пример определения источника, приемника и простого пути:

    source s_localhost < network(ip(127.0.0.1) port(1999)); >; destination d_tcp < network("10.1.2.3" port(1999) localport(999)); >; log < source(s_localhost); destination(d_tcp); >;

    Тот же пример определения простого пути с использованием inline-определений источника и приемника:

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

    Пример применения глобальных опций:

    Отключения разрешения имен через DNS:

    Перечень основных источников, приемников и фильтров:

    Таблица 1. Драйверы источников

    Прием сообщений от удаленного хоста по протоколу BSD-syslog в сетях IPv4 и IPv6. Поддерживает сетевые протоколы TCP, UDP и TLS..

    Таблица 2. Драйверы приемников

    Отправка сообщений на сервер Elasticsearch. Вариант драйвера elasticsearch2 поддерживает Elasticsearch версия 2 и новее.

    Таблица 3. Доступные фильтры.

    Название Описание Комментарий
    facility() Фильтрация сообщений по указанному объекту (facility).
    filter() Вызов другого фильтра.
    host() Фильтрация сообщений по имени хоста-отправителя.
    inlist() Фильтрация сообщений по черным и белым спискам в файлах.
    level()
    priority()
    Фильтрация сообщений по приоритету.
    match() Фильтрация по регулярным выражениям, применяемым к заголовку и содержимому сообщения.
    message() Фильтрация по регулярным выражениям, применяемым к содержимому сообщения.
    netmask() Фильтрация сообщений по IP-адресу хоста-отправителя.
    program() Фильтрация сообщений по названию приложения.
    source() Фильтрация сообщений по указанному источнику.
    tags() Фильтрация сообщений по наличию указанных тегов.

    Служба rsyslog

    Расположение файлов конфигурации

    Служба logrotate

    Расположение файлов конфигурации

    Настройки по умолчанию (основной файл конфигурации /etc/logrotate.conf):

    • weekly — файлы журналов подвергаются ротации, если текущий день недели меньше дня недели последней ротации или если со времени последней ротации прошло больше недели;
    • rotate— файлы журнала ротируются указанное количество раз перед тем, как будут удалены или отправлены на адрес, указанный в директиве mail. Если количество равно нулю, прежние версии удаляются, а не ротируются. Количество по умолчанию — 4;
    • create — сразу после ротации (до запуска сценария postrotate) создать файл журнала (с таким же именем, как у только что ротированного файл журнала). Поле режим определяет режим для файла журнала в восьмеричном представлении (как в chmod(2)), поле владелец определяет имя пользователя который является владельцем этого файла журнала, и поле группа определяет группу, которой принадлежит файл журнала. Любой из этих атрибутов может быть пропущен, в таком случае для пропущенных атрибутов будут использоваться атрибуты исходного файла журнала. Эта опция может быть отключена с помощью опции nocreate;

    Подробное описание см. man logrotate.

    Взаимная замена служб rsyslog/syslog-ng

    Замена пакетов

    B Astra Linux Special Edition x.7 служба rsyslog не поддерживается. Если служба rsyslog была установлена ранее, то для замены службы rsyslog на службу syslog-ng выполнить команду:

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

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

    Миграция конфигурационных файлов

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

    Для проверки синтаксической корректности конфигурационных файлов службы syslog-ng можно использовать команду:

    Далее в качестве примера приведено соответствие конфигураций rsyslog и syslog-ng некоторых пакетов. :

    # Log cloudinit generated log messages to file :syslogtag, isequal, "[CLOUDINIT]" /var/log/cloud-init.log # comment out the following line to allow CLOUDINIT messages through. # Doing so means you'll also get CLOUDINIT messages in /var/log/syslog & stop
    log < source(s_src); filter < message("^.*CLOUDINIT.*$"); >; destination < file("/var/log/cloud-init.log"); >; flags( final); >;
    # Create an additional socket in haproxy's chroot in order to allow logging via # /dev/log to chroot'ed HAProxy processes $AddUnixListenSocket /var/lib/haproxy/dev/log # Send HAProxy messages to a dedicated logfile :programname, startswith, "haproxy" < /var/log/haproxy.log stop >
    log < source < unix-dgram("/var/lib/haproxy/dev/log"); >; filter < program("haproxy"); >; destination < file("/var/log/haproxy.log"); >; flags( final); >;
    # Log kernel generated UFW log messages to file :msg,contains,"[UFW " /var/log/ufw.log # Uncomment the following to stop logging anything that matches the last rule. # Doing this will stop logging kernel generated UFW log messages to the file # normally containing kern.* messages (eg, /var/log/kern.log) #& stop
    log < source(s_src); filter < message("^.*UFW.*$"); >; destination < file("/var/log/ufw.log"); >; # flags( final); >;
    # Send Jetty messages to jetty.out when using systemd :programname, startswith, "jetty9" < /var/log/jetty9/jetty-console.log stop >
    log < source(s_src); filter < program("jetty9"); >; destination < file("/var/log/jetty9/jetty-console.log"); >; flags( final); >;
    # Create an additional socket in postfix's chroot in order not to break # mail logging when rsyslog is restarted. If the directory is missing, # rsyslog will silently skip creating the socket. $AddUnixListenSocket /var/spool/postfix/dev/log
    log < source < unix-stream("/var/spool/postfix/dev/log" keep-alive(yes)); >; filter < program("postfix"); >; destination(d_syslog); >;
    # Send Tomcat messages to catalina.out when using systemd $template TomcatFormat, "[%timegenerated. date-year%- %timegenerated. date-month%- %timegenerated. date-day% %timegenerated. date-hour%: %timegenerated. date-minute%: %timegenerated. date-second%] [%syslogseverity-text%]%msg%\n" :programname, startswith, "tomcat9" < /var/log/tomcat9/catalina.out;TomcatFormat stop >
    log < source(s_src); filter < program("tomcat9"); >; destination < file("/var/log/tomcat9/catalina.out", template("[$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC] [$PRIORITY]$MSG\n")); >; flags( final); >;

    Инструмент сбора журналов astra-create-debug-logs

    В состав дистрибутивов ОС Astra Linux входит инструмент командной строки astra-create-debug-logs, предназначенный для автоматического сбора архива журналов системных служб.
    Для создания архива журналов инструмент должен быть запущен от имени суперпользователя:

    Расположение файлов журналов основных системных служб

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

    Необходимо включить запись в журнал в конфигурационном файле /etc/dovecot/conf.d/10-logging.conf в параметре log_path.
    Например, указать: /var/log/dovecot.log

    Источник

    Просмотр истории входа в Linux. Кто и когда входил в систему

    Кто и когда входил в Linux. Команда Last

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

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

    Где хранятся логи входа в систему

    Информация о том, кто входил (залогинивался) или пытался войти в систему, хранится в лог файлах. Для этого используется три лог-файла:
    /var/log/btmp — неудачные попытки входа.
    /var/run/utmp — кто в данный момент залогинен (текущие сессии).
    /var/log/wtmp — список всех сессий входа в систему.

    Эти файлы, в отличии от большинства других лог-файлов Linux, имеют бинарный формат. Если вы попробуете просмотреть их командой cat , то на экран будет выведена «каша». Для их просмотра используется команда last .

    Просмотр истории входа в систему

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

    yuriy pts/0 181.23.456.189 Sat Mar 23 12:27 still logged in nifnif pts/11 181.45.678.912 Wed Mar 20 05:30 - 05:49 (00:19) nafnaf pts/22 181.45.678.312 Fri Mar 15 00:01 - 02:27 (02:26) nufnuf pts/33 181.45.678.411 Wed Mar 13 11:02 - 11:28 (00:26) . 

    Как вы можете видеть, выводится таблица с информацией. В ней содержатся имена пользователей, IP-адрес, с которого осуществлялся вход, дата и время входа и продолжительность сессии. Запись вида pts/0 означает, что для входа использовалось SSH соединение (или другое удаленное соединение, например, telnet).

    Также выводится информация о включении/выключении системы.

    Последняя строка в файле /var/log/wtmp показывает, когда был создан файл.

    Просмотр истории входа в систему. Команда Last

    Просмотр истории входа для определенного пользователя

    Чтобы показать информацию о сессиях определенного пользователя, то для команды last необходимо указать имя этого пользователя:

    Команда last username

    Ограничить количество строк

    Иногда лог, который выводит команда last , может быть очень большой. Чтобы ограничить количество выводимых строк, используется опция -n ЧислоСтрок или просто -ЧислоСтрок .

    Выведем только десять свежих записей:

    Просмотр неудачных попыток входа в систему

    Как было сказано выше, записи о неудачных попытках входа в систему хранятся в лог-файле /var/log/btmp .

    Команда last по умолчанию выводит информацию из файла /var/log/wtmp . Чтобы вывести информацию из другого файла, используется опция -f ИмяФайла

    Выведем записи о неудачных попытках входа (из файла /var/log/btmp ):

    Или же можно воспользоваться командой lastb . Команда lastb работает точно также, как и команда last , но выводит информацию из файла /var/log/btmp

    Заключение

    Мы рассмотрели использование команды last для просмотра информации об истории входа в систему.

    Дополнительную информацию по использованию команды last можно получить, выполнив в терминале:

    Источник

    Читайте также:  What is root folder in linux
Оцените статью
Adblock
detector