Anschluss eines Studentenwohnheims an das Hochschulnetz / Internet

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Das Portal zur Kommunikation mit den Nutzern
1.1. Das Konzept
1.2. Umsetzung und Ergebnis

2. Die Anbindung der Wohnheime an das Hochschulnetz

3. Aktueller Zustand und geplante Änderungen
3.1. Installation des neuen Servers
3.2. Trafficzählung
3.3. Sperrpolitik
3.4. MAC-IP Binding
3.5. Öffentliche IP-Adressen im Wohnheim
3.6. Automatische Warnung bei 80% des Limits
3.7. Die Verwaltungssoftware

4. Konzeption des neuen Systems
4.1. Einrichtung des neuen Servers
4.2. Verwaltungssoftware
4.2.1. Anwendungsfälle
4.2.2. Konzeption der Datenbank
4.2.3. Hinweise zum Datenschutz
4.3. Vergabeschema der IP-Adressen
4.4. Automatische Adressvergabe mittels DHCP
4.5. Realisierung der MAC-IP Bindung und Firewallsperrung
4.5.1. Konzeption der Firewall
4.5.2. Beispiel: Freischaltung eines neuen Nutzers
4.5.3. Schnittstelle für die Verwaltungssoftware
4.6. Realisierung der Portsperre
4.7. Verwaltung von Sperrungen
4.8. Traffic-Zählung
4.8.1. Die Ausgaben des Trafficaccountingsystems
4.8.2. Auswertung der Zähler
4.8.3. Anzeige des Trafficzählers
4.9. Automatische Nutzerverwaltung
4.9.1. Alle 5 Minuten zu erledigen
4.9.2. Täglich zu erledigen
4.9.3. Wöchentlich zu erledigen

5. Wechsel zum neuen System
5.1. Migration der Daten
5.2. Umzug der Nutzer

6. Fazit

Literaturverzeichnis

A. Protokoll der Konferenz zur Neugestaltung des Wohnheimnetzes

B. Veraltetes Datenbankdiagramm der Nutzerverwaltung

C. ERM der Nutzerverwaltung

D. Auszug der Manpage des Firewall-Tools iptables [ipt02]

E. Anwendungsfälle für die Nutzerverwaltung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

1.1. Datenbankmodell des Nutzerkommunikationsportals

1.2. Das Portal zur Nutzerkummunikation im Stiel der Vogtshof Webseite

2.1. Funkstrecken des Studentenwerk Dresden in Görlitz

2.2. Verteilung des Netzes im Vogtshof

3.1. Gegenüberstellung der Trafficzählungsverfahren

3.2. Vereinfachte schematische Darstellung des Sperrmechanismusses im Istzustand

4.1. Virtuelle Maschinen des Wohnheimservers

4.2. ERD Zur Ressourcenverwaltung

4.3. ERD zur Nutzerverwaltung

4.4. ERD zur Datenhaltung für die Nutzerfunktionen

4.5. ERM der MAC-IP-Bindung

4.6. Vereinfachte schematische Darstellung der MAC-IP Bindung mit Sperrmöglichkeit

4.7. Notwendige Daten für das Sperren von Ports

4.8. ERM zur Verwaltung von Sperrungen

4.9. Verarbeitung der Trafficzähler

4.10. Traffic-Zähler auf der Webseite der Wohnheime

4.11. Detailierter Trafficzähler

Tabellenverzeichnis

4.1. Richtlinien zur Löschung personenbezogener Daten

4.2. Beispieldatensätze für die Portsperre

1. Das Portal zur Kommunikation mit den Nutzern

1.1. Das Konzept

Da das Netzwerk der beiden Studentenwohnheime in Görlitz für die Studenten gedacht ist, ist es von Vorteil, mit diesen bei der Entwicklung des Netzes zusammen zu arbeiten, um auch deren Wünsche und Anregungen berücksichtigen zu können. Zu diesem Zweck soll ein spezielles Portal entstehen, welches in die bestehende Webseite der Wohnheime als neue Sektion integriert werden soll. Dabei muss sicher gestellt werden, das dieser Teil der Webseite nur für die Bewohner der Wohnheime zugänglich ist.

Das Portal soll auf eine Datenbank basieren, welche für die Datenhaltung verantwortlich ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1.: Datenbankmodell des Nutzerkommunikationsportals

