FeM Blog - Technik

HowTo enable WiFi roaming with hostapd and VLANs

nospam@example.com (Michael Braun) — Tue, 03 Nov 2015 21:13:00 +0100

A WiFi client is usually connected to an AccessPoint for WPA-protected network access. When the AccessPoint becomes unreachable for example as the client moved, the client needs to switch over to an other AccessPoint providing the same extended service set (ESSID). This is called roaming.

Roaming involves the following steps:

Scanning for an other reachable AccessPoint (Probe)
Disconnect from the old AP
Changing the WiFi-channel
Authentication and Association
WPA-EAP-Handshake (only for 802.1X)
4-way WPA handshake
Connection is ready again

These steps need time and the client is disconnected until he completed them, but there are some options available to speed things up: "HowTo enable WiFi roaming with hostapd and VLANs" vollständig lesen

Accepting expired client certificates with apache 2.4

nospam@example.com (Michael Braun) — Fri, 30 Oct 2015 19:16:37 +0100

Some time ago, we enabled IPv6 on our internal database webserver. The PHP application running bound its sessions to the client IP address. The local clients configured its IPv6 address using IPv6 auto-configuration with privacy-extensions enabled. This lead to IPv6 clients sometimes changing its IPv6 address used with the connection to the web server, so they could no longer use their session and thus were logged off.

The solution was to install SSL client certificates, so clients could reliably be identified even across different IPv6 privacy extension addresses. These client certificates were automatically generated and signed by a local CA using HTML <keygen> and PHPseclib and only served to identify the browser instance.

Now these client certificates started to expire.

As our Firefox users had not cleared the "Remember this decision" flag when choosing their single client certificate to connect with, Firefox 41 continued to connect using an expired certificate. The "auto select client certificate" in Firefox does not do any better, thought. When the server rejects an SSL client certificate with ssl_error_expired_cert_alert, Firefox shows an error message to the user but does not offer him to reselect an other client certificate. So users started to puzzle about how to fix this error. Even installing a renewed client certificate (same subject, issuer and public key) ahead of expiration into Firefox 41 does not help, as that does not remove the old certificate which is still chosen for connecting with.

So the only place to fix this is the server. On server side, the list of accepting CAs could be changed. Though Firefox code looks like in "auto select client certificate" mode this would work, the "use remembered client certificate" lacks any client certificate issuer check. So this does not look promising (see ClientAuthDataRunnable::RunOnTargetThread), though it has not been tested. Next, trying to configure apache 2.4 (Debian Jessie) to accept expired client certificates (while still requesting - at least optionally - one) turns out to be impossibly. There just is no such option. Thought, patching and recompiling apache2 was to be avoided as the server should still be able to install Debian security updates without much manual intervention.

After digging through the source of apache 2.4 mod_ssl, it appears that it is making heavy use of OpenSSL certificate validation routines to check client certificates - including the expiration checks (in contrast to https proxy server certificate validation, where expiration time is checked in mod_ssl itself). Specifically, it uses ssl_callback_SSLVerify with SSL_set_verify to ignore some verification errors already.

LD_PRELOAD is a mechanism to load a shared library early during linking (starting) of an applicaton (like apache2). The linker will the prefer the functions provided by LD_PRELOAD libraries over those libraries indicated by the application itself - so it can be used to hook into library function calls. By writing a specifically crafted LD_PRELOAD library, SSL_set_verify can be hooked and the callback replaced. The new callback will filter out any X509_V_ERR_CERT_HAS_EXPIRED error before passing back control to the original ssl_callback_SSLVerify callback.

LD_PRELOAD can the be configured in /etc/apache2/envvars (used by apache2ctl and thus Debian init scripts) to load the new library.



# mysslverify.c

// gcc -Wall -D_GNU_SOURCE -fPIC -DPIC -shared -ldl -o mysslverify.so mysslverify.c

// use with LD_PRELOAD=/.../mysslverify.so



#include <openssl/ssl.h>

#include <dlfcn.h>



void (*orig_SSL_CTX_set_verify)(SSL_CTX *ctx, int mode, int (*verify_callback)(int, X509_STORE_CTX *)) = NULL;

void (*orig_SSL_set_verify)(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *)) = NULL;

int (*orig_verify_callback)(int, X509_STORE_CTX *) = NULL;



