Kategorie: Security

Das eduroam Wurzelzertifikat der deutschen Telekom läuft am 9.Juli 2019 ab – und plötzlich funktioniert eduroam nicht mehr – warum Sie bis zum 31.5.2019 handeln müssen!


Eine verkürzte Version der Informationen hier gibt es auch als PDF-Foliensatz.

Ein Zertifikat läuft ab – na und?

Was bei einem Webserver keine große Sache ist, kann im eduroam so richtig Probleme bereiten. Denn hier läuft nicht irgendein Zertifikat ab, nein ein Root-Zertifikat läuft ab. Das ist bisher im eduroam-Verbund, den es schon fast 15 Jahre gibt, bisher nicht vorgekommen.

Zur Erinnerung: Root -Zertifikate sind sehr viel „haltbarer“, als herkömmliche Server-Zertifikate. Tatsächlich geht der Trend derzeit in Richtung sehr kurzlebiger Zertifikate, wie beispielsweise bei “Let‘s Encrypt“, wo Zertifikate alle drei Monate erneuert werden müssen. Für eduroam, also für den Radius-Server der Uni, handelt es sich um das „Telekom Root CA2„ -Zertifikat, welches nur noch bis zum 9.7.2019 gültig ist. Danach müssen  alle eduroam-Klienten, die sich mit unserem Radius-Server verbinden, neu konfiguriert werden. Vorher einfach ein neues  Server-Zertifikat ausstellen und ausrollen ist nicht so einfach möglich, weil dieses mit einem neuen Root-Zertifikat unterschrieben werden muss. Typische Radius-Klienten für z.B. Windows oder Android unterstützen aber nur ein einziges Root-Zertifikat für Radius. Daher entsteht folgendes Dilemma: Wenn ein neues Root-Zertifikat gewählt wird, funktionieren sofort alle bisher konfigurierten Klienten nicht mehr. Wenn einfach abgewartet wird, müssen alle Geräte an einem Termin neu konfiguriert werden.

Der Ausweg – so machen wir es

Aber es gibt einen Ausweg. Wir haben gemeinsam mit der eduroam-Community und dem DFN-Verein, der den zentralen Radius-Server für die de-Top-Level-Domain betreibt, eine Konfiguration ausgetüftelt, die einen Parallelbetrieb mit einem einzigen Radius-Server erlaubt. Dazu wird die eduroam-Konfiguration anhand der sogenannten äußeren Identität aufgeteilt. Ein Klient, der als äußere Identität „anonymous@uni-due.de“ oder eine Kennung vorweist, bekommt die bisherige Konfiguration mit dem alten Telekom-Root Zertifikat, welches am 9.7.2019 abläuft (und schon seit 1999 gültig ist), zu sehen. Einem Klienten der in der äußeren Identität „eduroam@uni-due.de“ konfiguriert hat, wird das neue Zertifikat “T-Telesec Global Root Class 2″, gültig bis zum Jahr 2033, vorgezeigt. (Falls ein eduroam-freeradius-Admin mitliest – es handelt sich um die “Straufsche-Zertifikatsweiche”, in den Folien hier ab Seite 10).

Folie_aessere_Identitaet-300x222

Die neue äußere Identität – alle Folien dazu gibt es hier

Damit läuft sowohl die alte Konfiguration, diese allerdings nur bis zum 31. Mai 2019 (siehe unten), als auch die neue sofort und auch über den Termin hinaus weiter. Diese Lösung hat auch den Charme, dass Klienten, die keine Einstellung einer äußeren Identität ermöglichen, wie z.B. das relativ seltene Windows Phone, welches nicht von  weiter unten betriebenen eduroam CAT unterstützt wird, weiter bis zum 31.5. 2019 betrieben werden können. Nach dem 31. Mai ist eine Unterscheidung der Zertifikate nicht mehr erforderlich, d.h. auch solche Geräte müssen dann mit dem neuen Zertifikat manuell konfiguriert werden und können so weiter an der Uni benutzt werden.

Termine – Termine

Das Datum  9. Juli 2019 (Jul  9 23:59:00 2019 GMT) bezieht sich auf das Root-Zertifikat mit dem unser Radius-Server-Zertifikat unterschrieben worden ist. Das eigentliche Radius-Server-Zertifikat ist nur noch bis zum 31.5. 2019 um 14:28 Uhr (GMT) gültig und eine Verlängerung für nur zwei Monate mit dem alten Root-Zertifikat ist nicht mehr möglich. Deshalb wird bei uns an der UDE der 31.5. 2019 der spannende Termin für den Zertifikatsablauf werden. An anderen Hochschulen wird möglicherweise erst am 9.7. umgeschaltet. Für UDE-Nutzer ist aber unser Termin relevant, auch wenn sie unterwegs sind.

Warum die äußere Identität wichtig ist

