maschinenraum

Häufige Gäste der M18 kennen es vielleicht: Jeden Dienstag Abend sind die "Freifunker" im Maschinenraum. Was verbirgt sich hinter Freifunk und dem lokalen Ableger namens Weimarnetz? Und wie funktioniert das eigentlich...

Was ist Freifunk?

Eine schöne Definition  findet sich auf der Seite der Berliner Freifunker:

Die Vision von Freifunk ist die Verbreitung freier Netzwerke, die Demokratisierung der Kommunikationsmedien und die Förderung lokaler Sozialstrukturen. Durch die Vernetzung ganzer Stadtteile wollen wir der digitalen Spaltung entgegenwirken und freie unabhängige Netzwerkstrukturen aufbauen. Konkret hat sich Freifunk zum Ziel gesetzt, offene WLAN-Netze einzurichten und diese miteinander zu verbinden. Dies ermöglicht einen freien Datenverkehr "durch die Luft" in der ganze Stadt innerhalb des Freifunk-Netzes. Freifunk ist somit eine offene nicht-kommerzielle hierarchielose Initiative für freie Funknetzwerke.

...kurz&knapp: lokal unhabängige freie Netzwerke aufbauen, technischer und sozialer Natur. Anders formuliert: Internet selber bauen mit - aber nicht nur -  WLAN-Routern.

Hier, hier und hier kann Mensch weiterlesen...

Wie funktionierts?

Freifunker sagen:

Die Grundlage von Freifunk bildet ein sogenanntes Mesh-Netzwerk. Alle WLAN-Router im Freifunk-Netz kommunizieren direkt miteinander und bilden ein eigenes Funknetzwerk in der Stadt. Jeder Mensch im Freifunknetz kann mit Hilfe eines Routingprotokolls andere Teilnehmer_innen erreichen und so Daten austauschen. Manche Knoten sind desweiteren auch direkt mit dem Internet verbunden und so haben alle Menschen im Freifunk Netz auch direkten Zugriff auf das globale Netz.

...äh ja.. Mesh klingt gut... aber:

Wie läuft's nun technisch im Detail?

...kurz&knapp: WLAN-Router +  Linux + Mesh-Software + Freifunk-Software = Freifunk.

Es folgt ein kleiner unvollständiger, selektiver Crashcourse gefüllt mit Links zu weiteren Informationen, die nützlich sein können wenn man selbst an der Firmware entwickeln will oder mehr wissen will. Mitbringen muss man erstmal nichts außer Neugier, Zeit und Geduld... sowie ein klein wenig Frustrationstoleranz ;)

Linux

..ja auf vielen WLAN-Routern läuft Linux. Wie auch auf Android-Telefonen, Flugzeugen und Raumstationen. Das man auf den meisten Routern selbst Linux installieren kann ist der GPL, Linksys und einer Klage zu verdanken. Das war 2004. So lange gibt es auch schon das Weimarnetz. Aus dem veröffentlichten Quellcode des Linksys-Routers entwickelte sich eine Linux-Distribution für alle möglichen Arten von Routern namens OpenWRT und jede Freifunk Software, auch in Weimar, baut auf OpenWRT auf. Mittlerweile sind gängige Chipsätze und Routermodelle gut unterstützt und einige Hersteller liefern ihre Router auch gleich mit OpenWRT aus.

OpenWRT

Linux ist streng genommen nur der Kernel des Betriebssystems. Die Shell und weitere Software wird mit einer Distribution wie OpenWRT angepasst und verteilt. OpenWRT ist die Grundlage für die Firmware und als normaler Nutzer hat man damit nicht viel zu tun. Wenn man einfach nur einen Router aufstellen will, kann man sich fertig vorkonfigurierte Images bauen lassen. Dabei nutzt man Meshkit, dass auf dem OpenWRT Imagebuilder aufbaut.

