Diplomarbeit SS 2007 m0n0AP – Wireless Access...

Diplomarbeit SS 2007

m0n0AP – Wireless Access Point

Autoren Manuel Kasper ([email protected]) Daniel Spörri ([email protected]) HSR Hochschule für Technik Rapperswil Oberseestrasse 10 Postfach 1475 CH-8640 Rapperswil Betreuer Prof. Dr. Andreas Steffen ([email protected])

mailto:[email protected]:[email protected]:[email protected]

Diplomarbeit m0n0AP: Inhaltsverzeichnis 22. Mai 2007

Inhaltsverzeichnis (dokumentenübergreifend)

Aufgabenstellung auf-1 Abstract abs-1

bgrenzung Fortsetzungsarbeit abf-1 A

Anforderungsspezifikation as-2

1 Einführung as-32 Analyse bestehender Produkte as-4 3 Funktionsumfang as-8 4 Anforderungen an m0n0AP as-10 5 Zielplattformen, Hardware as-12

Management Summary ms-2 1 Ausgangslage ms-3 2 Vorgehen ms-3 3 Ergebnisse ms-4 4 Ausblick ms-5

Entwicklungsumgebung ewu-2 1 Infrastruktur ewu-3 2 Buildumgebung ewu-5

Überarbeitung des Kerns cor-2 1 Einführung cor-3 2 Sicherheitsanalyse cor-4 3 Core-Refactoring cor-9 4 Komplettierung der Core-Funktionalitäten cor-16

Basissystem bss-2 1 Einführung bss-3 2 Diskpartitionierung bss-4 3 Minimales FreeBSD-System bss-7 4 Lokale Konsole bss-9

Module mod-2 1 Einführung mod-3 2 Aufbau von Modulen mod-4 3 Vorgehen zur Modulerstellung mod-7 4 FreeBSD-Netzwerkschnittstellen-Modul mod-9 5 DHCP-Client-Modul mod-12 6 Wireless-LAN-Modul mod-13 7 NTP-Modul mod-17 8 XML-RPC SSL-Proxy-Modul mod-18

Web-Interface wi-2 1 Einführung wi-3 2 Modularisierungskonzept wi-4 3 Web-Server wi-5 4 Implementierung wi-6

Projektplan pp-1 Projektstatistiken pst-1 itzungsprotokolle sp-1 S

Persönlicher Bericht Manuel Kasper pb-mk Persönlicher Bericht Daniel Spörri pb-ds

Manuel Kasper, Daniel Spörri

ITA – Institute for Internet Technologies and Applications 2.4.2007 Steffen

Diplomarbeit 2007

m0n0AP – Wireless Access Point Student: Manuel Kasper, Daniel Spörri

Betreuer: Prof. Dr. Andreas Steffen Ausgabe: Montag, 2. April 2007 Abgabe: Freitag, 25. Mai 2007

Einführung In der Open-Source-Welt herrscht ein Mangel an einfach zu bedienender Software, mit der bestehende PC-kompatible Hardware als Wireless-Access-Point genutzt werden kann. Ver-fügbare Lösungen gibt es hauptsächlich in zwei Ausprägungen: solche mit passablem User-Interface aber relativ wenig Funktionalität, und solche mit grossem Funktionsumfang aber fehlendem GUI.

Aufgabenstellung Basierend auf der im Rahmen der zweiten Studienarbeit von M. Kasper und D. Spörri entwi-ckelten neuen Architektur für m0n0wall soll daher ein Open-Source Wireless-Access-Point für den semiprofessionellen Einsatz entwickelt werden. Zu diesem Zweck soll der bestehende Proof-of-Concept überarbeitet werden, um einen stabilen Kern zu erhalten. Zudem ist der Kern auf Sicherheit zu überprüfen und allfällige gefundene Schwachstellen sind auszumerzen. Dabei sind insbesondere die Authentifizierung von Benutzern, die Echtheitsprüfung von Softwarekomponenten und die sichere Übertragung sensitiver Informationen zu berücksichti-gen. Schliesslich sind alle notwendigen Module zu entwickeln, damit das Produkt als Wire-less-AP genutzt werden kann.

Resultate Als Resultat soll ein voll funktionsfähiger Wireless-Access-Point mit Web-GUI vorliegen. Der generische Kern soll aus dem Alpha-Stadium des Proof-of-Concepts zu einer ausliefe-rungsfähigen "Version 1.0" weiterentwickelt werden

Rapperswil, 2. April 2007

Prof. Dr. Andreas Steffen

Diplomarbeit m0n0AP: Abstract 23. Mai 2007

Abstract

Aufgabenstellung Im Rahmen der zweiten Studienarbeit wurde von den Diplomanden bereits eine neue, modulare Architektur für m0n0wall (ein komplettes Firewall-Softwarepaket auf Basis von FreeBSD) entworfen, welche das dynamische Laden, Entladen und Aktualisieren von Modulen zur Laufzeit vorsah. Basierend auf dieser soll ein Open-Source Wireless-Access-Point für den semiprofessionellen Einsatz entwickelt werden. Dazu soll die bestehende Proof-of-Concept-Implementation komplett überarbeitet werden, um einen stabilen Kern zu erhalten. Dieser ist zudem auf Sicherheit zu prüfen und allfällige Schwachstellen sind auszumerzen. Dabei sind insbesondere die Authentifizierung von Benutzern, die Echt-heitsprüfung von Softwarekomponenten und die sichere Übertragung sensitiver Informa-tionen zu berücksichtigen. Schliesslich sind alle notwendigen Module zu entwickeln, da-mit das Produkt als Wireless-AP genutzt werden kann.

Ziel der Arbeit Als Resultat soll ein voll funktionsfähiger Wireless-Access-Point mit Web-Interface vor-liegen. Der generische Kern soll zu einer auslieferungsfähigen «Version 1.0» weiterentwi-ckelt werden.

Lösung Als Basisbetriebssystem kommt FreeBSD zum Einsatz. Um eine optimale Performance auf Embedded-Systemen zu erreichen, wurden der Kern (Core) sowie sämtliche Module in C++ implementiert. Das lokale Web-Interface wurde in PHP geschrieben und kom-muniziert über XML-RPC mit dem Core und den Modulen, welche mit Hilfe von Zertifi-katen auf ihre Echtheit geprüft werden. m0n0AP unterstützt alle wichtigen Funktionen eines zeitgemässen Wireless-Access-Points, einschliesslich WPA2 (PSK und Enterprise mit 802.1X), MAC-Filtering, 802.1Q VLANs, Syslog, NTP, DHCP und bietet ein leicht zu bedienendes, visuell ansprechendes Web-Interface. Die XML-RPC-Schnittstelle ermög-licht es überdies, m0n0AP leicht in eigene, flexible Netzwerk-Managementsysteme einzu-binden.

Manuel Kasper, Daniel Spörri Seite abs-1

Diplomarbeit m0n0AP: Abgrenzung Fortsetzungsarbeit 22. Mai 2007

Abgrenzung Fortsetzungsarbeit

Da es sich bei dieser Diplomarbeit um eine Fortsetzungsarbeit der zweiten Studienarbeit handelt, wird auf dieser Seite klar abgegrenzt, was aus der Studienarbeit übernommen werden konnte, und was für die Diplomarbeit neu erarbeitet wurde.

Studienarbeit 2 Diplomarbeit

Architekturkonzept für m0n0wall Konzept für m0n0AP angepasst

Analyse bestehender AP-Lösungen

Proof-of-Concept-Implementation des Kerns

Komplettüberarbeitung des Kerns zur Erreichung einer stabilen Implementation

Sicherheitsanalyse des Kerns inkl. notwen-digen Verbesserungen

Ergänzung fehlender Funktionalität im Kern (Logging, digitale Signaturen, Soft-ware-Upgrade, Berechtigungen)

Testmodul und Proof-of-Concept Netz-werk-Interface-Modul

Neuauflage/Erweiterung des Netzwerk-Interface-Moduls für Bridge/VLAN

DHCP-Client-Modul kleinere Anpassungen

rudimentäres Web-Interface Web-Interface modularisiert und visuell überarbeitet

Wireless-LAN-Modul

NTP-Modul

SSL XML-RPC-Proxy-Modul

Manuel Kasper, Daniel Spörri Seite abf-1


m0n0AP – Wireless-Access-Point Anforderungsspezifikation


Dieses Dokument stellt die konkreten Anforderungen an das Projekt (im Rahmen der Aufgabenstellung) detailliert dar und ist massgebend für die Beurteilung des Projekterfolgs.


Diplomarbeit m0n0AP: Anforderungsspezifikation 22. Mai 2007

Inhaltsverzeichnis

1 Einführung ..................................................................................................................3 2 Analyse bestehender Produkte ....................................................................................4

2.1 Vorbemerkungen ................................................................................................4 2.2 Feature-Matrix...................................................................................................5 2.3 Cisco Aironet 1200 .............................................................................................6 2.4 D-Link DWL-700AP ..........................................................................................6 2.5 Linksys WAP54G ..............................................................................................7 2.6 ZyXEL G-3000H ................................................................................................7

3 Funktionsumfang ........................................................................................................8 3.1 Wireless..............................................................................................................8 3.2 Security..............................................................................................................8 3.3 Management ......................................................................................................8

4 Anforderungen an m0n0AP.......................................................................................10 4.1 Allgemeine Anforderungen ...............................................................................10 4.2 Sicherheitsanalyse des Proof-of-Concepts.........................................................10 4.3 Refactoring des Cores ......................................................................................10 4.4 Komplettierung der Core-Funktionalitäten......................................................10 4.5 Web-Interface ..................................................................................................11 4.6 Implementierung der AP-Funktionalität..........................................................11

5 Zielplattformen, Hardware ........................................................................................12 5.1 Zielplattformen ................................................................................................12 5.2 Hardware .........................................................................................................12

Manuel Kasper, Daniel Spörri Seite as-2


1 Einführung

Um die Anforderungen an das zukünftige Produkt „m0n0AP“ festlegen zu können, müs-sen zunächst einmal typische Features eines Wireless Access Points bestimmt werden. Dazu werden vier verschiedene Produkte aus dem semiprofessionellen und professionellen Bereich getestet und die wichtigsten Features erfasst.

Sodann wird in Kapitel 3 dargelegt, welche Features auch in „m0n0AP“ zu finden sein sollen (unter dem Vorbehalt der Realisierbarkeit).

Schliesslich werden in Kapitel 4 die effektiven Anforderungen formal aufgelistet.



2 Analyse bestehender Produkte

2.1 Vorbemerkungen Zur Analyse wurde eine Auswahl von vier gängigen Wireless-Access-Points getroffen, von denen die Autoren überdies je ein Exemplar zur Untersuchung beschaffen konnten.

Die Analyse ist qualitativ, d.h. es wird nur auf das Vorhandensein einzelner Features ge-prüft, nicht, ob letztere auch zuverlässig funktionieren – dies würde sonst den Zeitrah-men, der für diese Aktivität zur Verfügung steht, sprengen. Wenn aber offensichtliche Anzeichen dafür bestehen, dass ein bestimmtes Feature unzulänglich implementiert ist, wird dies in den produktspezifischen Kommentaren festgehalten.

