На сервере вдруг растёт нагрузка, в журнале появляются ошибки, а SSH один за другим пишет о неудачных входах. Администратор видит только шум, но логи уже показывают, кто и что пытался сделать.

Если журналы настроены нормально, по ним можно восстановить цепочку событий: когда началась активность, какие адреса стучались к серверу, что искали и чем всё закончилось. Ниже — практический разбор для тех, кто только начинает работать с инцидентами на Linux.

Какую проблему решаем

Один странный запрос сам по себе ещё не доказывает взлом. Адрес /admin могли открыть тестовый скрипт, поисковый робот или специалист, который проверяет сайт вручную.

Проблема начинается, когда такие запросы идут сериями, с короткими паузами и по разным путям. Тогда уже есть смысл смотреть не на отдельную строку, а на картину целиком.

Что подготовить

Для первичного разбора хватит трёх источников: системного журнала Linux, записей аутентификации и логов веб-сервера. На Debian и Ubuntu события входа обычно лежат в /var/log/auth.log, на RHEL-подобных системах — в /var/log/secure.

Если сервер использует systemd, удобно работать через journalctl. Для веб-части пригодятся access log и error log. Этого набора достаточно, чтобы понять, шли ли попытки входа по SSH, какие ресурсы запрашивали через HTTP и где приложение начало ошибаться.

Пошаговые действия

Сначала посмотрите на неудачные входы по SSH. Если в логе много попыток с короткими интервалами, разными именами пользователей и одним источником, это похоже на автоматизированный перебор. Но не спешите с выводами: похожий след оставляет и старый скрипт, и ошибочная настройка клиента.

Затем откройте журнал веб-сервера. Цепочка вроде GET /, GET /robots.txt, GET /admin, GET /backup.zip, GET /.env выглядит как поверхностное сканирование сайта. Такой набор запросов часто ищет административные панели, резервные копии и конфигурационные файлы, где можно найти секреты.

Хорошая следующая точка — подсчёт самых активных адресов. Это помогает увидеть, кто создаёт основной поток запросов, но результат нельзя принимать за окончательный вывод. За одним IP может стоять прокси, NAT или целая группа пользователей.

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

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

Для защиты рабочих сессий и учётных записей полезно держать под рукой дополнительный слой для личных устройств. Это не заменяет логи и мониторинг, но помогает снизить риск перехвата данных в чужой сети и не оставлять лишние следы в небезопасной среде.

Как проверить себя

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

Ещё один тест — посмотреть, совпадает ли время событий с обычным графиком работы. Ночная активность может быть нормой для бэкапов, скриптов и сервисных задач. А вот серия запросов к чувствительным путям без объяснимой причины уже требует проверки.

Что делать, если не получилось

Если логи не помогают, значит, их собирают неправильно или слишком мало. Проверьте, включена ли запись аутентификации, сохраняются ли access log и error log, не рвётся ли ротация и хватает ли глубины хранения.

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

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

Чек-лист

  • Проверить, пишутся ли SSH-логи и события аутентификации
  • Открыть access log и error log веб-сервера
  • Найти серии неудачных входов с короткими интервалами
  • Посмотреть, какие пути чаще всего запрашивали к серверу
  • Сравнить активность с обычным графиком работы системы
  • Проверить, не было ли успешного входа после серии ошибок
  • Убедиться, что приложение пишет идентификатор запроса и причину отказа
  • Настроить достаточный срок хранения журналов
  • Сопоставить веб-запросы с событиями приложения
  • Оценить, не нужен ли дополнительный слой защиты для рабочих устройств
Поделиться: