Hoe om toestellogboeke veilig na ’n afgeleë versamelaar te stuur

Die toestel kan logboeke uitstuur, die versamelaar sit op die ander kant van die internet, en die eerste vraag wat almal vra, is watter tonnel om te bou. Daardie raamwerk begin op die verkeerde plek. Wat die vervoer bepaal, is die formaat wat die toestel kan produseer, die verifikasie wat die versamelaar sal aanvaar, en wat “afgelewer” veronderstel is om te beteken wanneer die skakel val. Skryf daardie drie antwoorde neer, en die vervoer kies gewoonlik homself.

Begin by wat die toestel kan uitstuur

Daar is net drie vorms in die praktyk. Individuele syslog-gebeurtenisse oor UDP of TCP, ’n geauthentiseerde HTTPS-oplaai wat in die produk ingebou is, of volledige lêers wat op skyf geskryf word en verskuif moet word. ’n Vuurskerm wat net UDP-syslog kan stuur, sal nie ’n TLS-afsender word omdat jy ’n tonnel bygevoeg het nie; dit sal steeds onbevestigde datagramme stuur, nou binne ’n geënkripteerde omhulsel.

So maak eerste ’n inventaris van die afsender: protokol, TLS-ondersteuning en watter TLS-biblioteek, of dit die versamelaar se sertifikaat kan valideer, of dit ’n kliëntsertifikaat kan voorlê, en of die stuurbuffer ’n herstart oorleef. Enigiets wat die toestel nie kan doen nie, moet deur iets anders in die pad gedoen word, en daardie iets anders word deel van jou ontwerp.

TLS-syslog: kortste pad wanneer beide kante dit praat

As die toestel syslog oor TLS ondersteun en die versamelaar dit beëindig, gebruik dit en stop. Die toepassingprotokol beskerm homself, die versamelaar verifieer die afsender, en daar is geen ekstra hop waarvan jy nou die beskikbaarheid besit nie. Die vangnet is dat “TLS-syslog” ’n wye reeks implementasies dek, en die huidige riglyne vir veilige syslog het verder beweeg van die syferlyste in ouer handleidings, wat is hoe ’n werkende aanstuurder ’n gebreekte een word ná ’n biblioteekopgradering.

Op rsyslog sê die naam van die vervoermodule alleen aan jou watter era jy is: lmnsd_gtls omhul GnuTLS, terwyl lmnsd_ossl OpenSSL omhul en dit is wat huidige 8.x-pakkette versend. ’n Aanstuur-aksie met sertifikaatverifikasie lyk rofweg so, en die presiese parametername is die moeite werd om teen jou geïnstalleerde weergawe na te gaan:

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

Verifieer die eindpunt voordat jy die afsender ontfout. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error voltooi óf ’n handtekening met ’n geldige ketting óf sê presies watter kontrole misluk het. Toets van die toestel af, nie van jou skootrekenaar nie, omdat die toestel se trust store die een is wat saak maak.

SFTP: goed vir lêers, verkeerd vir strome

Lêergebaseerde aflewering pas by toestelle wat geroteerde logboeke skryf en niks anders nie. SSH-gebaseerde oordrag gee jou gasheersleutels, per-rekening-sleutels en ’n lêerstelsel wat jy kan oudit, wat ’n redelike vertrouensverhaal is vir ’n toestel wat glad nie TLS kan doen nie. Dit pas swak by gebeurtenisstrome, waar “die lêer word elke uur geskryf” beteken dat ’n onderbreking jou die stert van die huidige uur kos.

Hou gasheerverifikasie aan. ’n Batch-oproep wat dit afskakel om ’n opdrag te vermy, verydel die enigste verifikasie wat die vervoer het:

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

Pen die gasheersleutel in die rekening se known_hosts tydens voorsiening, beperk die rekening tot die teikengids, en verkies die internal-sftp-subsisteem met ’n chroot. Beplan ook die herversendingverhaal: as ’n lêer ná ’n gedeeltelike mislukking weer gestuur word, moet die versamelaar ’n duplikaat van ’n nuwe lêer kan onderskei, gewoonlik deur naam plus kontrolesom eerder as deur aankomstyd.

Wanneer ’n plaaslike poort of ’n tonnel die eerlike antwoord is

Sommige toestelle kan net ’n formaat praat wat niemand wil blootstel nie. In daardie geval ontvang ’n gemagtigde versamelaar op die toestel se eie netwerk die oorspronklike formaat en stuur dit verder oor TLS. Dit is ’n wettige ontwerp, maar wees presies oor wat dit koop: enkripsie wat by die poort begin, beskerm nie met terugwerkende krag die segment tussen die toestel en die poort nie, so daardie hop het steeds sy eie vertrouensgrens en toegangsbeheer nodig.

’n Gerouteerde werf- of toesteltonnel is die swaarste opsie en die regte een wanneer die versamelaar ’n privaat adres moet behou en verskeie dienste moet dra, nie net logboeke nie. Dit bring adresbeplanning, toegangsreëls, terugpaaie en die lewensiklus van die tonnel-eindpunt. Dit verbeter ook nie die binnerste protokol nie: UDP-syslog binne ’n IPsec-tonnel is steeds ’n datagramdiens met geen afleweringsbevestiging nie.

Wat jy ook kies, hou versamelaarmagtiging smaller as die vervoer. ’n Tonnel-identiteit behoort aan ’n eindpunt, en dit sê niks oor watter stroomaf-toestel ’n gegewe gasheernaamveld in ’n boodskap geproduseer het nie.

Skryf die afleweringskontrak voordat jy verskeep

Enkripsie, verifikasie en bewaring beantwoord verskillende vrae, en ’n ry is nie ’n bewaringsbeleid nie. Voor die eerste log die toestel verlaat, besluit wat ’n bevestiging op hierdie versamelaar werklik beteken: op die draad ontvang, vir verwerking aanvaar, of duursaam na berging geskryf. Dit is drie verskillende waarborge en net die laaste een oorleef ’n herstart van die versamelaar.

Beantwoord dan die operasionele vrae skriftelik. Waar wag ongesende gebeurtenisse, en oorleef daardie buffer ’n kragonderbreking? Wat gebeur wanneer dit vol word, en wie word ingelig? Hoe is herpogings begrens, en hoe word duplikate geïdentifiseer? Watter veld bewys die afsender se identiteit, gegewe dat ’n aanstuur-hop die gasheernaam kan herskryf?

Hou die ontwerp klein genoeg om in een paragraaf te verduidelik: die kleinste ondersteunde vervoer wat die vereiste gebeurtenisse dra, plus ’n eksplisiete verklaring van die waarborge wat dit nie bied nie. As die antwoord twee hops nodig het, sê so in die runbook en gee elke hop ’n eienaar.