Kiel sekure sendi aparatprotokolojn al fora kolektanto

La aparato povas elsendi protokolojn, la kolektanto staras en la alia flanko de la interreto, kaj la unua demando, kiun ĉiuj faras, estas kiun tunelon konstrui. Tiu kadro komenciĝas en la malĝusta loko. La transporton decidas la formato, kiun la aparato povas produkti, la aŭtentigo, kiun la kolektanto akceptos, kaj kion «livrita» devas signifi, kiam la ligo falas. Skribu tiujn tri respondojn, kaj la transporto kutime elektas sin mem.

Komencu de tio, kion la aparato povas elsendi

En la praktiko ekzistas nur tri formoj. Unuopaj syslog-eventoj per UDP aŭ TCP, aŭtentigita HTTPS-alsuprenŝuto enkonstruita en la produkton, aŭ kompletaj dosieroj skribitaj al la disko, kiuj devas esti movitaj. Fajroŝirmilo, kiu povas sendi nur UDP-syslog, ne fariĝos TLS-sendanto ĉar vi aldonis tunelon; ĝi daŭre sendos nekontirmitajn datagramojn, nun ene de ĉifrita koverto.

Do unue inventaru la sendanton: protokolo, TLS-subteno kaj kiu TLS-biblioteko, ĉu ĝi povas validigi la atestilon de la kolektanto, ĉu ĝi povas prezenti klientan atestilon, kaj ĉu la sendbufro postvivas restarton. Ĉion, kion la aparato ne povas fari, devas fari io alia en la vojo, kaj tiu io alia fariĝas parto de via dezajno.

TLS-syslog: la plej mallonga vojo, kiam ambaŭ flankoj parolas ĝin

Se la aparato subtenas syslog per TLS kaj la kolektanto finas ĝin, uzu tion kaj haltu. La aplika protokolo protektas sin mem, la kolektanto aŭtentigas la sendanton, kaj ne ekzistas plia salto, kies disponeblecon vi nun posedas. La kaptilo estas, ke «TLS-syslog» kovras larĝan gamon da realigoj, kaj la nunaj gvidlinioj por sekura syslog moviĝis preter la ĉifrolistoj en pli malnovaj lerniloj, kaj tial funkcianta plusendilo rompiĝas post biblioteka ĝisdatigo.

En rsyslog la nomo de la transportmodulo sola diras al vi, en kiu epoko vi estas: lmnsd_gtls ĉirkaŭvolvas GnuTLS, dum lmnsd_ossl ĉirkaŭvolvas OpenSSL kaj tion liveras la nunaj 8.x-paketoj. Plusenda ago kun atestila validigo aspektas proksimume tiel, kaj la precizajn parametrojn indas kontroli kontraŭ via instalita versio:

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

Validigu la finpunkton antaŭ ol sencimigi la sendanton. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error aŭ kompletigas manpremon kun valida ĉeno, aŭ diras al vi precize, kiu kontrolo malsukcesis. Testu de la aparato, ne de via tekkomputilo, ĉar la fida konservejo de la aparato estas la grava.

SFTP: bona por dosieroj, malĝusta por fluoj

Dosierbazita liverado taŭgas por aparatoj, kiuj skribas rotaciajn protokolojn kaj nenion alian. SSH-bazita transigo donas al vi gastigantajn ŝlosilojn, ŝlosilojn po konto kaj dosiersistemon, kiun vi povas revizii, kio estas racia fida rakonto por aparato, kiu tute ne povas TLS. Ĝi estas malbona elekto por eventfluoj, kie «la dosiero estas skribata ĉiun horon» signifas, ke paneo kostas al vi la voston de la nuna horo.

Lasu gastigantan validigon ŝaltita. Baga alvoko, kiu malŝaltas ĝin por eviti prompton, detruas la solan aŭtentigon, kiun la transporto havas:

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

Fiksu la gastigantan ŝlosilon en la known_hosts de la konto dum provizado, limigu la konton al la cela dosierujo, kaj preferu la internal-sftp-subsistemon kun chroot. Planu ankaŭ la re-sendan rakonton: se dosiero re-sendiĝas post parta malsukceso, la kolektanto devas distingi duplikaton de nova dosiero, kutime per nomo plus kontrolsumo, ne per alvena tempo.

Kiam loka pordego aŭ tunelo estas la honesta respondo

Iuj aparatoj povas paroli nur formaton, kiun neniu volas elmeti. En tiu kazo rajtigita kolektanto en la propra reto de la aparato ricevas la denaskan formaton kaj plusendas ĝin plu per TLS. Tio estas legitima dezajno, sed estu preciza pri tio, kion ĝi aĉetas: ĉifrado komenciĝanta ĉe la pordego ne protektas retroaktive la segmenton inter la aparato kaj la pordego, do tiu salto ankoraŭ bezonas sian propran fidan limon kaj alirkontrolon.

Enkursigita reteja aŭ aparata tunelo estas la plej peza opcio kaj la ĝusta, kiam la kolektanto devas konservi privatan adreson kaj porti plurajn servojn, ne nur protokolojn. Ĝi alportas adresplanadon, alirregulojn, revenajn vojojn kaj la vivciklon de la tunela finpunkto. Ĝi ankaŭ ne plibonigas la internan protokolon: UDP-syslog ene de IPsec-tunelo restas datagrama servo sen livera konfirmo.

Kion ajn vi elektas, tenu la rajtigon de la kolektanto pli mallarĝa ol la transporto. Tunela identeco apartenas al finpunkto, kaj ĝi diras nenion pri tio, kiu suba aparato produktis donitan gastigantnoman kampon en mesaĝo.

Skribu la liverkontrakton antaŭ ol sendi

Ĉifrado, aŭtentigo kaj retenado respondas al malsamaj demandoj, kaj vico ne estas retenpolitiko. Antaŭ ol la unua protokolo forlasos la aparaton, decidu, kion konfirmo vere signifas ĉe tiu ĉi kolektanto: ricevita sur la drato, akceptita por prilaborado, aŭ daŭre skribita al konservejo. Tiuj estas tri malsamaj garantioj kaj nur la lasta postvivas restarton de la kolektanto.

Poste respondu skribe la operaciajn demandojn. Kie atendas nesenditaj eventoj, kaj ĉu tiu bufro postvivas elektropanion? Kio okazas, kiam ĝi pleniĝas, kaj kiu estas sciigata? Kiel limigatas la reprovoj, kaj kiel identigatas duplikatoj? Kiu kampo pruvas la identecon de la sendanto, konsiderante ke plusenda salto povas reskribi la gastigantnomon?

Tenu la dezajnon sufiĉe malgranda por klarigi ĝin en unu alineo: la plej malgranda subtenata transporto, kiu portas la postulatajn eventojn, plus eksplicita deklaro pri la garantioj, kiujn ĝi ne donas. Se la respondo bezonas du saltojn, diru tion en la runbook kaj donu al ĉiu salto posedanton.