FeM

Der WLAN-Ausbau auf dem Campus schreitet voran. Nach und nach werden die AccessPoints geliefert, die Software installiert und die Geräte verbaut.

Dafür sind wir auf eure Mithilfe angewiesen, da die AccessPoints in den Fluren der WGs installiert werden sollen! Wir werden euch daher in den kommenden Zeit bei Bedarf persönlich ansprechen oder anschreiben, sofern in eurer WG ein AccessPoint installiert werden soll.

Derzeit ist das Haus I an der Reihe. Außerdem gibt es in den Studentenclubs, im Keller des Haus A, im Interclub, im Haus P, im FeM-Office sowie bei einigen Administratoren bereits FeM-WLAN.

Die Authorisierung von Anfragen einloggter Nutzer erfolgt in Webanwendungen sehr oft mit Hilfe von Sitzungscookies.

Kann ein Angreifer ein solches Ausspionieren oder erraten, kann er oft die gesamte Sitzung des eingeloggten Nutzers übernehmen und mit seinen Rechten die Webanwendung / Webseite nutzen.

Derartige Angriffe sind in der Vergangenheiten manigfaltig dokumentiert worden. Ein erster Schritt zum Schutz der Sitzungscookies ist die Nutzung von HTTPS.

Die Nutzung von HTTPS reicht jedoch nicht in allen Fällen aus, wie die BEAST, CRIME und BREACH Angriffe zeigen.

Angenommen, man möchte einen LAN-Anschluss bereit stellen, an welchem sich die Nutzer zunächst mit 802.1X authentifizieren müssen, und danach das passende VLAN bereit gestellt bekommen.
Bei der FeM bespielsweise an den APs für Veranstaltungsstreaming.

Die dafür notwendigen Änderungen am Linux-Kernel, an Bibliotheken und am hostapd finden sich nun auf http://git.fem.tu-ilmenau.de

• libnl: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/libs/libnl/patches/0001-macvlan-add-support-for-source-mode.patch;h=4572e10f54bf809bdd3659bcda220d81dfbff63e;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• iproute2: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/network/utils/iproute2/patches/999-iproute2-macvlan-add-source-mode.patch;h=0abcb39925efa12485fe0df2b5535eebbf6ab89c;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• linux kernel: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=target/linux/generic/patches-3.10/998-add-macvlan-source-mode.diff;h=3862d393f19fd1b5e342024b8f15d7ca4bf9c0d2;hb=6400346de8c49e2b45c6acaa2534f972921f75b9
  
• hostapd: http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/network/services/hostapd/patches/905-add-wireng-vlan-driver.diff;h=d34519710e069eff9e86f3a4abda63f12217356f;hb=2ba3eff2d9ed3e573055bf8b1835b0da9265e7d1
  

Einrichtung im hostapd:

interface=eth2
driver=wired-ng

ieee8021x=1

# RADIUS
auth_server_addr=1.2.3.4
auth_server_shared_secret=MySharedPasswd

# VLAN
dynamic_vlan=2
vlan_tagged_interface=vpnuplink
vlan_bridge=brvlan


Die Deauthentifizierung erfolgt bei timeout oder wenn der Port offline geht.

Seit einigen Jahren ist der sogenannte DNS-"ReBind"-Angriff bekannt. Dabei wird ausgenutzt, dass im DNS unerwartete IP-Adressen eingetragen sind, und kann dazu genutzt werden, beispielsweise eine Firewall oder andere Zugriffskontroll-Maßnahmen zu umgehen. Datails dazu unter [1] oder [2] und anderen.

In der Folge kann es ratsam sein, dagegen schützende Filter im lokalen DNS Server einzurichten. Eine andere Möglichkeit besteht darin, den Filter im Browser einzurichten - beispielsweise mit der Firefox-Erweiterung NoScript und ihrem Feature Application Boundary Enforcer (ABE).

WPA-PSK wird nur für Heimnutzer empfohlen, da alle Geräte an einem AccessPoint das gleiche Passwort verwenden - was im Kontext großer Organisationen jedoch nur unzureichende Sicherheit bietet.

• So kann jeder Teilnehmer einen eigenen AccessPoint aufsetzen, welcher mit allen anderen Geräten eine Verbindung aufbaut (AP Impersonation), da jeder Teilnehmer das gemeinsame Geheimnis kennt. Dies kann zur Überwachung und Man-In-The-Middle Angriffen genutzt werden.


