Seite wählen

NETWAYS Blog

Squid 4 Proxy mit LDAP & MITM SSL-Bump

von | Okt 15, 2020 |

Im Zuge meiner Ausbildung bei NETWAYS durfte ich mich diese Woche mit Squid auseinandersetzen. Dabei merkte ich, dass man sich bezüglich LDAP & SSL-BUMP wirklich nur auf die offiziellen Squid Dokus und die Red Hat Dokus verlassen konnte.

Squid ist ein Caching Proxy für Web Seiten das HTTP, HTTPS, FTP und vieles mehr unterstützt. Es reduziert Bandbreite und verbessert Aufrufzeiten. Dabei kann es den effektiven Netzwerkdurchsatz verbessern.

  • Es ermöglicht Caching und Verteilung.
  • Es erlaubt Content Filtering.
  • Es unterstützt LDAP-Anbindung für die Authentifizierung.
  • Es kann als transparent / MITM Proxy genutzt werden.

 

 

Ubuntu 20.04.01 Server: Die für SSL Bump benötigten Kompilerflags lauten --enable-ssl-crtd & --with-openssl. Aktuell ist Squid in Version 4 mit diesen Flags in den Ubuntu-Server-Repos nicht vorkompiliert, sodass man man sich Squid praktisch selbst damit bauen muss. Ob die Flags aktiv sind kann man folgendermaßen checken:

$ squid -v | grep ssl

CentOS 8: Unter CentOS kommt Squid direkt mit SSL-Bump vorkompiliert.

  • Der folgende Artikel basiert auf Squid Version 4.4 unter CentOS 8.

 

Vorab-Konfiguration

  • Firewallregeln sollten Squid entsprechend angepasst werden.
$ sudo firewall-cmd --permanent --add-port=3128/tcp
$ sudo firewall-cmd --reload
  • Falls jemand sich wie ich noch nicht so sehr mit SELinux auskennt, empfiehlt es sich die SELinux Policies erstmal auf Permissive zu stellen. Dies geschieht in der /etc/selinux/config. Später nach erfolgreicher Installation sollte man sie wieder zurück auf Enforcing setzen.
SELINUX=permissive

LDAP

  • Das Root Zertifikat der Umgebung muss heruntergeladen, in den Zertifikatsordner des Squid Servers geschoben und aktualisiert werden damit LDAP signiert via TLS funktioniert.
$ sudo cp ROOT_ZERTIFIKAT.cer /etc/pki/ca-trust/
$ sudo update-ca-trust

Die auth_param Parameter sollten schon in der Konfigurationsdatei /etc/squid/squid.conf stehen und entsprechend aktiviert und vervollständigt werden.

  • Wichtig ist es exakt passend Base/Domain/Suchfilter und Server zu übergeben. Hilfreich hierzu sind die Man Page von basic_ldap_auth sowie ldapsearch.
  • Folgendes Beispiel basiert auf einer Microsoft Active-Directory Umgebung was an dem -f Suchparameter erkannt werden kann. Zwingend wichtig ist es hier das %s für den User mitzugeben.
Das –R Flag muss manchmal gesetzt werden um Referrals nicht zu folgen, da ansonsten mehrere Aufrufe stattfinden und Konflikte auslösen womit Squid LDAP verweigern wird.

 

auth_param basic program /usr/lib64/squid/basic_ldap_auth -b "dc=FIRST_DOMAIN,dc=SECOND_DOMAIN,dc=ROOT_DOMAIN"
-D "CN=LDAP/USERNAME,OU=SERVICEGROUP,OU=COMPANY,OU=NET,OU=COMPANY,DC=FIRST_DOMAIN,DC=SECOND_DOMAIN,DC=TOP_DOMAIN"
-w "password" -f "(&(objectCategory=Person)(samAccountName=%s))" -R -H ldaps://FIRST_DOMAIN.SECOND_DOMAIN.TOP_DOMAIN:636
auth_param basic children 5
auth_param basic realm Hi this is your Squid Proxy speaking
auth_param basic credentialsttl 5 minutes
#Falls die LDAP Authentifizierung nicht durching,HTTP Traffic sperren.
acl ldap-auth proxy_auth REQUIRED
http_access deny !ldap-auth

 

  • Jetzt braucht Squid noch einen Neustart
$ sudo systemctl restart squid
  • Innerhalb weniger Sekunden sollte die LDAP/AD Passwortabfrage kommen.

 