Zur Erinnerung, die äußeren (auch anonym genannten) Identitäten sollen im eduroam verhindern, dass Radius-Administratoren an anderen Universitäten mitbekommen, mit welcher Kennung sich ein “roamender” Nutzer anmeldet. Auch dortige oder lokale Netzwerkadministratoren bekommen die innere Identität nicht zu sehen und können so keine Verknüpfung von MAC-Adressen (also Geräten) zu Personen vornehmen, immer vorausgesetzt die äußere Identität ist korrekt und anonym konfiguriert. Das ist also ein Datenschutz-Feature, auf das keinesfalls bei der Konfiguration verzichtet werden sollte.

Leider sind viele Klienten so konfiguriert, dass datenschutzunfreundlich in der äußeren Identität auch die Kennung steht. Diese Einstellungen entstehen so: Apple (bei IOS) und Microsoft (bei Windows Phone und Windows 10) wollen es den Nutzern möglichst einfach machen und verlangen in Enterprise WPA2 WLANs wie eduroam nur nach einer ID und einem Kennwort und würfeln die restlichen Einstellungen ohne Zutun des Nutzers aus.

Schlampige Klienten

Diese „schlampig“ eingestellten Klienten untergraben dann den Datenschutz und verschleiern vor den Nutzern die wichtigen Detaileinstellungen.

Wenn beispielsweise der sogenannte „realm“, d.h. die Endung „@uni-due.de“ hinter der Kennung weggelassen wird, kann Ihre eduroam-Konfiguration an anderen Hochschulen gar nicht funktionieren, da die dortige IT nicht herausfinden kann zu welcher Heimatorganisation Sie gehören. Der „realm“ lautet bei allen Mitgliedern der Hochschule, auch bei  den Studierenden, immer „@uni-due.de“. Es handelt sich also nicht um eine Mailadresse, d.h. „stud“ hat dort gar nichts zu suchen.

Auch der oben beschriebene Weg mit der äußeren Identität „eduroam@uni-due.de“ ist mit so einem “schlampigen” Klienten nicht zu realisieren. Aber es gibt Abhilfe: Der eduroam.org-Dachorganisation, dem DFN-Verein und auch uns ist das Problem der Komplexität der Konfiguration bewusst. Daher wurde ein webbasiertes Konfigurationstool geschaffen, welches den Nutzerinnen komfortabel passende Konfigurationsprofile für alle eduroam.org Partnerorganisationen zur Verfügung stellt. Das eduroam CAT ist unter der Adresse https://cat.eduroam.org zu erreichen. Der Vorläufer “cat.eduroam.de” wird nicht mehr gepflegt und soll nicht mehr verwendet werden.

Die Webanwendung erkennt Ihr Betriebssystem und, falls Sie im Browser ihre Standortinformationen freigeben und sich an einem der Campi der UDE befinden, das passende Profil für die UDE automatisch. Falls die Betriebssystemerkennung oder die Erkennung der Heimatorganisation fehlschlägt, kann auch manuell ausgewählt werden. Wichtig ist, dass immer die Heimatorganisation gewählt wird, auch wenn man unterwegs an einer anderen Universität zu Gast ist.

Geräte die die Zertifikate gar nicht überprüfen – warum Zertifikate wichtig sind

Leider erlauben die Radius-Klienten vieler Betriebssysteme auch den Verzicht auf die Konfiguration von Zertifikaten für die sichere Kommunikation mit dem Radius-Server. Wir haben auf Server-Seite leider keine Möglichkeit die Zertifikatsüberprüfung zu erzwingen. Ohne Zertifikat können Sie niemals sicher sein, mit dem richtigen Radius-Server der UDE verbunden zu sein. Ein Angreifer in Ihrer Nähe kann einfach einen WLAN-Accesspoint betreiben, der die SSID (den WLAN-Namen) “eduroam” ausstrahlt und durch einen eigenen manipulierten Radius-Server versuchen zu erzwingen, dass ein Klartextpasswort übertragen wird. Einen solchen Angriff hat es schon gegeben. Er wurde unter dem Namen PEAPing Tom auf der Black Hat Konferenz vorgestellt. Ein ähnlicher Angriff ist hier beschrieben.

PeapingTomBild1-179x300

Falsch und Unsicher: keine Zertifikate installiert!

PeapingTomBild2

PEAP-ing Tom Angriff: Der Angreifer sieht das UNI-Passwort im Klartext!

Sie gefährden mit dem Verzicht auf Zertifikate im Radius Protokoll die IT-Sicherheit und die Integrität ihrer Uni-Kennung. Auch ein Identitätsdiebstahl, also Handlungen Dritter in ihrem Namen, z.B. bei Prüfungsanmeldungen im oder im SAP, wären in so einem Szenario denkbar.

Zusammenfassung

Wenn Ihr Gerät vom CAT-Tool unterstützt wird, das ist für Windows Vista, 7, 8, 10, MacOS ab 10.7, Android ab 4.3, IOS ab IOS5 und Chrome OS der Fall, sollten Sie umgehend mit dem CAT-Tool die neue Konfiguration installieren. Sie können die Thematik dann vergessen und haben auf keinen Fall ein Problem nach dem 31.5. 2019. Außerdem ist Ihr Gerät dann datenschutzfreundlich und sicher konfiguriert.

Alle bisherigen Konfigurationen und auch das alte CAT funktionieren bis zum 31.5. 2019 wie gewohnt.