• Weiterhin muss bei Änderungen der Gruppe der Berechtigten allen Teilnehmern ein neues Passwort mitgeteilt werden


• und es kann über die verwendeten Zugangsdaten nicht mehr rekonstruiert werden, welcher Nutzer ein bösartiges Gerät genutzt hat.

Für größere Organisationen wird daher WPA-EAP empfohlen, welches neben unbestreitbaren Vorteilen jedoch auch Nachteile hat. Der größte Nachteil ist in meinen Augen, dass beim Einsatz von TTLS-PAP Passwörter ausspioniert werden können sowie AP-Impersonation möglich ist, sofern auf dem Gerät das CA-Zertifikat nicht eingerichtet wurde (oder der Angreifer ein gültiges Server-Zertifikat besitzt). Der Einsatz von TTLS empfiehlt sich jedoch, wenn die Nutzeridentität gegenüber dem AP-Netzbetreiber anonym bleiben soll.

Weniger bekannt ist die Möglichkeit, WPA-PSK mit geräte-spezifischen Zugangsdaten zu betreiben. Dabei wird auf dem AccessPoint jedem Client ein eigenes Passwort zugeordnet, die Identifikation erfolgt anhand der MAC-Adresse des Gerätes. Eine solche Konfiguration wird beispielsweise von hostapd unterstützt, welches in neueren Versionen die WPA-Passphrase auch mittels RADIUS (Tunnel-Passwort Attribut) abfragen kann sowie mehrere Passwörter je Gerät (beispielsweise für mehrere Nutzer) unterstützt. Weiterhin ist es auch möglich, den gleichen Satz Passwörer für alle MAC-Adressen zu erlauben - und so die Vorregistrierung der Geräte überflüssig zu machen und doch nutzerspezifische Passwörter zu verwenden. Nicht implementiert - aber prinzipiell möglich - wäre es sogar, weitere Einstellungen (beispw. VLAN) abhängig von der verwendeten Passphrase anzupassen.

Vorteile:

• Keine Fehlkonfiguration am Client möglich - es wird nur die Passphrase für WPA-PSK benötigt.
  
• Automatischer Schutz vor AP-Impersonation und damit ggf. verbundenem Passwortausspionieren, Netzwerküberwachung und Man-In-The-Middle angriffen.
  

Der vielleicht wichtigste Nachteil dabei ist jedoch, dass das Passwort (im Klartext) an jeden der AccessPoints übermittelt werden muss - ein kompromitierter AccessPoint also die WLAN-Zugangsdaten ausspionieren könnte.

Die hostapd-Implementierung für die Übertragung des PSK mittels RADIUS einschließlich der Unterstützung mehrerer PSKs je Gerät ist übrigens im Rahmen des FeM WLAN Projektes entstanden.

DNS (Domain Name System) ist ein sehr wichtiger Bestandteil des Internets. Mit DNS finden unsere Browser heraus, welchen Webserver sie für eine Webseite kontaktieren müssen, und die Mailserver, an welchen Server Post gesendet werden soll. Auch viele andere Dienste wie beispielsweise Chat, Fernwartung, Spam-Erkennung oder VPN nutzen oft DNS, um die Adressen der jeweiligen Server heraus zu finden.

DNS hat viele Vorteile, darunter Lastskalierung und eine in weiten Teilen dezentraler Aufbau, jedoch auch Schwächen. Dazu zählt, dass die übertragenen Informationen nicht kryptografisch signiert sind - also Manipulationen nicht erkannt werden können. Manipulationen können dabei beispielsweise durch gefälschte Pakete, kompromitierte Nameserver oder Schadsoftware, welche Einstellungen auf AccessPoints und Routern verstellt, erfolgen. Mitunter passieren solche Manipulationen jedoch auch ganz offiziell und sind ggf. sogar erwünscht - beispielsweise wenn der Zugangsanbieter bei Tippfehlern den Browser automatisch auf eine Suche umleitet.

Mit DNSSEC wurde das DNS um krytografische Signaturen (Unterschriften) ergänzt, sodass interessierte Rechner überprüfen können, ob die erhaltenen Informationen korrekt sind. Dabei wurde das System abwärtskompatible gestaltet, sodass sich der Inhaber einer Domain auch dazu entscheiden kann, diese unsigniert zu lassen - beispielsweise weil es für seinen Anwendungsfall überflüssig ist. Möchte der Domaininhaber seine Domain jedoch signieren, benötigt er DNSSEC-fähige Nameserver, welche seine DNS-Einträge samt ihrer Signaturen verteilen.
Derzeit gibt es sehr wenige Anbieter (wenn überhaupt), welche DNSSEC-fähige Nameserver zur Miete anbieten. In der Folge muss jeder, der eine mit DNSSEC-signierte Zone betreiben will, sich nicht nur um die Erzeugnung der Signaturen und die Verwaltung der Schlüssel kümmern, sondern auch noch mehrere Nameserver entsprechend den Vorgaben der jeweiligen Registry vorhalten.

