Как настроить удалённый лог‑сервер (rsyslog) на Linux

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

Этот материал объясняет, как поднять удалённый лог‑сервер (log host) на Linux, чтобы агрегировать логи с нескольких узлов в одном месте для удобного анализа и архивации.

Почему нужен выделённый лог‑сервер

Linux ведёт большинство системных сообщений через демон syslog/rsyslog. Почему стоит вынести логи на отдельный сервер:

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

Важно: логи — часть процедур превентивного обслуживания и аудита инфраструктуры.

Краткая структура решения

• Роль «лог‑хоста» (сервер) — принимает входящие сообщения и хранит их по шаблону.
• Роль «клиента» — отправляет свои локальные сообщения на лог‑хост по UDP или TCP.
• Сеть и фаервол — разрешают выбранный порт (обычно 514).
• Политика хранения — ротация, удержание и, при необходимости, редактирование/анонимизация логов.

Что умеет rsyslog — одно предложение

rsyslog — это расширенный демон syslog с поддержкой шаблонов, протоколов TCP/UDP, модулей входа/выхода и гибкой маршрутизацией сообщений.

Шаг 1: Установка 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 Linux (AUR helper):

yay -S rsyslog

Проверить статус демона:

systemctl status rsyslog

Вывод состояния сервиса (пример):

Шаг 2: Настройка лог‑хоста (приёмника)

Файл конфигурации rsyslog обычно находится в /etc/rsyslog.conf. Перед изменением создайте резервную копию:

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

Откройте файл в редакторе (пример Vim):

sudo vim /etc/rsyslog.conf

Rsyslog поддерживает два транспорта: UDP и TCP. Выберите один.

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

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

Для приёма по TCP используйте:

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.

Сохраните файл и перезапустите rsyslog:

sudo systemctl restart rsyslog

Примечание: если используется SELinux на дистрибутивах Red Hat, убедитесь, что контекст и политика позволяют rsyslog писать в /var/log/remote.

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

Если фаервол включён, откройте порт 514 для выбранного протокола.

UFW (Ubuntu/Debian):

• Для UDP:

sudo ufw allow 514/udp

• Для TCP:

sudo ufw allow 514/tcp

firewalld (Fedora/Red Hat):

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

iptables (старые системы Red Hat):

Откройте /etc/sysconfig/iptables и добавьте правило для UDP:

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

Затем перезапустите службу iptables (в зависимости от системы):

sudo service iptables restart

Проверки фаервола и порта:

• ss или netstat: убедитесь, что rsyslog слушает на 0.0.0.0:514

ss -ltnp | grep 514
ss -lunp | grep 514

• tcpdump/wireshark: отловьте трафик на интерфейсе для подтверждения прихода пакетов.

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

На клиенте откройте /etc/rsyslog.conf и добавьте строку для пересылки логов:

Для UDP (один символ @):

*.* @192.168.12.123:514

Для TCP (два символа @@):

*.* @@192.168.12.123:514

Где 192.168.12.123 — IP адрес вашего лог‑хоста. Сохраните и перезапустите rsyslog:

sudo systemctl restart rsyslog

Совет: вместо IP можно использовать DNS‑имя; в конфигурации можно ограничить пересылку по приоритетам/фасилам логов.

Шаг 5: Проверка приёма логов на сервере

Залогиньтесь по SSH на лог‑хост и перейдите в каталог с удалёнными логами:

cd /var/log/remote
ls -l

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

Просмотреть лог можно командами cat/less/grep:

less andiwa.log
grep sshd andiwa.log | tail -n 50

Тестирование и отладка — пошагово

1. На клиенте: убедитесь, что локально rsyslog генерирует сообщения (logger):

logger "test message to remote"

2. На клиенте: проверьте, отправляются ли соединения на лог‑хост (tcpdump):

sudo tcpdump -n host 192.168.12.123 and port 514

3. На сервере: проследите, приходят ли пакеты и пишутся ли они в файл.

4. Проверить, слушает ли rsyslog нужный порт:

ss -ltnp | grep rsyslog
ss -lunp | grep rsyslog

5. Если логов нет: проверить фаервол, SELinux (audit.log), права на каталог /var/log/remote и свободное место на диске.

6. Логи SELinux могут блокировать запись — используйте audit2why/audit2allow для диагностики.

Политика хранения и ротация

Rsyslog не управляет ротацией сам по себе — используйте logrotate или аналог. Пример /etc/logrotate.d/remote:

/var/log/remote/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 0640 root adm
    postrotate
        systemctl reload rsyslog > /dev/null 2>&1 || true
    endscript
}