mehr lesen…

TLS: Eine kleine Übersicht

von | Jun 6, 2019 | ,

Der durschnittliche Internetbenutzer benutzt TLS (Transport Layer Security) mittlerweile auf fast allen größeren Websiten – ohne, dass sich dieser darüber bewusst wäre, in den allermeisten Fällen. Auch in meiner Ausbildung bei NETWAYS darf ich mich nun intensiv mit TLS beschäftigen. Doch was ist TLS? Dieser Text soll einen groben Umriss um die zugrunde liegenden Prinzipien und Techniken hinter TLS legen.

Warum brauchen wir TLS?

TLS wird benötigt, um drei Probleme zu lösen. Unsere Kommunikationen sollen verschlüsselt sein – wir wollen nicht, dass Pakete oder Informationen, die wir übertragen, abgehört werden. Außerdem wollen wir sicher gehen, dass der andere Teilnehmer dieser Kommunikation auch derjenige ist, mit dem wir diesen Austausch an Informationen vollziehen wollen. Darüber hinaus wäre es auch gut, sich darauf verlassen zu können, dass das, was von der einen Seite losgeschickt wurde, auch das ist, was der andere erhält. Um diese drei Probleme kümmert sich TLS. Doch wie macht es das?

Eine Beispielverbindung:

1. ClientHello

Ein Client verbindet sich mit einem Server und verlangt eine gesichertete Verbindung. Dazu wird die Version von TLS übertragen, und eine Chiffrensammlung, aus denen sich der Server die Verschlüsselungsmethode aussuchen kann.

2. ServerHello & Certificate & ServerKeyExchange

Der Server antwortet, welches Chiffre verwendet werden soll, und einem Zertifikat, welches den Server authentifizieren soll und einen öffentlichen Schlüssel enthält.

3. ClientKeyExchange

Dieses Zertifikat wird von dem Client verifiziert, und der öffentliche Schlüssel des Servers wird vom Client benutzt, um ein pre-master secret zu erstellen, welcher dann wieder an den Server geschickt wird.

Der Server entschlüsselt das pre-master secret, und beide Parteien nutzen es, um einen geheimen, geteilten Schlüssel zu erstellen, welcher als shared secret bezeichnet wird.

4. ChangeCipherSpec

Der Client versendet die erste, mit dem shared secret verschlüsselte Nachricht, welche der Server entschlüsseln soll, damit geprüft werden kann, ob die Verschlüsselung richtig initialisiert wurde. Wenn diese Verifizierung erfolgreich abgelaufen ist, kommunizieren dann der Client und der Server verschlüsselt untereinander. Dieser ganze Prozess wird als TLS-Handshake bezeichnet.

Geschichte: TLS wurde unter dem Vorläufernamen SSL (Secure Sockets Layer) in 1994 von Netscape für den damals sehr populären Browser Mosaic vorgestellt. Version 2.0 und 3.0 folgten jeweils ein Jahr später. 1999 wurde SSL 3.1 bei der Aufnahme als Standart von der Internet Engineering Task Force in TLS 1.0 umbenannt. 2006 folgte Version 1.1, 2008 1.2 und 2018 die heutige Version 1.3.

Asymmetrische & Symmetrische Verschlüsselung: TLS ist zunächst asymmetrisch, dann symmetrisch verschlüsselt. Was bedeutet das? Nun, hier kommen die Schlüsselpaare ins Spiel. TLS benötigt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel wird benutzt, damit der Gegenpart einen Vorschlüssel erstellen kann, welcher dann von dem privaten Schlüssel wieder decodiert wird. Das ist eine asymmetrische Verschlüsselung – welche allerdings deutlich kostenintensiver und aufwändiger ist, und sich dementsprechend nicht für die zahlreichen Anwendungsmöglichkeiten für eine TLS-Verbindung eignet. Dank‘ dem Vorschlüssel können allerdings beide Seiten des Austausches einen gemeinsamen, geheimen Schlüssel berechnen, mit Hilfe dessen die verschlüsselten Nachrichten auf jeweils beiden Seiten entschlüsselt werden können. Somit ist der Kern von TLS eine symmetrische Verschlüsselung; der Austausch der tatsächlichen Information passiert über diesen Kanal. Um aber an diesen Punkt zu kommen, sind asymmetrische Verschlüsselungsprinzipien im Einsatz.