Für die FeM hat sich das neu gegründete Projekt DNS-Hosting das Ziel gesetzt, solche DNSSEC-fähigen Nameserver (für die Zone fem-net.de) zu betreiben. Dabei geht es explizit nicht darum, als Registrar tätig zu werden.

Seit der Umstellung auf die neue Verwaltungsinfrastruktur werden außerdem den Rechnern in der FeM Nameserver ausgeteilt, welche die DNSSEC-Signaturen überprüfen und weiterreichen, sodass auch andere Rechner in der FeM diese überprüfen können und Rechner, welche dies nicht können, dennoch keine gefälschten Antworten (sofern die Zone signiert war) erhalten.

Wie derzeit der Presse zu entnehmen ist, interessieren sich diverse Stelle nicht nur für die Kommunikationsinhalte sondern vor allem auch für die zugehörigen sozialen Netzwerke - also wer kommunziert mit wem und wieviel.

Nutzt man nun eine klassischen eMail-Provider, können diese Soziales-Netzwerk-Informationen - auch bei der Verwendung verschlüsselter eMails - dort gebündelt abgegriffen werden. Gleichzeitig sichert die Verwendung eines großen Providers bei der Überwachung der verschlüsselten Verbindung zum / zwischen Providern ein wenig die Privatssphäre, weil nur ersichtlich ist, dass mit/zwischen den Providern Daten ausgetauscht worden ist. Weiterhin ist für Otto-Normal-Angreifer auch über die Domain nicht sofort Name und Anschrift des Kommunikationspartners ersichtlich.

Möchte man nun die Zugriffsmöglichkeit des Providers beseitigen, läuft es darauf hinaus, entweder vor dem Provider seine Identität zu verbergen (was die meisten nicht erlauben), oder einen eigenen Mailserver zu betreiben. Allerdings erlauben viele TOR Exit-Nodes derzeit nicht die Kommunikation auf TCP Port 25 (SMTP), sodass die eMails darüber nicht unbeobachtet zugestellt werden können. Außerdem wäre in diesem Fall der Einsatz von TLS und Zertifikatsüberprüfung erforderlich, damit der Exit-Knoten nicht mitlesen kann - mit den ganzen Problemen, die sich bei der Überprüfung der Zertifikate ergeben.

Alternativ könnte man für eingehende Post den Mailserver als Hidden-Service im Tor-Netzwerk erreichbar machen [1] und sich so das TLS und die Zertifikatsüberprüfung ersparen. Dabei muss man aber unter Umständen darauf achten, dass nicht der Mailserver oder Client selbst schon zu viele Informationen über die Identität preis gibt, wenn die Identitäten dabei auch gegenseitig deheim gehalten werden sollen. Weiterhin kann die Adresse nur genutzt werden, wenn sowohl Empfänger als auch Absender über TOR eMails austauschen können. Zudem dürfte eine @<HiddenService>-eMail-Adresse schwer zu merken sein.

Um die Erreichbarkeit im Tor-Netzwerk zu vereinfachen, könnte man jedoch die .onion-Adresse des Hidden-Service als zusätzlichen MX-Eintrag ins DNS eintragen. Dann könnten alle Teilnehmer weiterhin die klassischen Domains verwenden, TOR-kompatible Systeme aber eine Zustellung mittels Tor-Netzwerk vornehmen, ohne dass nicht-TOR-fähige Systeme ausgeschlossen wären. Dabei wäre zu beachten, dass die Namensauflösung ebenfalls über Tor erfolgen muss und die Antwort mittels DNSSEC überprüft werden sollte, um Manipulationen und Abhörtätigkeiten auszuschließen.

Problematisch wird in diesem Zusammenhang die Spam-Erkennung anhand von IP-Blacklisten bezogen auf das einliefernde System. Dies ist jedoch auch schon mit IPv6-PrivacyExtension-Adressen der Fall und führt dazu, dass SPAM vermehrt mit anderen Methoden (Schlagworte im Inhalt, DKIM, gpg-Absenderprüfung) erkannt werden muss.

