Введение
В областях системного администрирования и кибербезопасности анализ журналов (логов) является критически важным навыком. Системные журналы записывают широкий спектр событий, от рутинных операций до критических ошибок и потенциальных нарушений безопасности. Возможность эффективно ориентироваться и интерпретировать эти журналы необходима для мониторинга состояния системы, устранения неполадок и реагирования на инциденты безопасности.
Эта лабораторная работа знакомит вас с journalctl — стандартным инструментом для запроса и отображения журналов из службы journald в современных системах Linux. Вы научитесь выполнять основные задачи анализа журналов, которые составляют основу мониторинга и реагирования на инциденты.
В ходе этой лабораторной работы вы:
- Просмотрите журналы загрузки системы.
- Отфильтруете журналы для поиска конкретных событий, таких как сбои аутентификации.
- Смоделируете и обнаружите подозрительное событие.
- Экспортируете журналы для дальнейшего анализа.
Просмотр журналов загрузки системы с помощью Journalctl
На этом шаге вы научитесь использовать команду journalctl для просмотра системных журналов, уделяя особое внимание сообщениям, сгенерированным во время последнего процесса загрузки. Это распространенный первый шаг при диагностике проблем при запуске.
Команда journalctl позволяет запрашивать содержимое журнала systemd. Без каких-либо аргументов она отображает все журналы, что может быть избыточным.
Чтобы сделать вывод более управляемым, мы можем использовать флаг -b или --boot для просмотра только журналов текущей сессии загрузки.
Выполните следующую команду в вашем терминале, чтобы просмотреть журналы текущей загрузки:
journalctl -b
Вы увидите постраничный вывод, начинающийся с самых ранних сообщений процесса загрузки. Вы можете использовать клавиши со стрелками Вверх и Вниз для навигации. Нажмите q, чтобы выйти из постраничного режима и вернуться к командной строке.
-- Journal begins at Tue 2023-10-31 08:30:00 UTC, ends at Tue 2023-10-31 09:00:00 UTC. --
Oct 31 08:30:01 labex-vm kernel: Linux version 5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: KERNEL supported cpus:
Oct 31 08:30:01 labex-vm kernel: Intel GenuineIntel
Oct 31 08:30:01 labex-vm kernel: AMD AuthenticAMD
...
(END)
Эта команда неоценима для понимания того, какие службы успешно запустились, и для выявления любых ошибок, возникших во время запуска системы.
Фильтрация журналов по сбоям аутентификации
На этом шаге вы научитесь фильтровать журнал для поиска конкретных событий, таких как неудачные попытки аутентификации, которые критически важны для мониторинга безопасности. Распространенной целью для злоумышленников является служба SSH, поэтому мониторинг ее журналов имеет высокий приоритет.
Мы можем использовать флаг -u с journalctl для фильтрации журналов по конкретному юниту systemd. Для службы SSH юнит обычно называется ssh.service (в Ubuntu/Debian) или sshd.service (в Red Hat/CentOS).
Давайте отфильтруем журналы, чтобы увидеть только записи, относящиеся к демону SSH. Обратите внимание, что для просмотра системных журналов вам может потребоваться использовать sudo:
sudo journalctl -u ssh
Эта команда показывает все записи журнала, сгенерированные службой sshd. Чтобы сузить наш поиск до потенциальных проблем безопасности, мы можем передать этот вывод команде grep для поиска ключевых слов, таких как "Failed".
Выполните следующую команду, чтобы найти неудачные попытки ввода пароля для службы SSH:
sudo journalctl -u ssh | grep "Failed password"
Если недавних неудачных попыток входа не было, эта команда может не выдать никакого вывода. Это нормально для защищенной системы. На следующем шаге мы сами сгенерируем такое событие, чтобы увидеть, как оно отображается в журналах.
Имитация подозрительного события и анализ журналов
Теперь давайте имитируем подозрительное событие, а затем используем наши навыки анализа журналов для его обнаружения. Распространенным признаком атаки методом перебора является серия неудачных попыток входа. Мы имитируем одну из таких попыток, пытаясь подключиться по SSH к нашей собственной машине (localhost) с несуществующим именем пользователя.
Выполните следующую команду в вашем терминале. Вам будет предложено ввести пароль; вы можете ввести что угодно, так как ожидается, что попытка не удастся.
ssh non_existent_user@localhost
Система откажет в соединении, что является ожидаемым результатом. Вы должны увидеть сообщение, похожее на это:
non_existent_user@localhost's password:
Permission denied, please try again.
non_existent_user@localhost's password:
Permission denied (publickey,password).
Теперь, когда мы сгенерировали событие неудачного входа, давайте повторно выполним команду анализа журналов из предыдущего шага, чтобы увидеть, сможем ли мы его найти.
sudo journalctl -u ssh | grep "Failed password"
На этот раз команда должна выдать вывод, показывающий только что сделанную нами неудачную попытку.
Oct 31 09:15:12 labex-vm sshd[1234]: Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2
Это простое упражнение демонстрирует основной цикл реагирования на инциденты: происходит событие, оно регистрируется, а администратор или автоматизированная система анализирует журналы для его обнаружения.
Экспорт журналов для симуляции централизованного анализа
В реальном сценарии вы часто экспортируете журналы с отдельных машин на централизованный сервер журналов (например, SIEM) для долгосрочного хранения и корреляции. На этом шаге мы симулируем это, экспортируя наши последние журналы SSH в файл.
journalctl может выводить журналы в различных форматах. Формат json-pretty особенно полезен, поскольку он одновременно удобочитаем и легко парсится другими инструментами.
Давайте экспортируем все журналы SSH за последние 10 минут в файл с именем ssh_logs.json в вашей текущей директории (~/project).
sudo journalctl -u ssh --since "10 minutes ago" -o json-pretty > ~/project/ssh_logs.json
Теперь проверьте, что файл был создан:
ls -l ~/project
В списке файлов вы должны увидеть ssh_logs.json.
total 4
-rw-r--r-- 1 labex labex 1234 Oct 31 09:20 ssh_logs.json
Наконец, давайте посмотрим содержимое нашего экспортированного файла журнала.
cat ~/project/ssh_logs.json
Вывод будет представлять собой структурированный JSON-массив, где каждая запись журнала является объектом. Этот формат идеально подходит для загрузки в другие аналитические платформы.
[
{
"__CURSOR" : "s=...",
"__REALTIME_TIMESTAMP" : "...",
"__MONOTONIC_TIMESTAMP" : "...",
"_BOOT_ID" : "...",
"_TRANSPORT" : "syslog",
"PRIORITY" : "6",
"SYSLOG_FACILITY" : "4",
"SYSLOG_IDENTIFIER" : "sshd",
"MESSAGE" : "Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2",
"_PID" : "1234",
...
}
]
Вы успешно симулировали процесс подготовки журналов для централизованного анализа.
Резюме
В этой лабораторной работе вы получили практический опыт работы с journalctl, мощным инструментом для анализа журналов в современных системах Linux. Эти навыки являются фундаментальными для любого системного администратора, инженера DevOps или специалиста по безопасности.
Вы научились:
- Просматривать системные журналы и журналы загрузки для диагностики проблем при запуске.
- Фильтровать журналы по конкретным службам и содержимому сообщений для поиска релевантных событий.
- Выявлять подозрительную активность, такую как неудачные попытки входа, по записям в журналах.
- Экспортировать журналы в структурированном формате, таком как JSON, для централизованного хранения и дальнейшего анализа.
Овладение этими методами позволит вам лучше отслеживать ваши системы, более эффективно устранять неполадки и делать первые шаги в реагировании на инциденты безопасности.
