Geräteprotokolle sicher an einen entfernten Collector senden

Das Gerät kann Protokolle ausgeben, der Collector steht auf der anderen Seite des Internets, und die erste Frage, die alle stellen, lautet, welcher Tunnel gebaut werden soll. Diese Rahmung beginnt an der falschen Stelle. Was den Transport entscheidet, ist das Format, das das Gerät erzeugen kann, die Authentifizierung, die der Collector akzeptiert, und was „zugestellt“ bedeuten soll, wenn die Verbindung abbricht. Schreiben Sie diese drei Antworten auf, und der Transport wählt sich meist selbst.

Beginnen Sie mit dem, was das Gerät ausgeben kann

In der Praxis gibt es nur drei Formen. Einzelne Syslog-Ereignisse über UDP oder TCP, ein authentifizierter HTTPS-Upload, der im Produkt eingebaut ist, oder vollständige Dateien, die auf die Platte geschrieben werden und bewegt werden müssen. Eine Firewall, die nur UDP-Syslog senden kann, wird nicht dadurch zum TLS-Sender, dass Sie einen Tunnel hinzufügen; sie sendet weiterhin unbestätigte Datagramme, jetzt in einem verschlüsselten Umschlag.

Erfassen Sie also zuerst den Sender: Protokoll, TLS-Unterstützung und welche TLS-Bibliothek, ob er das Zertifikat des Collectors prüfen kann, ob er ein Client-Zertifikat vorlegen kann und ob der Sendepuffer einen Neustart übersteht. Alles, was das Gerät nicht kann, muss etwas anderes auf dem Weg erledigen, und dieses Etwas wird Teil Ihres Entwurfs.

TLS-Syslog: der kürzeste Weg, wenn beide Seiten es sprechen

Wenn das Gerät Syslog über TLS unterstützt und der Collector es terminiert, nutzen Sie das und hören Sie auf. Das Anwendungsprotokoll schützt sich selbst, der Collector authentifiziert den Sender, und es gibt keinen zusätzlichen Sprung, dessen Verfügbarkeit Sie nun besitzen. Der Haken ist, dass „TLS-Syslog“ ein breites Spektrum an Implementierungen abdeckt, und die aktuellen Leitlinien für sicheres Syslog sich von den Cipher-Listen älterer Anleitungen entfernt haben, weshalb aus einem funktionierenden Forwarder nach einem Bibliotheks-Upgrade ein kaputter wird.

Bei rsyslog verrät schon der Name des Transportmoduls, in welcher Ära Sie sich befinden: lmnsd_gtls umschließt GnuTLS, während lmnsd_ossl OpenSSL umschließt und das liefern aktuelle 8.x-Pakete aus. Eine Weiterleitungsaktion mit Zertifikatsprüfung sieht ungefähr so aus, und die genauen Parameternamen sollten Sie gegen Ihre installierte Version prüfen:

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

Prüfen Sie den Endpunkt, bevor Sie den Sender debuggen. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error schließt entweder einen Handshake mit gültiger Kette ab oder sagt Ihnen genau, welche Prüfung fehlgeschlagen ist. Testen Sie vom Gerät aus, nicht vom Laptop, denn der Vertrauensspeicher des Geräts ist der entscheidende.

SFTP: gut für Dateien, falsch für Streams

Dateibasierte Zustellung passt zu Geräten, die rotierte Protokolle schreiben und sonst nichts. SSH-basierte Übertragung gibt Ihnen Hostschlüssel, Schlüssel pro Konto und ein Dateisystem, das Sie prüfen können, was eine vernünftige Vertrauensgeschichte für ein Gerät ist, das gar kein TLS kann. Für Ereignisströme ist es eine schlechte Wahl, denn „die Datei wird stündlich geschrieben“ bedeutet, dass ein Ausfall Sie das Ende der aktuellen Stunde kostet.

Lassen Sie die Hostprüfung eingeschaltet. Ein Batch-Aufruf, der sie abschaltet, um eine Eingabeaufforderung zu vermeiden, zerstört die einzige Authentifizierung, die der Transport hat:

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

Heften Sie den Hostschlüssel während der Bereitstellung in der known_hosts des Kontos fest, beschränken Sie das Konto auf das Zielverzeichnis und bevorzugen Sie das internal-sftp-Subsystem mit chroot. Planen Sie auch die Geschichte der erneuten Übertragung: Wenn eine Datei nach einem Teilfehler erneut gesendet wird, muss der Collector ein Duplikat von einer neuen Datei unterscheiden können, üblicherweise über Name plus Prüfsumme statt über die Ankunftszeit.

Wenn ein lokales Gateway oder ein Tunnel die ehrliche Antwort ist

Manche Geräte sprechen nur ein Format, das niemand offenlegen will. In diesem Fall empfängt ein autorisierter Collector im Netz des Geräts selbst das native Format und leitet es über TLS weiter. Das ist ein legitimer Entwurf, aber seien Sie genau darin, was er kauft: Verschlüsselung ab dem Gateway schützt das Segment zwischen Gerät und Gateway nicht rückwirkend, also braucht dieser Sprung weiterhin seine eigene Vertrauensgrenze und Zugriffskontrolle.

Ein gerouteter Site- oder Gerätetunnel ist die schwerste Option und die richtige, wenn der Collector eine private Adresse behalten muss und mehrere Dienste tragen soll, nicht nur Protokolle. Er bringt Adressplanung, Zugriffsregeln, Rückwege und den Lebenszyklus des Tunnelendpunkts mit. Er verbessert auch das innere Protokoll nicht: UDP-Syslog in einem IPsec-Tunnel bleibt ein Datagrammdienst ohne Zustellbestätigung.

Was Sie auch wählen, halten Sie die Collector-Autorisierung enger als den Transport. Eine Tunnelidentität gehört zu einem Endpunkt und sagt nichts darüber aus, welches nachgelagerte Gerät ein bestimmtes Hostnamenfeld in einer Nachricht erzeugt hat.

Schreiben Sie den Liefervertrag, bevor Sie ausliefern

Verschlüsselung, Authentifizierung und Aufbewahrung beantworten unterschiedliche Fragen, und eine Warteschlange ist keine Aufbewahrungsrichtlinie. Bevor das erste Protokoll das Gerät verlässt, entscheiden Sie, was eine Bestätigung bei diesem Collector tatsächlich bedeutet: auf der Leitung empfangen, zur Verarbeitung angenommen oder dauerhaft in den Speicher geschrieben. Das sind drei verschiedene Garantien, und nur die letzte übersteht einen Neustart des Collectors.

Beantworten Sie dann die betrieblichen Fragen schriftlich. Wo warten ungesendete Ereignisse, und übersteht dieser Puffer einen Stromausfall? Was passiert, wenn er voll ist, und wer wird informiert? Wie sind Wiederholungen begrenzt, und wie werden Duplikate erkannt? Welches Feld belegt die Identität des Senders, wenn ein Weiterleitungssprung den Hostnamen umschreiben kann?

Halten Sie den Entwurf klein genug, um ihn in einem Absatz zu erklären: der kleinste unterstützte Transport, der die erforderlichen Ereignisse trägt, plus eine ausdrückliche Erklärung der Garantien, die er nicht bietet. Wenn die Antwort zwei Sprünge braucht, sagen Sie das im Runbook und geben Sie jedem Sprung einen Verantwortlichen.