OpenWRT ist natürlich anders als z.B. ein Ubuntu. Aber vieles ist auch ähnlich z.B gibt es auch eine Paketverwaltung bei OpenWRT und verdammt viele Pakete. OpenWRT ist für Embedded-Geräte optimiert, also Geräte mit meist auf irgendeiner Art beschränkten Ressourcen. So läuft OpenWRT mit ein paar Tricks schon mit 2MB Flash und 16MB RAM. Die fertigen Images für die Router im Weimarnetz sind inklusive Kernel+Systemtools sowie unserer Freifunk-Software auf dem Router-Flash nur etwa 3.5MByte groß. Dementsprechend muss man Kompromisse machen.

Nur passen die meisten Pakate nicht auf den geringen Flash-Speicher des Routers. Abhilfe schafft ein Router mit USB, da kann man das Dateisystem auf dem USB-Stick auslagern - Ein Router mit 4Mbyte Flash macht das ganze aber auch interessanter ;)

Alle Informationen, die man wissen muss finden sich im OpenWRT-Wiki.

Hardware

Preislich geht es mit tauglichen Routern so ab 15€ los und nach oben sind keine Grenzen gesetzt. Details über unterstützte Hardware gibt im OpenWRT-Wiki und auf der Weimarnetz-Website. Mit etwas Arbeit sollten aber alle von OpenWRT unterstützten Router mit mindestens 4MByte-Flash und 32Mbyte RAM laufen. Zu jedem Modell gibt es eine ausführliche Seite im OpenWRT-Wiki mit Details zum Stand der Unterstützung und Hinweise auf mögliche Probleme. Unterschiede gibt es bezüglich der WLAN-Features, wie auch in der Prozessorarchitektur (MIPS, ARM und PowerPC sind häufig anzutreffen) sowie natürlich bezüglich Flash-Speicher und RAM.

Generell gilt, dass TP-Link gut und günstig ist und Ubiquity besser aber etwas teurer ist.

WLAN

Die Router sollen ja auch Daten hin und her senden... Dafür wird WLAN genutzt. Also kann man sich auch mit WLAN-Standards beschäftigen und ist bestrebt ständig neue Möglichkeiten die Bandbreite und Reichweite sowie die generelle Effizenz des Netzes zu verbessern. Man kann z.B. Antennen selber bauen oder mit Tools wie Horst nach optimalen Standorten suchen. Wissen um die Theorie und Praxis von Antennen ist immer nützlich. Außerdem kommt mal aus dem Haus, wenn man Outdoor-Installation baut :)

Meshing

..oder Vermaschtes Netz. Der Kern der ganzen Geschichte: Jetzt hat man ein paar Router die sich im vermaschten Adhoc-Modus sehen können und wie genau können die jetzt ein größeres und nutzbares Netzwerk bilden? Dafür braucht man ein Routingprotokoll! Da gibt es z.B. OLSR (Layer 3) oder B.A.T.M.A.N. (Layer 2) und noch ein paar mehr... So ein Routingprotokoll definiert wie verbundene Router auf der Netzwerk-Ebene miteinander sprechen können und welche Pfade die Pakete unter allen Möglichen Bedingungen nehmen können. Da wird viel Experimentiert und es gibt teilweise RFCs sowie viele wissenschaftliche Veröffentlichungen über die Protokolle und sogar einen Wettbewerb welches Protokoll besser ist... einfach mal bei die Links durchklicken...

Weimarnetz nutzt OLSR und so läuft auf allen Routern der olsrd Dienst der aus dem Routern das Weimarnetz macht. Hier ist eine Karte aller aktueller Knoten mit ihren Verbindungen zueinander.

Freifunk-Software

Wir haben jetzt einen passenden Router, für das Teil auch noch eine tolle Linux-Distribution und wir haben uns für ein Routingprotokoll, dass wir fürs vermaschen nutzen wollen entschieden... Und jetzt?

Irgendwie fehlt da noch ein System. Das Image muss konfiguriert werden und für neue Router angepasst werden, man möchte als Nutzer nicht immer mit telnet und seriellen Kabel die Bytes herumschieben... eine Weboberfläche wäre auch schön. Zudem ist einem schon beim Vorwort zum OLSR RFC schwindelig geworden und eigentlich will man das alles ja nur nutzen und experimentieren. Außerdem muss man die Knoten in der Community irgendwie benennen und für TCP/IP benötigt man eindeutige IP-Adressen damit es keine Konflikte gibt... und überhaupt wäre es cool, wenn alle Freifunknetze innerhalb von Deutschland miteinander reden könnten?

