Kako varno pošiljati dnevnike naprave v oddaljeni zbiralnik

Naprava lahko oddaja dnevnike, zbiralnik stoji na drugi strani interneta in prvo vprašanje, ki ga vsi postavijo, je, kateri tunel zgraditi. Ta okvir se začne na napačnem mestu. Prenos določajo oblika, ki jo naprava lahko ustvari, overjanje, ki ga bo zbiralnik sprejel, in kaj naj pomeni »dostavljeno«, ko povezava pade. Zapišite te tri odgovore in prenos se običajno izbere sam.

Začnite s tem, kar naprava lahko oddaja

V praksi obstajajo le tri oblike. Posamezni dogodki syslog prek UDP ali TCP, overjeno nalaganje HTTPS, vgrajeno v izdelek, ali cele datoteke, zapisane na disk, ki jih je treba premakniti. Požarni zid, ki zna pošiljati le UDP syslog, ne bo postal pošiljatelj TLS zato, ker ste dodali tunel; še naprej bo pošiljal nepotrjene datagrame, zdaj v šifrirani ovojnici.

Zato najprej popišite pošiljatelja: protokol, podpora TLS in katera knjižnica TLS, ali lahko preveri potrdilo zbiralnika, ali lahko predloži odjemalsko potrdilo in ali vmesnik za pošiljanje preživi ponovni zagon. Vse, česar naprava ne zmore, mora opraviti nekaj drugega na poti, in to nekaj drugega postane del vaše zasnove.

TLS syslog: najkrajša pot, ko ga govorita oba konca

Če naprava podpira syslog prek TLS in zbiralnik ga zaključi, uporabite to in se ustavite. Aplikacijski protokol ščiti samega sebe, zbiralnik overi pošiljatelja in ni dodatnega preskoka, katerega razpoložljivost bi zdaj imeli v lasti. Past je v tem, da »TLS syslog« pokriva širok nabor izvedb in sedanje smernice za varen syslog so šle dlje od seznamov šifer v starejših priročnikih, zato se delujoč posredovalnik po nadgradnji knjižnice pokvari.

V rsyslogu že samo ime transportnega modula pove, v kateri dobi ste: lmnsd_gtls ovija GnuTLS, medtem ko lmnsd_ossl ovija OpenSSL in to dobavljajo sedanji paketi 8.x. Dejanje posredovanja s preverjanjem potrdila je videti približno takole, natančna imena parametrov pa velja preveriti glede na nameščeno različico:

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

Preverite končno točko, preden začnete odpravljati napake na pošiljatelju. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error bodisi dokonča rokovanje z veljavno verigo bodisi vam natančno pove, katero preverjanje je spodletelo. Preizkusite z naprave, ne s prenosnika, ker je odločilno skladišče zaupanja naprave.

SFTP: dober za datoteke, napačen za tokove

Dostava na podlagi datotek ustreza napravam, ki pišejo vrteče se dnevnike in nič drugega. Prenos prek SSH vam da ključe gostitelja, ključe na račun in datotečni sistem, ki ga lahko revidirate, kar je razumna zgodba o zaupanju za napravo, ki sploh ne zmore TLS. Slaba izbira je za tokove dogodkov, kjer »datoteka se zapiše vsako uro« pomeni, da vas izpad stane rep trenutne ure.

Pustite preverjanje gostitelja vklopljeno. Paketni klic, ki ga izklopi, da bi se izognil pozivu, uniči edino overjanje, ki ga prenos ima:

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

Med pripravo pripnite ključ gostitelja v known_hosts računa, omejite račun na ciljno mapo in dajte prednost podsistemu internal-sftp s chrootom. Načrtujte tudi zgodbo ponovnega pošiljanja: če se datoteka po delni napaki pošlje znova, mora zbiralnik razlikovati dvojnik od nove datoteke, običajno po imenu in kontrolni vsoti, ne po času prihoda.

Ko sta lokalna prehodna postaja ali tunel pošten odgovor

Nekatere naprave znajo govoriti le obliko, ki je nihče noče izpostaviti. V tem primeru pooblaščeni zbiralnik v omrežju same naprave prejme izvorno obliko in jo posreduje naprej prek TLS. To je zakonita zasnova, vendar bodite natančni glede tega, kaj kupi: šifriranje, ki se začne na prehodni postaji, ne ščiti za nazaj odseka med napravo in postajo, zato ta preskok še vedno potrebuje svojo mejo zaupanja in nadzor dostopa.

Usmerjen tunel lokacije ali naprave je najtežja možnost in prava, kadar mora zbiralnik ohraniti zasebni naslov in nositi več storitev, ne le dnevnikov. Prinese načrtovanje naslovov, pravila dostopa, povratne poti in življenjski cikel končne točke tunela. Prav tako ne izboljša notranjega protokola: UDP syslog v tunelu IPsec ostaja datagramska storitev brez potrditve dostave.

Karkoli izberete, držite pooblastilo zbiralnika ožje od prenosa. Identiteta tunela pripada končni točki in ne pove ničesar o tem, katera nižja naprava je ustvarila določeno polje imena gostitelja v sporočilu.

Napišite pogodbo o dostavi, preden pošljete

Šifriranje, overjanje in hramba odgovarjajo na različna vprašanja, čakalna vrsta pa ni politika hrambe. Preden prvi dnevnik zapusti napravo, se odločite, kaj potrditev na tem zbiralniku v resnici pomeni: prejeto na žici, sprejeto v obdelavo ali trajno zapisano v shrambo. To so tri različna jamstva in le zadnje preživi ponovni zagon zbiralnika.

Nato pisno odgovorite na obratovalna vprašanja. Kje čakajo neposlani dogodki in ali ta vmesnik preživi izpad elektrike? Kaj se zgodi, ko se napolni, in kdo je obveščen? Kako so omejeni poskusi in kako se prepoznajo dvojniki? Katero polje dokazuje identiteto pošiljatelja, glede na to, da lahko preskok posredovanja prepiše ime gostitelja?

Držite zasnovo dovolj majhno, da jo je mogoče razložiti v enem odstavku: najmanjši podprti prenos, ki nosi zahtevane dogodke, skupaj z izrecno izjavo o jamstvih, ki jih ne daje. Če odgovor potrebuje dva preskoka, povejte to v runbooku in vsakemu preskoku dodelite odgovornega.