W2018-ITS: Difference between revisions
mNo edit summary |
|||
Line 2: | Line 2: | ||
==CredentialProvider zum Windows Login mit Personalausweis== |
==CredentialProvider zum Windows Login mit Personalausweis== |
||
Passworte als häufigst verwendete Authentisierungsmethode stoßen zusehends an Grenzen. Windows gestattet aber auch eine tokenbasierte Authentisierung. Allerdings sind Hardwaretoken noch nicht überall verbreitet und erfordern ggf. zusätzliche Investitionen. Der ab 2010 eingeführte neue Personalausweis jedoch ist bereits in den Taschen vieler und er hat mit der eID-Funktion eine kryptografisch starke Authentisierung an Bord. Kann diese benutzt werden, um sich an einem Windows-System sicherer anzumelden? |
|||
Links: |
|||
* [https://docs.microsoft.com/en-us/windows/desktop/secauthn/credential-providers-in-windows Credential Provider] |
|||
* [https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03110/index_htm.html BSI TR-03110] |
|||
Mentor: [mailto:Frank.Morgner@BDr.de Frank Morgner] |
Mentor: [mailto:Frank.Morgner@BDr.de Frank Morgner] |
Revision as of 11:17, 17 September 2018
Themen (DRAFT) für IT-Security Workshop 1. bis 12. Oktober 2018
CredentialProvider zum Windows Login mit Personalausweis
Passworte als häufigst verwendete Authentisierungsmethode stoßen zusehends an Grenzen. Windows gestattet aber auch eine tokenbasierte Authentisierung. Allerdings sind Hardwaretoken noch nicht überall verbreitet und erfordern ggf. zusätzliche Investitionen. Der ab 2010 eingeführte neue Personalausweis jedoch ist bereits in den Taschen vieler und er hat mit der eID-Funktion eine kryptografisch starke Authentisierung an Bord. Kann diese benutzt werden, um sich an einem Windows-System sicherer anzumelden?
Links:
Mentor: Frank Morgner
UAF Java Card Applet
Mentor: Frank Morgner
DNSSEC@Informatik
Eigentlich wird schon lange über die sichere Variante von DNS gesprochen. Dennoch ist die HU und auch unser Institut noch nicht über DNS-SEC von außen validierbar. Für die Domain hu-berlin.de hat das CMS schon Grundlagen geschaffen, aber die Einbindung nach oben ist noch nicht erfolgt.
Erarbeiten Sie ein Konzept und versuchen Sie, exemplarisch einige Schritte umzusetzen. Welche Software wird benötigt, um eine Zone zu signieren. Wie können Schlüssel sicher aufbewahrt werden. Was ist mit dynamischen Einträgen?
Welche Vorteile bietet DNSSEC bei erfolgreicher Validierung? Mit DANE können auch weitere Felder über DNSSEC ausgeliefert werden. Denkbar wäre zum Beispiel auch SMTP mithilfe von DANE stärker zu machen oder auch SSH-Fingeprints von Informatikrechnern automatisch ausliefern zu lassen und so Trust-on-First-Use oder das manuelle Vergleichen mit unserer Liste zu überwinden.
Links:
Mentoren: Robert Sombrutzki, Wolf Müller
Sicheres HTTPS für Legacy-Server
Während bei aktueller Software die Chancen recht gut sind, dass noch starke Ciphersuites zur Verfügung stehen, ist es mit Altanwendungen ungleich schwerer, diese zu ertüchtigen. Versuchen Si,e beispielsweise für einen Microsoft IIS 6.0 nach außen eine starke Verschlüsselung nachzurüsten.
Weiterhin könnten in den Reverse-Proxy-Varianten mit Apache / Nginx auch weitere aktuelle Sicherheitsfeatures scharfgeschaltet werden, wie zum Beispiel Einstellungen zur Content Security Policy (CSP). Während in Altbeständen die Chancen gut stehen, dass Bilder als separate Ressourcen (Dateien) eingebunden sind, sind häufig Style-Elemente und JavaScript-Zeilen inline in der Seite eingebettet, was dann Probleme macht. Entwerfen Sie Software, die hier eine möglichst komfortable Auslagerung in externe Ressourcen vornimmt. Ein Startpunkt könnte beispielsweise Tidy sein.
Links:
Mentor: Wolf Müller
Sicherer und schneller SSL/TLS-Handshake
Nach den Enthüllungen von Edward Snowden haben wir verstanden, warum authentische und vertrauliche Kommunikation wichtig ist. Naiv betrachtet, könnte man denken, es ist ausreichend "s"-Protokolle wie https, imaps, pops ... zu verwenden und alles ist gut. Es ist in Praxis jedoch wesentlich komplexer eine unter dem gegenwärtigen Angreifermodell hinreichend starke SSL/TLS-Verbindung zu erzwingen.
In der Vergangenheit wurden zahlreiche teils sehr originelle Angriffe auf SSL/TLS entwickelt, die Seitenkanäle oder auch Probleme im Protokollentwurf oder der Implementierung adressieren. Weiterhin ist es wünschenswert, "forward secureness" zu nutzen, da auch nicht für jeden Server der private Schlüssel immer privat bleiben muss.
Versuchen Sie für einen aktuellen SSL/TLS-Server (z.B. Apache oder NGINX) eine möglichst sichere Konfiguration zu erstellen. Eine gute Orientierung bietet die Technische Richtlinie "BSI TR-02102-2" Behalten Sie dabei auch die Performance für den Handshake im Auge:
- Könnte die Nutzung von ECC hier weiter helfen?
- DH oder ECDH?
- Was muss ein sorgsamer Client alles prüfen, wie kann ihn der Server dabei unterstützen?
- Kann man die gesamte Zertifikatskette auch ECC-signiert bekommen?
- Was ist OCSP-stampling
- Was bringen die einzelnen Maßnahmen?
Links:
Mentor: Wolf Müller
Die Zukunft "TLS auf Speed"
Wo geht die Reise in der Standardisierung hin? Weniger Optionen, schnellerer Handshake, schneller Transport. Gibt es bereits erste Implementierungen des neuen Standards? Was gibt OpenSSL 1.1.* her. Welche Optimierungen können bei der eigentlichen vertraulichen und authentischen Übertragung helfen?
- Ciphersuites auch aus TLS 1.3 ChaCah
- Hardwareunterstützung von AES
- Einsparung von Kontextwechseln SSL/TLS-Kernel-Support
- Integration mit OSI-Layer 7 HTTP/2
Links:
Mentor: Wolf Müller
Absicherung NFS
Bei NFS-Freigaben sind hohe Anforderungen an die Integrität des NFS-Clienten gestellt, da allein dieser über die Einhaltung der im exportierten Dateisystem gesetzten Rechte entscheidet. Daher ist es essenziell, dass sich bei dem mountenden Clienten wirklich um den beabsichtigten legitimen Rechner handelt. Der Normalfall ist eine simple Überprüfung der IP-Adresse, die in der /etc/exports angegeben ist.
Untersuchen Sie, welche Verbesserungen hier möglich sind und welchen Aufwand, welche Komplexität die von Ihnen erarbeitenden Lösungen haben. Die verlässlichere Prüfung könnte auf verschiedenen Schichten angesetzt werden. Wünschenswert wäre zumindest eine starke und persistente Authentisierung (z.B. basierend auf privaten Schlüsseln). Denkbar wäre eine Absicherung über SSL/TLS vielleicht mit einem performanten Modus mindestens zur Integritätssicherung (TLS_RSA_WITH_NULL_SHA, TLS_RSA_WITH_NULL_SHA256, ..., TLS_RSA_WITH_AES_128_GCM_SHA256), womit zumindest aktive Angriffe unterbunden werden könnten. Alternativ könnte auch die Verwendung von NFS mit Kerberos helfen. Betrachten Sie das Verhältnis von Sicherheit und Performance.
Links:
Mentoren: Wolf Müller, Robert Sombrutzki
Informatik-Sync-Server für Firefox
Die Authentisierung mittels (Name,Passwort) wird nach wie vor von vielen Diensten im Internet verwendet. Der Nutzer ist bei der Vielzahl der Dienste schlichtweg überfordert, sich all diese zu merken. Als Konsequenz wurden Lösungen wie Single Sign On oder Open ID vorgeschlagen. In der post-Snowden-Ära gibt es jedoch Bedenken, die Authentisierung an eine dritte Partei auszulagern, da diese auch im Namen des legitimen Nutzers ohne diesen eine erfolgreiche Authentisierung bewerkstelligen könnte.
Einen anderen Ansatz bieten Passwortmanager. Hier wird dem Benutzer angeboten, mit Hilfe (eines hoffentlich starken Masterpassworts) den Zugang zu den Authentisierungsdaten für die einzelnen Dienste abzusichern. Die Referenzdaten dazu können beispielsweise lokal verschlüsselt gespeichert werden. Allerdings ist es ggf. wünschenswert, den Passwortmanager auch auf verschiedenen Geräten nutzen zu können. Eine Lösung die auch die Synchronisierung zwischen verschiedenen Geräten vorsieht, ist Firefox Sync" was auch direkt im Firefox ohne zusätzliche Plugins oder Erweiterungen nutzbar ist.
Jedoch werden die (zwar verschlüsselten) Referenzdaten auf einem zentralen Server gespeichert. Hier wäre es wünschenswert, eine Lösung umzusetzen, die eine Speicherung auf unserem eigenen Informatik-Server zulässt.
Links:
- Run your own Sync-1.5 Server
- Run your own Firefox Accounts Server
- Ansible
- Eigener Sync-Server für Firefox
Mentoren: Wolf Müller, Robert Sombrutzki
Experimentell: VoIP-Honigtopf
Vielerorts werden und wurden bereits traditionelle Telefonnetze auf VoIP umgestellt. Aber beinhaltet diese Umstellung neben Vereinheitlichung und Komfort ggf. auch Risiken und neue Angriffsvektoren? Versuchen Sie, einen "VoIP honeypot" aufzusetzen, um sich im Erfolgsfall einen Überblick zu verschaffen.
- Welche Angriffe gibt es?
- Wie kann man sich schützen?
- Gibt es Provider die mehr als normales zip also z.B. SRTP/TLS bieten?
- Welche Endgeräte können das?
- Gibt es Router mit DECT, die genutzt werden könnten?
Links:
Mentor: Wolf Müller
Sicheres OpenVPN
OpenVPN ist eine gute Möglichkeit, seine Kommunikation durch öffentliche Netze abzusichern oder sich logisch in die HU oder in das Institut für Informatik zu begeben. Untersuchen Sie, wie diese Verbindungen (hu-berlin.ovpn und am Institut) konfiguriert sind, und welche Verbindungen zwischen Server und Client ausgehandelt werden. Hierbei gibt es zu beachten, dass es OpenVPN eine Kontrollverbindung zur Authentisierung und Schlüsselvereinbarung und eine Datenverbindung zum sicheren Transport der eigentlichen Daten nutzt. Für einen aktuellen OpenVPN-Clienten kann man die die Möglichkeiten für eine TLS-Absicherung der Kontrollverbindung mit openvpn --show-tls
und die Absicherungsmöglichkeiten der Datenverbindung mit openvpn --show-cipher
einsehen. Versuchen Sie eine effiziente, starke und auch möglichst interoperable Konfiguration zu erstellen, die mit aktueller Software den Zugriff unter Linux, Mac, Windows, iOS und Android gestattet. Verschaffen Sie sich einen Überblick. Welche Vor- / Nachteile haben die Modi CBC, CFB, CFB1, CFB8, OFB und was bewirken diese überhaupt?
Links:
Mentoren: Wolf Müller, Robert Sombrutzki