Wenn Sie ein Gerät haben, dass nicht von CAT unterstützt wird (z.B. ein Windows Phone), bzw. keine Konfiguration einer äußeren Identität zulässt, müssen Sie nach dem 31.5. 2019 eine Konfigurationsänderung vornehmen, bei der Sie ein Root-Zertifikat einstellen bzw. installieren müssen. Nach dem 31.5. 2019 wird dann jeder äußeren Identität das neue Root-Zertifikat präsentiert. Anleitungen dazu finden Sie auf den Support-Seiten des ZIM unter:

https://www.uni-due.de/zim/services/wlan/eduroam-konfiguration.shtml

So soll nun konfiguriert werden:

  • EAP-Methode: PEAP oder TTLS
  • Innere Authentifizierung: MSCHAPv2
  • Zertifikat: “T-Telesec Global Root Class 2” wählen, wenn installiert oder nachinstallieren unter https://www.pki.dfn.de/fileadmin/PKI/zertifikate/T-TeleSec_GlobalRoot_Class_2.crt
  • innere Identität: <Unikennung>@uni-due.de   (immer “@uni-due.de” niemals “stud” oder eine Mailadresse)
  • äußere Identität: eduroam@uni-due.de
  • Radius-Server: radius1.uni-duisburg-essen.de (hier Langform)
  • Passwort: <Unipasswort> ODER WLAN-Passwort, falls in der Benutzerverwaltung gesetzt

„Ich kann dich das nicht tun lassen Dave“* – oder wie Google ab Android 7 eduroam im 5 GHz Frequenzbereich an den Hochschulen ausbremst – 5 GHz erzwingen oder bevorzugen mit Android, IOS, MacOS und Windows


User Experience ist großen Playern wie Google, MS und Apple (die Reihenfolge stimmt heute nicht mehr, MS gehört nun verdient auf den letzten Platz) heute scheinbar in vielen Bereichen wichtiger als Konfigurationsoptionen für erfahrene Nutzer. So hat Google bei der Android-Entwicklung ab Android 7 mit einem Federstrich entschieden, die Konfigurationsoption unter „Einstellungen“ – „WLAN“ – „Erweitert“ -“Bandauswahl 2,4GHz/5GHz/automatisch“, also die „freedom of choice“, zu entfernen. Nun ist alles „automatisch“ und der Nutzer hat keine Möglichkeit mehr einzugreifen.

Einstellungen-WLAN-erweitert-ab-Android7-168x300

Hier war es bis Android 6 möglich 5GHz zu erzwingen. Ab Android 7 hat nun der Nutzer keine Möglichkeit mehr 5GHz zu erzwingen.

 

Das ist aber in überbuchten 2,4 GHz Netzen, wie typischerweise an Hochschulen verbreitet, unbedingt erforderlich! Die Empfehlung in Foren doch einfach eine andere SSID für 5 GHz (nach IEEE 802.11ac) zu wählen ist eine Option für Heimnetze und im WPA-Enterprise-Umfeld (nach IEEE_802.1X) nicht einfach umzusetzen. Wenn man sich die Schnitzer von Apple und Google bezüglich professionellen Enterprise-WPA2-Netzten so anschaut, erkennt man, dass dort wohl in erster Linie nur an die Heimnutzer gedacht wird.

Professionelle WLAN-Controller bieten vielfach Optionen an, um Klienten in 5GHz Netze zu verschieben, sofern sie beide Netze unterstützen. Das klappt aber nicht immer, da in diesem Fall der nicht nur der Access Point (bzw. der Controller) sondern auch der Klient mitspielen muss, was im Fall von „halbschlauen“ Heuristiken, die jeder Treiberhersteller oder gar das Betriebssystem selbst implementiert, oft nicht gegeben ist.

Im eduroam-Verbund ist es von eduroam.org vorgeschrieben, die Netze auch mit „eduroam“ im SSID (WLAN-Namen) zu benennen. Klar, eine Einstelloption für das zu verwendende WLAN-Band birgt für unerfahrene Benutzer die Gefahr, sich das WLAN zu „ver-konfigurieren“ und dann das eigenen Netz nicht mehr wiederzufinden. Man hätte die Option aber beispielsweise auch in den Developer-Einstellungen unterbringen können. So vertraut Google Heuristiken und Automatismen, die auf ausschließlich Empfangsstärke (Signal-Level) beruhen und Nutzer in eduroam-Netzen regelmäßig mit dem naturgemäß (5GHz wird wegen der höheren Frequenz durch Wände stärker gedämpft als 2,4Ghz) stärkerem 2,4 GHz SSID „eduroam“ verbindet mehr als kompetenten Menschen. Der Durchsatz in den 5GHz Bändern ist aber sehr viel höher, da dort wesentlich mehr Kanäle zur Verfügung stehen. Deshalb sollte das 5GHz-Band in hochfrequentierten Netzen an Hochschulen immer bevorzugt werden. Wir empfehlen auch immer in unseren Anleitungen nur solche Geräte zu kaufen, die auch 5 GHz unterstützen.

