Як бяспечна адпраўляць журналы прылады на аддалены калектар

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

Пачніце з таго, што прылада можа выдаваць

На практыцы ёсць толькі тры формы. Асобныя падзеі 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 і прызначце кожнаму кроку ўласніка.