FeM

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.

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.

In den kommenden Wochen wird die Konfiguration von Rechnern für die ausschließliche Nutzung von IPv6 im FeM-Net stark vereinfacht. Dazu wird unser Gateway in den Router Advertisments in allen Blöcken das "Other Configuration" - Flag setzen. Es bewirkt, dass eure IPv6-fähigen Computer sich automatisch per DHCPv6 die IPv6-Adressen der FeM-Namensserver und FeM-NTP-Server holen. Der Vorteil: Sollte ein Rechner nur mit IPv6-fähigen Servern kommunizieren wollen, kann er nun alle dafür nötigen Schritte über IPv6 abwickeln und braucht so keine IPv4-Adresse mehr, ohne dass der Administrator die IPv6-Adressen der FeM-Namensserver und FeM-Zeitserver manuell einstellen müsste.

Mehr zum Thema DHCPv6 gibt es im Artikel http://blog.fem.tu-ilmenau.de/archives/871-IPv6-Only-Netz-mit-DHCPv6.html .

Update: Seit 2013-10-15 umgesetzt.

Dieser Artikel soll kurz in die Verwendung von PGP mit Thunderbird einführen.
Mehr Informationen gibt es u.a. auf http://www.thunderbird-mail.de/wiki/Enigmail_OpenPGP