int verify_callback(int ok, X509_STORE_CTX *ctx) {

  if (!ok && X509_STORE_CTX_get_error(ctx) == X509_V_ERR_CERT_HAS_EXPIRED) {

    X509_STORE_CTX_set_error(ctx, X509_V_OK);

    ok = !ok;

  }

  return orig_verify_callback(ok, ctx);

}



void SSL_CTX_set_verify(SSL_CTX *ctx, int mode, int (*cb)(int, X509_STORE_CTX *)) {

  if (orig_verify_callback == NULL) orig_verify_callback = cb;

  if (cb != NULL && cb == orig_verify_callback) cb = verify_callback;

  if (!orig_SSL_CTX_set_verify) orig_SSL_CTX_set_verify = dlsym(RTLD_NEXT, "SSL_CTX_set_verify");

  orig_SSL_CTX_set_verify(ctx, mode, cb);

}



void SSL_set_verify(SSL *s, int mode, int (*cb)(int, X509_STORE_CTX *)) {

  if (orig_verify_callback == NULL) orig_verify_callback = cb;

  if (cb != NULL && cb == orig_verify_callback) cb = verify_callback;

  if (!orig_SSL_set_verify) orig_SSL_set_verify = dlsym(RTLD_NEXT, "SSL_set_verify");

  orig_SSL_set_verify(s, mode, cb);

}

Neuer Backup-Server für die FeM

nospam@example.com (Michael Pfeiffer) — Sun, 26 Apr 2015 21:04:08 +0200

In den letzten Monaten war im Technik-Team der Gedanke gereift, dass zumindest der Ältere unserer beiden Backup-Server in Jahre gekommen ist, und so langsam einmal ersetzt werden sollte. Zudem war er auch vom Energieverbrauch her (bedingt durch den Pentium 4-Prozessor) nicht mehr sinnvoll weiterzubetreiben.

Da das Problem durch Abwarten offensichtlich nicht zu lösen war, wurde ein neuer Backup-Server bestellt, und am 15.4.2015 in einem Betriebsraum im Haus L verbaut. Im Unterschied zum vorherigen Backup-System, der mit einem Gentoo-Linux betrieben wurde, läuft auf dem neuen Server ein FreeBSD, so dass ZFS als Dateisystem benutzt werden kann. Der neuen Server stellt ca. 7 TB Speicherplatz mit doppelter Parität zur Verfügung, was bedeutet, dass von den 6 Datenplatten zwei ausfallen dürfen, ohne dass Daten verloren gehen. Bisher liefern der Mail-Server, der Jabber-Server und die AdminDB ihre Backups per SSH und FTP auf dem System ein. Wenn im Laufe der nächsten Wochen alle Dienste migriert sind, wird der alte Backup-Server abgeschaltet.

Der neue Backupserver (oben), der Vorgänger (Mitte), die zugehörige USV (unten)

Noch ein paar Daten und Fakten zum neuen System:

CPU: Intel Xeon E3-1231 v3

RAM: 16 GiB ECC DDR3

Betriebssystem-HDD: 2x 160 GB (gespiegelt)

Daten-HDD: 6x 2 TB (RAIDZ2)

Netto-Speicherkapazität: 7 TB

Betriebsystem: FreeBSD 10.1

Admins: Bammes, Michael

Zuse-Uplink-Migration am 24.02.2015

nospam@example.com (Michael Pfeiffer) — Wed, 04 Mar 2015 15:31:40 +0100

Pünktlich zu Heiligabend am 24.12.2014 war unser Switch im Zuse-NSP (Cisco WS-C3750G-24) ausgefallen. Dieser stellte den Uplink für alle vom Internet aus erreichbaren FeM-Dienste (Websites, E-Mail, Jabber, ...) zur Verfügung, welche damit nicht erreichbar waren. Bedingt durch die Feiertage konnten wir erst am 29.12. den defekten Switch durch eine spontane Leihgabe des Rechenzentrums ersetzen. Für uns ein Grund mehr, die schon länger fällige Migration in einen anderen Netzbereich des RZs anzugehen.