Aber was nützt das, wenn die Hersteller den Nutzer nicht selber entscheiden lassen? Apple erlaubt solche Einstellungen den iPhone-Besitzern und den MacOS-Nutzern überhaupt gar nicht erst, da man dort vielleicht auch zurecht davon ausgeht, dass der Großteil der eigenen Kunden technisch ahnungslos seien. Diesem schlechten Beispiel folgt nun leider auch Google, was wegen des hohen Android-Anteils von über 80% bei den Smartphones an der Uni-DUE (von allen Android-Smartphones sind derzeit [Stand 7/2018] etwa 33% mit Android 7 oder 8 ausgestattet, dieser Anteil wird stark ansteigen) signifikante Auswirkungen auf die „gefühlte“ WLAN-Qualität haben wird. Während bei den „alten“ Windows-Versionen die Treiber über die Systemsteuerung es erlaubten 5GHz zu priorisieren, ist das in Windows 10 (ausnahmsweise, die Privatspäreneinstellungen sind eine Katastrophe) besser mit einer zentralen Einstellungsoption gelöst worden. Auch das mittlerweile abgekündigte Windows Mobile verfügt über eine solche Funktion.

Die Nutzer von Android und MacOS können sich derweil damit trösten, dass sie sich die möglicherweise falsche automatische Wahl ihres Betriebssystems wenigstens anschauen können. Bei MacOS funktioniert das mit Alt+ Klick auf das WLAN-Symbol. Wenn dort nicht wie in diesem Beispiel 5GHz für das WLAN angezeigt wird, kann man sich bei Apple für die schlechte WLAN-Performance bedanken.

so_macht_apple_das-222x300

Alt + Klick auf das WLAN Symbol und der MAC verrät, ob er am schnellen 5GHz-WLAN hängt.

 

Android-Nutzer müssen nun zu einer App greifen (hier empfohlen, WIFIAnalyzer, com.vrem.wifianalyzer) um zu schauen, welches Band die „schlaue“ Automatik ausgesucht hat. Eine Änderung der Wahl ist leider mit der App nicht möglich. WIFIAnalyzer eignet sich auch hervorragend um die beiden weiter unten empfohlenen Apps auf Wirksamkeit zu testen, da der aktuell verbundenen AP gekennzeichnet und mit MAC-Adresse angezeigt wird. Eine ähnliche Funktionalität würde übrigens auch die normale Android WLAN-Anzeige hinbekommen, wenn in den Android-Entwickleroptionen (so aktiviert man diese zusätzliche Option in den Android-Einstellungen) die Option “Ausführliche WLAN-Protokolle” aktiviert wird.

Screenshot_20180726-151334-168x300

Screenshot_20180802-1117091-168x300

Der WifiAnalyzer zeigt, dass sich das schlaue Android mit dem 2,4 GHz-WLAN verbunden hat, obwohl 5GHz verfügbar ist!

Hier wird in den Android-Entwickleroptionen die Option “Ausführliche WLAN-Protokolle” aktiviert.

 

Screenshot_20180802-110309-168x300

So sieht die Android-WLAN-Anzeige für “Erwachsene”aus, wenn in den Android-Entwickleroptionen die Option “Ausführliche WLAN-Protokolle” aktiviert wurde. Hier hat der WI-FI-Switcher, die zweite App, siehe unten, 5GHz erzwungen. Unter f wird die Frequenz angezeigt, alles mit 5xxx bedeutet 5Ghz 24xx bedeutet 2,4 Ghz. Es werden auch MAC-Adressen und rssi angezeigt.

 

Die App Wifi-Switcher erlaubt zumindest pro Accesspoint einzelne 5 GHz-APs zu priorisieren. Eine weitere  App mit dem sehr ähnlichen Namen Wi-Fi-Switcher erlaubt auch generell 5GHz zu priorisieren. Vor der gleichzeitigen Verwendung der beiden Apps ist aber abzuraten.

Screenshot_20180802-1114371-168x300

WI-FI-Switcher erlaubt die Priorisierung von 5GHz mit dieser Option.

 

Allerdings muss bei schon verbundenem eduroam die WLAN-Verbindung einmal ab- und wieder angeschaltet werden, damit die Einstellung greift. Das läßt sich direkt in der App erledigen. Möglicherweise ist auch ein Neustart erforderlich, damit die App im Hintergrund die Kontrolle über die WLAN-Auswahl übernehmen kann. Bei beiden Apps muss die Standortfreigabe aktiviert sein – eine weitere Limitierung, die sich Google für neuere Android-Versionen ausgedacht hat. Apps, welche die Wifi-API benutzen, benötigen nun eine Standortfreigabe (Standort nur Gerät, d.h. nur GPS funktioniert auch und ist Datensparsam, da der Standort dann nicht ständig an Google weitergegeben wird, bzw. der Nutzer für Google als War-Driver unterwegs ist). Die App-Autoren müssen nun mit schlechten Bewertungen ahnungsloser Android-Nutzer rechnen, die diese Zusammenhänge nicht verstehen. Auch auf die Bewertungsfunktion im Google Play Store kann man sich, bei der Vielzahl der Laien, die sich eine Bewertung zutrauen, nicht mehr uneingeschränkt verlassen.

