W2015-ITS: Difference between revisions
m (Created page with "=Themenvorschläge für [https://sar.informatik.hu-berlin.de/teaching/2015-w/2015w_ITSecurityWorkshop/ IT-Security Workshop] 28. September bis 9. Oktober [https://sar.informatik.…") |
|||
Line 1: | Line 1: | ||
=Themenvorschläge für [https://sar.informatik.hu-berlin.de/teaching/2015-w/2015w_ITSecurityWorkshop/ IT-Security Workshop] 28. September bis 9. Oktober [https://sar.informatik.hu-berlin.de/teaching/2015-w/2015w_ITSecurityWorkshop/ 2015]= |
=Themenvorschläge für [https://sar.informatik.hu-berlin.de/teaching/2015-w/2015w_ITSecurityWorkshop/ IT-Security Workshop] 28. September bis 9. Oktober [https://sar.informatik.hu-berlin.de/teaching/2015-w/2015w_ITSecurityWorkshop/ 2015]= |
||
==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: |
|||
* [https://de.wikipedia.org/wiki/IEEE_802.1X 802.1X] |
|||
* [https://www.stunnel.org/index.html stunnel] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell] |
|||
==BSI TR-03108 Sicherer E-Mail-Transport== |
|||
Die Technische Richtlinie "Sicherer E-Mail-Transport" (BSI TR-03108) definiert konkrete Anforderungen an einen E-Mail-Diensteanbieter (EMDA). Ziel der Technischen Richtlinie ist die Erhöhung der Vergleichbarkeit und Verbreitung sicherer E-Mail-Kommunikation. Ziel bei diesem Thema ist es zu schauen, welche Schutzmaßnahmen für unseren Informatik-Mail-Server umgesetzt werden können. Hierbei geht es vor allem um technische Maßnahmen zur Absicherung eines authentischen und vertraulichen E-Mail-Transport. |
|||
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. Bezüglich DANE gibt es bereits Vorarbeiten aus dem letzten Jahr [[DANE für unseren Mail-Server]]. |
|||
Hinsichtlich der umsetzbaren organisatorischen und physischen Sicherheitsmaßnahmen wird es sicherlich Unterschiede zu gewerblichen E-Mail-Dienste-Anbietern geben, jedoch ist es sicherlich interessant, was sich an technischen Schutzmechanismen am Institut umsetzen lässt oder schon so in Betrieb ist. |
|||
Links: |
|||
* [https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03108/index_htm.html TR-03108] |
|||
* [http://www.heise.de/ct/heft/2014-11-DANE-verbessert-sicheren-Transport-zwischen-Mailservern-2228494.html C't 11/14 Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern] |
|||
* [http://tools.ietf.org/html/rfc6698 RFC 6698 DANE] |
|||
* [http://www.ietf.org/rfc/rfc4033.txt RFC 4033 DNSsec] |
|||
Mentor: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell], [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
|||
==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: [https://sar.informatik.hu-berlin.de/people/jan-peter_bell.htm Jan-Peter Bell], [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm 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 [http://www.bva.bund.de/cln_351/DE/Aufgaben/Abt__III/nPA/Vergabestelle/node.html?__nnn=true 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: |
|||
* [https://www.buergerserviceportal.de/bayern/wuerzburg/bspx_selbstauskunft Selbstauskunft] |
|||
* [https://www.sofort.com/ger-DE/sicherheit/ Sofortüberweisung] |
|||
==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: |
|||
* [http://link.springer.com/chapter/10.1007%2F978-3-642-33383-5_7 Domain-Specific Pseudonymous Signatures for the German Identity Card] |
|||
Mentor: |
|||
==Sichere Wiki-Konfiguration / Migration == |
|||
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: [https://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller], [https://sar.informatik.hu-berlin.de/people/wolfgang_gandre.htm Wolfgang Gandre] |
|||
==UEFI Secure Boot== |
|||
Setzen sie eine virtuelle Maschine auf, welche UEFI Secure Boot verwendet. |
|||
* OpenSUSE mit UEFI Secure boot in KVM: http://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm |
|||
* Secure Boot in Fedora: http://mjg59.dreamwidth.org/12368.html (allgemein gibt es in dem Blog viele Informationen zu Secure Boot) |
|||
Alternativ/zusätzlich sind auch (U)EFI rootkits dieses Jahr ein heißes Thema: |
|||
* https://program.sigint.ccc.de/fahrplan/system/attachments/24/original/efi_rootkits.pdf |
|||
* http://ho.ax/De_Mysteriis_Dom_Jobsivs_-_Syscan.pdf |
|||
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. |
|||
* https://www.aerofs.com/ |
|||
; Weitere kreative Vorschläge sind willkommen! |
|||
: Viel Erfolg! |
|||
: Kontakt: [http://sar.informatik.hu-berlin.de/people/wolf_mueller.htm Wolf Müller] |
Revision as of 11:28, 14 September 2015
Themenvorschläge für IT-Security Workshop 28. September bis 9. Oktober 2015
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
BSI TR-03108 Sicherer E-Mail-Transport
Die Technische Richtlinie "Sicherer E-Mail-Transport" (BSI TR-03108) definiert konkrete Anforderungen an einen E-Mail-Diensteanbieter (EMDA). Ziel der Technischen Richtlinie ist die Erhöhung der Vergleichbarkeit und Verbreitung sicherer E-Mail-Kommunikation. Ziel bei diesem Thema ist es zu schauen, welche Schutzmaßnahmen für unseren Informatik-Mail-Server umgesetzt werden können. Hierbei geht es vor allem um technische Maßnahmen zur Absicherung eines authentischen und vertraulichen E-Mail-Transport.
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. Bezüglich DANE gibt es bereits Vorarbeiten aus dem letzten Jahr DANE für unseren Mail-Server.
Hinsichtlich der umsetzbaren organisatorischen und physischen Sicherheitsmaßnahmen wird es sicherlich Unterschiede zu gewerblichen E-Mail-Dienste-Anbietern geben, jedoch ist es sicherlich interessant, was sich an technischen Schutzmechanismen am Institut umsetzen lässt oder schon so in Betrieb ist.
Links:
- TR-03108
- C't 11/14 Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern
- RFC 6698 DANE
- RFC 4033 DNSsec
Mentor: Jan-Peter Bell, Wolf Müller
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:
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
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.
- OpenSUSE mit UEFI Secure boot in KVM: http://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm
- Secure Boot in Fedora: http://mjg59.dreamwidth.org/12368.html (allgemein gibt es in dem Blog viele Informationen zu Secure Boot)
Alternativ/zusätzlich sind auch (U)EFI rootkits dieses Jahr ein heißes Thema:
- https://program.sigint.ccc.de/fahrplan/system/attachments/24/original/efi_rootkits.pdf
- http://ho.ax/De_Mysteriis_Dom_Jobsivs_-_Syscan.pdf
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