Das Vorhandensein einzelner Features wird aus den im User-Interface verfügbaren Opti-onen und/oder der Dokumentation des Produkts abgeleitet.



2.2 Feature-Matrix

Produkt Feature C

isco

Airo

net

1200

D-L

ink

DW

L-70

0AP

Link

sys

WAP54

G

ZyXEL

G-

3000

H

Wireless

802.11a ( )1

802.11b/g Multi-BSSID Multi-ESSID Sendeleistung einstellbar SSID Broadcast ein/ausschaltbar Wireless Feineinstellungen2 Wireless Geschwindigkeit einstellbar Security MAC-Filtering WEP WPA2 WPA-PSK Management Backup/Restore der Konfiguration Benutzerverwaltung Firmware-Upload via (T)FTP Firmware-Upload via Web-Browser Integrierter DHCP-Server Liste assoziierter Clients Management-IP via DHCP Online-Hilfe Serielle Konsole Syslog-Unterstützung Telnet-Interface ( ) Web-Interface Zeitsynchronisierung via NTP Enterprise-Features Power over Ethernet (PoE) Sekundärer RADIUS-Server bei 802.1X SNMP VLAN-Tagging

WDS ( )3

WPA-Enterprise

1 802.11a-Radio-Modul optional 2 Beacon-Interval, RTS Threshold, Fragmentation Threshold, DTIM Interval, Preamble Type 3 Nur proprietärer Repeater-Modus unterstützt



2.3 Cisco Aironet 1200 Beim evaluierten Cisco-Access-Point handelt es sich erwartungsgemäss um ein absolut professionelles Modell mit allen erdenklichen Enterprise-Features. Natürlich schlägt sich dies aber auch im Preis nieder (dieses Gerät kostet etwa 10mal soviel wie der ebenfalls getestete D-Link-AP), und für weniger versierte Benutzer ist das Gerät aufgrund der vie-len Einstellmöglichkeiten schwierig zu konfigurieren.

Abbildung 1: Cisco Aironet 1200 Web-Interface

2.4 D-Link DWL-700AP Dieser Access-Point, der weder eindeutig dem Heimbenutzersegment, noch definitiv dem semiprofessionellen Bereich zugeordnet werden kann (er unterstützt zwar enterprisetaugli-che Features wie WPA mit 802.1X oder Logging via Syslog, hat aber keine Telnet-Konsole, keine Unterstützung für VLANs, etc.), fällt durch eine ziemlich niedrige Verarbeitungsqua-

lität der Hardware und des User-Interface-Designs auf.

Als für einen Access-Point ziemlich unübliches (und auch nicht besonders sinnvolles) Feature sei hier der integrierte DHCP-Server erwähnt, der optional aktiviert werden kann.

Sein Feature-Set ist, was den Wireless-Teil betrifft, trotzdem relativ vernünftig – alle Basisfunktionen, die man von einem durchschnittlichen

Wireless-AP erwartet, sind vorhanden.

Abbildung 2: D-Link DWL-G700AP Web-Interface



2.5 Linksys WAP54G Linksys ist heutzutage die „SOHO“-Linie von Cisco, und wenn dieser AP auch einige Features bietet, die über den üblichen SOHO-Rahmen hinausgehen (SNMP, WDS), wurden wichtige Enterprise-Features (wohl absichtlich) ausgelassen.

Dieses Modell (zusammen mit dem WRT54G(L), der zusätzlich noch über einen WAN-Port verfügt), ist in der Open-Source-Szene sehr beliebt, weil darauf Linux läuft und so die fehlenden Features quasi gratis wieder ergänzt werden können.

2.6 ZyXEL G-3000H Dieser ZyXEL-Access-Point ist im Enterprise-Segment platziert und bietet erwartungs-gemäss die meisten Features, die man von so einem Gerät erwarten würde. Oft bemän-gelt wird bei diesem Modell, dass nicht mehrere SSIDs gleichzeitig gebroadcastet werden können (Multi-BSSID-Unterstützung).

Die zentralisierte Verwaltung mehrerer dieser Access-Points ist dadurch erschwert, dass die Konfiguration nicht (wie z.B. bei Cisco üblich) im Textformat bearbeitet werden kann, sondern bei einem Backup/Restore nur binär vorliegt.

Abbildung 3: Screenshot des ZyXEL G-3000H Web-Interfaces



3 Funktionsumfang

Aus den in Kapitel 2 gewonnenen Erkenntnissen über den durchschnittlichen Funktions-umfang eines Wireless-Access-Points werden hier diejenigen Features selektiert, die für m0n0AP sinnvoll erscheinen und unter den gegebenen Bedingungen realisierbar sind.

3.1 Wireless

3.1.1 Unterstützung für 802.11a/b/g Mit entsprechender Hardware werden alle Betriebsmodi von 802.11a/b/g Wireless LAN unterstützt.

3.1.2 Sendeleistung Die Sendeleistung kann in mehreren Stufen den Bedürfnissen entsprechend eingestellt werden.

3.1.3 SSID-Broadcasting Das Broadcasten der SSID kann auch ausgeschaltet werden (damit eine „Hidden SSID“ entsteht).

3.1.4 Feineinstellungen Detaileinstellungen wie z.B. Beacon-Intervall, RTS-Threshold, Fragmentation-Threshold, DTIM-Interval und Präambel-Typ können vom Benutzer bei Bedarf feineingestellt wer-den.

3.1.5 Geschwindigkeit Die maximale Geschwindigkeit (im Rahmen der durch 802.11a/b/g festgelegten Profile) kann eingestellt werden.

3.2 Security

3.2.1 MAC-Filtering Die MAC-Adressen der Wireless-Clients, die sich mit dem Access-Point verbinden dür-fen, können in einer Liste erfasst werden.

3.2.2 WEP Obwohl WEP bekannterweise sicherheitsmässig zu Wünschen übrig lässt bzw. leicht ge-knackt werden kann, wird es trotzdem für die Rückwärtskompatibilität (z.B. mit exoti-schen Clients, die nichts anderes unterstützen) angeboten.

3.2.3 WPA Bei WPA werden möglichst alle Modi (WPA und WPA2, Verschlüsselung mit TKIP und AES, PSK) unterstützt.

3.2.4 802.1X Die Authentisierung von Benutzern mittels eines RADIUS-Servers (802.1X) sollte mög-lich sein.

3.3 Management

3.3.1 Backup/Restore der Konfiguration Die Konfiguration des Access-Points kann als Ganzes heruntergeladen und auch wieder-hergestellt werden.



3.3.2 Benutzerverwaltung Es können mehrere Benutzer definiert werden, die unterschiedliche Berechtigungen auf die einzelnen Funktionen des Access-Points haben.

3.3.3 Firmware-Upload via Web-Browser Neuere Versionen der Systemsoftware können direkt über das Web-Interface hochgeladen werden.

3.3.4 Liste assoziierter Clients Es kann eine Liste von Clients, die derzeit mit dem Access-Point assoziiert sind, ange-zeigt werden (Angabe der MAC-Adresse pro Client).

3.3.5 Management-IP-Adresse via DHCP Die Management-IP-Adresse kann via DHCP dynamisch bezogen werden.

3.3.6 Online-Hilfe Es gibt zu den wichtigsten/erklärungsbedürftigsten Funktionen im Web-Interface eine Online-Hilfe.

3.3.7 Serielle Konsole Für aussergewöhnliche Operationen, die nicht über das Web-Interface durchgeführt we-ren können (IP-Adresse erstmalig setzen oder zurücksetzen etc.), ist eine serielle Konsole vorhanden.

3.3.8 Syslog-Unterstützung Log-Meldungen der verschiedenen Systemkomponenten können an einen externen Syslog-Server übermittelt werden.

3.3.9 Zeitsynchronisierung via NTP Die lokale Systemzeit kann über einen NTP-Server eingestellt und nachgeführt werden.



4 Anforderungen an m0n0AP

4.1 Allgemeine Anforderungen

4.1.1 Verfügbarkeit Sämtliche eingesetzten Netzelemente und Programme sind so zu konfigurieren resp. ent-wickeln, dass sie ständig zur Verfügung stehen, ohne regelmässige, designbedingte Unter-brüche. Das Hinzufügen von optionalen Services und Konfigurationsänderungen sollten möglichst keine Neustarts erfordern.

4.1.2 Performance Das System ist so auszulegen, dass keine unnötigen Verzögerungen im Betrieb auftreten. Bei Änderungen soll innerhalb von höchstens 8 Sekunden eine Rückmeldung an den Be-nutzer erfolgen.

4.1.3 Skalierbarkeit Bei Bedarf soll sowohl horizontale als auch vertikale Skalierung möglich sein. Der Funk-tionsumfang soll an die Bedürfnisse des Benutzers und die Leistungsfähigkeit der Hard-ware anpassbar sein.

4.1.4 Sicherheit Das System ist so auszulegen, dass nur autorisierte Benutzer Zugriff auf vertrauliche Da-ten (wie z.B. sicherheitsrelevante Einstellungen) haben. Es sollen keine unautorisierten Änderungen an der Konfiguration von Aussen durch Attacken möglich sein. Die angebo-tenen Services sollten in sich sicher sein und keine böswilligen Manipulationen ermögli-chen.

4.2 Sicherheitsanalyse des Proof-of-Concepts Die im Rahmen der Studienarbeit „Neues m0n0wall-Konzept“ erarbeitete Proof-of-Concept-Implementation ist auf Sicherheitsmängel zu überprüfen. Allfällige gefundene Mängel sind auszumerzen.

4.3 Refactoring des Cores Zusätzlich zur Behebung allfälliger Sicherheitsmängel ist der Core der Proof-of-Concept-Implementation zu überarbeiten, um einen stabilen Kern für m0n0AP zu erhalten.

4.4 Komplettierung der Core-Funktionalitäten

4.4.1 Logging-Infrastruktur Der Core soll es den Modulen ermöglichen, über eine einfache Schnittstelle Log-Meldungen unterschiedlicher Stufen abzusetzen. Diese Meldungen sollen über Syslog an einen externen Server weitergeleitet oder lokal gespeichert werden können.

4.4.2 HTTPS-Unterstützung für XML-RPC-Schnittstelle Die im Core des Proof-of-Concepts bereits implementierte XML-RPC-Schnittstelle soll auch Verbindungen über HTTPS unterstützen.

4.4.3 Installation von Modulen Das System soll es ermöglichen, neue Module zur Laufzeit leicht hinzufügen und laden zu können.



4.4.4 Digitale Signierung von Modulen Vom Benutzer nachträglich installierte Module sollen auf ihre Integrität und Echtheit geprüft werden können. Das System soll den Benutzer warnen, wenn die Echtheit eines Moduls nicht festgestellt werden kann.