Zertifikate: Wie in dem TLS-Handshake betrachtet, sind Zertifkate elementar zur Ausweisung und Identifikation von Server und Client – und wohl der kritischste Punkt in dem ganzen TLS-Ablauf. Damit ein Kommunikationspartner identifiziert werden kann, muss er sein Zertifikat ausweisen, welches seine Identiät beweist. Ausgestellt wird ein Zertifikat von einer certificate authority, einem vertrauenswürdigen Aussteller dieser Zertifikate, was verschiedenste Dinge bedeuten kann: Viele multinationale Konzerne stellen kommerziell Zertifikate aus, darunter fallen Firmen wie IdenTrust, Sectigo und DigiCert Group. Es existieren allerdings auch einige non-profit organisations, wie CAcert und Let’s Encrypt, die als Zertifizierungsstelle auftreten. Darüber hinaus gibt es natürlich auch jede Menge Zertifikatsaussteller innerhalb von Netzen, welche in der Hand von einem vertrauenswürdigen Admin liegen.

Chiffrensammlung: Eine Chiffrensammlung ist eine Auflistung aus den Verschlüsselungsmethoden, die bei einer TLS-Verbindung eingesetzt werden können. Beispiele dafür wären RSA, MD5, SHA. Bei einer TLC-Verbindung wird in ClientHello und ServerHello unter den beiden beteiligten Parteien kommuniziert, welche dieser Methoden zur Verfügung für den Aufbau der Verbindung stehen.

https: Doch was hat es nun mit https auf sich? Ganz einfach: https (HyperText Transfer Protocol Secure) ist eine Extension von http, bei der http über eine verschlüsselte TLS-Verbindung versendet wird, was sie im Gegensatz zu Klartext-http vor unerwünschten Abschnorchelungen und sonstigen Attacken schützt.

Verbreitung: Laut der regelmäßig auf einen neuen Stand gebrachten Auswertung von SSL Labs von rund 140.000 Webpages bieten gerade mal 67.2% eine adequate TLS-Ausstattung. Das mag im ersten Moment etwas niedrig erscheinen, man darf aber auch nicht vergessen, dass diese Lage vor nicht allzu langer Zeit noch deutlich, deutlich schlimmer war, und durch Maßnahmen wie einer automatischen Warnung von Chrome verbessert wurde. So hat sich auch laut Firefox Telemetry die Anzahl der per https aufgerufenen Websiten sich von 25% auf 75% erhöht. Ebenso bemerkenswert: Einem Jahr nach Einführung von TLS 1.3 unterstützen gerade mal 15% den aktuellen Standart, der absolut überwiegende Teil bietet noch hauptsächlich TLS 1.2 an. Man darf gespannt sein, wie lange es dauert, bis der Großteil den Wechsel vollzogen hat. Auf der anderen Seite bieten 7.5% der Webpages noch Unterstüztung für SSL 3.0 an, einem Standart, der mittlerweile fast so alt ist wie ich selbst, und als nicht sicher gilt.

 

 

 

SSL/TLS Zertifikate für die Nutzung im internen Netz (apache)

von | Apr 17, 2019 |

Um verschiedene Dienste im LAN sicher zu nutzen, werden SSL-Zertifikate benötigt. Wir verwenden dafür in manchen Fällen ein selbstsigniertes Zertifikat. Das SSL-Zertifikat enthält Informationen über den Namen des Inhabers, den öffentlichen Schlüssel, eine Gültigkeitsdauer und gegebenenfalls den Namen der Zertifizierungsstelle. Mit dem öffentlichen Schlüssel kann das Zertifikat der Zertifizierungsstelle überprüft werden.

Das SSL-Zertifikat muss zuerst als vertrauenswürdig eingestuft werden, dazu sind bestimmte Rangordnungen der Autoritäten notwendig. Der Browser verfügt über Listen mit Zertifizierungsstellen deren SSL-Zertifikate bedingungslos vertraut werden. Beim Aufrufen einer SSL-verschlüsselten Website, prüft der Browser das Zertifikat auf Gültigkeit der Referenzen und des Herausgebers der Webadresse. Kennt der PC oder Browser den Herausgeber des Zertifikates nicht, meldet er einen Zertifikatsfehler. Diesen Fehler kann man übergehen und seinen Besuch auf der Website fortsetzen.

Selbstsignierte Zertifikate geben diesen Fehler logischerweise immer, da sie nicht von einer Zertifizierungsstelle als gültig und sicher geprüft wurden. Hier signiert der Server selbst für seine Dienste, die von den jeweiligen Clients besucht werden.

