Hogyan küldjünk eszköznaplókat távoli gyűjtőnek biztonságosan
A szállítást ahhoz igazítsa, amit az eszköz kibocsátani tud: TLS syslog, SFTP-fájlok, helyi átjáró vagy irányított alagút. Ezután írja le a szállítási szerződést.
Az eszköz naplókat tud kibocsátani, a gyűjtő az internet túloldalán ül, és az első kérdés, amit mindenki feltesz, hogy melyik alagutat építsük. Ez a keretezés rossz helyen kezdődik. A szállítást az dönti el, milyen formátumot tud előállítani az eszköz, milyen hitelesítést fogad el a gyűjtő, és mit kell jelentenie a „kézbesítve” szónak, amikor a kapcsolat megszakad. Írja le ezt a három választ, és a szállítás általában magától kiválasztódik.
Abból induljon ki, amit az eszköz kibocsátani tud
A gyakorlatban csak három forma van. Egyedi syslog-események UDP-n vagy TCP-n, a termékbe épített hitelesített HTTPS-feltöltés, vagy a lemezre írt teljes fájlok, amelyeket át kell mozgatni. Egy tűzfal, amely csak UDP-syslogot tud küldeni, nem válik TLS-küldővé attól, hogy alagutat adtunk hozzá; továbbra is nyugtázatlan datagramokat küld, most titkosított borítékban.
Tehát először leltározza fel a küldőt: protokoll, TLS-támogatás és melyik TLS-könyvtár, tudja-e érvényesíteni a gyűjtő tanúsítványát, tud-e ügyféltanúsítványt bemutatni, és túléli-e a küldőpuffer az újraindítást. Mindent, amit az eszköz nem tud megtenni, valami másnak kell megtennie az útvonalon, és az a valami más a terve része lesz.
TLS syslog: a legrövidebb út, ha mindkét vég beszéli
Ha az eszköz támogatja a syslogot TLS felett, és a gyűjtő lezárja, használja ezt, és álljon meg. Az alkalmazásprotokoll védi önmagát, a gyűjtő hitelesíti a küldőt, és nincs olyan további ugrás, amelynek elérhetősége most az öné. A csapda az, hogy a „TLS syslog” a megvalósítások széles körét fedi le, és a biztonságos syslog jelenlegi irányelvei túlléptek a régebbi útmutatók titkosítási listáin, és ezért egy működő továbbító egy könyvtárfrissítés után elromlik.
Az rsyslogban már a szállítási modul neve elárulja, melyik korszakban van: a lmnsd_gtls a GnuTLS-t csomagolja, míg a lmnsd_ossl az OpenSSL-t csomagolja, és ezt szállítják a jelenlegi 8.x csomagok. A tanúsítvány-ellenőrzéssel végzett továbbítási művelet nagyjából így néz ki, és érdemes a pontos paraméterneveket a telepített verzióhoz ellenőrizni:
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")
Ellenőrizze a végpontot, mielőtt a küldőt hibakeresné. A openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error vagy érvényes lánccal fejezi be a kézfogást, vagy pontosan megmondja, melyik ellenőrzés hiúsult meg. Az eszközről teszteljen, ne a laptopjáról, mert az eszköz bizalmi tárolója számít.
SFTP: jó fájlokhoz, rossz adatfolyamokhoz
A fájlalapú kézbesítés azoknak az eszközöknek felel meg, amelyek forgó naplókat írnak, és semmi mást. Az SSH-alapú átvitel hosztkulcsokat, fiókonkénti kulcsokat és auditálható fájlrendszert ad, ami észszerű bizalmi történet egy olyan eszközhöz, amely egyáltalán nem tud TLS-t. Eseményfolyamokhoz rossz választás, ahol „a fájl óránként íródik” azt jelenti, hogy egy kiesés az aktuális óra farkába kerül.
Tartsa bekapcsolva a hoszt ellenőrzését. Az a kötegelt hívás, amely kikapcsolja egy kérés elkerülésére, megsemmisíti az egyetlen hitelesítést, amellyel a szállítás rendelkezik:
sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]
Rögzítse a hosztkulcsot a fiók known_hosts fájljában az előkészítés során, korlátozza a fiókot a célkönyvtárra, és részesítse előnyben az internal-sftp alrendszert chroot-tal. Tervezze meg az újraküldés történetét is: ha egy fájlt részleges hiba után újra elküldenek, a gyűjtőnek meg kell különböztetnie a másolatot az új fájltól, általában név és ellenőrzőösszeg alapján, nem érkezési idő szerint.
Amikor a helyi átjáró vagy az alagút az őszinte válasz
Egyes eszközök csak olyan formátumban tudnak beszélni, amelyet senki nem akar kitenni. Ebben az esetben az eszköz saját hálózatán lévő jogosult gyűjtő fogadja a natív formátumot, és továbbítja TLS-en. Ez jogos terv, de legyen pontos abban, mit vásárol: az átjárónál kezdődő titkosítás nem védi visszamenőleg az eszköz és az átjáró közötti szakaszt, ezért annak az ugrásnak továbbra is saját bizalmi határra és hozzáférés-ellenőrzésre van szüksége.
Az irányított telephely- vagy eszközalagút a legnehezebb lehetőség, és akkor a helyes, amikor a gyűjtőnek meg kell tartania egy privát címet és több szolgáltatást kell hordoznia, nem csak naplókat. Címtervezést, hozzáférési szabályokat, visszatérési útvonalakat és az alagút végpontjának életciklusát hozza. A belső protokollt sem javítja: az IPsec-alagúton belüli UDP-syslog továbbra is nyugtázás nélküli datagramszolgáltatás.
Bármit választ, tartsa a gyűjtő jogosultságát szűkebben, mint a szállítást. Az alagút identitása egy végponthoz tartozik, és semmit sem mond arról, melyik alsóbb eszköz állította elő az adott hosztnévmezőt egy üzenetben.
Írja le a szállítási szerződést, mielőtt elküldi
A titkosítás, a hitelesítés és a megőrzés különböző kérdésekre válaszol, és a sor nem megőrzési szabályzat. Mielőtt az első napló elhagyja az eszközt, döntse el, mit jelent valójában a nyugtázás ezen a gyűjtőn: a vonalon fogadva, feldolgozásra elfogadva, vagy tartósan a tárolóba írva. Ez három különböző garancia, és csak az utolsó éli túl a gyűjtő újraindítását.
Ezután válaszoljon írásban az üzemeltetési kérdésekre. Hol várnak az el nem küldött események, és túléli-e a puffer az áramkimaradást? Mi történik, amikor megtelik, és kit értesítenek? Hogyan korlátozottak az újrapróbálkozások, és hogyan azonosítják a másolatokat? Melyik mező bizonyítja a küldő identitását, tekintettel arra, hogy egy továbbítási ugrás átírhatja a hosztnevet?
Tartsa a tervet elég kicsinek ahhoz, hogy egy bekezdésben elmagyarázható legyen: a legkisebb támogatott szállítás, amely a szükséges eseményeket hordozza, plusz annak a garanciának a kifejezett kimondása, amelyet nem nyújt. Ha a válaszhoz két ugrás kell, mondja ki a runbookban, és adjon minden ugrásnak felelőst.