W2014-ITS

From
Revision as of 12:26, 16 October 2014 by Wolfm (talk | contribs) (→‎Vorträge)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Vorträge

Donnerstag 2.10. 2014, Rudower Chaussee 25, Haus 3, Raum 3'328

09:30-10:30 Eigener Sync-Server für Firefox Maximilian, Tom
10.30-11:30 Verteilte Erkennung von fehlgeschlagenen SSH-Loginversuchen Phillipp, Dirk

pdf

11:30-12:30 Mittagspause
12:30-13:30 DANE für unseren Mail-Server Christoph, Sven pdf
13:30-14:30 U2F FIDO Oliver, Marc

pdf

Pro Gruppe ist angedacht, die 60 min auf 45 min Vortrag (+ ggf. Demo) und 15 min Diskussion und Umbaupause aufzuteilen.

Themenvorschläge für IT-Security Workshop 22. September bis 2. Oktober 2014

Eigener Sync-Server für Firefox (Maximilian, Tom)

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 Authenisierung 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 Ihrem eigenen Server zulässt.

Links:

Mentor: Wolf Müller


U2F FIDO (Oliver, Marc)

Zunehmend werden schwache Nutzerpassworte bei Webdiensten zum Problem. Die Nutzer sehen sich mit einer wachsenden Zahl von für ihr tägliches Leben bedeutungsvollen Webdiensten konfrontiert, für die sie eine sichere und individuelle Authentisierung benötigen. Die von Google vorgeschlagene Idee eines "universal second factor" U2F addressiert genau dieses Problem. Die Authentisierung verwendet einen universellen Hardwaretoken "Gnubby" der über USB, NFC später vielleicht auch über Bluetooth 4.0 an ein IT-System angebunden wird und einen Smardcardchip beinhaltet. Untersuchen Sie dieses System, finden Sie heraus, wie es arbeitet und ob ein pseudonymes Login damit realisierbar ist. U2F wird als Beitrag zu einem größeren Vorhaben der FIDO-Alliance gesehen

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 es essentiell, dass sich bei dem mountenden Clienten wirklich um den beabsichtigten legitimen Rechner handelt. Der Normalfall ist eine simple Überprüfung der IP-Addresse, 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.

Links:

Mentor: Jan-Peter Bell

DANE für unseren Mail-Server (Christoph, Sven)

Die im RFC 6698 beschriebene "DNS-Based Authentication of Named Entities (DANE)" scheint ein gutes Mittel zu sein, um jenseits von bestehenden PKI-Mechanismen eine starke Authentisierung eines Servers und spätere Absicherung der Verbindung über SSL/TLS ausgehend von dessen DNS-Namen zu erreichen. Versuchen Sie dieses Konzept für unseren Institutsmailserver umzusetzen.

Links:

Mentor: Jan-Peter Bell, Wolf Müller

Verteilte Erkennung von fehlgeschlagenen SSH-Loginversuchen (Phillipp, Dirk)

Derzeit werden fehlgeschlagene Loginversuche über SSH auf unseren Institutsrechnern in lokalen Logfiles mitprotokolliert. Erfolgen von einer Absender IP auf einem Rechner zu viele davon, so wird angenommen, dass es sich um einen Angriff handelt und der Zugriff von dieser IP wird für eine gewisse Zeit gesperrt. Wünschenswert wäre eine schnellere Erkennung von Angriffen, die parallel mehrere unserer Rechner zum Ziel haben.

Entwickeln Sie ein Konzept für eine verteilte Erkennung und Sperrung!

Mentor: Jan-Peter Bell

Smartcards@SUNray

Wie Sie ja vielleicht schon bemerkt haben, kann man gewisse Smartcards zur Identifizierung einer bestehenden Session auf einem SUNray nutzen und diese dann später wieder an einem anderen Terminal (oder auch dem gleichen) auf den Schirm holen (keine Sorge, Nutzername/Passwort werden noch zum Login benötigt). Dies funktioniert mit gewissen Kartentypen (Siehe condor:/etc/opt/SUNWut/smartcard) . Versuchen Sie zusätzliche Konfigurationsfiles zu schreiben, die in Deutschland verbreitete kontaktbehaftete Smartkarten (eGK, EC-Card) zu diesem Zweck nutzen.

Mentor: Jan-Peter Bell, Wolf Müller


Selbstauskunft "in-the-middle"

