rsyslog + TLS: переходим с UDP syslog на защищённый транспорт

Со стандартным syslogd на UDP мы жили давно и не особо жаловались. UDP работает, логи пишутся, сервер их копит - чего ещё надо? Надо, как выяснилось, немного больше. Подтолкнул к переосмыслению один из клиентов, которого мы готовим к выполнению требований 152-ФЗ: регулятор прямо указывает на необходимость защиты каналов передачи персональных данных, а логи у него летят открытым текстом через UDP поверх общей сети. Это, мягко говоря, не то.

Начали смотреть на rsyslog - демон, который сначала воспринимали как «syslogd с наворотами», а теперь видим как нормальную замену.

Что не так с UDP syslog

UDP - это fire and forget. Если коллектор перегружен или временно недоступен, пакеты молча уходят в никуда. Никаких ретраев, никаких квитанций. На небольшом объекте это незаметно. Когда машин двадцать и все они начинают гонять логи в пиковый момент - например, при инциденте, когда логи нужны особенно сильно, - коллектор захлёбывается именно тогда, когда меньше всего хочется что-то потерять.

Второй момент - открытый текст. Syslog-сообщения идут нешифрованными. Если сеть общая с клиентским сегментом или передача идёт через публичный канал - любое содержимое логов доступно тому, кто умеет слушать трафик. Для сред, где в логах мелькают имена пользователей, адреса, данные транзакций, это прямой путь к неприятностям с тем же 152-ФЗ.

Почему rsyslog

rsyslog 3.x появился не вчера, но именно сейчас он вырос до того состояния, когда его интересно ставить на производственные серверы. Что там есть:

• TCP-транспорт. В отличие от UDP, TCP даёт надёжную доставку с буферизацией. При перегрузке коллектора клиент встаёт в очередь, а не теряет сообщения.
• TLS-шифрование через gtls. Встроенная поддержка TLS - логи идут зашифрованным каналом. Перехватить трафик и прочитать - уже нетривиальная задача.
• Гибкие правила фильтрации и маршрутизации. Можно отправлять разные facility на разные коллекторы, писать в файлы по шаблонам, строить цепочки обработки.
• Компатибельность с syslogd. Конфиг rsyslog читает директивы старого формата, переход не требует переписывать всё с нуля.

Как выглядит схема

[Linux-сервер: rsyslog-клиент]
       |  TCP + TLS (gtls)
       v
[Центральный коллектор: rsyslog-сервер]
       |
       v
  /var/log/remote/<hostname>/

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

Для TLS нужна CA и клиентские сертификаты. Мы выпускаем их собственной CA с помощью openssl - ничего экзотического, та же схема, что для внутренних VPN. Каждый сервер получает свой сертификат, коллектор проверяет его при установке соединения. Подключиться к коллектору с левой машины без подписанного сертификата - не выйдет.

Что пришлось решать

Gtls на rsyslog 3.x требует libgnutls. На CentOS 5 это добавляется через yum без проблем, на более старых системах бывает сложнее - пришлось на одном объекте собирать rsyslog из исходников, потому что пакет из репозитория шёл без поддержки TLS. Не страшно, но занимает время.

Порт по умолчанию для rsyslog с TLS - 6514. Нужно открыть на коллекторе и проследить, что между клиентами и коллектором нет файрвола, который это режет. У одного клиента как раз был - забыли добавить правило, час потратили на диагностику, пока не догадались поднять tcpdump.

Буферизация на клиенте настраивается отдельно. rsyslog умеет хранить очередь сообщений на диске (disk-assisted queue) - если коллектор упал, клиент накапливает сообщения и доставляет, когда связь восстановилась. По умолчанию это не включено, нужно явно прописать в конфиге. Включили на всех объектах - при плановом обслуживании коллектора теперь не теряем ничего.

152-ФЗ и логи

Наш клиент из торговли готовится к приведению в соответствие - мы описывали этот аудит раньше. Там в числе прочего выяснилось, что логи информационных систем с персональными данными гуляют по сети незащищённо. Технические требования ФСТЭК к ИСПДн прямо говорят о защите каналов передачи - и это не только про передачу самих персданных, но и про управляющий трафик и журналы.

Переход на rsyslog с TLS снимает этот пункт. Теперь коллектор принимает только сообщения от авторизованных хостов, трафик зашифрован, целостность обеспечивается протоколом. На работах по ISO 27001 тоже записали в плюс: централизованные логи с надёжной доставкой - это конкретная мера контроля из Приложения A, которую теперь можно закрыть не словами, а фактом.

Где мы сейчас

Перевели на rsyslog четыре объекта - два на CentOS 5, один на Debian Etch, один на Ubuntu 8.04, который мы ставили в апреле. Схема везде одна, конфиги типовые. Коллектор на каждом объекте свой - выносить логи клиентов на общий коллектор пока не планируем, у каждого свои требования по хранению и доступу.

Откатываться обратно на syslogd не собираемся. UDP - это удобно, пока не сталкиваешься с потерями в неподходящий момент. TCP с TLS добавляет надёжности и закрывает вопрос с открытым текстом в сети - для сопровождаемой инфраструктуры это теперь стандарт при любом новом развёртывании.

Один нюанс, который пока открыт: мониторинг самого rsyslog-коллектора. Если он упал - клиенты молча буферизуют, но никто не бьёт тревогу. Nagios умеет проверять TCP-порт, но хотелось бы что-то умнее. Смотрим в сторону проверки возраста последнего сообщения в лог-файлах - если хост активный, но логов от него нет уже полчаса, это повод насторожиться. Расскажем, как настроим.