Es scheint leider so, als hätte man bei Google Nägel mit Köpfen gemacht, und auch die Auswahl per Android-API entfernt, so dass auch einige  weitere ältere Apps, die so etwas anboten, ab Android 7 gar nicht mehr oder nur noch mit eingeschalteter Standortfunktion funktionieren. (Quelle: https://stackoverflow.com/questions/17345788/scanning-for-wifi-signals-only-in-2-4ghz-band )

Wenn ein Leser eine Möglichkeit kennt unter IOS oder MacOS 5GHz zu erzwingen, wäre ich für einen kurzen Hinweis dankbar.

* Ein Zitat aus dem Film „2001 Odyssee im Weltraum“ in dem die KI “HAL9000″ versucht die Menschen an Bord eines Raumschiffes zu töten, indem sie mit der Begründung “I’m sorry Dave, I’m afraid I can’t do that” einen Befehl eines Menschen ignoriert.  Eine Anspielung auf das Zitat von HAL stammt aus der South Park Folge “You Have 0 Friends“. Als Stan dort versucht seinen facebook Account zu löschen, erhält er die Systemmeldung: “I’m afraid I can’t let you do that, Stan Marsh.”.

Eine Lanze brechen für PDF/A1 – oder wie sich Verschlüsselungstrojaner (Ransomware) verbreiten


Phishing-Mails mit Office-Makros waren anlässlich der Locky-Ransomware-Welle das Einfallstor in Windows-Systeme.  Damals hatten wir unsere Kunden gewarnt Office-Anhänge zu öffnen und alternativ auf PDF als Austauschformat zurückzugreifen. Das ist aber nur die halbe Wahrheit, weil gut gemachte Phishing-Mails nun auch Verschlüsselungstrojaner über PDF-Anhänge verbreiten. Der Grund dafür sind aktive Inhalte in PDF-Dokumenten. Wenig bekannt ist, dass auch ein PDF-Dokument aktive Inhalte, wie Videos, Audio und auch JavaScript enthalten kann.

Ich habe hier einmal ein Beispiel für ein aktives PDF-Dokument verlinkt. Wenn Sie es im Browser öffnen, sollte nichts interaktiv passieren, sofern Sie einen modernen Browser verwenden (siehe UPDATE 2022 unten). Wenn Sie das Dokument abspeichern und darauf klicken, poppt ein JavaScript „Hallo Welt“ Dialog auf, sofern der Acrobat Reader installiert ist. Der JavaScript-Code könnte auch potentiell gefährliche Dinge mit Ihrem PC anstellen.

Der in Firefox integrierte PDF-Reader ist selber in JavaScript geschrieben und führt keine aktiven Inhalte aus. UPDATE 2022: Das stimmt so nicht mehr: Der integrierte Javascript-basierte PDF-Reader führt nun selber auch Javascript aus! Zur Erhöhung der Sicherheit auf dem Windows-Desktop kann alternativ zu Adobe Acrobat SumatraPDF verwendet werden, welches ebenfalls keine aktiven PDF-Elemente zulässt. PDF/A1-Dateien für Langzeitarchivierung dürfen per Definition gar keine aktiven Inhalte wie  z.B. Javascript enthalten und sind deshalb als PDF-Austauschformat zu bevorzugen. Ein schöne Anleitung wie Sie ein solches ungefährliches PDF/A1 einfach aus Word heraus erzeugen findet man hier (einfach beim Exportieren als PDF in den Optionen „ISO 19005 kompatibel“ anwählen). Für Dokumente, die nicht weiter bearbeitet werden müssen, sollte ausschließlich PDF/A1 als Austauschformat eingesetzt werden!

Neben Phishing-Mails gibt es weitere Verbreitungswege von Ransomware, wie z.B. Drive-by-Downloads, Verbreitung über das LAN mit Zero-Day-Lücken und neuerdings auch über gekaperte Software-Updateserver. Ein paar Tipps wie man sich gegen Drive-by-Downloads schützen kann, finden sich in unserer Dokumentation.

Gegen schlimme Zero-Day-Lücken, wie bei WannaCry oder gar die Verteilung von Ransomware über Updateserver wie bei NotPetja helfen solche Vorsichtsmaßnamen alleine nicht. Die frühzeitige Warnung unserer Kunden und besonnenes Handeln kann möglicherweise in so einem Fall Schlimmeres verhindern, sofern überhaupt Informationen zum Verbreitungsweg vorliegen. Man darf gespannt sein, was uns in Zukunft noch alles an kreativer Ransomware begegnet. Der aktuelle NotPetja Angriff hat wieder gezeigt, dass hoch zentralisierte Systeme mit „Standardsoftware“ besonders angreifbar sind, wenn es dem Angreifer gelingt in die gemanagte Umgebung einzudringen. Insofern ist die UDE durch die Diversität der eingesetzten Betriebssysteme und der teils dezentralen IT vor einem worst case „IT-Totalschaden“ gesichert. Wenn allerdings zukünftig alle Betriebssysteme virtualisiert auf einer einheitlichen Virtualisierungsumgebung laufen, kann ein erfolgreicher Angriff auf diese die ganze IT der UDE auf einen Schlag lahmlegen.
Update 2024: Genau das ist beim Angriff auf die UNI-Duisburg-Essen im November 2022 passiert. Dieser Artikel erschien 2017 auch in dem internen Newsletter der IT (ZIM) dort, für die ich seinerzeit gearbeitet hatte. Man hätte also gewarnt sein können – told you so ;-).
Auch ein erfolgreicher Angriff auf die – oder auch nur ein Fehler in der – Update-Infrastruktur von Microsoft kann zu einem IT-Blackout zu mindestens der MS-Welt führen. Beide Szenarien sind (hoffentlich) sehr unwahrscheinlich und werden hier nur erwähnt, damit ich beim Eintritt Fefes „told you so“-Spruch loswerden kann ;-).

