Како безбедно послати дневнике уређаја удаљеном сакупљачу

Уређај може да емитује дневнике, сакупљач стоји са друге стране интернета, а прво питање које сви постављају јесте који тунел изградити. Тај оквир почиње на погрешном месту. Транспорт одређују формат који уређај може да створи, аутентификација коју ће сакупљач прихватити и то шта „испоручено“ треба да значи када веза падне. Запишите та три одговора и транспорт обично сам изабере себе.

Почните од онога што уређај може да емитује

У пракси постоје само три облика. Појединачни 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-у и дајте сваком скоку власника.