Ich zeige euch, wie wir das Zertifikat erstellen und manuell in den Firefox-Browser hinterlegen.

Zuerst müssen wir einen Private-Key erstellen, der immer bei uns verbleibt. Niemand außer uns sollte Zugriff auf diese Datei haben, da der Private-Key später untrennbar von unserem Zertifikat ist. Dazu wechseln wir in das Verzeichnis, indem wir den Schlüssel gerne haben wollen:

openssl genrsa -aes256 -out ca-key.pem 2048

Mit dem Argument -aes256 (Abkürzung für „Advanced Encryption Standard“) verschlüsseln wir unsere Datei mit einer 256Bit Schlüssellänge. Der Key muss eine Länge von 2048bit haben und in unserem Beispiel nenne ich ihn ca-key.pem (nehmt einen Namen, den ihr später leicht eurer Seite hinzufügen könnt). Das pass phrase muss mindestens 4 Zeichen lang sein und darf keine Sonderzeichen enthalten.

Nun kommt die CA-Datei, die die Antragsdaten sowie den öffentlichen Schlüssel zu unserem Private-Key enthält:

openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 1024 -out ca-root.pem -sha512

Benennt eure Dateien wieder mit einem beliebigen Namen. Ich nutze hier einige Argumente: -nodes (noDES) encrypted den Private-Key nicht, -x509 gibt das Certificate Data Management an, dass uns dann auch zu -extensions v3-ca führt. Hier wird eine Cryptographie erstellt und es werden Erweiterungen für policies verwendet.

Bei der Erstellung der CA werdet ihr nach einigen Details gefragt, die ihr angeben könnt um das Zertifikat eindeutig zu machen (oder aus Testzwecken einfach leer lassen).

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:

Wir brauchen jetzt noch einen Zertifikats-Key…

openssl genrsa -out zertifikat-key.pem 4096

…erstellen dann unsere CSR-Datei…

openssl req -new -key zertifikat-key.pem -out zertifikat.csr -sha512

…und signieren sie mit unserem eben erstellten Key.

openssl x509 -req -in zertifikat.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out zertifikat-pub.pem -days 365 -sha512

Gleiche Vorgehensweise wie zuvor beschrieben, pass phrase eingeben und bei belieben eure Details noch eintragen.

Wir sind fertig!

Jetzt bindet ihr das Zertifikat nur noch in euren Browser mit ein, in meinem Falle nutze ich den Firefox-Browser. Öffnet die Einstellungen und geht auf den linken Reiter „Datenschutz & Sicherheit“. Nun scrollt ihr ganz nach unten bis ihr die Option „Zertifikate“ seht. Klickt auf den Button „Zertifikate anzeigen…“, dort öffnet sich ein neues Fenster in dem ihr nun euer erstelltes Zertifikat einpflegen könnt.

Der Browser muss nun geschlossen werden um die Veränderungen anzunehmen. Startet ihn neu und verbindet euch mit eurer Website. Nun müsstet ihr sehen können, dass ein https:// angezeigt wird.

Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache

von | Aug 15, 2018 | , , ,

Die IT-Landschaften der Unternehmen wachsen prächtig – und auch die Anforderungen an die Sicherheit der dort gespeicherten Daten, denn besonders sensible Daten sind für so manch einen besonders interessant.
Passwörter werden noch heute viel genutzt, aber die vergangenen Jahre haben bewiesen, dass hier vor allem der Nutzer eine Schwachstelle darstellt. Passwörter werden hier sehr bequem; also zu kurz, mehrfach auf verschiedenen Diensten oder leicht zu erraten, gewählt.
Da nützt die beste Verschlüsselung im Zweifel nicht viel, wenn das Passwort auf einer der unzähligen Passwort-Listen im Internet rumschwirrt. Auch Phishing stellt ein Problem dar und nutzt die Unaufmerksamkeit der Nutzer aus. Kürzlich erhielten wir von einem unserer Managed-Services Kunden die Anfrage, ob wir nicht dafür eine Lösung haben. Das Stichwort „clientbasierte Zertifikats-Authentifizierung“ kam dabei vom Kunden. Wenn man danach sucht, findet man schnell den Fachbegriff Mutual SSL Authentication (also gegenseitige SSL Authentifikation).
Gesagt, getan. Wir haben eine Lösung auf seinem Managed-Server-System bereitgestellt und zu Abnahmetests aufgefordert – das Ergebnis überzeugt. Für den Zugang zum Webdienst des Kunden braucht man nun kein Passwort mehr und es ist sicherer als zuvor. Aber wie genau funktioniert das?

  1. Der Nutzer beantragt Zugang auf eine geschützte Ressource
  2. Der Server antwortet nun neben seinen TLS-Zertifikat mit seinem Serverzertifikat
  3. Der Client verifiziert das erhaltene Zertifikat
  4. Der Client vertraut dem Zertifikat und übersendet sein Publickey
  5. Der Server überprüft die vom Client erhaltenen Daten
  6. Der Server gewährt dem Client Zugang zum gewünschten Medium