Am 24.02. um 13:00 wurde dann der Leih-Switch wieder ausgebaut und an das Rechenzentrum zurückgegeben. Die Server im Zuse-NSP wurden umgepatcht und stecken nun direkt auf einer Linecard eines Cisco 4500 des RZs. Dadurch steigt auch die Geschwindigkeit der Anbindung unserer Server von 1 Gigabit auf 2x10 Gigabit. Zeitgleich mussten auch im Medienlabor 2 einige Server, die IP-Addressen aus demselben Subnetz besitzen, migriert werden. Um 13:28 waren die Dienste im Großen und Ganzen wieder verfügbar, und kurz darauf waren auch alle verbleibenden Ruckler beseitigt.

Beteiligte: Bammes, Texec, Pegro, Rafi, Meineeiner, Michael

Hier stecken die Server noch auf dem geliehenen Switch...

Umpatchen auf das Patchpanel.

Ohne Plan is nix... (Bammes und Texec)

Männer, die auf Server starren... (Pegro, Meineeiner, Bammes)

Goodbye Cisco - Der Auswanderer

nospam@example.com (Philipp Teutsch) — Mon, 01 Dec 2014 22:42:00 +0100

Cisco-Umzug 24./25. November 2014

In der Nacht vom Montag den 24.11.14 auf Dienstag den 25.11.14 wurde der Kernrouter des
FeM-Netzes aus dem Block M in den Block H umgezogen.

Hintergrund: Beweggrund für den (temporären) Umzug ist der geplante

Einbau eines Fahrstuhls in den Block M, bei welchem die Wand, neben der der Cisco bislang stand,
durchbrochen werden muss. Um nun die empfindliche Netzwerktechnik diese Bauarbeiten
unbeschadet überstehen zu lassen, ist diese nun vorübergehend im H-Betriebsraum untergebracht
(genau genommen "übergebracht", da er nun über den sich dort befindenden
Servern hängt).

Der eigentliche Umzug:
Die FeM-Mitglieder wurden zuvor per E-Mail darauf hingewiesen, dass es in der Nacht von Montag auf Dienstag
ab 00:00 Uhr zu einem Netzausfall kommen würde, der sich auf einen
Zeitraum von ca. 3-4 Stunden erstreckt.

Gegen
22:40 trudelten so langsam alle Helfer im FeM-Office ein. Die üblichen
Verdächtigen waren schon fleißig am Werkzeug zusammensuchen,Doku ausdrucken etc..

Ziemlich genau um 23:00 Uhr trafen wir am Block M ein, der uns, dank des zuvor informierten Wachschutzes, offen stand.
Flib und hebbet begannen einige Block - Cisco Steckverbindungen zu dokumentieren, um später Zeit zu sparen. Die
günstige Gelegenheit, das Campusnetz auseinander zu nehmen wurde auch
gleich dazu genutzt, um diverse Strecken auf ihre 10GE-Fähigkeit zu
testen. Hierzu bereiteten Gerbi, Rafael und Meineeiner unter der
Anleitung von Pegro zwei HP 3800 Switches als "Paketbeschleuniger"[0] vor, um die tatsächlich vorhandene
Bandbreite zu testen und sich nicht nur auf das Aufleuchten der Link-LED zu verlassen.

Als das eigentliche Abpatchen begann, zeigte die Uhr gerade 23:57 Uhr.
Parallel dazu wurden die restlichen Steckverbindungen dokumentiert und die Patchkabel fein säuberlich aufgerollt.
Einer der beiden 38er Switche war bereits in Position gebracht und der zweite wurde um 00:02 von
Pegro, Rafael und Anton in den K-Betriebsraum verfrachtet.

Unterdessen
kümmerte sich Gerbi um das Verkabeln zweier Laptops, die als Paketquelle und -senke für die 10GE-Tests herhalten sollten. Um
exakt 00:08 Uhr ging der Uplink down und etwa 10 Minuten später wird
der Cisco mithilfe von Stefan (lost_sync) und Thorsten (Aaaarrrggh) zum
Block H gefahren (Achtung Gefahrensituation). Dort angekommen fiel auf,
dass der BR-Schlüssel vergessen wurde und Meineeiner durfte noch einmal
zurücklaufen und ihn holen.

00:41
Uhr war die BR-Tür dann endlich offen und Mank kommentiert: "Staubig
hier", woraufhin ihm lost_sync, auf den Feuerlöscher deutend, eine CO2-Party offerierte....
Der Cisco wurde anschließend in einer dafür vorgesehen Schale
in das Rack geschraubt. Dabei fiel auf, dass eben jene Schale nicht für
den Schrank im H-BR geeignet ist, da der Cisco in ihr zu stark auf den
darunterliegenden Servern auflag. Zum Glück zauberte Keksi aus dem
Nichts (niemand möchte wissen woher genau ) eine passende 1HE Platte,
die wie gemacht schien, um einen Cisco in einem Serverschrank zu fixieren.

