Настройка удалённого сервера логирования на Linux

Введение

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

В этом руководстве вы узнаете, как развернуть удалённый сервер логирования (лог-хост) на Linux, чтобы агрегировать локальные логи удалённых машин и хранить их централизованно для удобного доступа и анализа.

Почему нужен выделенный лог-хост

Система syslog (и современные демоны типа rsyslog) записывает большинство событий операционной системы. Тем не менее отдельный лог-хост даёт практические преимущества:

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

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

Основные понятия (1‑строчное определение)

• rsyslog: расширенный syslog-демон для приёма, фильтрации и пересылки логов.
• log host: центральный сервер, принимающий логи от клиентов.
• client: хост, отправляющий свои системные логи на лог-хост.

Шаг 1 — Установка rsyslog на Linux

Руководство ориентировано на Ubuntu 20.04, но большая часть шагов применима и к другим дистрибутивам.

rsyslog обычно предустановлен на современных дистрибутивах. Если он отсутствует, установите его командой, соответствующей вашему дистрибутиву.

Debian / Ubuntu:

sudo apt update
sudo apt install rsyslog

Red Hat / CentOS (yum):

sudo yum install rsyslog

Fedora (dnf):

sudo dnf install rsyslog

Arch (yay):

yay -S rsyslog

Проверить статус службы:

sudo systemctl status rsyslog

Вывод примера состояния службы можно увидеть на изображении ниже.

Шаг 2 — Конфигурация лог-хоста (приём сообщений)

Лог-хост — сервер, на который приходят сообщения от клиентов. Конфигурация rsyslog обычно расположена в /etc/rsyslog.conf, а также в папке /etc/rsyslog.d/.

Перед редактированием всегда делайте резервную копию:

sudo cp /etc/rsyslog.conf /etc/rsyslog_original.config

Откройте файл для редактирования (пример с vim):

sudo vim /etc/rsyslog.conf

rsyslog поддерживает приём по UDP и TCP. Не обязательно включать оба — выберите то, что подходит вашей сети.

