Як безпечно надсилати журнали пристрою на віддалений колектор

Пристрій може видавати журнали, колектор розташований з іншого боку інтернету, і перше питання, яке всі ставлять, — який тунель будувати. Таке формулювання починається не з того місця. Транспорт визначають формат, який пристрій здатен створювати, автентифікація, яку прийме колектор, і те, що має означати «доставлено», коли зв'язок обірветься. Запишіть ці три відповіді, і транспорт зазвичай обирається сам.

Почніть із того, що пристрій може видавати

На практиці є лише три форми. Окремі події syslog через UDP або TCP, автентифіковане завантаження HTTPS, вбудоване в продукт, або цілі файли, записані на диск, які потрібно перемістити. Міжмережевий екран, який уміє надсилати лише syslog через UDP, не стане відправником TLS через те, що ви додали тунель; він і далі слатиме непідтверджені датаграми, тепер усередині зашифрованого конверта.

Тому спершу проведіть інвентаризацію відправника: протокол, підтримка TLS і яка саме бібліотека TLS, чи вміє він перевіряти сертифікат колектора, чи може пред'явити клієнтський сертифікат і чи переживає буфер надсилання перезавантаження. Усе, чого пристрій не вміє, має зробити хтось інший на шляху, і цей хтось стає частиною вашого проєкту.

TLS syslog: найкоротший шлях, коли обидві сторони його розуміють

Якщо пристрій підтримує syslog через TLS, а колектор його термінує, використовуйте це й зупиніться. Прикладний протокол захищає сам себе, колектор автентифікує відправника, і немає зайвого переходу, доступність якого тепер на вас. Пастка в тому, що «TLS syslog» охоплює широкий спектр реалізацій, і нинішні настанови щодо безпечного syslog пішли далі за списки шифрів зі старих посібників, і тому робочий пересилач ламається після оновлення бібліотеки.

У rsyslog уже саме ім'я транспортного модуля каже, у якій ви епосі: lmnsd_gtls обгортає GnuTLS, а lmnsd_ossl обгортає OpenSSL, і саме це постачають поточні пакети 8.x. Дія пересилання з перевіркою сертифіката виглядає приблизно так, і точні назви параметрів варто звірити зі встановленою версією:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

Перевірте кінцеву точку, перш ніж налагоджувати відправника. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error або завершує рукостискання з коректним ланцюжком, або точно повідомляє, яка перевірка не пройшла. Тестуйте з пристрою, а не з ноутбука, бо важливе саме сховище довіри пристрою.

SFTP: добрий для файлів, поганий для потоків

Доставка на основі файлів пасує пристроям, які пишуть лише журнали, що ротуються. Передавання через SSH дає ключі хоста, ключі на кожен обліковий запис і файлову систему, яку можна перевіряти, — розумна історія довіри для пристрою, який узагалі не вміє TLS. Для потоків подій це поганий вибір: «файл пишеться щогодини» означає, що збій коштує вам хвоста поточної години.

Залиште перевірку хоста ввімкненою. Пакетний виклик, який вимикає її, щоб уникнути запиту, знищує єдину автентифікацію, яку має транспорт:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

Закріпіть ключ хоста в known_hosts облікового запису під час підготовки, обмежте обліковий запис цільовим каталогом і віддайте перевагу підсистемі internal-sftp з chroot. Продумайте й історію повторного надсилання: якщо файл надсилають знову після часткового збою, колектор має відрізняти дублікат від нового файлу, зазвичай за ім'ям і контрольною сумою, а не за часом надходження.

Коли локальний шлюз або тунель — чесна відповідь

Деякі пристрої вміють говорити лише у форматі, який ніхто не хоче виставляти назовні. У такому разі вповноважений колектор у мережі самого пристрою приймає рідний формат і передає його далі через TLS. Це законний проєкт, але будьте точні щодо того, що він купує: шифрування, яке починається на шлюзі, не захищає заднім числом ділянку між пристроєм і шлюзом, тож цьому переходу все ще потрібні власні межа довіри й контроль доступу.

Маршрутизований тунель майданчика або пристрою — найважчий варіант і правильний, коли колектор мусить зберегти приватну адресу і нести кілька сервісів, а не лише журнали. Він приносить планування адрес, правила доступу, зворотні маршрути й життєвий цикл кінцевої точки тунелю. Він також не покращує внутрішній протокол: syslog через UDP усередині тунелю IPsec лишається службою датаграм без підтвердження доставки.

Що б ви не обрали, тримайте авторизацію колектора вужчою за транспорт. Ідентичність тунелю належить кінцевій точці й нічого не каже про те, який нижчий пристрій створив дане поле імені хоста в повідомленні.

Запишіть договір про доставку до надсилання

Шифрування, автентифікація й зберігання відповідають на різні питання, а черга не є політикою зберігання. Перш ніж перший журнал залишить пристрій, вирішіть, що підтвердження насправді означає на цьому колекторі: отримано по мережі, прийнято в обробку чи надійно записано в сховище. Це три різні гарантії, і лише остання переживає перезапуск колектора.

Потім письмово дайте відповіді на експлуатаційні питання. Де чекають ненадіслані події і чи переживає цей буфер відключення живлення? Що відбувається, коли він заповнюється, і кого сповіщають? Як обмежено повтори і як визначають дублікати? Яке поле доводить ідентичність відправника, з огляду на те, що перехід пересилання може переписати ім'я хоста?

Тримайте проєкт достатньо малим, щоб пояснити його одним абзацом: найменший підтримуваний транспорт, який несе потрібні події, плюс явна заява про гарантії, яких він не дає. Якщо відповідь потребує двох переходів, скажіть це в runbook і призначте кожному переходу власника.