Im nachfolgenden Beispiel werde ich die Vorgehensweise zur Erstellung der selbstsignierten Zertifikate, Konfiguration des Webservers (hier Apache) und Einbindung in den Webbrowser beschreiben. Ausgangssituation ist ein aktuelles Linux mit Apache (dieser nutzt für TLS bereits Zertifikate). Tools wie openssl und vim sehe ich jetzt mal als gegeben.
Wir wechseln zunächst auf die grüne Wiese und erstellen uns einen neuen Ordner, z. B. /usr/local/src/SSL
1. Erstellung eines firmenweiten rootca-Zertifikates-Privatekeys mit 4096 BIT Schlüssellänge

openssl genrsa -out ssl.netways.de_rootca.key 4096

2. Nun erstellen wir ein Serverzertifikat mit 10 Jahren Gültigkeit, dies kann natürlich individuell angepasst werden

openssl req -x509 -new -nodes -key ssl.netways.de_rootca.key -sha256 -days 3650 -out ssl.netways.de_rootca.pem


3. Wir erstellen einen Key unseres ersten Clients, dieser kann natürlich individuell benannt werden, damit die Unterscheidung leichter fällt

openssl genrsa -out ssl.netways.de_client1.key 4096

4. Für den soeben erstellten Client-Key erstellen wir nun eine Zertifikatsanforderung, CSR
Eine Besonderheit, ist hier dass wir als OU (also Organizational Unit, bzw. Abteilung) ein Mitarbeiter-Kürzel (im Beispiel gmimietz) angeben, dazu später mehr

openssl req -new -key ssl.netways.de_client1.key -out ssl.netways.de_client1.csr


5. Wir legen schnell die erforderlichen Daten an, damit wir nicht die ganze OpenSSL-Config umbauen müssen

mkdir -p demoCA/newcerts && mkdir demoCA/certs && mkdir demoCA/crl && echo 00 > demoCA/serial && touch demoCA/index.txt

6. Jetzt signieren wir das CSR des Clients gegen unsere Serverzertifikate und erstellen ein Clientzertifikat mit 10 Jahren Gültigkeit, dies auf Korrektheit überprüfen und bestätigen.

openssl ca -in ssl.netways.de_client1.csr -cert ssl.netways.de_rootca.pem -keyfile ssl.netways.de_rootca.key -out ssl.netways.de_client1.crt -days 3650

7. Abschließend exportieren wir das Clientzertifikat und den Key übertragungstauglich in PKCS12-Format, hierzu wird ein Passwort abgefragt, welches wir später beim Import wieder brauchen.

openssl pkcs12 -export -in ssl.netways.de_client1.crt -inkey ssl.netways.de_client1.key -out NETWAYS_Client_gmimietz.p12

8. wir kopieren unseren rootca in unser ca-Verzeichnis (wichtig, dies muss dort mit crt benannt sein, um im nächsten Schritt eingelesen zu werden)

cp /usr/local/src/SSL-TEST/ssl.netways.de_rootca.pem /usr/local/share/ca-certificates/ssl.netways.de_rootca.crt

9. Zunächst aktualisieren wir unseren Zertifikats-Store mit

update-ca-certificates

10. In der Apache-Config brauchen wir noch ein paar kleine Anpassungen innerhalb der jeweiligen vhost-Definition

SSLCACertificatePath "/etc/ssl/certs"
SSLVerifyClient require
SSLVerifyDepth 5

11. Falls wir einem Zertifikat das Vertrauen entziehen möchten, so müssten wir eine Unterscheidung sicherstellen, deshalb haben wir in Punkt 4 eine OU angegeben, diese dient nur der Unterscheidung

<location />
  SSLRequire (%{SSL_CLIENT_S_DN_OU} ne "gmimietz")
