FeM

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

Der Anschluss des Glasfaserkabels ist heute erfolgt und die Switche wurden eingerichtet.

Weitere Informationen für studentische Bewohner gibt es unter der Mailadresse admin@fem.tu-ilmenau.de

Der FeM DHCP Server läuft in zwei virtuellen Maschinen, wobei sich corosync+pacemaker um das Failover kümmern. Im Fehlerfall wird also zunächst die IP und dann der dhcpd auf die andere VM umgezogen. Es wird also für den DHCP-Server nur eine IP je VLAN benötigt.

Die beiden virtuellen Maschinen haben dafür je zwei Netzwerkkarten. Die erste Netzwerkkarte bekommt alle VLANs und wird nur für DHCP genutzt, auf der zweiten Netzwerkkarte liegen die für die Verwaltung genutzen VLANs an, damit die beiden VMs einzeln und unabhängig vom Failover-Status erreichbar sind. Dabei liegt ein VLAN auf beiden Netzwerkkarten an - in diesem VLAN gibt es je eine IP für die beiden VMs sowie die DHCP-Server-IP.

Dem DHCP Server wurde beim Start als Kommandozeilenoption mitgegeben, dass er nur VLAN-Interfaces der ersten Netzwerkkarte DHCP bereit stellen soll. Das funktionierte auch prima, nur einige Clienten in dem auf beiden Netzwerkkarten verfügbaren VLAN hatten Probleme, ihr Lease zu verlängern.

Es stellte sich heraus, dass bei der Verlängerung eines Leases im dafür gesendeten DHCP-Request das Feld Client-IP gesetzt ist. Dies bewirkt, dass der DHCP Server das Paket nicht über ein SOCK_PACKET Interface direkt auf eine Netzwerkkarte schreibt, sondern das Paket durch den IP Stack des Linux Kernels sendet. Dabei entscheidet jedoch der Kernel selbstständig über die Quell-IP und Quell-MAC des ausgehenden Paketes. Die Antwort kam also mit der MAC und IP der zweiten Netzwerkkarte an. Dies führte dazu, dass die neueren Switche in der FeM diese Pakete gefiltert haben, der Client also keine Antwort bekam. Mit Ablauf der Lease-Zeit gibt dann der Client auf und versucht, ein neues Lease zu beantragen - was dann auch klappt, da das Feld Client-IP dabei nicht gesetzt ist.

Die beiden VMs waren mittels Policy-Routing bereits so eingestellt, dass je nach Quell-IP automatisch das passende Interface gewählt wird.
Außerdem war das Server-ID Feld in der DHCP Antwort immer auf die (korrekte) IP der ersten Netzwerkkarte gesetzt. Eine Lösung hätte also vermutlich darin bestanden, dass der ISC DHCP Server das Socket vor dem Versenden an die richtige IP bindet und Linux dann automatisch die richtige Netzwerkkarte auswählt.

Definitiv funktionieren und hier eingesetzt wird jedoch eine andere Variante.

Zunächst wird eine zusätzliche Routingtabelle "dhcp" in /etc/iproute2/rt_tables eingetragen. Dann werden alle ausgehenden DHCP Pakete mittels iptables -A OUTPUT -t mangle -p udp --sport 67 -j MARK --set-mark 1 markiert und dann mit ip rule add fwmark 1 table dhcp entsprechend der neuen Routing-Tabelle versandt.
In die DHCP Routing-Tabelle wird nun für alle Netze, in denen DHCP bereit gestellt wird, die passende Regel eingefügt: ip route add $Subnetz dev $Netzwerkkarte table dhcp Dies stellt sicher, dass die Pakete auf der passenden Netzwerkkarte versandt werden.
Allerdings sind die Pakete immernoch mit der falschen Quell-IP unterwegs.
Dies lässt sich mit einem beherztem iptables -A POSTROUTING -t nat -o $Netzwerkkarte -s $Subnetz -j SNAT --to-source $Richtige-DHCP-Server-IP korrigieren.

Et voilà, schon kommen die Antworten mit passender MAC und IP beim Client an.

Das Glaskabel zur Anbindung des neuen Gebäudes ist nun schon seit einigen Wochen verlegt. Leider haben wir immernoch keinen konkreten Termin, wann das Glaskabel angeschlossen werden kann. Da für dieses Anschließen (auch Spleißen oder Aufpatchen genannt) teure Spezialtechnik benötigt wird, können wir es leider auch nicht so ohne weiteres selber machen.

Das Technikteam hat sich daher dazu entschlossen, das neue Gebäude übergangsweise per Funk anzuschließen. Die dafür notwendigen Arbeiten sind für den kommenden Montag, den 28. Oktober geplant. Sofern alles gut geht, gibt es danach dort FeM-Net. Natürlich arbeiten wir weiter mit Hochdruck daran, dass das Glaskabel angeschlossen wird.

Update: Wegen des Unwetters ist der Anschluss leider noch nicht erfolgt. Wir arbeiten aber daran.

Update: Der Anschluss des Glaskabels wird voraussichtlich am kommenden Freitag, den 1. November 2013, erfolgen.

Im Rahmen der Umstellung auf die neue Verwaltungsdatenbank AdminDBv2 - welche für das FeM CampusWLAN benötigt wird - wird am kommenden Montag auch das MyInfo auf die neue Infrastruktur umgestellt.

Das bringt euch folgende neuen Features im MyInfo:

• Änderung der WLAN-Passwörter im MyInfo,
  
• optionale individuelle Traffic-Statistiken (derzeit nur IPv4),
  
• online ausfüllbare Geräte-Anmeldeformulare im MyInfo,
  
• englischsprachige Übersetzung der wichtigsten Seiten.
  

Nachdem nun das OtherConfig=yes - Flag bei der FeM eingeschaltet ist, gibt es hier nun die ersten Erfahrungen.