Jak bezpečně odesílat protokoly zařízení do vzdáleného sběrače

Zařízení umí vysílat protokoly, sběrač sedí na druhé straně internetu a první otázka, kterou každý položí, je, který tunel postavit. Toto rámování začíná na špatném místě. Přenos určuje formát, který zařízení umí vytvořit, ověření, které sběrač přijme, a co má „doručeno“ znamenat, když spojení vypadne. Zapište ty tři odpovědi a přenos si obvykle vybere sám.

Začněte tím, co zařízení umí vysílat

V praxi existují jen tři podoby. Jednotlivé události syslog přes UDP nebo TCP, ověřené nahrání HTTPS zabudované do produktu, nebo celé soubory zapsané na disk, které je třeba přesunout. Firewall, který umí posílat jen UDP syslog, se nestane TLS odesílatelem proto, že jste přidali tunel; bude dál posílat nepotvrzené datagramy, nyní uvnitř šifrované obálky.

Nejprve tedy udělejte inventuru odesílatele: protokol, podpora TLS a která knihovna TLS, zda umí ověřit certifikát sběrače, zda umí předložit klientský certifikát a zda odesílací buffer přežije restart. Vše, co zařízení neumí, musí udělat něco jiného na cestě, a to něco jiného se stane součástí vašeho návrhu.

TLS syslog: nejkratší cesta, když jím mluví obě strany

Pokud zařízení podporuje syslog přes TLS a sběrač jej ukončuje, použijte to a skončete. Aplikační protokol chrání sám sebe, sběrač ověřuje odesílatele a neexistuje žádný skok navíc, jehož dostupnost byste nyní vlastnili. Háček je, že „TLS syslog“ pokrývá širokou škálu implementací a současné pokyny pro bezpečný syslog se posunuly od seznamů šifer ve starších návodech, a proto se funkční přeposílač po aktualizaci knihovny rozbije.

V rsyslogu už samotný název transportního modulu říká, v jaké éře jste: lmnsd_gtls obaluje GnuTLS, zatímco lmnsd_ossl obaluje OpenSSL a to dodávají současné balíčky 8.x. Akce přeposílání s ověřením certifikátu vypadá přibližně takto a přesné názvy parametrů stojí za kontrolu proti nainstalované verzi:

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")

Ověřte koncový bod, než začnete ladit odesílatele. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error buď dokončí navázání spojení s platným řetězem, nebo vám přesně řekne, která kontrola selhala. Testujte ze zařízení, ne z notebooku, protože rozhodující je úložiště důvěry zařízení.

SFTP: dobré pro soubory, špatné pro proudy

Doručování založené na souborech vyhovuje zařízením, která zapisují rotující protokoly a nic jiného. Přenos přes SSH vám dává klíče hostitele, klíče pro jednotlivé účty a souborový systém, který můžete auditovat, což je rozumný příběh důvěry pro zařízení, které vůbec neumí TLS. Je to špatná volba pro proudy událostí, kde „soubor se zapisuje každou hodinu“ znamená, že výpadek vás stojí konec aktuální hodiny.

Nechte ověřování hostitele zapnuté. Dávkové volání, které jej vypne, aby se vyhnulo výzvě, ničí jediné ověření, které přenos má:

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

Při zřizování připněte klíč hostitele do known_hosts účtu, omezte účet na cílový adresář a upřednostněte podsystém internal-sftp s chrootem. Naplánujte také příběh opětovného odeslání: pokud se soubor po částečném selhání odešle znovu, sběrač musí rozeznat duplikát od nového souboru, obvykle podle názvu a kontrolního součtu, ne podle času příchodu.

Když je místní brána nebo tunel poctivou odpovědí

Některá zařízení umí mluvit jen formátem, který nikdo nechce vystavovat. V tom případě autorizovaný sběrač v síti samotného zařízení přijme nativní formát a přepošle jej dál přes TLS. Je to legitimní návrh, ale buďte přesní v tom, co kupuje: šifrování začínající na bráně zpětně nechrání segment mezi zařízením a bránou, takže tento skok stále potřebuje vlastní hranici důvěry a řízení přístupu.

Směrovaný tunel lokality nebo zařízení je nejtěžší možnost a správná, když sběrač musí zachovat privátní adresu a nést několik služeb, ne jen protokoly. Přináší plánování adres, přístupová pravidla, zpětné cesty a životní cyklus koncového bodu tunelu. Také nezlepšuje vnitřní protokol: UDP syslog uvnitř tunelu IPsec zůstává datagramovou službou bez potvrzení doručení.

Ať vyberete cokoli, držte autorizaci sběrače užší než přenos. Identita tunelu patří koncovému bodu a neříká nic o tom, které níže postavené zařízení vytvořilo dané pole názvu hostitele ve zprávě.

Sepište smlouvu o doručení, než odešlete

Šifrování, ověřování a retence odpovídají na různé otázky a fronta není zásadou retence. Než první protokol opustí zařízení, rozhodněte, co potvrzení na tomto sběrači skutečně znamená: přijato na drátě, přijato ke zpracování, nebo trvale zapsáno do úložiště. To jsou tři různé záruky a jen poslední přežije restart sběrače.

Potom písemně odpovězte na provozní otázky. Kde čekají neodeslané události a přežije tento buffer výpadek napájení? Co se stane, když se naplní, a kdo se to dozví? Jak jsou pokusy omezeny a jak se rozpoznají duplikáty? Které pole dokazuje identitu odesílatele, když přeposílací skok může přepsat název hostitele?

Držte návrh dost malý, abyste jej vysvětlili v jednom odstavci: nejmenší podporovaný přenos, který nese požadované události, plus výslovné prohlášení o zárukách, které neposkytuje. Pokud odpověď potřebuje dva skoky, řekněte to v runbooku a každému skoku dejte vlastníka.