Для UDP — найдите и раскомментируйте (уберите #) модуль imudp и вход для порта 514:

module(load="imudp")
input(type="imudp" port="514")

Для TCP — раскомментируйте модуль imtcp и вход для порта 514:

module(load="imtcp")
input(type="imtcp" port="514")

Пример фрагмента конфигурации с включённым UDP показан ниже.

Организация файлов логов: рекомендовано хранить логи по директориям, соответствующим имени отправителя. Добавьте шаблон и правило в конфиг:

$template remote-incoming-logs, "/var/log/remote/%HOSTNAME%".log
*.* ?remote-incoming-logs

Эти строки указывают, что входящие логи будут храниться в /var/log/remote/.log.

Сохраните изменения и перезапустите службу:

sudo systemctl restart rsyslog

Важно: проверьте, что каталог /var/log/remote существует и имеет корректные права:

sudo mkdir -p /var/log/remote
sudo chown syslog:adm /var/log/remote
sudo chmod 750 /var/log/remote

Шаг 3 — Настройка фаервола

Если фаервол включён, разрешите порт для выбранного протокола (по умолчанию 514). Примеры для популярных инструментов:

UFW (Debian/Ubuntu):

UDP:

sudo ufw allow 514/udp

TCP:

sudo ufw allow 514/tcp

FirewallD (Fedora/CentOS):

sudo firewall-cmd --permanent --add-port=514/udp
sudo firewall-cmd --permanent --add-port=514/tcp
sudo firewall-cmd --reload

iptables (RHEL старые версии): добавьте правило в /etc/sysconfig/iptables:

-A INPUT -m state --state NEW -m udp -p udp --dport 514 -j ACCEPT

Перезапустите iptables:

sudo service iptables restart

Важно: в продуктивной среде ограничивайте источник подключений — разрешайте только IP-адреса клиентов или подсети, от которых ожидаете логи.

Шаг 4 — Настройка клиента (отправка логов)

На клиенте откройте /etc/rsyslog.conf или добавьте файл в /etc/rsyslog.d/ с правилом отправки.

Открываем конфиг:

sudo vim /etc/rsyslog.conf

Для отправки по UDP (замените IP на адрес вашего лог-хоста):

*.* @192.168.12.123:514

Для отправки по TCP (двойной @):

*.* @@192.168.12.123:514

После внесения изменений перезапустите сервис:

sudo systemctl restart rsyslog

Проверьте отправку простым тестом (пример для системных логов):

logger "test message to remote log host"

Шаг 5 — Просмотр логов на сервере

Подключитесь по SSH к лог-хосту и перейдите в каталог с удалёнными логами:

cd /var/log/remote
ls -l

Вы увидите файлы вроде andiwa.log и rukuru.log — каждый файл соответствует имени хоста-отправителя.

Открывать логи можно стандартными утилитами:

less andiwa.log
cat rukuru.log | tail -n 200
journalctl -u rsyslog

Практики безопасности и надёжности

1. Шифрование каналов: для защищённой передачи используйте TLS (rsyslog поддерживает omfwd с TLS). Это защищает логи от перехвата в сетях общего пользования.

2. Ограничение источников: на фаерволе разрешайте подключение только с доверенных IP. Можно также настроить ACL в rsyslog.

3. Аутентификация сертификатами: при TLS используйте взаимную аутентификацию (client certs) и централизованный PKI.

4. Контроль целостности: храните контрольные суммы/хеши важнейших логов и регулярно проверяйте их.

5. Ротация и хранение: используйте logrotate для управления размерами логов и политик хранения/архивации.

6. Мониторинг и алёртинг: подключите SIEM/ELK/Graylog/Prometheus Alertmanager для оповещений и корреляции событий.

Альтернативные подходы и инструменты

• syslog-ng: замена rsyslog с расширенными возможностями фильтрации и передачи.
• Fluentd / Fluent Bit: удобны для сбора логов приложений и отправки в облачные хранилища и аналитические системы.
• Beats (Filebeat) + Elasticsearch/Logstash/Kibana: стек для поиска и визуализации логов.

Когда rsyslog не подходит: если нужно высоко масштабируемое, индексируемое хранилище логов с быстрыми поисками и визуализацией, подумайте о ELK/EFK/Graylog.

Критерии приёмки

• Логи от тестового клиента корректно появляются в /var/log/remote/.log.
• Служба rsyslog на сервере активна и слушает ожидаемый порт (netstat/ss показывает слушающий порт).
• Фаервол пропускает трафик только от доверенных подсетей.
• Передача по TLS (если настроена) проходит с верификацией сертификатов.

Проверки:

ss -tulnp | grep 514
sudo tail -f /var/log/remote/.log
sudo journalctl -u rsyslog -f

Руководство по устранению неполадок (Troubleshooting)

• Ничего не приходит на сервер:

  • Убедитесь, что rsyslog слушает порт: ss -tulnp | grep 514
  • Проверьте фаервол на клиенте и сервере.
  • На клиенте используйте tcpdump для проверки отправки: sudo tcpdump -i any host 192.168.12.123 and port 514

• Логи приходят, но в неправильном формате:

  • Проверьте шаблон сохранения remote-incoming-logs и правила фильтрации.

• Проблемы с TLS:

  • Проверьте пути к сертификатам, права доступа и корректность цепочки сертификатов.

• Ошибки в журнале rsyslog:

sudo journalctl -u rsyslog | tail -n 200

Мини‑методология внедрения (шаги для проекта)

1. Тест: разверните лог-хост в тестовой сети.
2. Настройте одного клиента и убедитесь в корректности приёма.
3. Настройте фаервол и TLS (если нужно).
4. Подключайте поэтапно другие хосты, контролируя нагрузку.
5. Внедрите ротацию логов и политику хранения.
6. Интегрируйте с системой мониторинга и алёртинга.

Быстрый чек‑лист для администратора

• Установлен rsyslog на сервере и клиентах
• Включён нужный input (imudp или imtcp)
• Создан каталог /var/log/remote с корректными правами
• Разрешён порт 514 в фаерволе (только для доверенных IP)
• Настроен шаблон хранения логов
• Проверена отправка с клиента (logger)
• Настроена ротация логов и резервное копирование
• (Опционально) Включён TLS и аутентификация сертификатами

Короткий словарь терминов

• log host: центральный сервер для сбора логов.
• rsyslog: демон для приёма/фильтрации/пересылки логов.
• imudp/imtcp: модули rsyslog для приёма по UDP/TCP.

Примеры конфигураций (шаблоны)

Пример файла /etc/rsyslog.d/remote.conf на сервере (UDP):

module(load="imudp")
input(type="imudp" port="514")
$template remote-incoming-logs, "/var/log/remote/%HOSTNAME%".log
*.* ?remote-incoming-logs

Пример файла /etc/rsyslog.d/forward.conf на клиенте (TCP):

*.* @@192.168.12.123:514

Примечания по приватности и соответствию требованиям

Если логи содержат персональные данные или чувствительную информацию (PII), необходимо:

• Ограничить доступ к логам по ролям и правам файловой системы.
• Шифровать передачу логов (TLS).
• Определить сроки хранения и политику удаления в соответствии с требованиями локального законодательства и корпоративной политикой.

Когда централизованное логирование не решит проблему (контрпример)

• Если требуется полная индексация и поиск по терабайтам данных с аналитикой в реальном времени, простого rsyslog + файловое хранилище может быть недостаточно. В этом случае лучше использовать ELK/EFK/Graylog или коммерческие SIEM.

Краткое резюме

Удалённый лог-хост на базе rsyslog — простой и эффективный способ централизовать логи с множества Linux-хостов. Он повышает управляемость, безопасность и удобство архивации. В продакшене рекомендуется дополнить простую настройку шифрованием (TLS), ограничением источников и интеграцией с системой мониторинга.

Важно: всегда тестируйте изменения в безопасной среде и документируйте политику хранения логов.