Anhand des Datenbankmodells lässt sich sehr leicht die Funktionsweise des Portals erkennen. Während die Administratoren Themen einstellen können und den Stand der Entwicklung durch die Angabe eines Status angeben und verändern können,

können die Nutzer darauf antworten und so eigene Ideen mit einbringen. Da jeder Nutzer eine feste IP-Adresse besitzt, kann man diesen anhand dieser identifizieren. Dadurch ist es den Nutzern möglich, den selben Namen für Antworten zu verwenden, ohne diesen immerwieder neu eingeben zu müssen.

1.2. Umsetzung und Ergebnis

Da die Webseite der Wohnheime auf einem Apache Webserver läuft, soll auch dieses Portal auf einen solchen Webserver laufen. Hier läst sich zudem der Zugriff auf bestimmte Inhalte mittels der Datei .htacc ess sehr einfach kontrollieren.

Das Portal selbst ist in PHP geschrieben. Hierbei wurde auf Modularität großen Wert gelegt und somit der Quelltext in funktionale Einheiten zerlegt:

- Die Verbindung zur Datenbank: Sämtliche Daten, welche für das Verbinden zur Datenbank notwendig sind
- Eine Schnittstelle zur Datenbank: Diese Datei regelt den Zugriff auf die Datenbank. Dadurch ist es problemlos möglich, die verwendete Datenbank auszutauschen.
- Die Abfragen und die auf diese basierende Funktionen: Hiermit kommuniziert das eigentliche Portal mit der Datenbank.
- Templates und Style Sheets: Hier wird das Design des Portals bestimmt. Dieses stammt von der Webseite der Wohnheime
- Javascripte: Die im Portal verwendeten Javascripte
- Das Portal: Hier wird aus sämmtlichen Bausteinen das Portal zusammen gebaut.

Als Datenbanksystem wurde PostgreSQL in der Version 8.3.3 verwendet. Die Schnittestelle zur Datenbank ist momentan für die Verwendung von PostgeSQL und MyS- QL vorbereitet.

Die Unabhängigkeit von einer speziellen Datenbank wird einerseits daduch erreicht, das auf Datenbankspezifische Abfragen und Funktionen verzichtet wird und zum anderen durch die Schnittstelle zur Datenbank, welche eigene Funktionen zur Datenbankkommunikation implementiert. Diese erkennen die verwendete Datenbank und nutzen dann deren spezielle Funktionen.

Beispiel: Die Funktion query verwendet, entsprechend des eingesetzten Datenbanksystems entweder die Funktion mysql_query oder pg _query um eine Abfrage an die Datenbank zu senden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2.: Das Portal zur Nutzerkummunikation im Stiel der Vogtshof Webseite

2. Die Anbindung der Wohnheime an das Hochschulnetz

Die Studentenwohnheime in Görlitz bieten ihren Bewohnern die Möglichkeit, mit ihren privaten Rechnern das Hochschulnetz zu nutzen. Das Netz wird dabei von der Hochschule Zittau / Görlitz dem Studentenwerk kostenlos zur Verfügung gestellt. Der Übergabepunkt des Hochschulnetzes ist die Heynestraße. Im Gegenzug hat sich das Studentenwerk bereit erklärt, den Anschluss eines Teils der Hochschule, dem Gebäude GIII auf dem Obermarkt zu realisieren. Hierfür wurde vom Studentenwerk Dresden mehrere Richtfunkverbindungen eingerichtet, welche sowohl die Wohnheime als auch den Obermarkt an das Hochschulnetz anschließen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.: Funkstrecken des Studentenwerk Dresden in Görlitz

Im Wohnheim Vogtshof wird das Netz verteilt und den Bewohnern beider Wohnheime, sowie dem Gebäude GIII der Hochschule zur Verfügung gestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.: Verteilung des Netzes im Vogtshof

Der Wohnheimserver übernimmt eine Reihe von Aufgaben, von denen ein großer Teil den Hauptteil dieser Arbeit bilden.

3. Aktueller Zustand und geplante Änderungen

