Näin lähetät laitteen lokit turvallisesti etäkokoelmalle

Laite voi tuottaa lokeja, kerääjä on internetin toisella puolella, ja ensimmäinen kysymys, jonka kaikki esittävät, on se, mikä tunneli rakennetaan. Tämä kehystys alkaa väärästä paikasta. Siirron ratkaisevat muoto, jonka laite voi tuottaa, todennus, jonka kerääjä hyväksyy, ja se, mitä ”toimitettu” tarkoittaa, kun yhteys katkeaa. Kirjoita ne kolme vastausta muistiin, ja siirto valitsee yleensä itse itsensä.

Aloita siitä, mitä laite voi tuottaa

Käytännössä muotoja on vain kolme. Yksittäiset syslog-tapahtumat UDP:n tai TCP:n yli, tuotteeseen rakennettu todennettu HTTPS-lähetys tai kokonaiset levylle kirjoitetut tiedostot, jotka on siirrettävä. Palomuuri, joka osaa lähettää vain UDP-syslogia, ei muutu TLS-lähettäjäksi siksi, että lisäsit tunnelin; se lähettää edelleen kuittaamattomia datagrammeja, nyt salatussa kirjekuoressa.

Kartoita siis ensin lähettäjä: protokolla, TLS-tuki ja mikä TLS-kirjasto, voiko se validoida kerääjän varmenteen, voiko se esittää asiakasvarmenteen ja kestääkö lähetyspuskuri uudelleenkäynnistyksen. Kaikki, mitä laite ei osaa, on tehtävä jollain muulla polun varrella, ja siitä muusta tulee osa suunnittelua.

TLS-syslog: lyhin polku, kun molemmat päät puhuvat sitä

Jos laite tukee syslogia TLS:n yli ja kerääjä päättää sen, käytä sitä ja lopeta. Sovellusprotokolla suojaa itseään, kerääjä todentaa lähettäjän, eikä ole ylimääräistä hyppyä, jonka käytettävyyden omistaisit nyt. Hakanen on siinä, että ”TLS-syslog” kattaa laajan kirjon toteutuksia, ja nykyiset turvallisen syslogin ohjeet ovat siirtyneet vanhempien oppaiden salauslistojen ohi, ja siksi toimiva edelleenlähettäjä hajoaa kirjaston päivityksen jälkeen.

Rsyslogissa pelkkä siirtomoduulin nimi kertoo, millä aikakaudella olet: lmnsd_gtls käärii GnuTLS:n, kun taas lmnsd_ossl käärii OpenSSL:n ja sitä nykyiset 8.x-paketit toimittavat. Varmennevalidoinnilla varustettu edelleenlähetystoiminto näyttää suunnilleen tältä, ja tarkat parametrinimet kannattaa tarkistaa asennettua versiota vasten:

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

Varmista päätepiste ennen kuin alat selvittää lähettäjän ongelmia. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error joko suorittaa kättelyn kelvollisella ketjulla tai kertoo tarkasti, mikä tarkistus epäonnistui. Testaa laitteesta, älä kannettavasta, koska laitteen luottamusvarasto on ratkaiseva.

SFTP: hyvä tiedostoille, väärä virroille

Tiedostopohjainen toimitus sopii laitteille, jotka kirjoittavat kierrätettäviä lokeja eivätkä muuta. SSH-pohjainen siirto antaa isäntäavaimet, tilikohtaiset avaimet ja tiedostojärjestelmän, jota voit auditoida, mikä on kohtuullinen luottamustarina laitteelle, joka ei osaa TLS:ää lainkaan. Se on huono valinta tapahtumavirroille, joissa ”tiedosto kirjoitetaan joka tunti” tarkoittaa, että katkos maksaa nykyisen tunnin hännän.

Pidä isännän varmennus päällä. Eräajo, joka kytkee sen pois kehotteen välttämiseksi, tuhoaa ainoan todennuksen, joka siirrolla on:

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

Kiinnitä isäntäavain tilin known_hosts-tiedostoon valmistelun aikana, rajaa tili kohdehakemistoon ja suosi internal-sftp-alijärjestelmää chrootilla. Suunnittele myös uudelleenlähetyksen tarina: jos tiedosto lähetetään uudelleen osittaisen epäonnistumisen jälkeen, kerääjän on erotettava kopio uudesta tiedostosta, yleensä nimen ja tarkistussumman eikä saapumisajan perusteella.

Kun paikallinen yhdyskäytävä tai tunneli on rehellinen vastaus

Jotkin laitteet osaavat puhua vain muotoa, jota kukaan ei halua paljastaa. Siinä tapauksessa laitteen omassa verkossa oleva valtuutettu kerääjä vastaanottaa alkuperäisen muodon ja välittää sen eteenpäin TLS:n yli. Se on laillinen suunnittelu, mutta ole täsmällinen siitä, mitä se ostaa: yhdyskäytävällä alkava salaus ei suojaa taannehtivasti laitteen ja yhdyskäytävän välistä segmenttiä, joten se hyppy tarvitsee edelleen oman luottamusrajansa ja käyttöoikeuden valvonnan.

Reititetty toimipaikka- tai laitetunneli on raskain vaihtoehto ja oikea silloin, kun kerääjän on pidettävä yksityinen osoite ja kuljetettava useita palveluita, ei vain lokeja. Se tuo osoitesuunnittelun, käyttösäännöt, paluupolut ja tunnelin päätepisteen elinkaaren. Se ei myöskään paranna sisäistä protokollaa: UDP-syslog IPsec-tunnelissa on edelleen datagrammipalvelu ilman toimituskuittausta.

Mitä ikinä valitset, pidä kerääjän valtuutus siirtoa kapeampana. Tunnelin identiteetti kuuluu päätepisteelle, eikä se kerro mitään siitä, mikä alempi laite tuotti tietyn isäntänimikentän viestissä.

Kirjoita toimitusopimus ennen kuin lähetät

Salaus, todennus ja säilytys vastaavat eri kysymyksiin, eikä jono ole säilytyskäytäntö. Ennen kuin ensimmäinen loki lähtee laitteesta, päätä, mitä kuittaus todella tarkoittaa tällä kerääjällä: vastaanotettu verkossa, hyväksytty käsittelyyn vai kestävästi tallennettu. Ne ovat kolme eri takuuta, ja vain viimeinen selviää kerääjän uudelleenkäynnistyksestä.

Vastaa sitten operatiivisiin kysymyksiin kirjallisesti. Missä lähettämättömät tapahtumat odottavat, ja kestääkö puskuri sähkökatkon? Mitä tapahtuu, kun se täyttyy, ja kenelle ilmoitetaan? Miten uudelleenyritykset rajataan, ja miten kopiot tunnistetaan? Mikä kenttä todistaa lähettäjän identiteetin, kun välityshyppy voi kirjoittaa isäntänimen uudelleen?

Pidä suunnittelu tarpeeksi pienenä, jotta se mahtuu yhteen kappaleeseen: pienin tuettu siirto, joka kuljettaa vaaditut tapahtumat, sekä selkeä ilmoitus niistä takuista, joita se ei anna. Jos vastaus vaatii kaksi hyppyä, kerro se runbookissa ja anna kullekin hypylle omistaja.