Am 11.02.19 um 16:51 schrieb Frank Knoben:
ein paar technische Anmerkungen zum Betrieb einer solchen Firewall:
und ein bischen Senf von mir.
Wenn beim outgoing traffic was auffällt, ist das Kind meistens ja schon in den Brunnen gefallen.
Halb. Wenn dann beim outgoing Traffic was auffällt, hat man
a) einen Alarm (oder auch "nur" ein Log) b) den Finger drauf
Man kann sich blast-o-mat mäßig sogar eine sofortige Isolation des Systems ins LAN vorstellen.
Sobald Sensorik da ist, kann man damit arbeiten.
Ich kriege die email, Sie haben arbeit, also dann Stunden später, statt wie bisher Tage später.
Das dauert nur Minuten. Und mir macht der blast-o-mat keine Arbeit.
Wir haben die "software defined security" Infrastruktur namens "blast-o-mat" seit über 15 Jahren. Die Texte der versendeten E-Mails werden wir bald überarbeiten, die sind /fast) noch vom Original. (die FSMPI hat mich deswegen auch schon angema^W angetriggert :-).
Und nach einer Überarbeitung im letzten Jahr ist es kein echtes Problem mehr
Wahrscheinlich wird es sehr einfach sein, die Betriebssystem Update Server auf die Whitelist zu setzen.
Bei den sogenannten Next Generation Firewalls (kurz: NGFW) reden wir mittlerweile über Applications. In die diesem Zusammenhang heissen die "yum-update", "ubuntu-update" und "windows-update". So etwas wird auf den 2nd line Firewalls bereits benutzt.
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.
Immer eine gute Strategie, kritische Sachen nicht weltweit anzubieten.
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.
Auch das wurde auf der RWTH-Firewall mit einem Testkunden bereits realisiert.
Vorsicht: hier hätte ich auch ein "hübsches" Arbeitspaket:
umstellen der 1000 HTTP-IP-Freischaltungen auf "domain names" (vermutlich dann eher 4000 Einträge). Hat man dass, kann man auch URL-Pfade vorfiltern ("/admin/index.php" oder gleich "/admin").
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.
Frank Knoben ist einer der wenigen, der ein entsprechendes Angebot des IT Centers, hier öfter erwähnt, wahrnimmt.
Wir hatten mal eine Auswertung solcher Daten, das liegt aber im Moment brach. Wäre aber kein großes Problem.
Gruß, Jens Hektor