Wie bereits erwähnt, erfüllt der Wohnheimserver eine Reihe von Aufgaben, welche der Nutzerverwaltung und Netzintegrität dienen. Da die Nutzerverwaltung nicht den Anforderungen der Rahmennetzordnung [RNO07] genügt, wurde am 19.06.2008 eine Konferenz, an der Vertreter der Hochschule Zittau / Görlitz, dem Studentenwerk Dresden und den Netzwerkadministratoren der Wohnheime Vogtshof und Hirschwinkel beteiligt waren, abgehalten. Im Anhang A ab Seite 49 ist das Protokoll dieser Besprechung. Dieses bildet, zusammen mit de Rahmennetzordnung [RNO07] die Anforderungen an das Wohnheimnetz.

Um sämtlichen Anforderungen gerecht zu werden, sollen folgende Punkte umgesetzt werden:

1. Installation und Einrichtung des neues Servers laut Anhang A
2. Zählung des Traffcs laut [RNO07, § 7.7] mit Anpassung laut Anhang A
3. Sperrung laut [RNO07, §§ 7.2, 7.8] mit genehmigten Anpassungen
4. Sichere MAC-IP Bindung laut Anhang A
5. Umstellung auf öffentliche IP-Adressen
6. 80%-Warnung laut [RNO07, § 7.8] und Anhang A
7. Erstellung der neuen Verwaltungssoftware

Die folgenden Abschnitte zeigen kurz die momentanen Regelungen zu diesen Punkten und zeigen, wo genau Neukonzeptionierungen notwendig sind.

3.1. Installation des neuen Servers

Zur Zeit befinden sich im Vogtshof mehrere Server-Rechner im Einsatz, welche jeweils eine andere Funktion erfüllen. Es existiert eine Brücke, ein Gateway und ein Notfallserver.

Die primäre Aufgabe der Brücke ist es, die beiden Netzsegmente der Hochschule und der Wohheime zu verbinden. Auch der sekundäre DNS läuft auf diesem Rechner. Weiterhin laufen hier einige Projekte mit niedriger Priorität. Das Gateway übernimmt die gesammte Nutzerverwaltung und stellt die Netzintigrität durch Trffic-Shaping [Wik08-1] und eine Firewall sicher. Der Notfallserver übernimmt zwei wichtige Funktionen. Zum einen, wie der Name schon sagt, dient dieser als Notfallsystem, falls das Gateway oder die Brücke ausfällt. Zum Anderen dient dieser Rechner als Webserver für die Internetpäsenz der Wohnheime unter www.vogtshof.de.vu.

Da diese drei Rechner schon über zehn Jahre alt sind, sollen diese nun ausgemustert werden. Dafür wurde ein neuer Rechner gestellt, welcher als Ersatz dient. In Zukunft wird es also keine drei physikalischen Maschinen, sondern nur noch eine geben.

3.2. Traffczählung

Momentan werden die Trafficzähler der Nutzer jeden Montag um 4:30 zurück gesetzt. Der Traffic wird also immer von einer Woche gezählt. Laut Rahmennetzordnung [RNO07, § 7.1 auf S. 5] soll die Zählung allerdings immer die letzten sieben Kalendertage berücksichtigen. Statt den Traffic also von Montag bis Sonntag zu zählen, wie es momentan gehandhabt wird, soll nun eine Art Schieberegister mit sieben Tagen für den Traffic eingerichtet werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1.: Gegenüberstellung der Traffczählungsverfahren

3.3. Sperrpolitik

Die Sperrpolitik wird gemäß der Rahmennetzordnung [RNO07, §§ 7.2, 7.8] umgesetzt. Die Nutzer werden allerdings automatisch gesperrt, noch bevor diese ihr Limit überschritten haben. Zur Zeit liegt die Grenze bei 98% des Limits. Dadurch kann eine automatische Entsperrung, außerhalb der RNO [RNO07, § 7.8] zum Wochenbeginn erfolgen, wodurch lange Sperrzeiten vermieden werden. Einzelnen Nutzer haben jedoch die Möglichkeit, sich von der automatischen Sperre auszuschließen. Dies geschieht momentan durch Veränderung des Quelltextes. In einem solchen Fall greift die RNO.

Der Sperrvorgang an sich wird über iptables - einem Paketfilter und NAT unter Linux - realisiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2.: Vereinfachte schematische Darstellung des Sperrmechanismusses im Istzustand