</location>

12. Final starten wir den Apache neu

service apache2 restart

13. Zertifikat auf Client importieren
Wir importieren das Zertifikat (p12-File aus Schritt 7) unseren Browser. Dazu brauchen wir unser Entschlüsselungspasswort wieder, womit wir den Export verschlüsselt haben.
Im Firefox gehen wir hierzu auf Einstellungen -> Datenschutz & Sicherheit -> Zertifikate anzeigen.
Dort importieren wir im Register „Ihre Zertifikate“ nun das p12-File und geben einmalig das Passwort ein.

Für die Anlage weiterer Client-Zertifikate führen wir die Schritte 3., 4., 6., 7. erneut aus und unterscheiden mittels Nutzernamen anhand der OU.
Fertig, wird laufen. Bitte noch beachten, dass andere Vhost-Configs natürlich auch abgedichtet werden müssen, falls die in das gleiche Doc-Root mit sensiblen Daten zeigen!
Ja, so tolle Sachen machen wir – was der Kunde sich wünscht, setzen wir um!

SSL geknackt! Naja, fast.

von | Jul 26, 2018 | , , ,

Wer kennt das nicht: Da sitzt man beim Kunden (oder auch remote) und debugt ein Programm wie bspw. Icinga 2. Alle Stricke reißen und man ist dazu genötigt, den Netzwerk-Verkehr zu inspizieren… Ach ja, das ist ja alles SSL-verschlüsselt. Und dies ist auch nicht abschaltbar, selbst wenn man es dürfte. Und jetzt?
Genau in dieser Zwickmühle befand sich neulich ein Kollege und wandte sich kurzerhand an einen der Sicherheitsfanatiker hier in der Firma – mich.
Als solcher kenne ich die Maschen der dunklen Seite der Macht. So auch bspw. diese hier:

  1. Wireshark, den Netzwerk-Verkehr und den privaten Schlüssel von Icinga 2 Du brauchst: /var/lib/icinga2/certs/HOST_FQDN.key
  2. Den Schlüssel in Wireshark Du hinterlegst: Preferences (Command + Komma) / Protocols / SSL / RSA key list / Edit
  3. Den Netzwerk-Verkehr automatisch Wireshark entschlüsselt

So jedenfalls die Theorie ist…


In der Theorie sind Theorie und Praxis gleich – in der Praxis nicht. So wurden auch wir davon überrascht, dass sich am mitgeschnittenen Kauderwelsch nichts geändert hat. „Stimmt…“, fiel mir wieder ein, „da war was…“
 

Das DH macht den Unterschied


Zu Beginn einer SSL-Verschlüsselten Verbindung handeln Client und Server u.a. den konkreten Verschlüsselungsalgorithmus aus. In diesem Fall waren die beiden besonders schlau und wählten einen „Diffie Hellman“ Algo. Schön für den Sysadmin, doof für uns. Der Zweck von Diffie Hellman ist es nämlich, genau solche Machenschaften der dunklen Seite der Macht dumm aus der Wäsche schauen zu lassen.
Zum Glück hatte ich noch ein Ass im Ärmel. Icinga 2 gibt dem Admin nämlich die Möglichkeit, die zu verwendenden Algorithmen einzuschränken:

--- /etc/icinga2/features-available/api.conf
+++ /etc/icinga2/features-available/api.conf
@@ -7,4 +7,6 @@
   //accept_commands = false
   ticket_salt = TicketSalt
+
+  cipher_list = "AES256-SHA256"
 }

Im konkreten Fall habe ich mich der Einfachheit halber auf einen einzigen nicht-DH Algorithmus beschränkt:

openssl ciphers |tr : \\n |grep -vFe DH

Es aber gingen theoretisch auch alle:

openssl ciphers |tr : \\n |grep -vFe DH |paste -sd : -

Nach einem Neustart von Icinga 2 und einer Wiederholung der HTTP-Anfragen hatten wir dann endlich Transparenz à la DSGVO (die grün markierten Pakete):

 

Fazit

Viel Spaß beim debuggen (lasst euch nicht vom Datenschutzbeauftragten erwischen) und vergesst nicht, die Lücke hinterher abzudrehen.
Und wenn bei euch wirklich alle Stricke reißen, helfen wir euch gerne weiter.

Alexander Klimov
Alexander Klimov
Senior Developer
Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.
Lies mehr von Alexander und triff unser Team

Trainings

Web Services

Events