Die Serverschranktür musste jedoch ausgebaut werden, da das Rack zu
weit vorne saß und man deshalb beim Schließen der Tür die Glaskabel
beschädigt würden. In
der Zwischenzeit haben hebbet und fabian die nötigen Patches im Haus M
gesteckt. Hebbet zog danach weiter in den L und patchte dort fröhlich
vor sich hin.

Schlag 01:04 war der zweite Versuch den Cisco einzubauen erfolgreich, dann begannen hebbet und texec
damit die Glaskabel auf den Cisco zu patchen, während meineeiner und phite in den M liefen,
um die übrigen Patchkabel zu organisieren.

Gegen 01:49 Uhr waren die Uplinks der einzelnen Blöcken gesteckt,
womit das Netz auf Nutzerseite wieder funktionsfähig war.

Um 02.57 Uhr und später noch einmal um 03.25 Uhr mussten die WLAN-APs
einzeln neu wieder aktiviert werden.
Das Sorgenkind war bis zuletzt war der Link Richtung ML2.
Dieser konnte erst nachmittags von Meineeiner und Pegro gefixt werden.

[0] https://wiki.fem.tu-ilmenau.de/technik/howto/10ge-paketbeschleuniger

(Nur aus dem FeM-Net oder nach Anmeldung mit einem LDAP-Login sichtbar, Anm. der Redaktion)

FeM-WLAN Ausbauplanung

nospam@example.com (Michael Braun) — Fri, 17 Oct 2014 14:23:35 +0200

Nachdem ein Teil der AccessPoints nun geliefert ist, schreitet der Ausbau voran.

Aktuell ist Haus P vollständig, im Haus I sind noch 2, im Haus H noch 4 und im Haus K noch 23 AccessPoints zu installieren; diese sind auch als Nächstes für den Ausbau eingeplant.

Voraussetzung für den Ausbau mit FeM-WLAN sind freie LAN-Kabel und die Unterstützung von Strom-über-LAN (POE). Im Haus A, C, D, E, Q, CJD ist POE verfügbar, allerdings fehlen noch Kabel. Im Haus B, L und N sind Kabel verfügbar, aber noch kein POE - was sich jedoch nachrüsten ließe.

Daneben gibt es an ausgewählten Standorten (beispw. in den Clubs) bereits jetzt FeM-WLAN zu empfangen.

Wenn du also Interesse hast, den Ausbau beispw. in deinem Block zu beschleunigen, dann komm doch einfach mal vorbei.

Donnerstags in ungeraden Wochen um 20:30 Uhr im Haus L, Eingang 6d, im Keller.

HTML5 WLAN-Speedtest

nospam@example.com (Michael Braun) — Tue, 12 Aug 2014 11:30:41 +0200

Wie ermittelt man eigentlich aus dem Browser heraus, wie schnell gerade das WLAN ist? Diese Frage stellte sich uns, bei dem Versuch, über eine Webseite den Nutzern die Möglichkeit einzuräumen, uns Feedback zur FeM-WLAN Qualität und -Empfang zu geben. "HTML5 WLAN-Speedtest" vollständig lesen

FeM-WLAN Ausbau

nospam@example.com (Michael Braun) — Wed, 07 May 2014 18:58:58 +0200

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.

Absicherung von Sitzungen mit HTTPS Client Zertifikaten

nospam@example.com (Michael Braun) — Thu, 27 Mar 2014 20:32:53 +0100

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.

"Absicherung von Sitzungen mit HTTPS Client Zertifikaten" vollständig lesen

802.1X Authentifizierung mit dynamischen RADIUS-VLANs per LAN

nospam@example.com (Michael Braun) — Thu, 13 Mar 2014 22:11:23 +0100

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

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.

Neuanbindung des Wohnheim Block Q

nospam@example.com (Philipp Teutsch) — Wed, 12 Mar 2014 00:00:00 +0100

"Hintergrund:

