ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Популярное и похожее

Курс по сетям

Что такое Active Directory и LDAP?

URL и URI — в чем различие?

Погружение в Iptables – теория и настройка

Самое интересное про SMTP, POP3 и IMAP

Передача файлов по RDP – это просто

BootHole бросает вызов системам Windows и Linux

Apache или IIS – сравнение и преимущества

Еженедельный дайджест

Syslog протокол — серверы, сообщения и безопасность

4 минуты чтения

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

Обучайся в Merion Academy

Пройди курс по сетевым технологиям

Начать

Большинство сетевых устройств, таких как маршрутизаторы и коммутаторы, могут отправлять сообщения системного журнала. Кроме того, серверы *nix также могут генерировать данные системного журнала, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache. Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать данные журнала событий Windows или IIS и пересылать их на сервер Syslog.

В отличие от SNMP, Syslog не может использоваться для «опроса» устройств для сбора информации. Например, SNMP имеет сложную иерархическую структуру, которая позволяет станции управления запрашивать у устройства информацию о таких вещах, как данные о температуре или доступное дисковое пространство. Это невозможно с Syslog — он просто отправляет сообщения в центральное место, когда инициируются определенные события.

Syslog серверы

Syslog — отличный способ объединить логи из нескольких источников в одном месте. Как правило, большинство серверов Syslog имеют несколько компонентов, которые делают это возможным.

• Syslog слушатель: Syslog сервер должен получать сообщения, отправленные по сети. Процесс прослушивания собирает данные системного журнала, отправленные через 514 UDP порт. Как мы знаем UDP-сообщения не подтверждаются или не гарантируются, поэтому имейте в виду, что некоторые сетевые устройства будут отправлять данные Syslog через 1468 TCP порт для обеспечения доставки сообщений.
• База данных: большие сети могут генерировать огромное количество данных syslog’а . Хорошие серверы будут использовать базу данных для хранения логов для быстрого поиска.
• Программное обеспечение для управления и фильтрации: из-за больших объемов данных иногда бывает сложно найти конкретные записи в журнале. Решение состоит в том, чтобы использовать syslog сервер, который автоматизирует часть работы и позволяет легко фильтровать и просматривать важные сообщения журнала. Серверы должны иметь возможность генерировать оповещения, уведомления и алерты в ответ на выбранные сообщения, чтобы администраторы сразу узнавали, когда возникла проблема, и могли предпринять быстрые действия

Syslog сообщения

Сообщения системного журнала обычно содержат информацию, помогающую определить основную информацию о том, где, когда и почему был отправлен лог: IP-адрес, отметка времени и фактическое сообщение.

Системный журнал использует концепцию, называемое “facility”, чтобы идентифицировать источник сообщения на любом компьютере. Например, facility “0” будет сообщением ядра, а facility «11» будет сообщением FTP. Это восходит своими корнями к syslog’а UNIX. В большинстве сетевых устройств Cisco используются коды объектов «Local6» или «Local7».

Syslog сообщения также имеют поле уровня серьезности. Уровень серьезности указывает, насколько важным считается сообщение. Серьезность «0» является чрезвычайной ситуацией, «1» — это предупреждение, которое требует немедленных действий, а шкала продолжается вплоть до «6» и «7» — информационных и отладочных сообщений.

0	Emergency	Система не работоспособна
1	Alert	Система требует немедленного вмешательства
2	Critical	Состояние системы критическое
3	Error	Сообщения об ошибках
4	Warning	Предупреждения о возможных проблемах
5	Notice	Сообщения о нормальных, но важных событиях
6	Informational	Информационные сообщения
7	Debug	Отладочные сообщения

Недостатки syslog

У протокола syslog есть несколько недостатков.

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

Есть также некоторые проблемы, которые возникают из-за того, что syslog использует UDP в качестве транспорта — поэтому возможно потерять сообщения из-за перегрузки сети или потери пакетов.

Наконец, есть некоторые проблемы безопасности. В сообщениях syslog’а нет аутентификации, поэтому один компьютер может выдать себя за другой компьютер и отправить ложные события журнала. Он также подвержен повторным атакам.

Несмотря на это, многие администраторы считают, что syslog является ценным инструментом, и что его недостатки относительно незначительны.

Настройка rsyslog для хранения логов на удаленном сервере

Rsyslog позволяет настроить отправку логов для определенного приложения на централизованный сервер. Это может значительно упростить процесс контроля за событиями на компьютерах в сети. Его настройка на различных системах на базе Linux, практически, не отличается. В данной инструкции мы рассмотрим процесс установки и настройки на примере CentOS и Ubuntu.

Подготовка сервера

На сервере нужно, предварительно, выполнить следующие настройки.

Время

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

Сначала задаем правильный часовой пояс:

\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* в данном примере мы использовали московское время.

Затем устанавливаем и запускаем chrony.

а) на системе CentOS / Red Hat:

yum install chrony

systemctl enable chronyd

systemctl start chronyd

б) на системе Ubuntu / Debian:

apt-get install chrony

systemctl enable chrony

systemctl start chrony

Брандмауэр

Если используется брандмауэр, необходимо открыть порты TCP/UDP 514.

а) с помощью firewalld:

firewall-cmd —permanent —add-port=514/

б) с помощью iptables:

iptables -A INPUT -p tcp —dport 514 -j ACCEPT

iptables -A INPUT -p udp —dport 514 -j ACCEPT

в) с помощью ufw:

ufw allow 514/tcp

ufw allow 514/udp

SELinux

Проверяем, работает ли в нашей системе SELinux:

Если мы получаем в ответ:

. необходимо либо настроить SELinux:

semanage port -m -t syslogd_port_t -p tcp 514

semanage port -m -t syslogd_port_t -p udp 514