Im Ernst: Die beste Strategie gegen Verschlüsselungstrojaner ist die Erstellung regelmäßiger Backups. Wer alle wichtigen Dateien im Fileservice auf einen unserer Netzwerklaufwerke im ZIM speichert ist auf der sicheren Seite, da diese durch regelmäßige Snapshots unserer NetApp-Dateiserver geschützt sind. Frei nach Marius Mertens: „Es gibt gesicherte Daten und unwichtige Daten“ oder wie es die C‘t formuliert: Kein Backup? Kein Mitleid!

Empfehlungen zum Einsatz von Windows 10 an der Universität Duisburg-Essen


Das neue Betriebssystem von Microsoft Windows 10 hat durch seine verstärkte Ausrichtung auf mobile NutzerInnen neue Features erhalten, die ähnlich wie bei IOS und Android erhebliche Auswirkung auf die Privatsphäre der AnwenderInnen haben. So sammelt Windows 10 Telemetriedaten zu den NutzerInnen  um die User-Experience mit Hilfe der integrierten virtuellen Assistentin “Cortana” zu verbessern.
AnwenderInnen die deutsche oder europäische Datenschutzstandards gewohnt sind, werden aber anhand der Daten die Microsoft erhebt ein eher mulmiges Gefühl bekommen.  Microsoft hat die datenschutzrelevanten Einstellungen aber recht übersichtlich in der Registrierkarte “Datenschutz” unter “Einstellungen” zusammengefasst. Leider geht Microsoft nach dem “opt-out”-Verfahren vor, d.h. nach der Installation sind die Einstellungen maximal Datenschutz-ungünstig vorbelegt und die AnwenderInnen müssen sich die Zeitnehmen die Einstellungen anzupassen. Es ist zu befürchten, dass sich nicht Jeder die Zeit nimmt, die Datenschutzeinstellungen sorgfältig zu konfigurieren. Besonders  unangenehm aufgefallen ist, dass Microsoft bei Updates  -  absichtlich oder nicht – die Datenschutzeinstellungen auf ungünstige  Einstellungen zurücksetzt.
Einen schönen Überblick zu der Thematik und Tipps zur Konfiguration gibt dieser Artikel auf Heise-Online.

Die Universität Duisburg-Essen ist  dem Microsoft Bundesvertrag (Mitarbeiter) beigetreten. Im Rahmen dieses Vertrages können Sie Windows-Betriebssysteme  als Upgrade auf allen Arbeitsplatzrechnern und PC-Pools installieren. Voraussetzung für den Einsatz einer aktuellen Windows-Version ist immer das Vorhandensein einer qualifizierenden Betriebssystem-Lizenz. Das ZIM betreibt derzeit in den Pools Windows 7 und empfiehlt auch den AnwenderInnen der UDE diese Windows-Variante an Arbeitsplätzen.  Den Einsatz von Windows 10 an der UDE empfiehlt das ZIM aus Datenschutzerwägungen derzeit explizit nicht.

Wenn Sie nicht auf den Einsatz verzichten wollen oder können, verwenden Sie eine der Versionen  „Windows 10 Education“ oder  „Windows 10 Enterprise LTSB“ (Long Term Servicing Branch). „Windows 10 Enterprise LTSB“ wurde für geschäftskritische Systeme konzipiert. Für diese Version verteilt Microsoft ausschließlich aktuelle Sicherheitsupdates und Hotfixes. Für den Einsatz an Arbeitsplätzen besser geeignet ist die Version “Education”, die kontinuierliche Weiterentwicklungen erhält. Bei diesen beiden Versionen lässt sich über Gruppenrichtlinien zentral die Übermittlung von Telemetrie-Daten an Microsoft vollständig zu unterbinden (Telemetry-Level 0: Security).

UPDATE !!/2019: Scheinbar läßt sich die Übermittlung von Telemetrie-Daten in keiner Windows 10 Version vollständig unterbinden! Siehe:

https://www.dfn-cert.de/dokumente/ds_workshops/Datenschutzkonferenz2016/Windows10_Folien.pdf

und