Aufgrund geänderter Rahmenbedingungen, welche später erläutert werden, wird es in Zukunft nicht mehr sinnvoll sein, Nutzer auf diese Weise zu sperren.

In Zukunft soll bei Sperrungen ähnlich verfahren werden. Es folgende organisatorischen Dinge berücksichtigt werden:

1. Nicht bei Wochenbeginn entsperren, sondern wenn der Traffic unter 80% gefallen ist.
2. Ausnahmen sollen durch die Datenbank umgesetzt werden.
3. Datenquelle des Trafficzählers soll eine Kombination aus Datenbank- (für die letzten 6 Tage) und Dateizugriff (für den aktuellen Tag) sein.
4. veränderte Methode des Sperrens

3.4. MAC-IP Binding

Zur Zeit gibt es keine Bindung zwischen den MAC- und IP-Adressen der Nutzer. Zu Diagnosezwecken wird jedoch erfasst, welche IP wann mit welchen MACs im Netz ist. Dadurch ist es beispielsweise möglich, Addresskonflikte zu lösen, falls ein Nutzer versehentlich eine falsche IP eingestellt hat.

In Zukunft soll es aber eine feste Bindung zwischen der MAC- und der zugewiesenen IP-Adresse der Nutzer geben. Es soll also nur noch möglich sein, mit diesen festen Kombinationen ins Netz zu kommen. Um dies zu erreichen wird eine Kombination aus DHCP und dem iptables -Tool verwendet werden. Es ist geplant, die MAC-IP Bindung mittels iptables und das Sperren der Nutzer als eine Aufgabe zu betrachten und zu realisieren.

3.5. Öffentliche IP-Adressen im Wohnheim

Die Wohnheime Vogtshof und Hirschwinkel in Görlitz verwenden zur Zeit das private Netz 10.10.0.0/16 für die Nutzer. Diese werden über ein NAT zu ihrer eigenen festen IP gemapped. In Zukunft soll diese Lösung jedoch nicht mehr verwendet werden. Jeder Nutzer soll eine feste IP bekommen, über welche er direkt, also ohne NAT, mit dem Hochschulnetz verbunden ist.

Die Umstellung soll dabei für die Nutzer mit so wenig Aufwand wie möglich verbunden sein.

3.6. Automatische Warnung bei 80% des Limits

Auf der Webseite der Wohnheime haben die Nutzer die Möglichkeit, ihren aktuellen Trafficzähler jeder Zeit zu kontrollieren. Laut RNO reicht dies jedoch nicht aus. Die Nutzer sollen entweder per E-Mail oder per Post bei Erreichen von 80% ihres Limits gewarnt werden.

In Zukunft wird dies auch so geschehen. Da sich Nutzer allerdings von diesen Benachrichtigungen belästigt fühlen könnten, sollen diese die Möglichkeit bekommen, sich von den automatischen Warnungen auszuschließen.

3.7. Die Verwaltungssoftware

Da die aktuelle Nutzerverwaltug aus verschiedenen Gründen schlecht an die neuen Anforderungen anzupassen ist, wird auf dem neuen Server gleich eine neue Nutzerverwaltung entwickelt. Teile des alten Systems, welche ohne oder nur mit geringenn Aufwand weiter zu verwenden sind, werden in das neue System integriert.

Die wichtigsten Gründe für diesen Entschluss sind:

- Eine schlecht geplante Datenbank, welche sich nur unter Inkaufname von weiteren Inkonsistenzen den neuen Anforderungen anpassen lässt. Siehe dazu das Datenbankdiagramm der Nutzerverwaltung im Anhang B ab Seite 51
- Teilweise schlecht strukturierte Software: z.B.: Doppelte Funktionsnamen, schlecht lesbarer Quelltext, teilweise schlecht modularisiert.
- Schlechte Benutzerschnittstelle: z.B.: Kein Zentraler Einstiegspunkt, teilweise starke Redundanzen in den Oberflächen.

4. Konzeption des neuen Systems

Statt die neuen Anforderungen in das bestehende System zu integrieren, wird der umgekehrte Weg eingeschlagen. Teile des alten Systems, welche noch zu verwenden sind, werden in das neue System integriert. Wie dies im Einzelnen von Statten geht, werden die folgenden Abschnitte zeigen.

4.1. Einrichtung des neuen Servers