Bisher war der Block Q oberhalb vom Campus über die
RZ-Netzwerkinfrastruktur im Kirchhoffbau angebunden. Dort lagen die
notwendigen FeM-VLANs auf einem RZ-Switch direkt an. Dieser Switch
entfällt jedoch im Zuge der Modernisierung des RZ-Kernnetzes, sodass wir
gezwungen waren, unsere Anbindung für den Block Q zu erneuern. Idee war
dann, eine neues Singlemode-Kabel vom Q zum Kirchhoff zu ziehen und
sich von dort passiv direkt bis ins Haus M zu unserem Kernrouter
durchpatchen zu lassen. Das bisher liegende Multimode-Kabel war für
solche Verlängungsaktionen nicht brauchbar. Durch Verwendung einer
solchen Darkfiber sind wir komplett vom topologischen Aufbau des
RZ-Kernnetzes unabhängig, was sowohl unsere als auch die Arbeit vom RZ
deutlich einfacher macht. Wir können dort uns selbst soviel Netz machen,
wie wir wollen." Anm. der Redaktion]

Am Mittwoch, dem 12.03.2014 wurde das besagte Kabel vom Kirchhoffbau (KHB) bis zum Wohnheim Block Q gezogen. Mit dem Ziel vor Augen dies zu vollführen, hatten sich nun an besagtem Tage um 11:00 Uhr morgens einige FeM-Techniker im Office zusammengefunden.

Nachdem noch diverse notwendige Utensilien aus dem Lager zusammengesucht und abfahrtbereit gemacht worden waren, zog ein Teil schonmal los zum KHB, während der sehr geehrte Herr Technikchef zusammen mit dem nicht minder geehrten

Vorstandsvorsitzen einen Abstecher zum Schornlager machten um die notwendige Kabelzughilfe zu besorgen.

Die eigentliche Aktion begann gegen 11:45 Uhr, wobei bald klar wurde, dass Zugang zum Kellerabschnitt unterhalb des Serverraums benötigt wurde. Kurzerhand besorgte der Technikchef (mit besorgter Miene) auch diesen.

Die
Kabelrolle konnte nun dank reichhaltiger Erfahrung geschickt so auf
einigen Stühlen positioniert werden, dass ein unproblematisches Abrollen
möglich war.

Als nächstes begannen die Aktiven damit die einzelnen Kabelschächte auf dem Weg zum Q zu öffnen und das Kabel mithilfe der Kabelzughilfe durch die verbindenden Leerrohre zu ziehen.

Auf diese Weise lies sich das Kabel mehr oder weniger problemlos bis zum Applikationszentrum verlegen.

Bis zum Staudinger-Bau gab erst einige Verwirrung aufgrund des verdrehten Kabelschachtes vor der NANOteria. Nach Lösung der Probleme, war auch der Weg zum Staudingerbau kein Problem.

Ab da durften wir das vorhandene Leerrohr der Uni bis zur Anzeigetafel nahe der Schranke mitnutzen. An geeigneter Stelle wechselten wir in unser eigenes Leerrohr ([das mit dem alten Multimode-Kabel, Anm. der Redaktion]) weiter Richtung Q, wobei sich der eine oder andere nicht aktiv beteiligende FeM Aktive danebenstellte um "nur mal" zu gucken

Zwei Leerrohre später war der Q erreicht. Auch die Straßenquerung am Haus Q war erstaunlicherweise (wie gehofft) kein großes Problem.

Auf dem Weg zurück zum KHB wurden die Kabelschächte wieder verschlossen und
in einigen Fällen noch das Kabel etwas zurechtgezogen, damit keine zu
langen Schleifen zurückbleiben.

Auch wurde die geforderte Beschriftung angebracht. Zurück
am KHB, konnte ein Maßband benutzt werden, um das andere Ende des
Kabels zwei Stockwerke höher in den richtigen Betriebsraum zu leiten.
Damit war der Kahah belzug gegen ca. 16.20 Uhr beendet (und damit früher als erwartet).

Zum Schluss wurde wieder alles zusammen gepackt und alle Türen wieder ordnungsgemäß verschlossen.

Am 25.März erfolgten die letzten notwendigen Handgriffe um das neue Kabel in Betrieb zu nehmen:

Zunächst wurden vormittags,
im KHB, durch die Firma Baudler die 8 Fasern aufgepleißt. Anschließend
ging die Arbeit im Q weiter. Hier wurde das alte Multimode-Kabel
abgeschnitten und rausgefummelt. Danach kam das neue Kabel, mit neuem
Schrumpfschlauch ummantelt, in die Hauseinführung. Dieses wurde dann
noch im Q aufgespleißt, durchgemessen und aufgepatcht.