https://www.baden-wuerttemberg.datenschutz.de/wp-content/uploads/2019/11/Beschluss_zu_TOP_13_Win10_Pr%C3%BCfschema.pdf

Vor diesem Hintergrund würde ich von einer Verwendung von Windows 10 zur Verarbeitung personenbezogenen Daten dringend abraten!

Dies kann auch lokal auf dem jeweiligen Rechner eingestellt werden. Vor der Verwendung  der Versionen “Windows 10 Home” und “Pro”  an Arbeitsplätzen der Hochschule soll aus Datenschutzerwägungen abgesehen werden, da hier kein vollständigen Deaktivieren der Telemetrie möglich ist.

Das kostenlose Tool “O&O shutup10” vereinfacht die Datenschutzeinstellungen.

Für alle NutzerInnen ,die die Datenschutzeinstellungen manuell vornehmen möchten, sind anbei einige Screenshots mit empfohlenen Einstellungen aufgeführt:

win10-1win10-2win10-3win10-5win10-6win10-7

 

Es muss nicht immer VPN sein – surfen im IP-Adressbereich der Uni über einen SSH-Tunnel


Ein virtuelles Privates Netzwerk (VPN) bindet entfernte Nutzer über das Internet in ein lokales Netzwerk ein. Das geschieht im Allgemeinen transparent, d.h. für die Nutzerinnen und Nutzer sieht es so aus, als ob sie sich beispielsweise im Uni-Netz befinden. Alle Netzdienste in einem Firmen- Heim- oder Universitätsnetz können dann unterwegs so genutzt werden, als ob man vor Ort wäre. Sehr häufig geht es aber nur um einen einzigen Netzdienst, nämlich das Web. An der Universität Duisburg-Essen werden viele Dinge heute webbasiert erledigt. Allerdings erfordern viele Seiten, dass sich der Nutzer im IP-Adressbereich der Uni befindet. Warum also ein vollständiges VPN verwenden, wenn eigentlich nur die Verbindungen über die Ports 80 (http) und 443 (https) genutzt werden? Eine Möglichkeit http- und https-Verbindungen umzuleiten ist ein Web-Proxy, der auf Protokollebene zwischen dem Browser und dem Web vermittelt. Dazu muss aber ein dezidierter Proxy-Server betrieben werden, der von außerhalb des Uni-Netzes zugänglich ist. Alternativ realisiert ein sogenannter Socks-Proxy so etwas auf Socket-Ebene also über TCP/IP Ports.

Ein Tunnel sie alle zu knechten …

Alle aktuelle Browser unterstützen die Verbindung auch über einen Socks-Proxy. Wer Login-Zugriff per SSH auf einen Rechner in dem Zielnetz hat, kann sehr einfach einen Socks-Proxy per SSH-Tunnel realisieren. Das ist beispielsweise an der Universität Duisburg-Essen für alle Nutzer der Fall. Alle Mitarbeiter haben mit ihrer Unikennung Zugriff auf staff.uni-due.de und alle Studierende können die Maschine student.uni-due.de mit ihrer Kennung nutzen.

Linux/MacOS/Unix:

Unter unixoiden Betriebsystemen wie Linux und MacOS geht das sehr einfach mit Bordmitteln auf der Kommandozeile (hier mit staff.uni-due.de für Mitarbeiter):

ssh -N -D2000 <unikennung>@staff.uni-due.de

Der Parameter -N verhindert hier den Aufbau einer interaktiven Shell-Verbindung. Der Parameter -D gibt den lokalen Zugriffsport für den dynamischen Tunnel an. Diesen Port wählt man unter Unix geschickter Weise oberhalb von 1023, damit keine Root-Rechte erforderlich sind.

Windows:

Unter Windows benötigen Sie einen SSH-Clienten wie beispielsweise den quelloffen Putty.

Nach der Installation wird Putty folgendermaßen konfiguriert (hier staff.uni-due.de  für Mitarbeiter, Studierende verwenden student.uni-due.de):

putty_tunnel0

Dann wird der Tunnel mit dem lokalen Endpunkt Port 2000 (willkürlich gewählt) konfiguriert. Wichtig für einen Socks-Proxy ist die Einstellung “Dynamic”:

putty_tunnel1

Nach klick auf “Add” ist der Tunnel eingerichtet. Sinnvollerweise speichert man das Profil nun ab. Vorsicht ist geboten bei der Checkbox „Local ports accept connection from other hosts“. Wer diese Option anwählt tunnelt womöglich andere Rechner oder gar Angreifer mit in das Universitätsnetz.

Betriebssystemunabhängig – die Browser-Konfiguration:

So konfiguriert man den Browser (hier z.B. Firefox, sorry ich verwende nur den englischsprachigen), damit er den Tunnel auch benutzt:

putty_tunnel2

Technisch gesehen wird nun jeder http-Request über den lokalen Port 2000 des Klienten abgewickelt, der ja über den (gesicherten) ssh-Tunnel mit dem Publikumsrechner im LAN der Uni verbunden ist.