Der neue Server ermöglicht es, das neue System bereits fertig zu entwickeln und zu testen, während die Nutzer noch über das alte System ans Netz angebunden sind. So können Ausfallzeiten sehr gering gehalten werden.

Die Grundinstallation des neuen Servers beinhaltet mehrere virtuelle Maschinen (VM), welche jeweils einem speziellen Zweck dienen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.1.: Virtuelle Maschinen des Wohnheimservers

Die wichtigsten VMs sind dabei sicherlich das Gateway und der Webserver. Auf dem Gateway befindet sich die gesammte Netzverwaltung, wozu auch die Nutzerverwaltung zählt. Der Webserver hingegen ist für die Internetpräsenz der Wohnheime zuständig. Außerdem können sich die Bewohner hier über den aktuellen Stand ihres Trafficzählers informieren. Auf den Betrieb einer seperaten Brücke wird verzichtet.

4.2. Verwaltungssoftware

In den Wohnheimen Vogtshof und Hirschwinkel wohnen bis zu 333 Bewohner. Alle haben das Recht, sich für die Nutzung des Wohnheimnetzes anzumelden. Um sicher zu stellen, dass alles mit rechten Dingen zugeht und sich alle an die Rahmennetzordnung [RNO07] halten, haben die Administratoren im Bezug auf die Nutzerverwaltung eine Reihe von Aufgaben zu erfüllen.

Das Ziel ist es, diese Aufgaben weitestgehend automatisch zu erledigen, um den Aufwand der z.Zt. amtierenden und zukünftigen Administratoren der Wohnheime so gering wie möglich zu halten. Es ist daher erforderlich, Software zu entwickeln, welche diese Anforderungen weitestgehend automatisiert und die Administratoren durch die einzelnen Prozesse der Verwaltung führt.

Manipulationen des Systems, wie z.B. die Realisierung der MAC-IP Bindung gehören nicht zur Nutzerverwaltung. Hierfür werden spezielle Schnittstellen entwickelt, welche von der Nutzerverwaltung verwendet werden. Diese werden in späteren Abschnitten beschrieben.

Dieses Kapitel wird sich mit der Konzeptionierung, aber nicht mit der vollständigen Implementierung dieser Software beschäftigen. Mit der Implementierung sind teilweise weitere Personen betraut. In solchen Fällen wird darauf hingewiesen.

4.2.1. Anwendungsfälle

Die Nutzerverwaltungssoftware soll möglichst alle Aufgaben, welche ein Administrator zu erledigen hat, ermöglichen und ihn dabei unterstützen. Im Rahmen meiner langjährigen Tatigkeit als Administrator der beiden Wohnheime habe ich eine sehr gute Vorstellung von dem, was die Nutzerverwaltung leisten muss.

Im Anhang E ab Seite 58 befinden sich die wichtigsten von mir entworfenen Anwendungsfälle.

4.2.2. Konzeption der Datenbank

Der wichtigste Bestandteil der Nutzerverwaltung ist die Datenbank. Es muss daher sicher gestellt werden, dass sämmtliche Anwendungsfälle auf dieser abgebildet werden können.

Um die Datenhaltung möglichst optimal zu gestalten, teilt sich diese in drei Funktionsbereiche:

1. Ressourcenverwaltung
2. Nutzerverwaltung
3. Nutzerfunktionen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.2.: ERD Zur Ressourcenverwaltung

Dieser Teil der Datenbank ist für die Verwaltung der zur Verfügung stehenden Ressourcen zuständig. Diese können dann den Nutzern zugeteilt werden. Die hier enthaltenen Entitäten sind eher statisch umd verändern ihre Datenbestände nur sehr selten bis nie.

stat_IP:

Dies ist die Repräsentation sämmtlicher verfügbarer IP-Adressen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4.3.: ERD zur Nutzerverwaltung

Die Nutzerverwaltung ist für die Speicherung der Personenbezogenen Daten der Nutzer, sowie für die Zuteilung der Ressourcen zuständig.

stat_NutzerIP:

Hierbei handelt es sich um die Untermenge an IP-Adressen, welche an Nutzer vergeben werden können. Dies bedarf zusätzlich noch einer Spezialisierung der Attribute.

Abbildung in dieser Leseprobe nicht enthalten

[...]

---