Рекомендации: храните критичные логи дольше, а временные — короче; автоматизируйте архивацию и удаление.

Безопасность и приватность

• Логи часто содержат чувствительные данные (PII, IP, команды). Ограничьте доступ к /var/log/remote через ACL и группы.
• По возможности фильтруйте или маскируйте PII на клиенте перед отправкой.
• Для передачи по открытому каналу рассмотрите туннелирование rsyslog через TLS либо пересылку в VPN.
• Для соответствия GDPR/локальным законам документируйте сроки хранения и процедуры удаления.

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

• syslog‑ng: более гибкий и часто используемый в крупных инсталляциях.
• journald + systemd‑journal‑remote: перенос журналов systemd‑journal.
• Переадресация в систему сбора логов: ELK/Elastic, Graylog, Splunk — добавляют поиск, корреляцию и визуализацию.

Когда выбирать альтернативы: если нужны полные возможности поиска и визуализации — стоит смотреть на ELK/Graylog. Для простой, лёгкой и надёжной пересылки rsyslog остаётся отличным выбором.

Модель принятия решений — выбирать UDP или TCP

• UDP: низкая нагрузка, не контролирует доставку — подходит для больших количеств событий, где потеря отдельных записей допустима.
• TCP: гарантированная доставка и контроль потока — предпочтительнее для критичных логов.

flowchart TD
  A[Нужна ли гарантированная доставка?] -->|Да| B[Используйте TCP]
  A -->|Нет| C[Можно использовать UDP]
  B --> D[Откройте порт 514/tcp и настройте rsyslog imtcp]
  C --> E[Откройте порт 514/udp и настройте rsyslog imudp]

Роль‑ориентированные чек-листы

Системный администратор:

• Установить и запустить rsyslog.
• Настроить шаблон хранения /var/log/remote/%HOSTNAME%.log.
• Обеспечить ротацию через logrotate.
• Настроить мониторинг дискового пространства и прав доступа.

Инженер по безопасности:

• Проверить открытые порты и ограничить доступ по сети (ACL, firewall).
• Рассмотреть TLS или VPN для передачи логов.
• Оценить содержание логов на предмет PII и настроить маскировку.

Оператор/DevOps:

• Протестировать доставку сообщений от клиентов.
• Настроить интеграцию с SIEM/аналитикой при необходимости.
• Автоматизировать резервное копирование и архивацию логов.

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

• Клиентские сообщения появляются в /var/log/remote/.log.
• Для выбранного протокола (UDP/TCP) порт 514 слушается на лог‑хосте.
• Права доступа к файлам настроены согласно политике безопасности.
• Ротация и сжатие логов работает без ошибок.

Краткий план действий при инциденте (runbook)

1. Убедиться, что rsyslog запущен: systemctl status rsyslog.
2. Проверить слушаемые порты: ss -ltnp / ss -lunp.
3. Проверить сетевой трафик: tcpdump host <клиент> and port 514.
4. Проверить фаервол и правила безопасности.
5. Проверить SELinux/audit.log на блокировки.
6. Если логов нет — включить расширенное логирование rsyslog и временно увеличить уровень трассировки.

Мини‑шпаргалка — примеры конфигураций

Сервер (фрагмент /etc/rsyslog.conf):

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

Клиент (фрагмент /etc/rsyslog.conf):

*.* @@log-host.example.local:514

Замены: используйте @ для UDP и @@ для TCP.

Небольшой глоссарий — 1 строка на термин

• rsyslog: расширенный демон syslog для маршрутизации и записи системных сообщений.
• log host: сервер, принимающий логи от других машин.
• UFW/firewalld/iptables: инструменты управления сетевыми правилами.
• PII: персональные данные пользователя (лично идентифицируемая информация).

Когда централизованный лог‑сервер не подойдёт

• В сетях с крайне ограниченной связью или где нельзя открыть порт 514 — тогда используют агентную передачу через HTTPS/брокер сообщений.
• Если нужна сложная аналитика и корреляция инцидентов — потребуются системы уровня SIEM/ELK.

Резюме

Централизованный лог‑сервер на базе rsyslog даёт простую, надёжную и масштабируемую базу для хранения системных сообщений. Настройка сводится к: установить rsyslog, разрешить приём на сервере, настроить клиентов и позаботиться о безопасности и ротации. Для Production‑окружения решающими будут выбор транспорта (TCP vs UDP), политика хранения и меры по защите чувствительных данных.

Important: после развёртывания протестируйте доставку логов и настройте мониторинг заполнения логов и дискового пространства.