Wenn der Tunnel erfolgreich in Betrieb genommen worden ist, kann man zum Beispiel auf www.wieistmeineip.de überprüfen, ob auch wirklich der Tunnel im Browser verwendet wird. Dort wird nun eine IP-Adresse aus dem Uni-Adressbereich 132.252.X.X angezeigt. Natürlich muß die Proxy-Einstellung immer wieder rückgängig gemacht werden, wenn der Tunnel wieder abgebaut wird. Zweckmäßig ist die Nutzung eines extra Browsers oder beispielsweise bei Opera die Verwendung der Schnelleinstellungen.

So ein Socks-Proxy funktioniert auch in Umgebungen, in denen herkömmliche VPN-Lösungen versagen (müssen), z.B. doppeltes NAT. Es ist auch möglich beliebig viele Klienten aus einer NAT Umgebung gleichzeitig zu verbinden, was bei einem VPN zu Problemen führen kann. Auch Unitymedia-Kunden mit IPv6-Stack ohne IPv4 profitieren von dieser Lösung.

socks-proxy

Übrigens bekommt Ihr Provider (oder das Internet-Cafe in dem Sie sich befinden) nicht mit was in dem Tunnel passiert, alles ist bis zum Socks-Proxy in der Uni verschlüsselt. Nach dem Tunnel, also ab staff.uni-due.de bzw. student.uni-due.de geht es aber wieder unverschlüsselt weiter. Zumindest Ihr Provider hat aber keine Chance diese Verbindungsdaten abzugreifen.Der Provider sieht nur die Verbindung zum Socks-Proxy. Gegen die Datenschnüffellei der NSA schützt das aber nicht wirklich, da der Traffic aus der Uni zu den Webseiten die Sie besuchen abgegriffen wird, was wirklich eine Frechheit ist!

Spezialitäten:

Wer mehr möchte, kann auch Programme die keine Socks-Proxys unterstützen mit dieser Technik ausstatten, indem man einen Wrapper wie z.B. tsocks einsetzt.

Es ist sogar möglich einen kompletten Stack über einen Socks-Proxy umzuleiten. Dazu wird das Tool tun2sock (bzw. badvpn) eingesetzt. Damit ist ein SSH-basiertes VPN realisierbar.

Für Kunden von Unitymedia mit neuem Ipv6-Stack ohne IPv4 wäre es damit möglich das Zwangs-NAT für alle Verbindungen zu überwinden.

Noch ein Tipp für die Besitzer eines Servers/virtuellen Servers oder eines Shellaccounts mit fester erreichbarer IP:

Wer von einem limitierten Internetzugang (z.B. NAT und kein Zugriff auf den Router) aus Serverdienste (Web, ssh, etc.) betreiben möchte, kann z.B. mit

ssh -R 3333:localhost:22 <gateway-maschine>

einen ssh-Server des nicht erreichbaren Rechers in einem NAT (oder in einem Ipv6-only-Netz) auf den Port 3333 auf einer Gateway-Maschine (die über eine öffentlich erreichbare IP-Adresse verfügt) umlenken, wenn auf der Gateway-Maschine in der Konfigurationsdatei /etc/ssh/sshd_config

GatewayPorts yes

(Neustart des sshd erforderlich) eingetragen wird.

So kann die versteckte Maschine per ssh auf den Port 3333 der Gateway-Maschine erreicht werden. Das klappt beispielsweise auch mit einem Server (z.B. auch Webserver, dann aber Port 80 weiterleiten) auf einem Smartphone (oder einem mobilen Roboter, wie ich das hier im Jahre 2009 realisiert habe) im UMTS-Netz, dass bei fast allen Providern auch per NAT betrieben wird!

nat-tunnel-server

Dazu sind natürlich auf der aus dem Internet erreichbaren Maschine Root-Rechte erforderlich.

Ohne Root-Rechte ist es etwas komplizierter so etwas zu realisieren, hier benötigt man zwei Tunnel:

auf der hinter einem NAT versteckten lokalen Maschine:

ssh -R 3333:localhost:22 <gateway-maschine>

auf der Gateway-Maschine mit öffentlicher IP:

server# ssh -g -L4444:localhost:3333 localhost

Dann kann nun über den Port 4444 der Gateway-Maschine per ssh auf die versteckte Maschine zugegriffen werden. Das funktioniert mit beliebigen Quellports, also auch mit Port 80. Die Beispiele beziehen sich auf die Unix-Kommandozeile aber sollten mit entprechenden Einstellungen auch unter Windows funktionieren, sofern man einen sshd für Windows installiert.

Vorausgesetzt wird immer, dass keine Firewall die Ports blockiert. Wenn man nicht über root-Rechte verfügt, muss man Ports oberhalb von 1023 wählen, es geht bis 65535 ;-) .
Die Maschinen staff.uni-due.de und student.uni-due.de am ZIM der Universität Duisburg-Essen erlauben dieses erweiterte Verfahren übrigens nicht, da sie durch Firewalls geschützt sind. Einen Socks-Proxy können Sie aber mit diesen Maschinen aufbauen.

Dieser Beitrag wurde unter Allgemein, Anwendungen & Dienste, Code & Kernel, Tipps & Tricks abgelegt und mit , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.