Alle diese Probleme versucht die Freifunk-Software zu lösen - und noch ein paar weitere: So werden auf dem Router auch noch zugänge für VPN-Server konfigiguriert um auch Knoten die nicht physikalisch verbunden sind zu vernetzen und der Störerhaftung zu entgehen... es gibt zudem ein Monitoring der laufenden Knoten in der Community und viele weitere Details die gelöst werden müssen...

kalua

Auf den Weimarnetz-Routern erledigt davon vieles kalua - eine Werkzeugsammlung in POSIX-Shell programmiert, die den Router aufsetzt und konfiguriert und nachfolgend darüber wacht, dass das Router und das Netz laufen, auch wenn mal was schief geht.

dazu später mehr...

Neugierig? Freifunk-Treffen ist immer Dienstag ab 20.00Uhr - Maschinenraum M18.

Manche unsere Termine finden aktuell auch digital statt, schaut dafür in unseren Kalender.

[flash http://vimeo.com/12187489 w=500 h=281]

Terence McKenna

Vor einem Monat wurde die Uni-Pinnwand unfreiwillig auf das private Blog einer recht bekannten Person umgeleitet.

Hier nun ein kleiner Erklärbär-Post zur Pinnwand-Sicherheit und ein wenig Web-Security im Allgemeinen:

Disclaimer: Die Informationen dazu sind seit Jahren bekannt und niemand möchte der Universität schaden oder hat wirklich Cookies geklaut. Es ist aber teilweise einfach zu einfach und viele Fehler tauchen im Netz immer wieder auf oder man begeht sie selbst wenn man Webseiten bastelt (ist immer einfacher als man denkt ;)

Daher hier einmal die beiden (bislang bekannten und bereits gefixten) Bugs in der Piazza etwas erklärt:

Bug #1: HTML-Injection

Möglich geworden ist dies durch eine XSS-Lücke. Der Titel eines Beitrages wurde auf der Übersichtsseite nicht korrekt escaped. ¹

Das klingt auf den ersten Blick recht harmlos. In Verbindung mit JavaScript ergeben sich aber unendlich viele Möglichkeiten Spass zu haben oder eben auch "böse" Dinge zu tun. Mit JavaScript hat man Zugriff auf den kompletten DOM einer Website und kann normalerweise ² auch Cookies auslesen oder Asteroids mit den Elementen der Website spielen ³.

Cookies sind vor allen Dingen interressant, weil damit Sessions authentizifiert werden. Wer es noch nicht kennt: Firesheep demonstriert recht beeindruckend, dass man oft nur den Cookie stehlen muss um eine Session zu stehlen.

Zum Glück hat das SCC seine Hausaufgaben hier gemacht und das Vorlesungsverzeichnis (mit den Noten der Studenten) nutzt httponly-Cookies ² und ist damit (mit modernen Browsern) nicht angreifbar. Aber das TYPO3-Backend der Uni nutzt diese z.B. nicht.

Wie würde denn ein Angreifer mit bösen Absichten Session-Cookies stehlen?

Hier hilft wieder JavaScript. Cookies und JavaScript haben 2 verschiedene Sicherheitskonzepte. JavaScript hat eine sog. Same-Origin-Policy. D.h. man hat nur Zugriff auf Objekte der Domain in der das JavaScript ausgeführt wird.

Cookies haben zusätzlich zur Same-Origin-Policy noch einen Cookie-Path d.h. der Browser sendet nur Cookies an eine bestimmte Unterseite, wenn diese im Cookie-Path steht.

Dank JavaScript ist es aber kein Problem dies zu umgehen:

Man muss nur die Seite von der man die Cookies stehlen möchte in einen z.B. 1x1 Pixel großen <iframe> öffnen und kann dann über die JavaScript Funktion document.cookie den gewünschten Session-Cookie auslesen und unbemerkt weiterleiten.

Damit ist es dem Angreifer dann möglich sich als User zu authentifizieren.

Um das mal am Beispiel der Pinnwand zu illustrieren:

Person XY ist im TYPO3-Backend der Universtät eingeloggt und besucht die Pinnwand-Seite, dort ist ein verstecktes JavaScript in einer Nachricht, welches die TYPO3-Seite im Browser von Person XY in einem unsichtbaren (oder sehr kleinen) <iframe> öffnet, den Session-Cookie stielt und an den Angreifer weiterleitet.

Dieser kann sich nun selbst im TYPO3 einloggen in dem er den Cookie in seinen Browser einträgt.

Bug #2: Authentifizierung umgehen

Bis vor 3 Wochen konnte man ohne Passwort-Abfrage und ohne Freischaltung unter jeden Namen auf der Pinnwand Beiträge verfassen.

Die XSS-Lücke hat die Neugier geweckt und man kann sich ja mal den HTML-Quellcode ansehen und beobachten wie die Pinnwand funktioniert.... erstaunliches trat zu Tage:

Zur Erklärung: Dinge die man in Browser-Eingabekästchen eintippt werden gewöhnlich durch <form> und <input> Tags beschrieben. Beim Klick auf "Beitrag veröffentlichen" sendet der Browser in einen POST-Request die Daten an die URL die in dem Form-Tag angeben ist.

Auf der "Beitrag-Verfassen"-Seite wurde schon immer ein ein Passwort mitgesendet und überprüft. So weit so gut...

Nach der Verfassen-Seite kommt die Vorschau-Seite. Dort gibt gab es wieder ein Formular welches abgeschickt wird:


<form method="post"
action="https://www.uni-weimar.de/cms/index.php?id=2456" id="insert"
accept-charset="ISO-8859-1, ISO-8859-2">
<fieldset>
<input type="hidden" name="user" value="HIER EINEN
UNI-LOGIN EINTRAGEN">
<input type="hidden" name="titel" value="Titel des Posts">
<input type="hidden" name="inhalt"
value="Inhalt+vom+Post+urlencoded" />
<input type="hidden" name="datum" value="2010-10-20">
<input type="hidden" name="zeit" value="14:30:00">
<input type="hidden" name="dauer" value="1h">
<input type="hidden" name="intern" value="">
<input type="hidden" name="gast" value="">
<input type="hidden" name="pin_rubrik" value="11">
<input type="submit" value="Beitrag veröffentlichen"
name="insert">
</fieldset>
</form>


Na - fällt etwas auf? Hier gibt gab es kein Passwort-Feld. Und die URL an welche die Daten gesendet werden ist auch eine andere.

Blöd nur, dass HTTP zustandslos ist. Dementsprechend interressiert es weder den Browser noch die Website ob man sich vorher schon erfolgreich authentifiziert hat...

...basteln wir uns also eine kleine HTML-Datei, welche die Daten hinschickt und ändern wir den Eintrag im user=-Feld.

Huch. Da ist ein neuer Beitrag auf der Piazza ohne Passwortabfrage von einer anderen Person. In das Feld für den Namen konnte man eintragen was man möchte.

Jetzt können wir also alle unliebsamen Vorlesungen absagen und in Bernds Namen trollen. m(

Wer selbst eine Lücken finden sollte: Bitte der SCC Security Hotline melden: security@scc.uni-weimar.de. Die kümmern sich dann darum.

Und hier gibt es einen gutes Tutorial zur Sicherheit von Web-Anwendungen.

Anmerkungen

[1] Escaping ist das Umwandeln von Sonderzeichen wie < > in entsprechende HTML-Codes, so dass der Browser sie nicht mehr ausführt. In PHP z.B. mit htmlspecialchars() machbar.

[2] Da es das Problem des Cookie-Diebstahls schon sehr lange gibt wurde mit Internet Explorer 6 SP1 (2002) das httponly-Flag eingeführt. Damit wird verhindert, dass JavaScript- sowie AJAX-Funktionen Zugriff auf derart gesicherte Cookies haben.

[3] Einfach das Codeschnippsel in die Adresszeile kopieren mit den Pfeiltasten navigieren und mit der Leertaste ballern:

javascript:var%20s%20=%20document.createElement('script');
s.type='text/javascript';document.body.appendChild(s);
s.src='http://erkie.github.com/asteroids.min.js';void(0);