Nach der reinen Lehre über die Nutzung des neuen Personalausweises muss jeder (Dienstanbieter) der Datengruppen bzw. Funktionen aus dem nPA mit Hilfe der eID-Funktion nutzen will, ein gültiges Berechtigungszertifikat von der Vergabestelle vorweisen und einen eID-Server betreiben (oder den entsprechenden eID-Service anmieten). Das ist sicher etwas aufwändig. Geht es nicht etwas einfacher? Wenn man sich an der Lösung Sofortüberweisung orientiert, so könnte man auf die Idee kommen, einem Nutzer mittels "man-in-the-middle" quasi dabei über die Schulter zu schauen, wie er eine Onlineauthentisierung gegenüber einem Dienstanbieter mit Berechtigungszertifikat durchführt. Schreiben Sie eine App, die eine Piggyback-Authentisierung via den vom Bürgerportal der Stadt Würzburg angebotenen Dienst zur Selbstauskunft nutzt. Das Lesegerät für den nPA soll über Bluetooth mit dem nPA verbunden werden und der Leser soll eine eigenen PIN-Eingabe und Anzeige der Transaktion ermöglichen.

Links:


Rund um den eIDClientCore

Der eIDClientCore ist eine in Entwicklung befindliche Bibliothek, die die Kernfunktionalitäten für den Zugriff auf die eID-Funktion des neuen Personalausweises (nPA) und des elektronischen Aufenthaltstitels (eAT) bereitstellt.

GUI mit PIN-Management

Schreiben Sie ein portables GUI für den eIDCC, womit als erstes schon mal das PIN-Management (PIN-Neusetzen, ggf. PUK, ) realisiert werden kann.

Initialisierung, Signaturerstellung mit dem eIDClientCore

(Entwicklung nur in der BDr, Erfahrung mit Android notwendig!) Der neue Personalausweis ist als sichere Signaturerstellungseinheit vorbereitet. Um diese Funktion zu nutzen, kann ein QES-Signaturzertifikat passend zum auf der Karte generierten Schlüssel nachgeladen werden. In wieweit kann zumindest funktional, der eIDCC hierzu verwendet werden?

Links:

Mentor:


RSA-PSK Unterstützung für mod_ssl

Das Verschränken von kryptografisch mit SSL/TLS gesicherten Kanälen ist in vielen Webanwendungen wünschenswert. Bislang ist ein Handshake der einen "pre shared key" in Kombination mit RSA gemäß RFC 4279 bereitstellt, für openSSL nur als Patch (http://www.internet-sicherheit.de/service/tools/patches/) (auch für eine nicht ganz aktuelle Version) verfügbar. In dem Apachemodul mod_ssl ist diese Methode jedoch noch gar nicht vorgesehen. Hier wäre es sinnvoll, Ideen zu entwickeln, wie RSA-PSK hier Unterstützung finden kann.

Mentor:


Pseudonyme Signaturen mit dem nPA

In dem Paper "Domain-Specific Pseudonymous Signatures for the German Identity Card" wird ein Vorschlag gemacht, wie pseudonyme Signaturen dem (zukünftigen nPA) gemacht werden können. Das ermöglicht Signaturen mit dem nPA die nicht als QES angesehen werden, sondern eher zur Bestätigung oder Auslösung von Transaktionen genutzt werden können. Lesen und verstehen Sie die Ideen. Implementieren Sie dieses Protokoll, indealer Weise in OpenPACE.

Links:

Mentor:


Sichere Wiki-Konfiguration / Migration (Alexander)

Ein Wiki ist seiner Natur nach ein offenes System, in welchem der "Mitmachgedanke" weit vorne steht. Leider gibt es dann doch häufig automatisierte Angriffe, die diese Eigenschaft ausnutzen. So fand sich auch in unserm Wiki viel SPAM.

Versuchen Sie eine Kopie unseres Wikis auf eine aktuelle Codebasis zu heben. Dokumentieren Sie Ihre einzelnen Schritte. Treffen Sie eine begründete Auswahl an Zusatzpaketen zur Integration von Formeln, Bildern, ... und versuchen Sie eine möglichst sichere Konfiguration zu erreichen. Ansatzpunkte könnten die Verwendung von Captchas, sowie Beschränkungen zum anlegen von Nutzeraccounts sein.

Mentor: Wolf Müller, Wolfgang Gandre


UEFI Secure Boot

Setzen sie eine virtuelle Maschine auf, welche UEFI Secure Boot verwendet.

Alternativ/zusätzlich sind auch (U)EFI rootkits dieses Jahr ein heißes Thema:

Mentor:

AeroFS überwachen

Der "nicht-Cloud-Speicher" AeroFS speichert im Gegensatz zu Diensten wie Dropbox oder Wuala die Daten ausschließlich auf den eigenen Rechnern und synchronisiert zwischen diesen via LAN oder Internet verschlüsselt. Jedenfalls wird das behauptet. Man könnte sich anschauen, inwiefern es möglich ist, dieses Versprechen zu überprüfen.


Weitere kreative Vorschläge sind willkommen!
Viel Erfolg!
Kontakt: Wolf Müller
Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=W2014-ITS&oldid=11648"