Guten Morgen, On 09.02.2019 23:25, Jens Hektor wrote:
Aus "historischen" Gründen waren das bisher HTTP-Server. nicht HTTPS-, SSH- und RDP-Server. Letzte Vorfälle haben gezeigt, dass wir das ausdehnen wollen Welche Vorfälle waren das genau, über welche Schwachstellen sind Angreifer auf Systeme gekommen und was genau hat das mit sinnvoll konfigurierten SSH-Servern[0] zu tun? Gibt es post-mortems, von denen auch andere lernen können?
Damit werden diese Servergruppen ab sofort in dieselbe Gruppe wie die eduroam-Netzwerke Netzwerke aufgenommen, für die bereits seit einiger Zeit eine "Deep Inspection" des gesamten nicht verschlüsselten Traffics gilt Wie genau wird Traffic inspiziert? Welche Filterlisten werden verwendet? Gegen was wird ein Paket alles geprüft, das die DPI-Lösung passiert? Was wird wie lange gespeichert?
Was ich da bisher mitbekommen habe, bestand primär aus Blacklists - wo dann plötzlich Seiten des CCC in die Kategorie "Malware" fallen[1] und nur noch über https erreichbar sind[2].
P.S.: Die Inspizierung des ausgehenden Verkehrs der Server bedarf weiterer Schritte, da Schadsoftware mittlerweile zunehmend über HTTPS verteilt wird.
Dazu werden wir in der RWTH-Firewall eine Certification Authority (CA) in Betrieb nehmen, die ihrerseits Zertifikate von non-RWTH Servern aufbricht und als Root-CA (!) re-signiert. (nettes Wortspiel) Haha, resignieren. Ja, das liegt bei einer EMail wie dieser nahe.
Dazu wird es nötig sein, dass auf Euren Servern im Certificate Storage die Root-CA der RWTH Firewall installiert wird. Also ein "bischen" Aufwand auf 2k+ Maschinen. ;-) Oder besser: auf allen Maschinen, die Dienste nach aussen anbieten. Wie sieht das denn mit Fernmeldegeheimnis und DSGVO aus? So ein Server kann ja durchaus mal eine TLS-Verbindung aufmachen und Daten übertragen, die von einem Nutzer stammen[3] und wenn in der Aufzählung von SSL-Traffic (HTTPS, IMAPS, ...) nach außen ist *derzeit* noch nicht betroffen (s.u.). auch schon explizit IMAPS genannt wird, scheint auch durchaus an das Abholen von EMails aus einem externen Postfach gedacht zu sein?
Wie sieht das mit Authentifizierung mit TLS-Clientzertifikaten aus? Was ist mit auf Servern installierter Software, die certificate-pinning/HPKP nutzen oder EV-Zertifikate sinnvoll implementieren? In Firefox[4] kann eine CA für EV-Zertifikate nur in einem Debugbuild oder durch Selbstbau hinzugefügt werden[5] und wenn man etwas auf Servern will, sind es sicherlich selbstgebaute Anwendungen, die dann nie wieder geupdatet werden.
Wenn jemand über das kommende Aufbrechen von SSL-Verbindungen der Server nach draußen diskutieren will, schlage ich vor, ein anderes Subject in der E-Mail zu benutzen. (first come, first serve) Da hatte Thomas ja schon die passende Idee.
Mit freundlichen Grüßen Markus Witt [0] z.B. deaktivierte Passwortauthentifizierung oder Passwörter nur in Kombination mit einem zweiten Faktor wie TOTP. [1] <https://twitter.com/_pub_feuerrot/status/856823162696343553> [2] Das war dann auch ein guter Zeitpunkt, um mal HSTS anzumachen [3] "Telegrambot" war da so ein Anwendungsbeispiel aus der NetzAG-Gruppe [4] Ein anderes Beispiel habe ich gerade nicht zur Hand, aber ich nehme mal an, dass das bei anderer Software ggf. ähnlich ist. [5] <https://sidstamm.com/evssl-trust/firefox-evca.html>