Abschließend
wurden mit Hr. Hofmann vom RZ die weiteren Patches vom KHB zum Audimax
und von dort zum Wohnheim Block M (jedoch erstmal kein Link). Danach
konnte auf ein anderes Fasernpaar zwischen Audimax und M umgesteckt
werden

Als
Endergebnis ist das Haus Q jetzt direkt (ohne weitere aktive Technik
dazwischen) an unseren Kernrouter im Haus M angebunden, was mehr
Unabhängigkeit vom RZ-Netz schafft. - - > Happyend

WPA-PSK - warum eigentlich nur für Heimnutzer?

nospam@example.com (Michael Braun) — Fri, 13 Dec 2013 11:29:41 +0100

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 mit DNSSEC absichern

nospam@example.com (Michael Braun) — Sun, 24 Nov 2013 17:09:31 +0100

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.

Sichere und anonyme eMail über TOR mit DNSSEC vereinfachen

nospam@example.com (Michael Braun) — Sun, 24 Nov 2013 16:59:00 +0100

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

Großer Netzumbau am Uplink-Switch

nospam@example.com (Bernhard Hammes) — Thu, 14 Nov 2013 15:41:32 +0100

Gerbi stellt das Netz ab

Am Dienstag, dem 12.11.2013 trafen sich gegen 07:00 verschlafene FeM-Aktive um den großen angekündigten Netzumbau zu zelebrieren.
Nach etwas koffeinhaltigem Heiß- und zuckerhaltigem Kaltgetränk begab sich die Gruppe zum Haus M, um dem FeM-Netz um 07:30 durch das Herunterfahren von c-fem-1 (dem zentralen Router, aka "der cisco") den temporären Garaus zu machen.
Während die eine Hälfte nun damit beschäftigt war, den Ist-Zustand der Kabelage zu dokumentieren und dann den Cisco abzunabeln, bereitete ein weiteres Team den neuen Netzwerkschrank durch kleine Umbauten auf den Einbau des Routers vor.

Cisco im Landeanflug

Nach einer gefühlten Ewigkeit (gemessen: 1h10m) stand der Router an seinem neuen Platz, der Uplink ins Rechenzentrum nebst der ersten Verbindungen steckte und alles starrte gebannt die Konsole des Routers an.
Nach dem obligatorischen Umstecken (lechts und rings kann man nicht verwechseln!) konnte dann als erster Meilenstein das Studentenwerk wieder ans Netz genommen werden.

Pegro experminentiert mit innovativer Lichtwellen-Technologie

Zeitgleich zum Stecken der weiteren Verbindungen zum Cisco spaltete sich ein kleiner Trupp ab, um in den Betriebsräumen in den Wohnheimblöcken die nötige Steck- und Konfigurationsarbeit zu leisten.
Gegen 10:50 war die Arbeit im Haus M getan und gemeinsam wurden, unterbrochen von einer Mittagspause in der Mensa, in den letzten Blöcken die Uplinks konfiguriert und gesteckt. Leider gab es hier verschiedenste Fehlerquellen (kaputte Fasern zwischen den Häusern, fehlkonfigurierte Switche), was zu weiteren Wegen zwischen den Betriebsräumen führte. Gegen 16:00 stellte sich dann jedoch ein gewisser Erfolg ein und wir konnten schlussendlich in das FeM-Office zurückkehren.
Wieder bei koffeinhaltigen Heiß- und zuckerhaltigen Kaltgetränken wurde dann die getane Arbeit im Wiki dokumentiert und der Arbeitseinsatz beendet.

Hebbet trägt Verantwortung!

Was wurde erreicht:

-Wohnheim H, E, L und P mit 10 Gigabit/s angeschlossen (vorher 1Gigabit/s)
-Wohnheim I mit 3 Gigabit/s angeschlossen (vorher 1Gigabit/s)
-Leute (ohne Internet) zur direkten sozialen Interaktion gebracht
-Leute (ohne Internet) zum Lesen eines Buches gebracht
-Leute (ohne Internet) mit Frischluft vergiftet
-Leute (ohne Internet) zum Lernen gebracht

Der Cisco wieder bei der Arbeit