Как да изпращате журнали от устройство към отдалечен колектор сигурно

Устройството може да излъчва журнали, колекторът стои от другата страна на интернет и първият въпрос, който всички задават, е кой тунел да се изгради. Тази рамка започва от грешното място. Транспортът се определя от формата, която устройството може да произведе, от удостоверяването, което колекторът ще приеме, и от това какво трябва да означава „доставено“, когато връзката прекъсне. Запишете тези три отговора и транспортът обикновено се избира сам.

Започнете от това, което устройството може да излъчва

На практика има само три форми. Отделни syslog събития по UDP или TCP, удостоверено качване по HTTPS, вградено в продукта, или цели файлове, записани на диск, които трябва да бъдат преместени. Защитна стена, която може да изпраща само UDP syslog, няма да стане 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. Това е законен дизайн, но бъдете точни какво купува: криптирането, започващо на шлюза, не защитава обратно сегмента между устройството и шлюза, така че този скок все още се нуждае от собствена граница на доверие и контрол на достъпа.

Маршрутизиран тунел на сайт или устройство е най-тежката опция и правилната, когато колекторът трябва да запази частен адрес и да носи няколко услуги, не само журнали. Той носи планиране на адреси, правила за достъп, обратни пътища и жизнения цикъл на крайната точка на тунела. Той също не подобрява вътрешния протокол: UDP syslog вътре в IPsec тунел си остава услуга с дейтаграми без потвърждение за доставка.

Каквото и да изберете, дръжте оторизацията на колектора по-тясна от транспорта. Идентичността на тунела принадлежи на крайна точка и не казва нищо за това кое устройство надолу по веригата е произвело дадено поле за име на хост в съобщение.

Напишете договора за доставка, преди да изпратите

Криптирането, удостоверяването и задържането отговарят на различни въпроси, а опашката не е политика за задържане. Преди първият журнал да напусне устройството, решете какво всъщност означава потвърждение на този колектор: получено по мрежата, прието за обработка или трайно записано в хранилище. Това са три различни гаранции и само последната оцелява при рестарт на колектора.

След това отговорете на оперативните въпроси писмено. Къде чакат неизпратените събития и оцелява ли този буфер при спиране на тока? Какво се случва, когато се напълни, и кой бива уведомен? Как се ограничават повторенията и как се идентифицират дубликатите? Кое поле доказва самоличността на изпращача, като се има предвид, че скок за препращане може да пренапише името на хоста?

Дръжте дизайна достатъчно малък, за да го обясните в един абзац: най-малкият поддържан транспорт, който носи необходимите събития, плюс изрично изявление за гаранциите, които не предоставя. Ако отговорът изисква два скока, кажете го в runbook и дайте на всеки скок собственик.