Ako bezpečne odosielať protokoly zariadenia do vzdialeného zberača

Zariadenie dokáže vysielať protokoly, zberač sedí na druhej strane internetu a prvá otázka, ktorú každý položí, je, ktorý tunel postaviť. Toto rámovanie začína na nesprávnom mieste. Prenos určuje formát, ktorý zariadenie dokáže vytvoriť, overenie, ktoré zberač prijme, a čo má „doručené“ znamenať, keď spojenie vypadne. Zapíšte tieto tri odpovede a prenos si zvyčajne vyberie sám.

Začnite tým, čo zariadenie dokáže vysielať

V praxi existujú len tri podoby. Jednotlivé udalosti syslog cez UDP alebo TCP, overené nahrávanie HTTPS zabudované do produktu, alebo celé súbory zapísané na disk, ktoré treba presunúť. Firewall, ktorý vie posielať len UDP syslog, sa nestane TLS odosielateľom preto, že ste pridali tunel; bude ďalej posielať nepotvrdené datagramy, teraz v šifrovanej obálke.

Najprv teda urobte inventúru odosielateľa: protokol, podpora TLS a ktorá knižnica TLS, či dokáže overiť certifikát zberača, či dokáže predložiť klientsky certifikát a či odosielací buffer prežije reštart. Všetko, čo zariadenie nevie, musí urobiť niečo iné na ceste, a to niečo iné sa stane súčasťou vášho návrhu.

TLS syslog: najkratšia cesta, keď ním hovoria obe strany

Ak zariadenie podporuje syslog cez TLS a zberač ho ukončuje, použite to a skončite. Aplikačný protokol chráni sám seba, zberač overuje odosielateľa a neexistuje žiadny skok navyše, ktorého dostupnosť teraz vlastníte. Háčik je, že „TLS syslog“ pokrýva širokú škálu implementácií a súčasné usmernenia pre bezpečný syslog sa posunuli od zoznamov šifier v starších návodoch, a preto sa funkčný preposielač po aktualizácii knižnice pokazí.

V rsyslogu už samotný názov transportného modulu hovorí, v ktorej ére ste: lmnsd_gtls obaľuje GnuTLS, zatiaľ čo lmnsd_ossl obaľuje OpenSSL a to dodávajú súčasné balíčky 8.x. Akcia preposielania s overením certifikátu vyzerá približne takto a presné názvy parametrov stojí za to skontrolovať oproti nainštalovanej verzii:

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

Overte koncový bod, než začnete ladiť odosielateľa. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error buď dokončí podanie ruky s platnou reťazou, alebo vám presne povie, ktorá kontrola zlyhala. Testujte zo zariadenia, nie z notebooku, pretože rozhodujúce je úložisko dôvery zariadenia.

SFTP: dobré pre súbory, nesprávne pre prúdy

Doručovanie založené na súboroch vyhovuje zariadeniam, ktoré zapisujú rotujúce protokoly a nič iné. Prenos cez SSH vám dáva kľúče hostiteľa, kľúče pre jednotlivé účty a súborový systém, ktorý môžete auditovať, čo je rozumný príbeh dôvery pre zariadenie, ktoré vôbec nevie TLS. Je to zlá voľba pre prúdy udalostí, kde „súbor sa zapisuje každú hodinu“ znamená, že výpadok vás stojí koniec aktuálnej hodiny.

Nechajte overovanie hostiteľa zapnuté. Dávkové volanie, ktoré ho vypne, aby sa vyhlo výzve, ničí jediné overenie, ktoré prenos má:

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

Pri zriaďovaní pripnite kľúč hostiteľa do known_hosts účtu, obmedzte účet na cieľový adresár a uprednostnite podsystém internal-sftp s chrootom. Naplánujte aj príbeh opätovného odoslania: ak sa súbor po čiastočnom zlyhaní odošle znova, zberač musí rozlíšiť duplikát od nového súboru, zvyčajne podľa názvu a kontrolného súčtu, nie podľa času príchodu.

Keď je miestna brána alebo tunel poctivou odpoveďou

Niektoré zariadenia vedia hovoriť len formátom, ktorý nikto nechce vystavovať. V tom prípade autorizovaný zberač v sieti samotného zariadenia prijme natívny formát a prepošle ho ďalej cez TLS. Je to legitímny návrh, ale buďte presní v tom, čo kupuje: šifrovanie začínajúce na bráne spätne nechráni segment medzi zariadením a bránou, takže ten skok stále potrebuje vlastnú hranicu dôvery a riadenie prístupu.

Smerovaný tunel lokality alebo zariadenia je najťažšia možnosť a správna, keď zberač musí zachovať privátnu adresu a niesť niekoľko služieb, nielen protokoly. Prináša plánovanie adries, prístupové pravidlá, spätné cesty a životný cyklus koncového bodu tunela. Tiež nezlepšuje vnútorný protokol: UDP syslog v tuneli IPsec zostáva datagramovou službou bez potvrdenia doručenia.

Čokoľvek si vyberiete, držte autorizáciu zberača užšiu ako prenos. Identita tunela patrí koncovému bodu a nehovorí nič o tom, ktoré nižšie zariadenie vytvorilo dané pole názvu hostiteľa v správe.

Napíšte zmluvu o doručení pred odoslaním

Šifrovanie, overovanie a uchovávanie odpovedajú na rôzne otázky a front nie je politikou uchovávania. Než prvý protokol opustí zariadenie, rozhodnite, čo potvrdenie na tomto zberači skutočne znamená: prijaté na drôte, prijaté na spracovanie alebo trvalo zapísané do úložiska. To sú tri rôzne záruky a len posledná prežije reštart zberača.

Potom písomne odpovedzte na prevádzkové otázky. Kde čakajú neodoslané udalosti a prežije tento buffer výpadok napájania? Čo sa stane, keď sa naplní, a kto sa to dozvie? Ako sú obmedzené pokusy a ako sa rozpoznajú duplikáty? Ktoré pole dokazuje identitu odosielateľa, keď preposielací skok môže prepísať názov hostiteľa?

Držte návrh dosť malý na to, aby sa dal vysvetliť v jednom odseku: najmenší podporovaný prenos, ktorý nesie požadované udalosti, plus výslovné vyhlásenie o zárukách, ktoré neposkytuje. Ak odpoveď potrebuje dva skoky, povedzte to v runbooku a každému skoku dajte vlastníka.