Um die Antworten des DNS mittels DNSSEC überprüfen zu können, sind DNSSEC fähige DNS-Server - sowohl bei der Bereitstellung der Zone als auch bei der Namensauflösung - erforderlich. Um die Bereitstellung von DNSSEC-signierten Zonen zu vereinfachen, wurde in der FeM das Projekt DNS-Hosting ins Leben gerufen, welches sich zum Ziel gesetzt hat, DNSSEC-fähige Nameserver u.a. für die Zone fem-net.de zu betreiben.

Um nun seinen eigenen Mail-Server anonym für den Empfang und Versand von Post zu erreichen, kann man auf dem ohnehin laufenden Tor-Client einen weiteren Hidden-Service einrichten und diesen den passenden Dienst bereitstellen lassen. Dessen Adresse schreibt man sich dann aber doch besser auf, um die eigene Anonymität beim Abruf der eMails nicht zu gefährden - andernfalls könnte der Zugangsanbieter wo möglich aus der verwendeten Domain auf die eigene Person schließen. Damit wäre jedoch noch nicht preis gegeben, wer mit wem kommuniziert hat.

Verwandte Ansätze:

• http://tormail.org/
  
• https://groups.google.com/forum/#!msg/alt.privacy.anon-server/75_ayzjJaeY/tn5QFr1isGoJ
  
• http://www.danner-net.de/om.htm
  

[1] http://johannes.sipsolutions.net/Projects/exim-tor-hidden-mail?action=AttachFile&do=get&target=whitepaper.pdf

Derzeit zahlt ihr euren FeM-Mitgliedsbeitrag mittels Überweisung oder Lastschrift. Die "normalen" Lastschriften werden jedoch Anfang des kommenden Jahres eingestellt, sodass wir bis dahin auf die Nutzung von SEPA-Lastschrift umstellen müssen. Überweisungen können - müssen jedoch nicht - noch bis vorr. 2016 funktionieren (abhängig von den Konditionen deiner Bank), indem deine Bank diese dann selbstständig in SEPA-Überweisungen umwandelt.

Was ändert sich dabei für euch?

1. Aus Kontonummer und Bankleitzahl wird IBAN (Internation Bank Account Number) und BIC (Bank Identifier Code).
   
2. Aus Abbuchungs-, Einzugs- oder Lastschrift-Ermächtigungen werden sogenannte SEPA-Mandate. Jedes Mandat hat eine eindeutige Nummer (Mandatsreferenz).
   
3. Alle Abbuchungen werden euch einzeln oder gebündelt vorher angekündigt - mit konkretem Zahlungstermin. Bei der FeM wird dies per eMail passieren.
   
4. In jeder Abbuchung wird die Gläubiger-Identifikationsnummer (CI), die Mandatsreferenz sowie eine eindeutige Zahlungs-Identifikationsnummer (optional) angegeben, mit der die Zahlungen eindeutig einer Firma oder Verein, einem Vertrag oder einem Vorgang zugeordnet werden können. Dies ermöglicht es eurer Bank, euer Konto besser gegen unbefugt Abbuchungen abzusichern und vereinfacht die automatisierte Verarbeitung von Zahlungen.
   
5. Das SEPA-Lastschriftverfahren ist auch mit Konten von Banken im europäischen Ausland (SEPA-Zahlungsraum) möglich. http://de.wikipedia.org/wiki/Einheitlicher_Euro-Zahlungsverkehrsraum
   

Die neue IBAN (SEPA-Kontonummer) und BIC (SEPA-Bankleitzahl) sowie die Gläubiger-Identifikationsnummer der FeM findet ihr auf http://fem.tu-ilmenau.de/index.php?id=379.

Die Mandatsreferenz wird euch zusammen mit der Ankündigung der Abbuchung per eMail mitgeteilt.

Alle bestehenden Lastschrift-Ermächtigungen bleiben erhalten und werden von uns automatisch in SEPA-Mandate umgewandelt. Dies wird voraussichtlich am 5. Dezember 2013 passieren. Ab diesem Zeitpunkt werden wir für neue Mitglieder sowie bei der Änderung der Bankverbindung nur noch SEPA-Mandate akzeptieren, ihr könnte alte Formulare also entsorgen oder löschen. Die neuen Formulare gibt es ab dem 5. Dezember 2013 auf http://fem.tu-ilmenau.de/index.php?id=72 .

Für Fragen wende dich an admin@fem.tu-ilmenau.de oder nutze das Formular.