Im letzten Artikel dieser Serie haben wir euch gezeigt, wie ihr mit dem OTel Collector pingen könnt. Dieses Mal schauen wir in eine andere Ecke der digitalen Welt.
Das Transport Layer Security Protokoll (aka TLS) ist als Nachfolger des Secure Sockets Layer Protokoll (SSL) das Rückgrat der modernen, verschlüsselten Kommunikation im Internet. Es sichert die Kommunikation zwischen Browser und Webserver, E-Mail Servern, VPN Verbindungen und seit „neuestem” auch DNS-Abfragen (DNSSEC-DANE) vor unerwünschtem Mitlesen durch Dritte. Wesentlicher Bestandteil dieser Protokolle sind und waren schon immer Zertifikate.
Was abgelaufene Zertifikate mit Stress zu tun haben
Damit die Kommunikation sicher bleibt, haben Zertifikate üblicherweise ein Ablaufdatum. Nach Ablauf dieses Datums sind die Zertifikate – wer hätte es gedacht – abgelaufen und werden von den meisten Stellen nicht mehr als valide angesehen (aka „abgelaufen“) und die Kommunikation zwischen den Teilnehmern unterbunden. Was passieren kann, wenn Zertifikate das Ablaufdatum überschreiten, findet ihr in der Presse der letzten Monate (z. B. hier, hier oder auch hier) – ist nicht angenehm und hat wahrscheinlich jeder schon einmal mitbekommen. Für Admins bedeutet das in dem Moment Nachts aufstehen und viel Stress.
Abgelaufene Zertifikate automatisch finden lassen und rechtzeitig austauschen
Man denkt sich: „Na dann muss man die Zertifikate halt einfach rechtzeitig austauschen ¯\_(ツ)_/¯ ” Historisch gewachsen weiß man allerdings oft einfach nicht, wo diese Zertifikate überall versteckt sind. Daher stellen wir im folgenden eine Möglichkeit dar, diese Zertifikate mit dem OpenTelemetry Collector zu checken und daraus einen Alarm zu erstellen der uns rechtzeitig daran erinnert.
Abgelaufene Zertifikate mit OTel Collector finden – so gehen wir vor:
Zuerst installiert ihr den Splunk OpenTelemetry Collector. Die Anleitung für das jeweilige Betriebssystem findet ihr hier.
Damit habt ihr auch schon alle Komponenten, die für den Check benötigt werden. Nun müsst ihr nur noch in der agent_config.yaml (üblicherweise zu finden unter Linux: /etc/otel/collector/) beschreiben, welche Endpunkte auf gültige Zertifikate zu prüfen sind. Das macht man mit folgenden Eintrag im Bereich der receivers:
receivers: ... smartagent/myhttp1: type: http host: splunk.com useHTTPS: true ...
Mit den Informationen auf dieser Seite kann der Check noch detaillierter konfiguriert werden.
Erklärung:
Wir haben hier einen „Receiver” im OTel Collector erstellt. Dieser erhält Daten vom smartagent und heißt myhttp1. Der Name hinter dem smartagent kann fast beliebig gewählt werden. Den smartagent konfigurieren wir über den OTel Collector so, dass er mit dem http Monitor Anfragen an einen Host stellen soll und dabei dringend HTTPS (useHTTPS) verwendet. Der smartagent mit seinen Monitoren wird als Komponente bei der Installation des Splunk OpenTelemetry Collectors mitgeliefert.
Warum der Weg über den Splunk OpenTelemetry Collector?
Solange die oben beschriebenen Funktionalitäten nicht im standard OpenTelemetry Collector zur Verfügung stehen, liefern wir diese über die Splunk-eigene Distribution, den Splunk OpenTelemetry Collector, mit.
Zum Schluss muss man den neu geschaffenen Receiver noch in die metrics Pipeline unter service einbinden. Dies geschieht in der Konfigurationsdatei agent_config.yaml etwas weiter unten:
service: ... pipelines: ... metrics: receivers: [..., smartagent/myhttp1] ...
Ihr könnt so viele smartagent-Receiver anlegen, wie ihr benötigt. Achtet aber auf jeden Fall auf die richtige Benennung und die richtige Referenzierung.
Die Metriken werden nach der Standardinstallation des Splunk OpenTelemetry Collectors an Splunk Infrastructure Monitoring (IM) in die Splunk Observability Cloud geliefert. Ihr findet die Metriken sehr einfach über den Metric Finder (linke Navigation) wenn ihr das Suchfeld benutzt. Folgende Metriken stehen u.A. zur Verfügung:
- http.cert_expiry
Certificate expiry in seconds. This metric is reported only if HTTPS is available (from last followed URL). - http.cert_valid
Value is 1 if certificate is valid (including expiration test) or 0 else. This metric is reported only if HTTPS is available (from last followed URL). - http.code_matched
Value is 1 if status_code value match desiredCode set in config. Always reported. - http.response_time
HTTP response time in seconds. Always reported. - http.status_code
HTTP response status code. Always reported.
Die Sekunden der cert_expiry können mit einer Division durch 86400 einfach in Tage umgerechnet werden. Aus diesem Signal kann man im nächsten Schritt super einfach einen Detektor erstellen und diesen dann mit einer Auswahl an verfügbaren Algorithmen zum Alert führen. Die entsprechenden Stellen werden dann Tage oder Wochen, bevor dieses Zertifikat abläuft, informiert. Damit kommt man der Katastrophe eines abgelaufenen Zertifikats zuvor und muss die Admins nicht nachts aus dem Bett klingeln.
Wenn ihr mehr Informationen benötigt oder an anderen Beispielen interessiert seid, kommt gerne auf uns zu.
Weitere Teile dieser Blog-Serie:
Happy Splunking,
Andre