. либо отключить его командами:

sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config

Установка и запуск rsyslog

Установить rsyslog необходимо как на сервер, так и клиентские компьютеры. В зависимости от операционной системы сама установка будет выполняться одной из команд.

а) для систем на базе RPM (Red Hat / CentOS):

yum install rsyslog

б) для систем на базе deb (Debian / Ubuntu):

apt-get install rsyslog

После установки разрешаем автозапуск службы и стартуем ее:

systemctl enable rsyslog

systemctl start rsyslog

Настройка сервера

Открываем конфигурационный файл:

Снимаем комментарии со следующих строк:

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514

* в данном примере мы разрешили запуск сервера для соединений TCP и UDP на портах 514. На самом деле, можно оставить только один протокол, например, более безопасный и медленный TCP.

После добавляем в конфигурационный файл строки:

$template RemoteLogs,»/var/log/rsyslog/%HOSTNAME%/%PROGRAMNAME%.log»
*.* ?RemoteLogs
&

* в данном примере мы создаем шаблон с названием RemoteLogs, который принимает логи всех категорий, любого уровня (про категории и уровни читайте ниже); логи, полученный по данному шаблону будут сохраняться в каталоге по маске /var/log/rsyslog/ / .log; конструкция &

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

Перезапускаем службу логов:

systemctl restart rsyslog

Настройка клиента

Устанавливаем и запускаем rsyslog по инструкции, описанной выше. После приступаем к настройке клиента.

Все логи

Для начала можно настроить отправку всех логов на сервер. Создаем конфигурационный файл для rsyslog:

* где 192.168.0.15 — IP-адрес сервера логов. *.* — перенаправлять любой лог.

systemctl restart rsyslog

Для определенных категорий

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

Перезапускаем сервис логов:

systemctl restart rsyslog

Возможные категории для логов (facility):

№	Категория	Описание
0	kern	Сообщения, отправляемые ядром
1	user	Пользовательские программы
2	mail	Почта
3	daemon	Сервисы (демоны)
4	auth	Безопасность/вход в систему/аутентификация
5	syslog	Сообщения от syslog
6	lpr	Логи печати
7	news	Новостные группы (usenet)
8	uucp	Unix-to-Unix CoPy (копирование файлов между компьютерами)
9	cron	Планировщик заданий
10	authpriv	Безопасность/вход в систему/аутентификация — защищенный режим
11	ftp	Логи при передачи данных по FTP
12	ntp	Лог службы синхронизации времени (существует не везде)
13	security, log audit	Журнал аудита (существует не везде)
14	console, log alert	Сообщения, отправляемые в консоль (существует не везде)
15	solaris-cron, clock daemon	Cron в solaris (существует не везде)
16-23	local0 — local7	Зарезервированы для локального использования. Уровень серьезности определяется числом от 0 до 7.

Для определенного уровня

Если мы хотим передавать только сообщения об ошибках, добавляем строку в файл конфигурации rsyslog:

Перезапускаем сервис логов:

systemctl restart rsyslog

Возможные уровни логов:

Возможные категории для логов (severity):

№	Уровень	Расшифровка
0	emerg	Система не работает (PANIC)
1	alert	Серьезная проблема, требующая внимания
2	crit	Критическая ошибка
3	err	Ошибка (ERROR)
4	warning	Предупреждение (WARN)
5	notice	Важное информационное сообщение
6	info	Информационное сообщение
7	debug	Отладочная информация

Аудит определенного лог-файла

Мы можем настроить слежение за изменением определенного лога и передавать их на сервер. Для этого нужно настроить и сервер, и клиента.

Настройка клиента

Создаем новый конфигурационный файл:

$ModLoad imfile
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor

* в данном примере мы будем отслеживать изменения лог-файла /var/log/audit/audit.log; нас интересуют события от уровня info и выше; все события будет отмечены категорией local6 и переданы на сервер 192.168.0.15.

Перезапускаем сервис на клиенте:

systemctl restart rsyslog

Настройка сервера (фильтрация сообщений)

На сервере нам нужно фильтровать все сообщения категории local6 (такую категорию мы выбрали, когда настроили клиента) и перенаправлять их в нужных нам файл. Открываем на редактирование конфигурационный файл rsyslog:

Создаем новый шаблон для захвата логов:

$template HostAudit, «/var/log/rsyslog/%HOSTNAME%/audit.log»
local6.* ?HostAudit

* в данном примере мы создаем шаблон HostAudit; rsyslog будет принимать логи категории local6 и сохранять в файле /var/log/rsyslog/ /audit.log.

systemctl restart rsyslog

Лог определенного приложения

Некоторые приложения умеют отправлять лог напрямую на syslog. Например, nginx (начиная с версии 1.7.1). Для этого открываем конфигурационной файл (основной или конфиг виртуального домена):

Добавляем или редактируем соответствующие настройки для логов:

.
access_log syslog:server=192.168.0.15:514 info;
error_log syslog:server=192.168.0.15:514 warn;
error_log /var/log/nginx/error.log warn;
.

* в данном примере мы настроили хранение логов для nginx на сервере 192.168.0.15. Для ошибок также сохраняется локальный лог в файле /var/log/nginx/error.log.

Проверяем корректность конфигурационного файла nginx:

systemctl restart nginx

Чтение логов на сервере

В нашем примере сервер настроен на хранение логов по маске /var/log/rsyslog/%HOSTNAME%/%PROGRAMNAME%.log. Это значит, что в каталоге /var/log/rsyslog должны появляться папки с именами компьютеров, которые отправляют на сервер свои логи. Посмотреть список данных папок можно командой:

Чтение логов выполняется обычной командой cat или tail, например:

* здесь мы прочитаем лог для cron на компьютере comp1.