4.4.5 Software-Upgrade-Infrastruktur Es soll ein Konzept und eine Implementation erstellt werden, wie ein bestehendes System mit vernünftigem Aufwand auf den aktuellsten Softwarestand gebracht werden kann, oh-ne dass Konfigurationsinformationen verloren gehen.

4.4.6 Benutzerauthentifizierung und Berechtigungsprüfung Es soll ein Konzept und eine Implementation erstellt werden, wie Benutzer, die über das Web-Interface oder die XML-RPC-Schnittstelle auf den Core mit seinen Modu-len/Services zugreifen, authentifiziert werden können, und wie die Autorisierung für die unterschiedlichen Operationen erfolgt.

4.5 Web-Interface Als primäres User-Interface für m0n0AP soll ein visuell ansprechendes, angemessen be-dienbares Web-Interface implementiert werden.

4.6 Implementierung der AP-Funktionalität Sämtliche notwendigen Module sind zu entwickeln, damit das Produkt als voll funktions-fähiger Wireless-Access-Point eingesetzt werden kann. Es soll möglichst viel vom in Ka-pitel 3 beschriebenen Funktionsumfang umgesetzt werden.



5 Zielplattformen, Hardware

5.1 Zielplattformen Da als zugrundeliegendes Betriebssystem FreeBSD verwendet wird, ist im Prinzip jede Plattform, die von FreeBSD unterstützt wird, auch eine Zielplattform von m0n0AP. Der Fokus liegt aber natürlich auf i386-kompatibler Hardware, da diese am weitesten verbrei-tet und FreeBSD auf dieser Plattform auch am besten getestet ist.

5.1.1 Embedded-Computer In der Praxis sollte ein Access-Point möglichst klein/kompakt sein, damit er auch an schlecht zugänglichen Orten, wie z.B. Hohldecken, montiert werden kann. Für den Heimgebrauch sollte er zudem möglichst leise, sprich lüfterlos, sein. Aus diesem Grund fokussieren wir uns in dieser Arbeit in erster Linie auf Embedded Plattformen, welche bis dato als Plattform für „m0n0wall“ eingesetzt wurden. Dies sind:

PC Engines WRAP.2 Soekris net4826

5.1.2 PCs Obwohl es als nicht sehr sinnvoll erscheint, aus einem PC einen Access-Point zu machen, haben wir uns im Hinblick auf den Einsatz des Kerns für m0n0wall 2.0 entschieden, ein generisches Image von m0n0AP anzubieten, welches auf gewöhnliche PCs geladen werden kann.

5.2 Hardware Unter „Hardware“ werden ausschliesslich Komponenten beschrieben, welche für unser Projekt benötigt werden, da für einen Access-Point nicht sämtliche Hardware unterstützt werden muss. So ist z.B. eine Soundkarte für diese Anwendung absolut belanglos.

5.2.1 Ethernet-Karten Es werden sämtliche Karten unterstützt, welche ebenfalls von FreeBSD unterstützt wer-den. Da dies in der Regel die meisten gängigen Ethernet-Karten umfasst, sind von unser-rer Seite her keine weiteren Massnahmen nötig (ausser, alle möglichen Treiber im generi-schen Image einzuschliessen).

5.2.2 Wireless-Karten Bei den Wireless-Karten beschränken wir uns auf diejenigen Komponenten, welche auf dem Atheros-Chipsatz aufbauen. Dies liegt daran, dass es der einzige Chipsatz ist, wel-cher unter FreeBSD sämtliche Wireless-Features unterstützt.



m0n0AP – Wireless-Access-Point Management Summary


Dieses Dokument fasst Ausgangslage, Vorgehen und Ergebnisse der Dip-lomarbeit kurz zusammen und liefert einen Ausblick auf die zukünftige Verwendung der Resultate.


Diplomarbeit m0n0AP: Management Summary 22. Mai 2007

Inhaltsverzeichnis

1 Ausgangslage...............................................................................................................3 1.1 Begründung der Diplomarbeit............................................................................3 1.2 Begründung der Wahl........................................................................................3 1.3 Hauptziele der Arbeit.........................................................................................3

2 Vorgehen .....................................................................................................................3 2.1 Ausgeführte Arbeiten .........................................................................................3 2.2 Involvierte Personen ..........................................................................................4

3 Ergebnisse ...................................................................................................................4 3.1 Hauptresultat der Diplomarbeit .........................................................................4 3.2 Wiederverwendung von bestehenden Komponenten ..........................................4 3.3 Zielerreichung.....................................................................................................5 3.4 Kosten................................................................................................................5 3.5 Lernpunkte aus der Durchführung des Projekts.................................................5

4 Ausblick ......................................................................................................................5

Abbildung 1: Typische Hardware für m0n0AP

Abbildung 2: Web-Interface von m0n0AP

Manuel Kasper, Daniel Spörri Seite ms-2


1 Ausgangslage

1.1 Begründung der Diplomarbeit In der Open-Source-Welt herrscht ein Mangel an einfach zu bedienender Software, mit der bestehende PC-kompatible Hardware (insbesondere auch Embedded-Computer) als Wireless-Access-Point genutzt werden kann. Verfügbare Lösungen gibt es hauptsächlich in zwei Ausprägungen:

solche mit passablem User-Interface, aber relativ wenig Funktionalität solche mit grossem Funktionsumfang, aber fehlendem GUI

Durch die vorliegende Diplomarbeit sollte dieser Missstand behoben werden.

1.2 Begründung der Wahl Die Entscheidung für diese Diplomarbeit fiel auf der Suche nach möglichen Themen für eine Fortsetzung der in der zweiten Studienarbeit entworfenen neuen Architektur für m0n0wall. Die erste Idee war, die Funktionalität der bestehenden Version von m0n0wall auf die neue Architektur zu portieren; dies hätte aber vorallem Fleissarbeit bedeutet und dem Charakter einer Diplomarbeit (mit dem Ziel, durch Forschung neue Erkenntnisse zu ergründen) widersprochen.

Nach Evaluierung einiger Varianten fiel dann die Entscheidung im Sinne eines Kompro-misses auf die Entwicklung eines Wireless-Access-Points auf Basis der neuen Architektur.

1.3 Hauptziele der Arbeit Die Hauptziele der Arbeit waren:

eine komplette, funktionsfähige Wireless-Access-Point-Software auf Basis von Open-Source-Komponenten zu erstellen

o mit einer erweiterbaren, modularen Architektur o mit allen wichtigen Funktionen für den semiprofessionellen Einsatz

detaillierte Wireless-spezifische Einstellungsmöglichkeiten State-of-the-art-Security: WPA, 802.1X Benutzer-/Berechtigungsverwaltung

alles so zu dokumentieren, dass andere Entwickler in der Lage sind, den Aufbau von m0n0AP zu verstehen und eigene Module dafür zu entwickeln

2 Vorgehen

2.1 Ausgeführte Arbeiten Folgende Arbeiten wurden, grob zusammengefasst, während der Diplomarbeit ausge-führt:

Analyse von 4 bestehenden kommerziellen Access-Points o Festlegen des Feature-Sets und Formulieren der Anforderungsspezifikation

Security-Analyse der bestehenden Proof-of-Concept-Implementation Refactoring des Cores aus der Proof-of-Concept-Implementation Komplettierung der Core-Funktionalitäten

o Logging o Konzept & Implementation Modulinstallation inkl. digitaler Signierung o Konzept & Implementation Berechtigungsstruktur o Software-Upgrade-Konzept

Modularisierung des Web-Interfaces Implementierung aller notwendigen Module Dokumentation aller relevanten Teile



2.2 Involvierte Personen

2.2.1 Studierende Manuel Kasper und Daniel Spörri brachten den Vorschlag für diese Diplomarbeit, plan-ten sie und führten sie durch.

2.2.2 Dozent/Examinator Prof. Dr. Andreas Steffen von der Hochschule Rapperswil betreute das Projekt als Do-zent und Examinator. Er überprüfte regelmässig anlässlich von Sitzungen den Stand der Arbeit und wies auf allfällige Problemstellen hin.

3 Ergebnisse

3.1 Hauptresultat der Diplomarbeit

Abbildung 3: Architekturschema

Das Hauptresultat der Diplomarbeit ist eine Software, mit der gewöhnliche PC-Hardware (wie auch PC-kompatible Embedded-Computer) in einen voll funktionsfähigen Wireless-Access-Point für den semiprofessionellen Einsatz verwandelt werden kann.

Das System basiert auf einer modularen Architektur, die folgendes ermöglicht:

Installieren, Aktualisieren oder Entfernen beliebiger Module zur Laufzeit Entwicklung neuer Module durch andere Autoren externer Zugriff auf sämtliche Funktionalität über XML-RPC (ein Standardpro-

tokoll für Programmaufrufe über ein Netzwerk)

Die Software wird mit einem ansprechenden, einfach zu bedienenden Web-Interface, inkl. Online-Hilfefunktionen, sowie einer einfachen Befehlszeilenschnittstelle für die Erstkonfi-guration geliefert.

3.2 Wiederverwendung von bestehenden Komponenten Ohne die Verwendung bestehender Open-Source-Komponenten wäre es natürlich gar nicht möglich gewesen, in der kurzen Zeit der Diplomarbeit einen kompletten Wireless-Access-Point zu realisieren. Folgende Softwarekomponenten wurden im fertigen Produkt eingesetzt:

FreeBSD 6.2 (http://www.freebsd.org) o als Basisbetriebssystem


http://www.freebsd.org/


lighttpd (http://www.lighttpd.net) o als Web-Server

PHP (http://www.php.net) o als Skriptsprache für das Web-Interface

XmlRpc++ (http://xmlrpcpp.sourceforge.net) o Bibliothek für XML-RPC in C++

expat (http://expat.sourceforge.net) o XML-Parser-Bibliothek

3.3 Zielerreichung Sämtliche in der Anforderungsspezifikation gestellten Anforderungen wurden erfüllt. Teilweise wurde noch zusätzliche Funktionalität (z.B. VLANs) eingebaut.

3.4 Kosten Abgesehen von der durch die Diplomanden investierten Arbeitszeit verursachte die Durchführung der Diplomarbeit selbst kaum Kosten. Es wurden, getreu der Open-Source-Philosophie, nur frei verfügbare Werkzeuge zur Entwicklung eingesetzt.

Der Umfang des geschriebenen Codes für Kern, Module und Web-Interface beträgt ca. 12'500 Zeilen (SLOCs). Ungefähr 4000 Zeilen konnten aus dem Proof-of-Concept der Studienarbeit 2 übernommen werden, wobei aber ein Teil davon überarbeitet werden musste.

3.5 Lernpunkte aus der Durchführung des Projekts Die Durchführung der Diplomarbeit bereitete den Diplomanden primär aufgrund des grossen Umfangs an Programmierarbeit vertiefte Erfahrung und Routine in der Soft-wareentwicklung und dem Debugging mit C++. Auch wurden die Wireless-Funktionen von FreeBSD voll ausgekostet, und die eine oder andere Fallgrube konnte erkannt und umschifft werden.

4 Ausblick

Mit dem Produkt aus dieser Diplomarbeit – einer voll funktionsfähigen Version von m0n0AP – wurde der Grundstein für ein neues Open-Source-Projekt gelegt. Es ist vorge-sehen, alle Ergebnisse in Form einer (englischsprachigen) Website im Internet der Com-munity zugänglich zu machen. Das auf diese Weise erhaltene Feedback wird zur Ent-scheidung für eine Weiterführung des Projekts in gleicher Form, oder allenfalls einer Ab-wandlung dienen.

So wäre es z.B. auch denkbar, die jetzige Version von m0n0wall ebenfalls der neuen Ar-chitektur anzupassen und dann die bereits aus m0n0AP bestehenden Module zu integrie-ren, um so eine Firewall mit zusätzlicher umfangreicher Unterstützung für Wireless LAN zu erhalten.

Es ist möglich, dass einzelne Aspekte der Architektur bei Bedarf nochmals angepasst werden müssen, um der Realität bzw. dem tatsächlichen praktischen Einsatz entgegen-zukommen (z.B. Umsetzung der System/Modul-Updatefunktionen). Dies kann aber erst beurteilt werden, nachdem in verschiedenen Umgebungen entsprechende Erfahrungen ge-sammelt wurden.


http://www.lighttpd.net/http://www.php.net/http://xmlrpcpp.sourceforge.net/http://expat.sourceforge.net/


m0n0AP – Wireless-Access-Point Entwicklungsumgebung


In diesem Dokument wird dargelegt, wie die Entwicklungsumgebung für diese Diplomarbeit aufgebaut wurde.


Diplomarbeit m0n0AP: Entwicklungsumgebung 22. Mai 2007

Inhaltsverzeichnis

1 Infrastruktur ...............................................................................................................3 1.1 Hardware ...........................................................................................................3 1.2 Entwicklungsmaschine .......................................................................................3 1.3 VM-Server..........................................................................................................3 1.4 internes Netzwerk ..............................................................................................4 1.5 Gemeinsame Dateiablage ...................................................................................4 1.6 Versionskontrolle................................................................................................4

2 Buildumgebung ...........................................................................................................5 2.1 Einsatz von GNU „Autotools“ ...........................................................................5 2.2 Aufbau des Quellverzeichnisses für den Core .....................................................5 2.3 externe Abhängigkeiten......................................................................................6

Manuel Kasper, Daniel Spörri Seite ewu-2


1 Infrastruktur

1.1 Hardware Es wurden zwei von der HSR zur Verfügung gestellte PCs (Intel Pentium 4 3.0 GHz, 1 GB RAM, 80 GB HD) als Server eingesetzt. Zudem kamen die privaten Laptops der Dip-lomanden (2 x Apple MacBook Pro) zum Einsatz.

Im internen Netzwerk für die Entwicklungsmaschinen, Laptops und Embedded-Systeme wurde ein 24-Port 3com-Switch (unmanaged) verwendet.

1.2 Entwicklungsmaschine Um möglichst nahe an der Zielplattform – FreeBSD auf i386-kompatibler Hardware – entwickeln zu können und damit auch den Buildzyklus (Kompilieren, Linken) einfach zu halten (keine Cross-Compiler nötig), wurde auf einem der beiden HSR-PCs FreeBSD 6.2-RELEASE installiert. Desweiteren kamen folgende Open-Source-Softwarepakete zum Einsatz:

Apache 2.0.59 o als WebDAV-Server für die Dateiablage o als Subversion-Server

Autoconf 2.59 Automake 1.10 Libtool 1.5.22 Subversion 1.4.3

o für Versionskontrolle Valgrind 3.5.2

Auf die Entwicklungsmaschine wurde per SSH zugegriffen; sie fungierte zudem als NAT-Gateway für den Internetzugang der anderen Geräte im internen Netzwerk und wurde zu diesem Zweck mit einem zusätzlichen USB-Ethernet-Adapter ausgerüstet.

1.3 VM-Server Da Tests auf Embedded-Hardware relativ aufwändig sind, wurde zudem beschlossen, die-jenigen Tests, die keine spezielle Hardware (wie z.B. Wireless-Karten) erfordern, in Vir-tual Machines laufenzulassen. Zu diesem Zweck wurde ein weiterer HSR-PC mit Win-dows Server 2003 Standard Edition (vom HSR-ELMS-Server) aufgesetzt.

Für das Erstellen der Basis-FreeBSD-Images wurde eine virtualisierte Installation von FreeBSD 6.2 unter dem frei erhältlichen VMware Server eingerichtet. Ursprünglich war geplant, die erstellten Images gleich auch unter VMware zu testen; es hat sich aber ge-zeigt, dass dies relativ unpraktisch ist: rohe Disk-Images, wie sie unter FreeBSD erstellt werden, können nicht direkt mit VMware verwendet werden, und zudem lässt sich der Start von VMware nur aufwändig mit Scripts steuern.

1.3.1 QEMU Als alternative Lösung für das Testen der Images wurde QEMU1, ein Open-Source-Prozessoremulator, verwendet. Diese Software ist für viele Betriebssysteme verfügbar, lässt sich leicht über die Kommandozeile steuern, kann problemlos mit rohen Disk-Images umgehen, und ist in Verbindung mit dem „QEMU Accelerator“ auch mehr als schnell genug (ohne Accelerator werden sämtliche Instruktionen emuliert).

1 http://fabrice.bellard.free.fr/qemu/


http://fabrice.bellard.free.fr/qemu/


1.4 internes Netzwerk

Abbildung 1: Netzwerkdiagramm Entwicklungsumgebung

1.5 Gemeinsame Dateiablage Für nicht bzw. schlecht versionierbare Dateien (Binaries, Word-Dokumente) wurde auf der Entwicklungsmaschine mittels Apache ein WebDAV-Verzeichnis eingerichtet, auf das von Windows und Mac OS aus bequem und sicher über HTTPS zugegriffen werden konnte.

1.6 Versionskontrolle Für die Versionskontrolle kam, wie schon bei der Studienarbeit „Neues m0n0wall-Konzept“, Subversion2 zum Einsatz, da es den Diplomanden bereits bestens bekannt war und einige Vorteile gegenüber dem klassischen CVS aufweist.

Das Subversion-Repository wurde ebenfalls auf der Entwicklungsmaschine eingerichtet; der Zugriff erfolgte über HTTPS. Die Datensicherung, welche dadurch entsprechend wichtig wurde (praktisch gesamte Arbeit auf der Entwicklungsmaschine) erfolgte inkre-mentell nächtlich via SSH mittels dump(8) über das Internet auf einen Server zuhause bei M. Kasper.

2 http://subversion.tigris.org/


http://subversion.tigris.org/


2 Buildumgebung

Für die Proof-of-Concept-Implementation in der Studienarbeit „Neues m0n0wall-Konzept“ wurde Eclipse CDT zur Automatisierung aller notwendigen Compile/Link-Schritte verwendet. Es hat sich aber im Verlauf der Studienarbeit gezeigt, dass CDT noch nicht so ganz ausgereift ist und bei komplizierteren Projekten (mehrere Produkte, Abhängigkeiten etc.) schnell an seine Grenzen stösst.

2.1 Einsatz von GNU „Autotools“ Auf der Suche nach einer Alternative wurde bald klar, dass die allgemein akzeptierte Lö-sung für das Buildproblem bei C/C++-Projekten in den GNU „Autotools“ besteht, die da wären:

Autoconf o generiert configure-Scripts, welche wiederum Makefiles generieren

Automake o erzeugt portable Makefile-Templates (Makefile.in), die vom configu-

re-Script zu einem fertigen Makefile verarbeitet werden Libtool

o unterstützt den Prozess des Erzeugens statischer und dynamischer Pro-grammbibliotheken auf verschiedenen Betriebssystemen

Der Hauptvorteil der „Autotools“ besteht darin, dass es leicht(er) wird, plattformüber-greifende Software zu schreiben. Das ist zwar für diese Diplomarbeit keine Anforderung (m0n0AP resp. Core/Module müssen nur unter FreeBSD laufen), stellt aber eine Investi-tion in die Zukunft dar, da es sehr wahrscheinlich ist, dass jemand irgendwann zumindest den Core auf einer anderen Plattform kompilieren und ausführen möchte.

Notabene: es werden in der Refactoring-Phase des Cores aber keine speziellen Vorkeh-rungen für den Build auf anderen Plattformen als FreeBSD getroffen, da auch gar nicht klar ist, welche Plattformen sonst noch gefragt wären – dies muss daher allenfalls später von an der Portierung interessierten Personen übernommen werden.

2.2 Aufbau des Quellverzeichnisses für den Core Der Aufbau des Quellverzeichnisses für den Core (m0n0cored) wurde wie folgt gewählt (es werden nur wichtige Dateien aufgelistet):

m0n0cored o Doxyfile Einstellungen für doxygen o Makefile.am Automake-Vorlage o acinclude.m4 zusätzliche Autoconf-Makros o common/ Headerdateien, die auch von Modulen verwendet werden o configure.ac Autoconf-Eingabedatei o examples/ Beispiele für Konfiguration (XML), moduleMetaInfo o lib/ „fremde“ verwendete Programmbibliotheken

xmlrpc++/ XmlRpc++-Bibliothek o patches/ Ablage für Quellcodepatches für fremde Software o schemas/ XML-Schemas (XSD) o src/ Quellcode

coreservices/ Core-Services utils/ Utility-Klassen xmlrpc/ Klassen für XML-RPC (nicht XmlRpc++-Library!)

o test/ Testprogramme o tools/ Hilfsskripts (zur Modulentwicklung)



2.3 externe Abhängigkeiten Folgende Bibliotheken, die nicht standardmässig auf jedem mit einem C/C++-Compiler ausgerüsteten System erwartet werden können (Standard-C-Library bzw. C++ STL), setzt m0n0cored voraus:

expat3 o XML-Parser, in der Version 2.0

pthread o für Multithreading

OpenSSL o zur Überprüfung von digitalen Signaturen von Modulen und System-

Images, sowie für das Zertifikathandling libarchive

o Bibliothek zum Lesen von TAR-Archiven (wird mit FreeBSD standardmäs-sig mitgeliefert)

Diese Abhängigkeiten werden vom configure-Script geprüft; für pthread wurde das exis-tierende Autoconf-Makro acx_pthread4 eingesetzt.

Die XmlRpc++-Bibliothek wurde vollständig in den Quellcode-Baum von m0n0cored kopiert, da spezifische Anpassungen an der Bibliothek notwendig waren und es auch an-gesichts der kleinen Grösse der Bibliothek wenig sinnvoll erscheint, den Benutzer diese separat installieren zu lassen.

3 http://expat.sourceforge.net/4 http://autoconf-archive.cryp.to/acx_pthread.html


http://expat.sourceforge.net/http://autoconf-archive.cryp.to/acx_pthread.html


m0n0AP – Wireless-Access-Point Überarbeitung des Kerns


In diesem Dokument sind sämtliche Aspekte der Überarbeitung des Kerns dokumentiert, wie Sicherheitsanalyse, Refactoring und Komplettierung der Core-Funktionalitäten.

Diplomarbeit m0n0AP: Überarbeitung des Kerns 22. Mai 2007

Manuel Kasper, Daniel Spörri Seite cor-2

Inhaltsverzeichnis

1 Einführung ..................................................................................................................3 2 Sicherheitsanalyse .......................................................................................................4

2.1 Core ...................................................................................................................4 2.2 XML-RPC..........................................................................................................5 2.3 Webserver ..........................................................................................................7 2.4 Betriebssystem ...................................................................................................7

3 Core-Refactoring .........................................................................................................9 3.1 Analyse der Architektur.....................................................................................9 3.2 Analyse des Designs ...........................................................................................9 3.3 Code Walkthrough...........................................................................................12 3.4 Fazit der Codeanalyse......................................................................................14

4 Komplettierung der Core-Funktionalitäten ...............................................................16 4.1 Logging-Infrastruktur.......................................................................................16 4.2 HTTPS-Support für XML-RPC-Schnittstelle ..................................................17 4.3 Installation von Modulen .................................................................................18 4.4 Digitales Signieren von Modulen......................................................................20 4.5 Umsetzung der Installations- und Signierungsfunktionen.................................22 4.6 System-Upgrade ...............................................................................................25 4.7 Berechtigungsstruktur......................................................................................27



1 Einführung

Um den im Rahmen der 2. Studienarbeit von Manuel Kasper und Daniel Spörri erstellten Proof-of-Concept des Kerns releasefähig machen zu können, ist eine erneute grundlegende Überarbeitung notwendig.

Da der Kern sicherheitsrelevante Aufgaben übernimmt, ist er einer Sicherheitsanalyse zu unterziehen. Grundsätzlich wird es schwierig werden, alle möglichen Sicherheitslöcher auszuloten, da die Sicherheit nicht allein von selbst entwickelten Komponenten abhängt. Die von Dritten erstellte Software und APIs sind dabei als unterschiedlich vertrauens-würdig zu bewerten.

Des Weiteren wird der Kern einem Refactoring unterzogen, welches Design- und Imple-mentationsschwächen der Alphaversion eliminieren soll. Ziel ist es, den Kern weiter zu stabilisieren. Optimierungen bezüglich Speicher- und Ressourcenbedarf wären wün-schenswert.

Schliesslich werden bislang fehlende Core-Funktionalitäten, wie Update-, Back-up/Restore-, Modulinstallations- und Verwaltungsfunktionen ergänzt.



2 Sicherheitsanalyse

Hauptsächlich können vier sicherheitsrelevante Komponenten identifiziert werden. Der Kern zum Ersten ist als zentrale Einheit des Systems eine gefährdete Komponente. Diese sollte möglichst fehlerfrei implementiert sein. Zum Zweiten wäre da der XML-RPC-Server, welcher als externe Schnittstelle für asynchrone Aufrufe dient. Der Webserver zum Dritten, da dieser als Standard-Benutzer-Interface gewählt wurde. Zum Letzten sei noch das Betriebssystem erwähnt, bei welchem die grösste Gefahr von falschen Konfigu-rationen ausgeht. Die Sicherheitsanalyse soll in den aufgelisteten Komponenten mögliche Sicherheitsmängel aufdecken. Auch beim anschliessenden Refactoring und bei den Ergän-zungen ist bei der Umsetzung ein Augenmerk auf die Sicherheit zu legen.

Um in der kurzen zur Verfügung stehenden Zeit schnell einen Überblick über allfällige bekannte Sicherheitslöcher oder schlechte Praktiken im Core und der verwendeten XmlRpc++-Library zu erhalten, wurde beschlossen, deren Quellcode mit einigen stati-schen Source-Code-Analyzern zu untersuchen.

Von den drei verwendeten Tools (Flawfinder1, RATS2 und ITS43) produzierte Flawfinder am meisten Resultate; die anderen zwei Tools listeten eigentlich nur noch eine Unter-menge der von Flawfinder bereits gefundenen potentiellen Schwachstellen auf.

2.1 Core Einen möglichen Angriffspunkt im Kern stellt die Benutzerverwaltung dar. Sicherheits-technisch sind der Benutzerauthentisierung und -autorisierung grosse Aufmerksamkeit zu schenken, so dass in diesem Bereich keine Sicherheitslöcher entstehen können. Eine wei-tere kritische Operation stellt das Laden von neuen Modulen dar. Dem installierenden Benutzer muss eindrücklich klar signalisiert werden, dass er ein potentiell gefährliches Modul installiert, welches nicht entsprechend signiert wurde. Einen Angreifer könnte un-ter Umständen die Konfiguration des Geräts interessieren, um weitere Rückschlüsse auf die Topologie des restlichen Netzwerks zu ziehen. Aus diesem Grund muss sichergestellt werden, dass die Konfiguration nur authentisierten Benutzern zugänglich ist.

2.1.1 Flawfinder Folgende potentielle Probleme wurden mittels Flawfinder 1.27 im Core gefunden:

Verwendung von realpath() o Ausgabepuffer muss gross genug für jeden Pfad sein, sonst ist ein Buffer-

Overflow möglich

Ist bereits sichergestellt (Verwendung von PATH_MAX, was zu PATHLEN äquivalent ist)

Verwendung von open() o Symlink-Attacken etc. theoretisch möglich

Hier kein Problem, da Core sowieso als Root gestartet wird (mit Übergabe des Pipe-Pfads) und kein setuid-Programm ist

Character-Arrays mit fixer Länge o Read-Buffer in EventPipeReader.cpp: Länge ist als Makro definiert und

wird bei read() etc. immer angegeben. Allerdings ist dabei noch aufgefal-len, dass der aus der Pipe gelesene String nicht NULL-terminiert wird und somit ein Buffer-Overflow auftreten könnte, wenn strsep() darauf aufge-rufen wird

Dies muss unbedingt noch gefixt werden, auch wenn in die Named Pipe nur lokal mit Root-Rechten geschrieben werden kann

1 http://www.dwheeler.com/flawfinder 2 http://www.securesoftware.com/rats 3 http://www.cigital.com/its4/



o Read-Buffer in ModuleMetaParser.cpp und SystemConfigParser.cpp: wird ebenfalls korrekt verwendet

Verwendung von atoi() o in ModuleMetaParser.cpp und SystemConfigParser.cpp: atoi() wird zum

Parsen der Versionsnummer und der letzten Änderung aufgerufen. Diese Felder sind rein informativ

Es sollte aber noch eine Plausibilitätsprüfung eingebaut werden

o in SystemConfigParser.cpp: dort ist sowieso noch ein TODO vorhanden, dass gelesene Integer-Parameter aus der Config überprüft werden, ob es sich tatsächlich um einen Integer handelt (ansonsten Exception)

Muss in der Refactoring-Phase noch implementiert werden

Verwendung von read() o wird in EventPipeReader.cpp, ModuleMetaParser.cpp und SystemConfig-

Parser.cpp in einem Loop aufgerufen.

Ein manuelles Review liess keine Probleme mit der Verwendung des Puf-fers erkennen

2.1.2 RATS Keine zusätzlichen potentiellen Schwachstellen gefunden.

2.1.3 ITS4 Folgende potentielle Probleme wurden mittels ITS4 zusätzlich zu den obigen (mit Flaw-finder aufgedeckten) im Core gefunden:

Potentielle Race-Condition beim Erstellen/Öffnen/Löschen der Pipe in EventPi-peReader.cpp.

Die Pipe wird aber an einem sicheren, durch den startenden User (root) vorgegebenen Ort erzeugt.

Verwendung von dlopen() o in ModuleInfo.cpp: ist natürlich riskant (geladene Library könnte ja böse

sein).

Daher wird ja auch Modulsignierung implementiert, damit keine nicht ver-trauenswürdigen Module unbewusst installiert werden können

Verwendung von opendir() o in ModuleManager.cpp: falls vor opendir() noch ein bestimmter Test

(auf Symlink etc.) durchgeführt würde, so wäre eine Race-Condition mög-lich.

Hier keine bestimmten Tests (Verzeichnis wird durch startenden User vor-gegeben) vorhanden oder nötig

2.2 XML-RPC Die XML-RPC-Schnittstelle stellt bei entsprechender Konfiguration die Verbindung zur Aussenwelt und damit ein primäres Angriffsziel eines Eindringlings dar. Darum ist sie eingehend auf Schwachstellen programmatischer Natur zu untersuchen.

Jeder XML-RPC-Aufruf muss authentisiert werden; dazu wurde in der Studienarbeit XmlRpc++ bereits um Unterstützung für HTTP-Authentifizierung erweitert. Wie be-reits angemerkt ist HTTP jedoch für entfernte XML-RPC-Aufrufe besonders beim Ein-satz von Basic-Authentifizierung völlig ungeeignet.

Die XML-RPC-Schnittstelle ist so anzupassen, dass Aufrufe über HTTPS möglich sind; HTTP soll für entfernte Aufrufe gar nicht mehr zugelassen werden (es kann für Aufrufe des lokalen Web-Interfaces aus Effizienzgründen weiterhin offen blei-ben, wenn gewährleistet ist, dass nur lokale Verbindungen möglich sind)



Methodenaufrufe und deren Parameter sind serverseitig auf Korrektheit und Vollständig-keit hin zu prüfen. Falls die über XML-RPC aufgerufene Methode nicht existiert, muss eine entsprechende Fehlermeldung generiert und zurückgegeben werden.

2.2.1 Flawfinder Folgende potentielle Probleme wurden mittels Flawfinder 1.27 in XmlRpc++ gefunden:

*printf() mit variablem Format-String o in den Log-Funktionen in XmlRpcUtil.cpp wird vsnprintf() mit einem

variablen Format-String aufgerufen.

Dieser ist allerdings bei allen Aufrufen der Log-Funktionen im restlichen Code konstant definiert und kann nicht von Netzwerkclients beeinflusst werden. Somit ist hier kein Problem vorhanden.

o Mit einigen #defines für *printf()-Funktionen bekundete Flawfinder etwas Mühe: er hielt sie ebenfalls für potentiell gefährliche *printf-Aufrufe mit variablem Format-String.

Sie sind aber völlig unproblematisch

o Ebenfalls in XmlRpcValue.cpp wird der Format-String für Double-Werte als Variable an snprintf() übergeben.

Ist aber trotzdem konstant, also auch kein Problem

Character-Arrays mit fixer Länge o in XmlRpcClient.cpp, XmlRpcSocket.cpp und XmlRpcServerConnecti-

on.cpp findet sich Code wie der folgende: char buff[40]; sprintf(buff,":%d\r\n", _port); Das ist zwar kein Problem, da mit dem angegebenen Format-String niemals die ganzen 39 reservierten Zeichen verbraucht werden können.

Es ist aber trotzdem nicht sehr schön und sollte behoben werden (snprintf o.ä.)

o Verwendung von Lesepuffern mit fixer Länge in XmlRpcSocket.cpp: die Länge ist in einem Makro definiert und wird bei recv()/read()/etc. strikte verwendet.

Alles normal

o Ebenfalls in den Log-Funktionen von XmlRpcUtil.cpp werden Puffer mit fixer Grösse (1 KB) für Log-Messages verwendet; da aber vsnprintf() (mit Längenangabe) zum Einsatz kommt, besteht kein Problem

Allenfalls würde die Log-Message einfach abgeschnitten

Verwendung von atoi() o in XmlRpcClient.cpp und XmlRpcServerConnection.cpp wird atoi() ver-

wendet.

Das Ergebnis wird aber auf einen plausiblen Bereich geprüft und somit OK

Verwendung von memcpy() o in XmlRpcSocket.cpp wird mittels memcpy() in eine sin_addr-Struktur

kopiert; die Länge stammt aus einem struct hostent, das über gethostbyname() erhalten wurde.

Das ist zwar technisch nicht perfekt, scheint aber weit verbreitet zu sein.

Verwendung von strlen()



o in XmlRpcUtil.cpp: kann gefährlich sein, wenn nicht garantiert ist, dass der zu untersuchende String Null-Terminiert ist. Bei allen Verwendungen der betroffenen Methoden ist der übergebene String jedoch eine Konstante.

Kein Problem (wobei man natürlich bei Konstanten über den Sinn von strlen() streiten könnte)

2.2.2 RATS Folgende potentielle Probleme wurden mittels RATS 2.0 zusätzlich zu den obigen (mit Flawfinder aufgedeckten) in XmlRpc++ gefunden:

Resultate von gethostbyname() nicht vertrauenswürdig o XmlRpcSocket.cpp verwendet in der connect()-Methode ein

gethostbyname(), um allfällige als DNS-Namen angegebene Hosts aufzu-lösen.

Natürlich ist klar, dass Ergebnisse von DNS-Abfragen gefälscht sein kön-nen, aber eine andere Quelle steht hier gar nicht zur Verfügung und für eine sichere Authentifizierung sind Zertifikate resp. SSL nötig. Es handelt sich um Code für den XML-RPC-Client-Teil, der im Core derzeit über-haupt nicht eingesetzt wird (nur Server).

2.2.3 ITS4 Keine weiteren potentiellen Schwachstellen gefunden.

2.3 Webserver Als Webserver für das Web-Interface von m0n0AP wurde der bereits in der letzten Stu-dienarbeit eingeführte lighttpd4 ausgewählt – dies aufgrund seines effizienten, schlanken Designs, der Fähigkeit, PHP im FastCGI-Modus auszuführen, und der Fokussierung auf Sicherheit.

Eine Recherche auf dem Internet bezüglich der Security-History von lighttpd ergab, dass auch lighttpd in der Vergangenheit einige sicherheitsrelevante Bugs hatte (was man von praktisch jeder Software behaupten kann) – der gravierendste war ein Source-Code-Disclosure-Bug, mit dem es Web-Clients unter bestimmten Umständen möglich war, den Quellcode eines über lighttpd zugänglich gemachten Scripts zu lesen5.

Für aktuellere Versionen von lighttpd konnten keine solchen Security-Advisories mehr gefunden werden.

Um die Sicherheit zusätzlich zu erhöhen, wird lighttpd auf m0n0AP unter einem unprivilegierten Benutzerkonto ausgeführt und, falls möglich, auch noch chroot eingesetzt.

2.4 Betriebssystem FreeBSD als Basisbetriebssystem ist natürlich auch sicherheitsrelevant, und zwar sowohl was den Kernel betrifft (z.B. Verarbeitung von Netzwerkpaketen von nicht vertrauens-würdigen Maschinen), als auch alle daraus verwendeten Userland-Programme. Ersterer ist aber weitaus kritischer, da er während der ganzen Betriebszeit verfügbar ist und des-sen Code ausgeführt wird, während die meisten Userland-Programme nur kurzfristig z.B. während des Bootvorgangs aufgerufen werden.

An dieser Stelle eine Sicherheitsanalyse von FreeBSD durchführen zu wollen, wäre gewiss völlig vermessen; historisch gesehen hat FreeBSD aber einen ziemlich guten „track re-cord“, was die Sicherheit des Basissystems betrifft, und allfällige gefundene Fehler wer-den schnell behoben.

4 http://www.lighttpd.net/ 5 http://secunia.com/advisories/18886/



Das grössere Risiko besteht darin, dass Komponenten von FreeBSD durch Fehl-konfiguration oder nicht bestimmungsgemässen Einsatz unsicher verwendet wer-den.

Um diesem Risiko zu begegnen, werden so wenige Komponenten (Userland-Programme, Kerneloptionen etc.) wie möglich verwendet, und die verwendeten sorgfältig und gemäss Dokumentation konfiguriert. Dies ist auch im Interesse der Effizienz – nutzlose Komponenten verbrauchen auf dem Zielsystem trotzdem wertvollen Speicherplatz.

Mittels Tools wie sockstat oder netstat kann zur Laufzeit überprüft werden, ob irgendwelche Programme Netzwerksockets offen haben, die nicht nötig wären. Dies ist möglichst zu minimieren, da jeder geöffnete Socket einen Angriffspunkt darstellt.

Mittels Laufzeiteinstellungen (sysctl) kann zudem dafür gesorgt werden, dass der Kernel z.B. bei der Verarbeitung von ICMP-Meldungen konservativ vorgeht, keine potentiell sensitiven Informationen herausgibt oder eine DoS-Attacke aktiv unterstützt.



3 Core-Refactoring

Da es sich bei dem zugrunde liegenden Kern um einen Prototypen handelt, sind ver-schiedene Arbeiten notwendig, um diesen releasefähig zu machen. In einem ersten Schritt werden das Design und der existierende Code erneut analysiert. Die dabei entdeckten Mängel werden in einem zweiten Schritt in der Implementation behoben.

3.1 Analyse der Architektur Bei der Architektur des Kerns und der Interaktion mit seinen Modulen (v.a. die Auftei-lung in Module und Services mit ihren Operationen) wurden keine grundlegenden Prob-leme festgestellt, die eine Anpassung der Architektur erfordern würden. Die in der Stu-dienarbeit gewählte Variante hat sich bislang gut bewährt.

3.2 Analyse des Designs Bei der Analyse des Designs aus dem Proof-of-Concept (auch unter Zuhilfenahme des Codes zur Klärung allfälliger Unklarheiten) fiel insbesondere auf, dass einige Objekte (z.B. ModuleManager oder CoreXMLRPCServer) in ihren Konstruktoren Pointer auf fremde Objekte (z.B. SystemConfig, ServiceManager, etc.) annehmen müssen, mit denen sie selbst gar nichts zu tun haben, nur damit sie sie dann an von ihnen erstellte Objekte anderer Klassen weitergeben können.

Damit sie diese Objekttypen aber überhaupt annehmen und weitergeben können (ohne auf Frevel wie die Verwendung von void-Pointern zurückzugreifen), müssen sie die ent-sprechenden Header-Dateien inkludieren (oder zumindest eine „class“-Deklaration auf-weisen).

Nach reiflicher Überlegung wurde beschlossen, dass diejenigen systemweiten Objekte, die derzeit in der main()-Funktion der Coreapplikation erzeugt werden, in einem Objekt einer neuen Klasse „CoreApplication“ gekapselt werden. Diese Klasse kann dann auch die Verantwortlichkeit für die Initialisierung der diversen Manager, das Laden der SystemConfig, das Erstellen des EventPipeReaders und das Starten des Co-reXMLRPCServers übernehmen – alles Dinge, die derzeit noch von main() gehandhabt werden.

Sodann könnte allen Objekten, die von dieser neuen CoreApplication erzeugt werden, eine Referenz bzw. Pointer auf das CoreApplication-Objekt übergeben werden, und dieser Pointer könnte von jenen Objekten weiterpropagiert werden. Danach kann sich je-des Objekt die benötigten Referenzen auf Module-/Service-/EventManager etc. beim Co-reApplication-Objekt abholen.

Wir sind uns natürlich bewusst, dass dadurch eine Kopplung vieler Klassen mit Co-reApplication entsteht, welche dann etwas wie die „Spinne im Netz“ ist, was die Ini-tialisierungsphase von Objekten betrifft. Jedoch sind wir zum Schluss gekommen, dass dies das kleinere Übel ist, als wenn (wie bei der jetzigen Version) möglicherweise diverse Klassen angepasst werden müssen, nur um irgendeine zusätzliche Objektreferenz weiter-reichen zu können.

Es wurde auch noch die Variante der Verwendung globaler Variablen diskutiert, aber gleich wieder als einer OO-Anwendung völlig unwürdig verworfen.



3.2.1 Überarbeitetes Klassendiagramm

+ shutdown()+ init()+ handleServiceRequest()

ServiceHandler

+ handleEvent()

EventHandler

+ handleEvent()

SomeEvent

+ resolve()+ addNode()+ addDependency()

- nodes

DependencyResolver

+ call()

- initialized- name

ServiceInfo

- dependencies- description

ServiceMetaInfo

- lastChange- author- version

ModuleMetaInfo

+ deleteParam()+ setParam()+ getParam()

SystemConfigInterface

+ run()

CoreApplication

+ run()

- listenPort

CoreXMLRPCServer

+ unregisterEventHandler()+ registerEventHandler()+ triggerEvent()+ callService()+ registerService()

ModuleCallback


- moduleName

SystemConfigProxy+ removeEventHandler()+ addEventHandler()+ callHandlers()

- name

EventType

+ unregisterEventHandler()+ registerEventHandler()+ triggerEvent()

EventManager

+ execute()

TriggerEventMethod


SystemConfig

+ getResult()

WorkQueueServiceCall

EventPipeReader

+ unloadModule()+ loadModule()+ loadModulesFromDirectory()

ModuleManager

11

+ enqueueSync()+ enqueueAsync()

WorkQueue

1

1

- dependentServices

*

*

1

1

+ shutdown()+ init()+ handleServiceRequest()

SomeServiceHandler

1

*

- handlers

*

*

+ parse()

SystemConfigParser

1111

+ initServices()+ unregisterService()+ registerService()+ callService()

ServiceManager

*

1 - modules

*

+ unregisterEventHandler()+ registerEventHandler()+ triggerEvent()+ callService()+ registerService()

- name

ModuleInfo

1

1 1 1

+ parse()

ModuleMetaParser

WorkQueueTriggerEvent

1

* 1

1

1

1

*

1

1 1

1

1

1

1

1

1

1

1

1

1

1

*

11

- events

*

1

1

1*

*

1

1

1

- services

*

1 1

1

1

1

1

*

1

+ execute()

CallServiceMethod

- services

*

Module

Core

*

1

+ execute()

- done

WorkQueueEntry

11

1

11

1

ModuleInterface

1

*

1*

SomeModule

Abbildung 1: UML-Klassendiagramm Core (überarbeitet)



3.2.2 Sequenzdiagramm Programmstart

systemConfigParser : SystemConfigParser

moduleMetaParser : ModuleMetaParser

: CoreServices

SomeModuleLibrary

someServiceHandler : SomeServiceHandler

moduleInfo : ModuleInfo

systemConfigProxy : SystemConfigProxy

serviceManager : ServiceManager

eventManager : EventManager

resolver : DependencyResolver

workQueue : WorkQueue

eventPipeReader : EventPipeReader

coreXMLRPCServer : CoreXMLRPCServer

callServiceMethod : CallServiceMethod

triggerEventMethod : TriggerEventMethod

moduleManager : ModuleManager

systemConfig : SystemConfig

streamLogSink : StreamLogSink

sysLogSink : SyslogSink

logManager : LogManager

coreApp : CoreApplication

: main

someServiceController : SomeServiceController

someModule : SomeModule

2.7.1.2.2.1.1: new()2.7.1.2.2.2.1: registerService()

2.7.1.2.2.2: registerService()

2.7.1.4.5.1: registerEventHandler()

2.7.1.2.2.1: new()

2.7.1.2.1: loadLibrary()

2.7.1.2.2: module_create()

2.7.1.4.5: init()

2.7.1.4.4: resolve()

2.7.1.4.3: addDependency()

2.7.1.4.2: addNode()

2.7.1.4.1: new()

2.7.1.4: initServices()

2.7.1.3: getServiceManager()

3.2: run()

3.1.1: run()3.1: start()

2.10.2: new()

2.10.1: new()

2.10: new()

2.9: new()

2.8: new()

2.7.1.2.3: new()

2.7.1.2: load()

2.7.1.1.2: parse()

2.7.1.1.1: new()

2.7.1.1: new()

2.7.1: myLoadModule(path)

2.2.2: parse()

2.2.1: new()

2.2: new()

2.6.2: registerCoreService()

2.6.1: registerCoreService()

2.6: registerCoreServices(coreApp)

2.7: loadModulesFromDirectory(modulePath)

2.1.4: registerLogSink(streamLogSink)

2.1.3: new()

2.1.1: new()

2.1.2: registerLogSink(sysLogSink)

2.5: new()

2.4: new()

2.3: new()

2.1: new()

3: run()

2: init()

1: new()

Abbildung 2: UML-Sequenzdiagramm Programmstart



3.3 Code Walkthrough

Die schwerwiegendsten Schwächen, welche anhand eines Code-Walkthroughs entdeckt wurden, werden in diesem Abschnitt für jede Klasse dokumentiert. Einleitend werden die Schwächen, auf welche der Code untersucht wird, aufgelistet.

3.3.1 Potentielle Refactorings Extract, Inline Method Hide Method Extract, Inline Class Extract, Inline Subclass Pull up and push down Change Value to Reference Change Reference to Value

3.3.2 EventManager getAllEvents EventType-Objekte in Rückgabe-Vektor sollten konstant sein.

Die zurückgegebenen Objekte dürfen nicht manipuliert werden, aus diesem Grund muss der Code so angepasst werden, dass diese als konstant deklariert werden.

3.3.3 ModuleInfo Harmonisierung der Verwendung von set versus vector.

In dieser Klasse werden aus keinem ersichtlichen Grund die Konstrukte set und vec-tor eingesetzt. Um die Effizenz beim Suchen zu erhöhen, werden die Vektoren durch Sets, welche sortiert sind, ersetzt. Zudem werden mit dieser Massnahme die Lesbarkeit und die Verständlichkeit des Codes erhöht.

getMetaDependencies korrekte Fehlerbehandlung falls der gesuchte Service nicht existiert.

Bei der STL-Implementierung von map wird beim Suchen in dieser mit dem Konstrukt myMap[key] im Fall, dass kein passender Wert gefunden wurde, ein NULL-Wert in die map eingefügt. Dies führt bei der weiteren Verwendung zu Abstürzen wegen fehlerhaften Speicherzugriffen. Um diesen Effekt zu umgehen, kann die zur Verfügung gestellte Me-thode myMap.find(key) benutzt werden, welche einen iterator zurückgibt. Falls myMap.end() ohne Ergebnis erreicht wird, ist der gewünschte Wert nicht in der Collec-tion vorhanden.

prepareServiceDependency aus Header-File löschen, wird nie verwendet. Diese Methode stellt eine Implementations-Leiche der Alpha-Version dar und kann ersatzlos gelöscht werden.

3.3.4 ModuleMetaInfo Aus Effizienzgründen wurden die Felder dieser Klasse als public deklariert. Der Zugriff erfolgt nur aus den Klassen ModuleInfo und ModuleMetaParser. Um die Sicherheit zu erhöhen, werden alle Felder auf protected geändert. Die Klassen, welche Module-MetaInfo verwenden, werden als friend-Klassen definiert.

3.3.5 ModuleMetaParser In den Handlern für Start- und End-Elemente dürfen keine Exceptions geworfen werden, da Expat in C implementiert ist. Die Fehler müssen zwischengespeichert und später aus-serhalb den Handlern behandelt werden.

3.3.6 ParamStruct Die Methode setParam() kann in der Methode setStrParam() wiederverwendet werden, was eine Code-Duplizierung vermeidet.

clear() Alle Elemente freigeben, nicht nur Liste löschen.



In der Methode clear() wurde entdeckt, dass nur die verwendete Liste gelöscht wurde, die darin enthaltenen Objekte aber nicht freigegeben wurden. Dies führt zu einem Memo-ry-Leak, welches aus dem einfachen Grund nicht entdeckt wurde, da die Methode clear() bislang nie verwendet wurde.

3.3.7 ParamString printXML() switch/case verwenden anstatt if/else.

3.3.8 ServiceInfo Refactoring Extract Subclass für CoreServices

Für Systemdienste könnte theoretisch eine spezialisierte Unterklasse von ServiceInfo eingesetzt werden. Die Vorteile (eine einzige Methode könnte einfacher geschrieben wer-den bzw. ein Test auf NULL würde entfallen) sind aber so gering, dass sich der Aufwand nicht lohnt.

3.3.9 ServiceMetaInfo Aus Effizienzgründen wurden die Felder dieser Klasse als public deklariert. Der Zugriff erfolgt nur aus den Klassen ModuleInfo und ModuleMetaParser. Um die Sicherheit zu erhöhen, werden alle Felder auf protected geändert. Die Klassen, welche Module-MetaInfo verwenden, werden als friend-Klassen definiert.

3.3.10 ServiceRequest Refactoring Inline Class

Die ganze Klasse wird eigentlich nicht mehr benötigt, da beim Aufruf in den Klassen ServiceInfo und ServiceManager stattdessen direkt die beiden in ServiceRe-quest gekapselten Parameter übergeben werden können.

Im Hinblick auf die Berechtigungsstruktur macht die Klasse ServiceRequest jedoch wieder Sinn, da in dieser ein weiteres Feld mit den Benutzerdaten ergänzt und übergeben werden kann. Wenn dies so implementiert würde, müsste jedoch die Erzeugung des Ser-viceRequest-Objekts in die Klasse CallServiceMethod verschoben werden, da die-se die Benutzerdaten kennt.

3.3.11 SystemConfig set- und delete-Methoden Aufruf von setLastChange()

Um immer ein aktuelles Datum der letzten Änderung zu haben, ist es notwendig, dass ändernde Methoden dieses aktualisieren. Betroffen sind sämtliche set- und delete-Methoden der Klasse SystemConfig. Neu rufen diese Methoden zusätzlich set-LastChange auf.

3.3.12 SystemConfigMetaParser In den Handlern für Start- und End-Elemente dürfen keine Exceptions geworfen werden, da Expat in C implementiert ist. Die Fehler müssen zwischengespeichert und später aus-serhalb den Handlern behandelt werden.

3.3.13 CoreXMLRPCServer etc. Die HTTP-Authentication, die im Rahmen der Studienarbeit in XmlRpc++ eingebaut wurde, sollte noch etwas refactored werden, damit korrekte HTTP 401-Header zurückge-geben werden – einige XML-RPC-Client-Bibliotheken bestehen darauf, zuerst eine 401-Antwort zu erhalten, auch wenn vorher bereits ein Username/Passwort eingestellt wurde.

Zu diesem Zweck sollte eine neue abstrakte Basisklasse XmlRpcServerAuthenticator er-stellt werden, die eine Methode zum Überprüfen der Credentials enthält. Somit kann dann beim Erstellen des XmlRpcServer-Objekts der Authenticator auf eine eigene Imp-lementierung gesetzt werden. Bei jedem Request wird der Authenticator zur Überprüfung aufgerufen, und wenn er false zurückgibt, generiert XmlRpc++ eine 401-Antwort.



3.4 Fazit der Codeanalyse Zusätzlich zum Code-Walkthrough wurden einige Überlegungen zu Performance und all-gemeinen Belangen angestellt.

3.4.1 Template-Overhead Der Code des Cores verwendet (notwendigerweise) viele Collections aus Objekten, die in Form von Pointern abgelegt werden. Dazu werden die Collection-Klassen der STL-Library (vector, set, map) verwendet. Das Problem dabei ist, dass für jede mögliche Kombination aus Collection-Typ und Datentyp der Werte (sowie auch der Keys für Maps) ein Template instanziiert werden muss – und zwar obwohl die Werte fast immer sowieso nur Pointers sind, sich am Code des Templates also intern nichts ändert.

Da unklar war, wie viel der so verursachte Overhead tatsächlich ausmacht, wurden die kompilierten Binaries des Cores mit objdump untersucht und mit simplen Perl-Scripts etwas umformatiert.

Nachstehend die Tabelle der 10 grössten Symbole:

Grösse (Bytes)

Symbolname

5195 strtod

4337 XmlRpc::XmlRpcServerConnection::executeMulticall(std::string const&, XmlRpc::XmlRpcValue&, XmlRpc::XmlRpcValue&) 3894 ModuleMetaParser::startElement(void*, char const*, char const**)

3670 SystemConfigParser::startElement(char const*, char const**)

2773 CallServiceMethod::execute(XmlRpc::XmlRpcValue&, XmlRpc::XmlRpcValue&, std::string, std::string) 2619 SystemConfigParser::SystemConfigParser(std::string, SystemConfig*)

2619 SystemConfigParser::SystemConfigParser(std::string, SystemConfig*)

2613 ModuleMetaParser::parse()

2507 SvcUserManager::checkUser(Param*)

2466 XmlRpc::XmlRpcServerConnection::generateFaultResponse(std::string const&, int)

Tabelle 1: die 10 grössten Symbole in m0n0cored

Es fällt auf, dass Konstruktoren doppelt vorkommen. Auf der Suche nach dem Grund für dieses Phänomen stiessen wir auf die „non-bugs“-Liste von GCC6. Anscheinend generiert GCC 3.x bis zu drei verschiedene Konstruktoren:

Complete object constructor Base object constructor Allocating constructor

Die ersten zwei können auf einen einzigen reduziert werden, falls keine virtuellen Basis-klassen eingesetzt werden; zwei Konstruktoren sind aber immer vorhanden. In GCC 2.x wurde dies noch mit einem einzigen Konstruktor und einem versteckten Parameter ge-löst; GCC 3.x ist aber unter FreeBSD 6 obligatorisch.

Es hat sich herausgestellt, dass der Template-Overhead (vector/set/map mit unter-schiedlichen Typen) viel kleiner ausfällt, als zunächst angenommen: nur 1-2 KB pro ver-wendeter Templateinstanz.

Es wurde zunächst noch in Erwägung gezogen, für Collections statt STL die „boost Poin-ter Container Library“7 zu verwenden. Diese Containerklassen verwalten die in sie einge-fügten, heap-allozierten Objekte selbständig; wenn also ein Objekt aus so einem Contai-ner entfernt wird, so sorgt der Container dafür, dass der davon belegte Speicher wieder freigegeben wird. Der Container ist also der „Eigentümer“ des Objekts. Die boost-Containerklassen verwenden intern STL-Container mit void-Pointern; somit hätte man sich dort einige Templateinstanzen sparen können. Angesichts des geringen Overheads

6 http://gcc.gnu.org/bugs.html#nonbugs_cxx 7 http://www.boost.org/libs/ptr_container/doc/ptr_container.html



(GCCs Eigenheit, alle Konstruktoren doppelt anzulegen, verursacht viel mehr Overhead) und der potentiellen Probleme mit dem frühzeitigen Löschen von Objekten beim Entfer-nen aus einem Container (vorallem bei ModuleInfo und ServiceInfo) wurde diese Variante aber wieder verworfen.

3.4.2 If/else-Blöcke für Operation-Demultiplexing in Service-Handlern etc. Wenn eine Operation auf einem bestimmten Service über den Core aufgerufen wird, so leitet der Core den Aufruf an die Methode handleServiceRequest() im entspre-chenden Service-Handler weiter. Diese Methode ist dann selber dafür zuständig, je nach gewünschter Operation (deren Name als String übergeben wird) die nötigen Aktionen durchzuführen. Dies wurde bewusst so gewählt, damit nicht jede Operation als eigene Klasse implementiert werden muss, und damit der Core neben den Services nicht auch noch die Operationen zu verwalten hat.

In der Proof-of-Concept-Implementation wurde das Demultiplexing auf den Operations-namen jeweils mit einem if/else-Block und einfachen String-Vergleichen behandelt. Dies ist aber nicht sehr effizient (für die als Letztes im if/else-Block aufgeführte Operation müssen sämtliche Vergleiche durchgeführt werden) und auch nicht besonders übersicht-lich. Wünschenswert wäre die Verwendung eines switch/case-Blocks, aber das ist in C++ mit Strings nicht möglich.

Nach einiger Überlegung war ein Lösungsansatz gefunden: die Abbildung von einem String-Operationsnamen auf einen besser handhabbaren Datentyp (Integer bzw. Enum) könnte effizient durch eine STL-Map erfolgen, und danach liesse sich auf den resultieren-den Enum-Wert bequem ein switch/case-Block anwenden.

Dieselben Verbesserungen können auch bei den XML-Parsern (ModuleMetaParser und SystemConfigParser) angewendet werden.

Die Suche nach Lösungen für diese Problematik im Internet führte zu Beschreibungen desselben Ansatzes8.

3.4.3 Methoden-Deklaration Falls Methoden nichts verändern, sollen sie als konstant deklariert werden.

3.4.4 Verwendung der Param-Typen Mit der jetzigen Implementation der Param-Typenhierarchie muss Code, der Param-Typen castet (z.B. in ServiceHandlern) immer zuerst prüfen, ob der Typ korrekt und der jeweilige Param nicht NULL ist. Letztere zwei Prüfungen können zwar mit einem dyna-mic_cast auf eine reduziert werden (falls der Cast fehlschlägt, wird ebenfalls NULL zu-rückgegeben); die Gefahr ist aber gross, dass mal so eine Prüfung vergessen geht, und zudem leidet die Lesbarkeit des Codes.

Es wäre sinnvoll, eine Sammlung von statischen Hilfsmethoden zur Verfügung zu stellen, die einen generischen Param in einen gewünschten Typ umwandeln, wenn dies möglich ist, und ansonsten eine Exception auslösen. Diese Hilfsmethoden können dann gleich auch noch auf NULL-Pointer prüfen und ebenfalls eine (andere) Exception werfen.

3.4.5 Versionierung der Modulschnittstelle Es ist noch aufgefallen, dass die Schnittstelle zwischen Modul und Core nicht versioniert ist. Wenn also Änderungen am Core vorgenommen werden, die die Binärkompatibilität beeinträchtigen (z.B. grössere Änderungen an den „Interfaces“ bzw. abstrakten Basis-klassen ModuleInterface, ServiceHandler, EventHandler, SystemConfigIn-terface), ist es möglich, dass alte Module geladen werden können, aber zur Laufzeit Zugriffsverletzungen (oder noch schlimmer: subtile Fehler durch Überschreiben von Spei-cherbereichen anderer Klassen/Objekte) auftreten.

Aus diesem Grunde sollte die Modulschnittstelle eine fest in den Core einkompilierte Versionsnummer (eine simple Ganzzahl genügt) erhalten, die beim Laden des Moduls mit der Angabe in der XML-Metainformationsdatei verglichen wird. Bei Nichtübereinstim-mung wird das Laden des jeweiligen Moduls abgebrochen.

8 z.B. http://www.codeguru.com/cpp/cpp/cpp_mfc/article.php/c4067/



4 Komplettierung der Core-Funktionalitäten

Im Gegensatz zum Proof of Concept, welcher im Rahmen der zweiten Studienarbeit er-stellt wurde, sollte der Release 1.0 von m0n0core sämtliche Funktionen umfassen, welche zur reibungslosen Verwaltung von Modulen benötigt werden.

4.1 Logging-Infrastruktur Da im laufenden Betrieb sehr viele Log-Aktionen stattfinden, werden die Logging-Komponenten direkt im Core implementiert, um den Overhead eines Service-Aufrufs bei jeder Logmeldung (der bei einer Implementation der Logging-Komponenten als Modul er-forderlich wäre) zu vermeiden.

4.1.1 Format der Log-Meldungen In Anlehnung an das unter UNIX verbreitete syslog-Konzept besteht eine Log-Meldung aus einem beliebigen, einzeiligen ASCII-Text-String sowie einer Prioritätsstufe. Syslog definiert 8 Stufen; wir haben uns entschieden, nur deren 4 anzubieten, da beim Pro-grammieren die Entscheidung sonst häufig schwer fällt und die zusätzlichen Stufen kei-nen grossen Nutzen bringen. Folgende Prioritätsstufen sind definiert:

Debug o Meldungen, die bei der Diagnose von Problemen v.a. durch Entwickler oder

versierte Benutzer nützlich sein können; diese Meldungen werden im nor-malen Betrieb i.d.R. unterdrückt

Info o Zustandsmeldungen (z.B. beim Start einer Komponente), die kein Fehlver-

halten beschreiben Warning

o Meldungen über Fehlverhalten, das zwar nicht fatal ist (das Programm kann fortgesetzt werden), aber evtl. genauer untersucht werden sollte

Error o Meldungen über Fehler, die eine ordnungsgemässe Weiterführung des Pro-

gramms verunmöglichen

4.1.2 Klassendiagramm

+ log() : void

LogSink

- logLevel

StreamLogSink

+ unregisterSink()+ registerSink()+ log()

LogManager

+ log()

- name

LogSource

LogInterface

SyslogSink

- sinks

*

1

- manager 1

*

Abbildung 3: UML-Klassendiagramm Logging-Architektur

4.1.3 LogSource Um den Log-Aufruf möglichst einfach halten zu können, wird eine Proxy-Klasse zwischen die aufrufende Komponente und den LogManager geschaltet. Diese Klasse übernimmt die Funktion, der Log-Meldung einen vorgegebenen Text zur Identifikation der Kompo-nente hinzuzufügen. Somit muss sich ein Entwickler von Modulen nicht jedes Mal wenn ein Log-Eintrag gemacht wird darum kümmern, diese mitzugeben.

Zudem bietet die LogSource für die einfache Formatierung von Logstrings mit variab-len Komponenten eine Variante der Log-Funktion an, die einen printf()-kompatiblen Formatstring mit beliebig vielen Argumenten akzeptiert.



4.1.4 LogInterface Damit es bei der Weitergabe von LogSources an Module keine Probleme mit Vermi-schung von Core- und Modulcode gibt, erhalten Module nur einen Pointer auf ein Objekt der Klasse LogInterface (welche von LogSource erweitert wird) – vgl. SystemCon-figProxy.

4.1.5 LogManager Die hauptsächliche Aufgabe des LogManagers besteht darin, eine erhaltene Log-Meldung an die LogSinks zu verteilen. Zudem ist er damit betraut, die verschiedenen Log-Meldungs-Empfänger zu verwalten. Diese können sich bei ihm registrieren und im Bedarfsfall auch wieder abmelden.

4.1.6 LogSink LogSink stellt die gemeinsame Schnittstelle sämtlicher spezialisierter Meldungs-Empfänger dar.

4.1.7 SyslogSink Da wir bei unserer Implementierung des Cores auf FreeBSD aufbauen, wird in unserem Fall SyslogSink den zentralen Logger-Dienst darstellen. SyslogSink leitet Log-Meldungen über die syslog()-Bibliotheksfunktion an den lokalen Syslog-Daemon wei-ter.

4.1.8 StreamLogSink Zusätzlich wird eine Senke realisiert, welche beim Erstellen einen C++-Output-Stream und eine Prioritätsstufe als Parameter erhält. Sämtliche erhaltenen Log-Nachrichten, welche eine Priorität von grösser oder gleich dem voreingestellten Wert haben, werden während dem Betrieb in diesen Stream geschrieben (optional auch mit Zeitstempel).

4.2 HTTPS-Support für XML-RPC-Schnittstelle Wie bereits in der Anforderungsspezifikation erwähnt, soll die im Core implementierte XML-RPC-Schnittstelle HTTPS-fähig gemacht werden.

Im CVS-Repository9 von XmlRpc++ (der im Core verwendeten XML-RPC-Bibliothek) findet sich Code, der SSL-Unterstützung für den Client (XmlRpcClient) implementiert. Allerdings fehlt die Unterstützung im Server-Teil (der für uns interessant wäre), und zu-dem ist der Code ziemlich rudimentär (kaum Fehlerbehandlung etc.).

XmlRpc++ verwendet das Reactor-Pattern (mit select()), um mit einem einzigen Thread „gleichzeitig“ mehrere Clients bedienen zu können. Bei der Verwendung von SSL wird das aber erschwert, da man sich nicht darauf verlassen kann, auch tatsächlich (un-verschlüsselte) Nutzdaten lesen zu können, wenn select() einen lesbaren Socket signa-lisiert. Es ist sogar so, dass SSL_read(), welches zu

Diplomarbeit SS 2007 m0n0AP – Wireless Access...

Documents

Transcript of Diplomarbeit SS 2007 m0n0AP – Wireless Access...