Benutzer-Werkzeuge

Webseiten-Werkzeuge


de.bkp:intern:ipa:tp2022:ipa_tp2022

Inhaltsverzeichnis

IEEE 802.1X - Authentifizierung für LAN und WLAN

IPA 2022
01.04.2022 - 20.04.2022
Kandidat: Timafei Pabiarzhyn

Teil 1 – Umfeld und Ablauf

Projektorganisation und Aufgabenstellung

Personen und Adressen

Kandidat
Pabiarzhyn Timafei

Betrieb (=Durchführungsort)
Rafisa Informatik GmbH
Bernstrasse 88, PLZ 8953
T 079 152 95 78 (am bester erreichbar)
G 044 910 50 10
M tim.pabiarzhyn@gmail.com
Verantwortliche Fachkraft
Rüefli Egil
Rafisa Informatik GmbH
Bernstrasse 88, 8953 / Dietikon
T 078 767 84 04 (am bester erreichbar)
G 044 910 50 10
M e.rueefli@rafisa.ch
BerufsbildernIn/Lehrfirma
Wegelin Rudolf
Rafisa Informatik GmbH
Bernstrasse 88, 8953 / Dietikon
T 076 555 05 55 (am bester erreichbar)
G 044 910 50 10
M r.wegelin@rafisa.ch
Hauptexperte
Akgül Tarkan
T 079 322 81 58
M tarkan.akguel@ploit.ch
Nebenexperte
Pascutto Andreas
T 079 351 00 38
M a.pascutto@bluewin.ch

Aufgabestellung

Original gemäss Eingabe der verantwortlichen Fachkraft
Hier ist die gesamte Aufgabestellung inkl. Titel und Ausgangslage UNVERÄNDERT hineinzukopieren.

Detaillierte Aufgabenstellung

Titel der Arbeit

IEEE 802.1X - Authentifizierung für LAN und WLAN

Ausgangslage

In der Rafisa Informatik GmbH werden zurzeit 50 Lernende der Fachrichtungen Applikationsentwicklung, ICT-Fachmann/Fachfrau, Systemtechnik und Betriebsinformatik sowie Plattformentwicklung zu InformatikerInnen EFZ ausgebildet. Neben dem regulären Ausbildungsbetrieb bietet die Rafisa auch Eignungsabklärungen, Arbeitstrainings, Vorbereitungen für eine Informatik-Ausbildung sowie Bewerbungs- und Job-Coachings an.

Das Netzwerk der Rafisa wird zusammen mit den Lernenden stetig weiterentwickelt und den neuen technologischen und Sicherheits-Standards angepasst. In einer ersten Phase wurde das ursprüngliche Netz in verschiedene logische Teilnetze (VLAN) aufgeteilt. In einem weiteren Schritt wurden alle Firmenstandorte über VPN-Verbindungen in das bestehende VLAN-Konzept integriert. Schliesslich wurde eine WLAN-Infrastruktur aufgebaut, in welcher Clients über Pre-Shared-Keys nach der Anmeldung dem für sie vorgesehenen VLAN zugewiesen werden. In der vorliegenden IPA sollen nun die Grundlagen zur Einführung des 802.1x Standards im gesamten Netzwerk der Rafisa geschaffen werden.

Detaillierte Aufgabenstellung

1. Ziel des zu realisierenden Systems


Das Ziel des Projektes besteht darin, die Grundlagen für eine erfolgreiche Einführung des IEEE Standards 802.1X im Netzwerk der Rafisa zu erarbeiten. Dazu soll in einer Testumgebung der Netzwerkzugang gemäss 802.1X implementiert werden. Sowohl an den physischen LAN-Ports als auch im WLAN sollen die Supplicants (Client-Geräte) über einen Authenticator (Switch, WLAN-AP) sowie einen Authentifizierungs-Server (Radius-Sever) Zugriff auf die entsprechenden VLAN erhalten. Als Backend-Lösung für die Benutzerkennung ist ein Active-Directory-Service einzurichten. Die Authentifizierung und Autorisierung soll aufgrund der Zugehörigkeit eines Nutzers zu einer Sicherheitsgruppe erfolgen.

2. Anforderungen


2. 1. Anforderungen an die Testumgebung


Netzwerk


Unter Verwendung der zur Verfügung gestellten Hardware soll ein Test-Netzwerk (LAN und WLAN) eingerichtet werden. Das Netzwerkdesign soll sich bezüglich Adressierung, zu realisierende VLAN und Zugriffsberechtigungen sowie Namenskonzept an den Firmenstandards orientieren, muss aber für die Testumgebung entsprechend angepasst werden. Es sind nur die für die Zielerreichung notwendigen VLAN einzurichten, die Systeme sind den korrekten VLAN zuzuordnen. Das Testnetzwerk ist in einem Netzwerkdiagramm zu dokumentieren:

* VLAN und Subnetz-Adressierung sind gemäss Firmenstandard eingerichtet

* Alle benötigten Network-Services sind gemäss eigener Planung eingerichtet

* Die Hostnames aller Systeme sind gemäss Firmenstandard vergeben und können korrekt aufgelöst werden

* Die administrativen Zugänge zu den Servern und den Netzwerkgeräten sind verschlüsselt

* Das Testnetzwerk ist in einem Netzwerkdiagramm dokumentiert

Proxmox VE Virtualisierungsplattform


Auf einem dedizierten Server ist die Proxmox VE Virtualisierungsumgebung einzurichten. Sie dient als Basis für alle weiteren benötigten Server, welche als VM erstellt werden sollen. Auf den VM sind folgende Dienste zu realisieren: AD als Backend für Benutzerdatenbanken, Authentifizierungs-Server, WLAN-Controller. Wie viele VM angelegt werden und welche Betriebssysteme zur Anwendung kommen ist Teil der zu erbringenden Planungsleistung. Dabei müssen aber die zur Verfügung stehenden Mittel und Methoden berücksichtigt werden (s.u.).

* Die Konfiguration des Servers gewährleistet die Datensicherheit bestmöglich

* Die Serverinfrastruktur (VM) für die benötigten Dienste ist evaluiert und gemäss Planung realisiert

* Die für die VM benötigten virtuellen Ressourcen sind evaluiert und gemäss Planung realisiert

Benutzer-Backend


Als Benutzer-Backend ist ein Active-Directory-Service einzurichten. Die Organisationsprinzipien sind den Firmenstandards zu entnehmen. Es sind die Sicherheitsgruppen „Netadmins“, „Lernende“ und „Ausbildner“ sowie entsprechende Testuser anzulegen. Beim Anlegen der Testuser sollen die Firmenstandards zu den Namenskonventionen eingehalten werden. Es ist zu entscheiden, welche der eingesetzten Geräte in die AD-Verwaltung aufgenommen werden.

* Im Netzwerk steht ein Active-Directory-Service zur Verfügung

* Das AD ist gemäss Firmenstandard eingerichtet

* Sicherheitsgruppen und entsprechende Testuser sind eingerichtet

* Die Geräte sind gemäss Planung in die AD-Verwaltung aufgenommen

2.2. Anforderungen an die 802.1X-Lösung


Dienste


Sowohl für die Switch-Ports als auch für das WLAN ist die Authentifizierung und Autorisierung gemäss 802.1X einzurichten. Dabei ist klar zu definieren, wie die benötigten Dienste Supplicant, Authenticator sowie Authentifizierungs-Server auf den realen Systemen implementiert werden.

* Die Dienste Supplicant, Authenticator und Authentifizierungs-Server sind gemäss Planung eingerichtet

* Als Benutzer-Backend wird der Active-Directory-Service eingesetzt

* Die Supplicants können sich sowohl über LAN als auch über WLAN gemäss 802.1X authentifizieren und autorisieren

Authentifizierung und Autorisierung


Der Supplicant (Client-Gerät) soll nach der Anmeldung durch den Testuser das für die Sicherheitsgruppe vorgesehene VLAN nutzen können. Die sinnvolle Abbildung der Sicherheitsgruppen auf die entsprechenden VLAN ist Teil der Planung. Gäste sollen nur über einen WLAN-Zugang verfügen. Für Gäste und Netadmins ist abzuklären, ob die Nutzung der entsprechenden VLAN über 802.1X oder andere Zugangsmethoden gewährleistet wird.

* Lernende und Ausbildner können nach der Anmeldung über 802.1X ihre jeweiligen VLAN nutzen

* Den Gästen steht nur ein WLAN-Zugang zur Verfügung

* Für Gäste und Netadmins ist eine geeignete Zugangsmethode zu ihren VLAN bestimmt und realisiert

2.3. Anforderungen an die Backup-Lösung


Backup-System


Als Backup-Lösung soll die im Betrieb eingesetzte freie Suite BackupPC zum Einsatz kommen. Diese wird als Vorarbeit auf einem Debian Linux-Server aufgesetzt.

Daten


Für die Dauer des Projektes soll ein Backup für die Arbeitsresultate eingerichtet werden. Zunächst sind die zu sichernden Systeme und Daten sowie die Ausfallrisiken zu bestimmen. Danach ist eine auf die vorgegebene Backup-Lösung abgestimmte Backup-Strategie zu erarbeiten und zu realisieren.

* Das Backup stellt sicher, dass höchstens die Resultate eines Arbeitstages verloren gehen können

* Der Restore ist für eine ausgewählte VM, den Switch sowie die Firewall zu testen

3. Verlangte Dokumentationen


* Inventar der unter Mittel und Methoden aufgeführten Hardware

* Kurzbeschreibungen der unter Mittel und Methoden aufgeführten Services

* Beschreibung des IEEE 802.1X Standards

* Layer3-Diagramm der Einbettung der Testumgebung in das Netzwerk der Rafisa

* Netzwerkdiagramm der Testumgebung

* Portbelegung von Switches und Firewall

4. Testing


Die gesamte Lösung ist auf Basis eines Testkonzeptes zu testen und die Testresultate sind zu dokumentieren.

Mittel und Methoden

Hardware


1x Dedizierter Server

1x PC mit Linux-Basisinstallation und BackupPC (Vorarbeit)

1x Firewall pfSense auf APU-Hardware

1x Managed Switch 24-Port

2x Arbeitsplatzrechner für Doku und Testing (Installation als Vorarbeit)

1x UniFi AP

Software und Services


Virtualisierungslösung: Proxmox-VE Version 7.1

Firewall: pfSense-Firewall Version 2.5.2-RELEASE (amd64)

WLAN-Controller: UniFi Network Application Version 7.0.23 for Windows oder Debian/Ubuntu Linux

Server-Betriebssysteme: Windows Server 2019 Standard oder Debian Linux 11

Client-Betriebssysteme: Windows 10 Enterprise

Backup-Lösung: BackupPC Version 4.4

Labor-Netzwerk: VLAN54_LAB04, Gateway: 172.16.54.1/24, DHCP aktiviert

Firmenstandards: Dokument “Firmenstandards für das Netzwerk der Rafisa Informatik GmbH” Version 1.1

Vorkenntnisse

- 802.1X

- Windows Server und Active Directory

- Linux Server

- BackupPC

- Switches und Firewalls

Vorarbeiten

- Einrichten BackupPC auf PC

- Einrichten der Client PCs für Konfig und Testing

Neue Lerninhalte

- Verfassen von Kurzbeschreibungen zu den Services

- Gesamtprojekt nach Firmenstandards erarbeiten

Arbeiten in den letzten 6 Monaten

- Verantwortlicher für BackupPC

- Auseinandersetzung mit IEEE-Standard 802.1X

- Verantwortlicher für Rafisa Wiki

Durchführungsblock

Startblock 7, KW13:28.03.2022 – 01.04.2022
IPA-Durchführung: 28.03.2022 – 01.05.2022
Einreichung bis: 28.02.2022

Projektaufbauorganisation

Die Prüfungsexperten bilden zusammen mit dem Fachverantwortlichen der Ausbildung und dem Kunden den Auftraggeber. Zusammen sind sie für die Formulierung der Aufgabenstellung und Benotung der Projektarbeit zuständig.

Personen

Fachvorgesetzte: Egil Rüefli
Lernende: Timafei Pabiarzhyn

Rollen

Projektleiter: Timafei Pabiarzhyn
Auftraggeber, Kunde: Egil Rüefli

Aufgaben

Der Projektleiter ist für die komplette Realisierung und Dokumentation der IPA zuständig.
Der Auftraggeber ist für die Formulierung des Auftrages zuständig.

Verantwortung

Die Realisierung der IPA liegt allein in der Verantwortung des Lernenden.

Projektorganigramm

Abbildung 1: Projektorganigramm

Vorgehen

Projektmethode IPERKA

Dieses Projekt wird nach IPERKA realisiert. IPERKA ist eine Projektmethode, die in 6 Phasen gegliedert ist. Jeder der Buchstaben repräsentiert eine Phase. Beim ersten Schritt “I-Informieren” geht es darum, den Auftrag zu verstehen und sich ein Bild des angestrebten Ziels zu machen. Bei “P-Planen” werden je nach Auftrag die möglichen Lösungsvarianten und das Vorgehen ausgearbeitet. Nach der Planung, bei “E-Entscheiden”, muss eine Lösungsvariante ausgewählt werden. Das “R-Realisieren” oder Ausführen nimmt oft den zeitlichen Hauptteil eines Auftrags in Anspruch. Dabei führt Man die einzelnen Arbeitsschritte wie geplant aus. Jede ausgeführte Arbeit ist zu “K-” kontrollieren, bevor sie aus den Händen gegeben wird. Kontrollieren heisst z. B., nochmals den Ausführungsbeschrieb durchlesen, nachrechnen, mit Vorgaben vergleichen. Bei dem letzten Schritt, “A-Auswerten” lässt man nun die ganze Bearbeitung des Auftrags, vom Informieren bis zum Kontrollieren, nochmals in Gedanken ablaufen und beurteilt einzelne Schritte.

Organisation der Arbeitsergebnisse

Die Dokumentation wird in OneDrive gespeichert. Die Ordner sind nach Arbeitstagen benannt und enthalten Versionen der Dokumentation, die am Ende des Tages in die entsprechenden Ordner kopiert werden.

Abbildung 2: Ordner im OneDrive, wo die Dokumentation gespeichert wird

Für die Sicherung der aufgebauten Testumgebung wird das Programm „BackupPC“ verwendet. Damit werden die Konfigurationen von Switch und Firewall gesichert, sowie die virtuellen Maschinen von Proxmox. Das detaillierte Backup-Konzept wird in Verlauf der Arbeit entwickelt.

Firmenstandards für das Netzwerk der Rafisa Informatik GmbH

An verschiedenen Stellen der Arbeit wird Bezug genommen auf die Firmenstandards. Diese wurden vorab im Dokument «Firmenstandards für das Netzwerk der Rafisa Informatik GmbH» [1] ausgegeben. Die Firmenstandards betreffen folgende Bereiche:

  • Subnetz-Konzept
  • VLANs der Rafisa Dietikon
  • Berechtigungsmatrix
  • IP-Zuteilung der Geräte der Rafisa Dietikon
  • Rafisa Namenstkonzept
  • Benutzer
  • Geräte
  • Physikalische Standorte
    • Kürzel für die Standorte
    • Kürzel für die internen Räume
    • Kürzel für Racks
  • AD-Struktur

Das vollständige Dokument ist im Anhang zu finden.

Zeitplan

Abbildung 3: Zeitplan

Arbeitsprotokoll

TAG 1 
Datum  Fr, 01.04.2022
Arbeitszeit  09:00-17:00 
Ausgeführte Aufgaben  Teil 1 der Dokumentation vervollständigt

Zeitplan erstellt

Hardware der eingesetzten Geräte erfasst

Eingesetzte Software und Services beschrieben

Layer 3 Netzplan des Systemumfelds gezeichnet

1. Expertengespräch

Daily mit dem Fachvorgesetztem
Aufgetretene Probleme - Für das Erfassen der Hardware des Linux Servers habe ich den Befehl dmidecode eingesetzt. Auf dem Backup Server wurde der Befehl nicht erkannt/gefunden.
Problemlösung  <HTML><ol start=„2“ style=„list-style-type: decimal;“></HTML>
<HTML><li></HTML><HTML><p></HTML>Damit das Debian OS auf dem Backup Server den Befehl finden kann, musste ich statt nur «su» «su -» ausführen. Das Minus Zeichen bewirkt, dass die Umgebungs-Variablen für root geladen werden.<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML>
Reflexion  Während der Arbeit ist mir aufgefallen, wie viel Zeit ich für die Dokumentation brauche, das hat mich überrascht und etwas gestresst. Ich werde das in Zukunft im Auge behalten.
Wissensbeschaffung  * Zyxel Switch Datasheet https://www.zyxel.com/products_services/8-24-48-port-GbE-Smart-Managed-Switch-GS1920-Series/specification
* Datasheet Access Point https://dl.ui.com/datasheets/unifi/UniFi_AC_APs_DS.pdf
* Linux Befehle zur Erfassung der HW-Infos https://www.makeuseof.com/check-system-details-and-hardware-information-on-linux/
* Firewall Hardware Datasheet https://www.pcengines.ch/apu4d2.htm
Beanspruchte Hilfe  * Der Fachvorgesetzte hat mit Problem #1 geholfen.
* Der Experte hat bei dem 1. Gespräch viele hilfreiche und informative Tipps gegeben.
Zeitplan eingehalten  90%, Beschreibung der Projektmethode IPERKA wird über Wochenende erstellt

 

TAG 2
Datum  Di, 05.04.2022
Arbeitszeit  09:00-17:30 
Ausgeführte Aufgaben  Kapitel «Planen Netzwerk» teilweise geschrieben

Kapitel «Planen Proxmox» fertig geschrieben

Kapitel «Planen VMs» fertig geschrieben

Kapitel «Planen 802.1X» fertig geschrieben

Kapitel «Planen Backup und Restore» teilweise geschrieben

Daily mit dem Fachvorgesetztem
Aufgetretene Probleme - Es sind alle Tabellen und Überschriften im Dokument gebrochen.
Problemlösung  - Es lag daran, dass neben dem Word 2016 auch die Online-Version von Word angewendet wurde. Das ergab Versionsinkonsistenz. Nach dem das alte Office 2016 durch Office 365 ersetzt wurde, wurde alles wieder richtig angezeigt.
Reflexion  Ich brauche immer noch viel Zeit für die Dokumentation und ich bin etwas im Verzug mit dem Zeitplan.
Wissensbeschaffung  * Wiki Proxmox https://pve.proxmox.com/wiki/Main_Page
* IPA Sabareeshan Nadeswaran [2]
* IPA Lea Cotar [3]
Beanspruchte Hilfe  * Der Fachvorgesetzte hat mit Problem #1 geholfen.
Zeitplan eingehalten  80%
TAG 3
Datum  Mi, 06.04.2022
Arbeitszeit  09:00-17:30 
Ausgeführte Aufgaben  Kapitel «Planen Netzwerk» fertig geschrieben

Kapitel «Planen Backup und Restore» fertig geschrieben

Kapitel «Netzwerk-Konzept» teilweise geschrieben

Kapitel «Proxmox-Konzept» teilweise geschrieben

Kapitel «Konzept VMs» teilweise geschrieben

Kapitel «Konzept 802.1X» teilweise geschrieben

Kapitel «Backup-Konzept» teilweise geschrieben

Kapitel «Arbeitsplan für die Realisierungsphase» teilweise geschrieben
Aufgetretene Probleme Keine Probleme sind vorgekommen
Problemlösung  -
Reflexion  Es frustriert mich, dass ich mich nicht an den Plan halten und am Ende etwas als „erledigt“ markieren konnte.

Im Grunde habe ich alle notwendigen Entscheidungen getroffen. Das Problem ist, dass ich die dokumentieren muss, und das braucht bei mir viel Zeit.
Wissensbeschaffung  * Rafisa Standards https://wiki.rafisa.net/doku.php?id=intern:standards:standards
Beanspruchte Hilfe  Keine
Zeitplan eingehalten  80%
TAG 4
Datum  Do, 07.04.2022
Arbeitszeit  09:00-17:00
Ausgeführte Aufgaben  Kapitel «Netzwerk-Konzept» vervollständigt

Kapitel «Proxmox-Konzept» vervollständigt

Kapitel «Konzept VMs» vervollständigt

Kapitel «Konzept 802.1X» vervollständigt

Kapitel «Backup-Konzept» vervollständigt

Den Netzplan der Testumgebung gezeichnet

Switch aufgesetzt und konfiguriert

Firewall aufgesetzt und teilweise konfiguriert
Aufgetretene Probleme Ich schaffe nicht in LAN-Netz des Firewalls auf die Web-Oberfläche zu kommen, auch wenn der Arbeitsrechner im gleichen Netz ist.
Problemlösung  Problem nicht gelöst.
Reflexion  Die Tatsache, dass die Firewall nicht funktionieren will, ist ein schwerer Schlag für meinen Fortschritt, da ich theoretisch den Plan einhalten würde, aber jetzt bin ich noch weiter im Rückstand.
Wissensbeschaffung  * Zyxel Switch User’s Guide https://manualmachine.com/zyxel/gs192024hp/2739059-user-manual/#1
Beanspruchte Hilfe  Keine
Zeitplan eingehalten  40%
TAG 5
Datum  Fr, 08.04.2022
Arbeitszeit  09:00-17:00
Ausgeführte Aufgaben  Firewall fertig konfiguriert

BackupPC konfiguriert

Proxmox aufgesetzt und eingerichtet

Die VMs vorbereitet
Aufgetretene Probleme Bei der Proxmox-Installation erkennt die Hardware den USB-Stick nicht als bootfähiges Medium.
Problemlösung  Firewall Problem von Tag 4: Das Problem entstand durch eine falsche VLAN Konfiguration. Das Problem durch eine Rekonfiguration behoben.

Da verschiedene USB-Sticks und Programme nicht funktionierten, wurde vom Fachvorgesetztem eine Boot-CD gebrannt, mit dieser funktionierte es.
Reflexion  Das Problem mit Proxmox hat mir die Chance genommen, den Zeitplan einzuhalten und frühere Teile zu verbessern
Wissensbeschaffung  * Proxmox Installationsanleitung https://pve.proxmox.com/wiki/Installation
*
Beanspruchte Hilfe  Der Fachvorgesetzte hat mit Firewall und Proxmox geholfen.
Zeitplan eingehalten  50%
TAG 6
Datum  Di, 12.04.2022
Arbeitszeit  09:00-17:30
Ausgeführte Aufgaben  BackupPC rekonfiguriert

Unifi Controller eingerichtet

Access Point und WLAN eingerichtet

User-Backend eingerichtet

Alle rollen von 802.1X eingerichtet

Daily mit dem Fachvorgesetztem
Aufgetretene Probleme Bei der neuen Version von BackupPC wurden viele notwendige Funktionen entfernt. Das führt dazu, dass das für heute geplante Backup der VMs nicht möglich ist.
Problemlösung  Ich habe dem Helpdesk einen Auftrag erteilt, eine ältere Version von BackupPC aufzusetzen. Mit dieser Version konnte ich die Backups, wie geplant aufsetzten.
Reflexion  Ich habe entschieden, dass ich die Dokumentation später nachführen kann und werde einfach für später Screenshots mit Notizen machen, anstatt das Realisieren durch Dokumentieren zu unterbrechen. Dadurch konnte ich in der Realisierungsphase grosse Fortschritte erzielen.
Wissensbeschaffung  * Netzwerkrichtlinien-Server https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-server
* BackupPC Doku https://backuppc.github.io/backuppc/BackupPC.html
Beanspruchte Hilfe  Helpdesk

Der Fachvorgesetzter musste die Partitionierung des BackupPC nachträglich noch anpassen.
Zeitplan eingehalten  100%
TAG 7
Datum  Di, 13.04.2022
Arbeitszeit  09:00-17:30
Ausgeführte Aufgaben  Expertenbesuch #2

Das Testkonzept geschrieben

Die Realisierungsphase von «Switch einrichten» dokumentiert

Die Realisierungsphase von «Firewall einrichten» dokumentiert

Die Realisierungsphase von «BackuPC Konfigurieren» dokumentiert
Aufgetretene Probleme Keine Probleme sind aufgetreten.
Problemlösung  -
Reflexion  Da ich gestern entschieden habe, dass ich die Dokumentation später nachführen kann, musste ich jetzt hauptsächlich die Dokumentation schreiben und mit Screenshots vervollständigen.
Wissensbeschaffung  * Für die Dokumentation wurde keine Wissensbeschaffung benötigt
Beanspruchte Hilfe  Der Fachvorgesetzter hat mit mir den Expertenbesuch nachbesprochen.
Zeitplan eingehalten  100%
TAG 8
Datum  Di, 14.04.2022
Arbeitszeit  09:00-17:30

Über Ostern wurde an dem Projekt noch 3 Stunden gearbeitet.
Ausgeführte Aufgaben  Die Realisierungsphase von «Proxmox einrichten» Dokumentiert

Die Realisierungsphase von «Unifi Controller einrichten» Dokumentiert

Die Realisierungsphase von «Access Point und WLAN einrichten» Dokumentiert

Die Realisierungsphase von «User Backend erstellen» Dokumentiert

Die Testszenarios erstellt

Tests #3, #4, #5 und #6 durchgeführt
Aufgetretene Probleme Keine Probleme sind aufgetreten.
Problemlösung  -
Reflexion  Nach dem ich fertig bin mit der Hälfte der Tests, denke ich, dass ich gut unterwegs bin und ohne Stress fertig werden sollte.
Wissensbeschaffung  * Für die Dokumentation wurde keine Wissensbeschaffung benötigt
Beanspruchte Hilfe  Ein Arbeitskollege hat die Dokumentation auf Rechtschreibefehler durchgelesen.
Zeitplan eingehalten  100%
TAG 9
Datum  Di, 19.04.2022
Arbeitszeit  09:00-18:30
Ausgeführte Aufgaben  Die Realisierungsphase von «Authentication-Server einrichten» dokumentiert

Die Realisierungsphase von «Authenticators einrichten» dokumentiert

Die Realisierungsphase von «Supplicants einrichten» dokumentiert

Tests #1, #7, #8, #9 und #10 durchgeführt
Aufgetretene Probleme Keine Probleme sind aufgetreten.
Problemlösung  -
Reflexion  Nach heutigem Tag habe ich das Gefühl, dass zeitlich es sehr knapp wird. Sobald man denkt, dass ein Teil/Kapitel fertig ist, fallen die Kleinigkeiten auf, die korrigiert oder verbessert werden müssen.
Wissensbeschaffung  * Für die Dokumentation wurde keine Wissensbeschaffung benötigt
Beanspruchte Hilfe  Keine
Zeitplan eingehalten  70%
TAG 10
Datum  Di, 20.04.2022
Arbeitszeit  09:00-18:00
Ausgeführte Aufgaben  Tests #2 und #11 durchgeführt

Die Dokumentation ausgewertet

Die Kurzfassung geschrieben

Das Glossar geschrieben

Die Abbildungen und Tabellen bezeichnet

Die Dokumentation auf die PkOrg-Webseite hochgeladen
Aufgetretene Probleme Keine Probleme sind aufgetreten.
Problemlösung  -
Reflexion  Ich habe auch am letzten Tag viel länger gebraucht, als ich gedacht habe und bin deswegen froh, dass ich einen Reserve-Tag eingeplant habe.
Wissensbeschaffung  * Für die Dokumentation wurde keine Wissensbeschaffung benötigt
Beanspruchte Hilfe  Der Fachvorgesetzter hat mir Tipps zur Endredaktion gegeben.
Zeitplan eingehalten  100%

Teil 2 – Projekt

Kurzfassung IPA-Bericht

In der Rafisa Informatik GmbH werden zurzeit 50 Lernende der Fachrichtungen Applikationsentwicklung, ICT-Fachmann/Fachfrau, Systemtechnik und Betriebsinformatik sowie Plattformentwicklung zu InformatikerInnen EFZ ausgebildet. Das Netzwerk der Rafisa wird zusammen mit den Lernenden stetig weiterentwickelt. Eine der Entwicklungsideen ist die Implementierung des 802.1X-Standards. In der vorliegenden IPA werden die Grundlagen zur Einführung des 802.1x Standards im gesamten Netzwerk der Rafisa geschaffen. Zu diesem Zweck sollte eine Testumgebung mit den für 802.1X nötigen Komponenten – Supplicants, Authenticators, Authentication-Server und User-Backend – aufgebaut und die Anmeldung über 802.1X für ausgewählte Testuser geprüft werden.

Die Rollen der 802.1X Komponenten werden von verschiedenen Systemen übernommen. Die Rolle des Supplicants übernimmt ein Windows 10 Arbeitsplatzrechner, der für den 802.1X Einsatz konfiguriert wurde. Die Rolle der Authenticators haben ein Unifi Access-Point und ein Zyxel Switch. Als Authentication-Server und User Backend wurde ein Windows Domain Controller eingerichtet. Als Basis für die VMs wurde die Virtualisierungsplattform Proxmox VE installiert. Auf diesem läuft nicht nur die Windows Domain Controller-VM sondern auch eine Unifi Controller-VM, über die der Access Point konfiguriert wurde. Auf der pfSense Firewall, wurden die VLANs und entsprechende Zugriffsberechtigungen eingerichtet. Die Firewall übernimmt das Routing zwischen den VLANs. Zusätzlich wurde ein Backup-Server eingerichtet, mit dem die Backups der wichtigsten Systeme durchgeführt werden.

Beim Testing wurde festgestellt, dass die benötigten 802.1X Komponenten, Supplicant, Authenticator, Authentication-Server und User Backend mit passenden organisatorischen oder technischen Richtlinien zu einem funktionstauglichem System eingerichtet werden konnten.

Informieren

Erfassung der zur Verfügung gestellten Hardware

Hardware Server und PCs

Die Hardwarespezifikationen unter Windows wurden mit Hilfe der «Systeminformationen» rausgelesen. Unter Linux wurden die Befehle dmidecode, fdisk und lspci [4] angewendet, um die Hardwareinformationen rauszufinden.

Gerät ModellbezeichnungCPU MemoryHD NW-Adapter
Proxmox-Server IBM System x3200 M3 Intel Xeon X3430 2.40GHz

(1 Socket, 4 Cores)
16 GB 2x 300 GB2x Intel Corporation 82574L Gigabit Network Connection
Backup-Server HP ProDesk 600 G1 TWRi5-4570 3.20GHz 6 GB 1 TB Intel Corporation Ethernet Connection I217-LM
Arbeitsplatzrechner 1HP p6-2310ez i5-3470 3.20GHz 8 GB 2 TB Realktek PCIe GBE Family Controller
Arbeitsplatzrechner 2HP p6-2210ezm i5-2320 3.00GHz 8 GB 150 GB Realktek PCIe GBE Family Controller

Tabelle 1: Hardware Server und PCs

Hardware Switch

Es handelt sich um einen Managed Switch, dass über Webinterface und CLI konfiguriert werden kann. Die Informationen zu dem Switch wurden auf der Herstellerwebpage [5] gefunden.

GerätModellbezeichnungFirmware ÜbertragungsrateAnzahl Ports
Switch Zyxel GS1920-24HP V4.30(AAOC.0) 09/16/20151000 Mbps 28

Tabelle 2: Hardware Switch

Hardware Access-Point

Die Access-Point Spezifikationen wurden auf dem Datasheet des Herstellers [6] gefunden.

Gerät ModellbezeichnungAnzahl Interfaces WLAN-Standards FrequenzbänderVerschlüsselungsmöglichkeiten
Access-PointUAP-AC-PRO 2x 10/100/1000 Ethernet Ports802.11 a/b/g/n/r/k/v/ac2.4 GHz

5 GHz
WEP, WPA-PSK, WPA-Enterprise (WPA/WPA2, TKIP/AES)

Tabelle 3: Hardware Access-Point

Hardware Firewall

Da es auf dem Firewall keine Herstellerbezeichnungen gibt, wurde auch auf der Firewall der Befehl «dmidecode» ausgeführt. Bei der Ausgabe des Befehls wurde der Hersteller gefunden, PC Engines. Danach konnte man das richtige Modell auf der Hersteller Webseite [7] identifizieren.

GerätModellbezeichnungCPU Memory FestplatteNW-Interfaces Übertragungsrate
Firewall apu4d2 GX-412TC2GB DDR3-1333 DRAM12 GB igb0

igb1

igb2

igb3
1000 Mbps

Tabelle 4: Hardware Firewall

Erfassung der einzusetzenden Software und Services

Die Virtualisierungsplattform Proxmox VE

Proxmox Virtual Environment (Proxmox VE oder PVE) ist ein Open-Source-Software-Server für das Virtualisierungsmanagement. Es handelt sich um einen Hypervisor, der Betriebssysteme wie Linux und Windows auf x64-Hardware ausführen kann. Es handelt sich um eine Debian-basierte Linux-Distribution mit einem modifizierten Linux-Kernel und ermöglicht die Bereitstellung und Verwaltung von virtuellen Maschinen (KVM) und Containern (LXC). Proxmox VE umfasst eine Web-Konsole und Befehlszeilen-Tools. Es enthält eine webbasierte Verwaltungsschnittstelle. Zudem ist es möglich, mit mehreren Proxmox Nodes HA-Lösung (High Availability) aufzubauen.

Die Minimal-Anforderungen an die Proxmox-Hardware sind:

  • CPU: 64bit (Intel EMT64 oder AMD64)
  • Intel VT/AMD-V-fähige CPU/Mainboard (für KVM Full Virtualization Unterstützung)
  • Mindestens 1 GB RAM
  • Festplatte
  • Eine Netzwerkkarte

Der Backup-Server BackupPC

Bei BackupPC handelt es sich um eine freie Disk-zu-Disk Backup-Suite, mit welcher sich sowohl Windows als auch Linux Systeme sichern lassen. Als Übertragungsarten stehen smb für das Backup von Windows-Shares, sowie für die Sicherung der Daten das rsync-Protokoll. Zusätzlich Funktionen lassen sich mit Pre- und Post-Backupscripts realisieren. Zu den Main Features gehören [2] :

  • Webbasiertes Administrationsinterface: Konfiguration von Backups, Analyse der Logfiles, manuelles Starten und Stoppen von Backups, Browse und Restore von Backupdaten
  • Datendeduplikation: Identische Files von mehreren Backups des selben Clients oder von verschiedenen Clients werden nur einmal gespeichert. Das erlaubt Einsparungen im Bereich der benötigten Kapazitäten sowie des Disk I/Os.
  • Kompression: Da nur neue Files komprimiert werden müssen, werden die CPUs weniger beansprucht
  • Open-Source: BackupPC wird auf Github gehostet und unter einer GPL-Lizenz verteilt
  • Es wird keine clientseitige Software benötigt

pfSense Firewall

pfSense ist eine auf FreeBSD basierende Firewall/Router-Software-Distribution. pfSense wird auf einem physischen Computer oder einer virtuellen Maschine installiert, um eine dedizierte Firewall/Router für ein Netzwerk zu erstellen. Sie kann über eine webbasierte Schnittstelle konfiguriert und aktualisiert werden und erfordert keine Kenntnisse über das zugrundeliegende FreeBSD-System, um sie zu verwalten.

Zu den wichtigsten Funktionen von pfSense gehören Traffic Shaping, VPNs mit IPsec oder OpenVPN, Captive Portal, Stateful Firewall, Network Address Translation, 802.1q-Unterstützung für VLANs und dynamisches DNS.

UniFi Network Application

Die UniFi Network Applikation ist eine Software, die erlaubt, Unifi-Geräte zu verwalten. Die Access-Points werden durch das Web-Interface konfiguriert, danach laufen sie selbständig (passiver Kontroller).

Hauptfeatures der Applikation sind:

  • Integration von Grundrissen für das Monitoring der Wireless-Abdeckung
  • Detailliertes Reporting und Statistiken
  • Wireless-Uplink: Ein mit Kabel angeschlossener AP erlaubt Wireless-Uplinks auf bis zu 4 Geräte.
  • Guest-Portal-Support: Mit Voucher-Management
  • Multi-Site-Management: Verwalten mehrerer Sites mit nur einem Controller
  • Verwalten von WLAN-Gruppen

Windows Server 2019 Standard

Windows Server 2019 ist die achte Version des Windows Server-Betriebssystems von Microsoft, als Teil der Windows NT-Betriebssystemfamilie. Es ist nach Windows Server 2016 die zweite Version des Server-Betriebssystems, die auf der Windows 10-Plattform basiert.

Die Minimalanforderungen [8]:

Prozessor – 1.4GHz 64-bit

RAM – 2 GB für Server mit Desktop GUI

Disk – 32 GB (Absolute Minimum)

Debian

Debian ist eine GNU/Linux-Distribution, die aus freier und Open-source Software besteht und vom community-supported Debian-Projekt entwickelt wird. Der Debian-Stable-Zweig ist die beliebteste Ausgabe für Personal Computer und Server. Debian ist auch die Basis für viele andere Distributionen, vor allem Ubuntu. Debian ist eines der ältesten Betriebssysteme, die auf dem Linux-Kernel basieren.

Die Minimalanforderungen ohne Desktop [9]:

Processor - Pentium 4, 1GHz

RAM – 128 MB

Disk – 2 GB

Windows 10 Enterprise

Windows 10 Enterprise bietet alle Funktionen von Windows 10 Pro für Workstations, mit zusätzlichen Funktionen zur Unterstützung von IT-basierten Organisationen. Windows 10 Enterprise ist für zwei Service-Kanäle konfigurierbar, den halbjährlichen Kanal und das Windows Insider-Programm.

Der Standard IEEE 802.1X

An der 802.1X-Authentifizierung sind drei Parteien beteiligt: ein Supplicant, ein Authenticator und ein Authentifizierungsserver. Der Supplicant ist ein Client-Gerät (z. B. ein Laptop), das sich mit dem LAN/WLAN verbinden möchte. Der Begriff „Supplicant“ wird auch als Synonym für die auf dem Client laufende Software verwendet, die dem Authenticator Anmeldeinformationen zur Verfügung stellt. Der Authenticator ist ein Netzwerkgerät, das eine Datenverbindung zwischen dem Client und dem Netzwerk herstellt und den Netzwerkverkehr zwischen den beiden zulassen oder blockieren kann, wie z. B. ein Ethernet-Switch oder ein drahtloser Zugangspunkt; der Authentication Server ist in der Regel ein vertrauenswürdiger Server, der Anfragen für den Netzwerkzugang empfangen und beantworten kann und dem Authenticator mitteilen kann, ob die Verbindung zugelassen werden soll, sowie verschiedene Einstellungen, die für die Verbindung oder die Einstellung dieses Clients gelten sollen.

Abbildung 4: Radius Arbeitsschema

Der Authenticator fungiert wie ein Sicherheitswächter für ein geschütztes Netz. Der Supplicant (d. h. das Client-Gerät) darf erst dann über den Authenticator auf die geschützte Seite des Netzwerks zugreifen, wenn die Identität des Supplicants validiert und autorisiert wurde. Bei der portbasierten 802.1X-Authentifizierung muss der Anfragende dem Authenticator zunächst die erforderlichen Anmeldedaten zur Verfügung stellen, die zuvor vom Netzwerkadministrator festgelegt wurden und einen Benutzernamen/ein Passwort oder ein zulässiges digitales Zertifikat enthalten können. Der Authenticator leitet diese Anmeldedaten an den Authentifizierungsserver weiter, um zu entscheiden, ob der Zugang gewährt werden soll. Stellt der Authentifizierungsserver fest, dass die Anmeldeinformationen gültig sind, informiert er den Authenticator, der wiederum dem Antragsteller (Client-Gerät) den Zugriff auf Ressourcen auf der geschützten Seite des Netzes ermöglicht.

L3-Plan IST-Zustand des Projektumfelds

Als Gateway haben die Subnetze das Firewall VLAN-Interface des entsprechenden Subnetzes, für das VLAN01-MGMT also z.B. 172.16.1.1/24. Der Gateway für die IPA-Testumgebung ist demnach 172.16.54.1/24. Der Berechtigungsmatrix kann man entnehmen, dass die Zugänge zu allen anderen VLAN's der Rafisa durch Filterrules auf der Firewall geblockt werden. Die Firewall stellt ausser dem Gateway für den Internetzugang einen DHCP-Dienst zur Verfügung, über welchen IP-Adressen aus dem entsprechenden Subnetz, die Gateway-IP sowie die IP-Adressen der DNS-Server verteilt werden. Alle im Layer 3-Diagramm festgehaltenen Systeme verfügen über statische IP-Adressen.

Abbildung 5: Layer 3 Plan des Projektumfelds

FQDN IP-Adresse OS Services Service-Team Owner
Server
prox-zh-ruga-01.zh.rafisa.org172.16.1.21/24 Proxmox VE Virtualisierungsplattform Team Server Services RS
prox-zh-ruga-02.zh.rafisa.org172.16.1.22/24 Proxmox VE Virtualisierungsplattform Team Server Services RS
dc-zh-ruga-02.zh.rafisa.org 172.16.10.22/24 Windows Server 2019DC/AD, DNS Team Server Services RS
dc-zh-ruga-04.zh.rafisa.org 172.16.10.24/24 Windows Server 2019DC/AD, DNS Team Server Services RS
fs-zh-ruga-01.zh.rafisa.org 172.16.14.21/24 Windows Server 2019Fileserver Employees Team Server Services RS
fs-zh-ruga-02.zh.rafisa.org 172.16.15.21/24 Windows Server 2019Fileserver Learners Team Server Services RS
bkp-zh-r02b-01.zh.rafisa.org 172.16.1.100/24 Ubuntu 20.04 LTS Fileserver Learners Team Network ServicesER
uni-zh-ruga-01.zh.rafisa.org 172.16.1.30/24 Ubuntu 20.04 LTS Ubiquiti WLAN Controller Team Network ServicesER
ap-zh-01-05.zh.rafisa.org 172.16.1.31-35/24 AirOS AP, WPA-Enterprise Radius Auth Team Network ServicesER
Firewall
fw-zh-ruga-01.zh.rafisa.org MGMT VLAN: 172.16.1.1/24

WAN: 46.140.45.118
pfSense (BSD) VLAN-Routing, Filtering, VPN Concentrator, DHCPTeam Network ServicesER

Tabelle 5: Die Systeme im Projektumfeld

Planen

Planen Netzwerk

Planen der VLAN

In der Tabelle ist die Differenz zwischen den für die Zielerreichung minimal zu erstellenden VLANs und alle VLANs gemäss den Firmenstandards ersichtlich. Für die Erfüllung des Auftrages wird ein Management VLAN benötigt. In diesem VLAN befinden sich die Zugänge zur Firewall, zum Switch, zum Proxmox Interface, sowie zum WLAN Controller. Für das User-Backend wird ein Authentifizierungs-VLAN benötigt. Ausbildner und Lernende sollen mittels 802.1X automatisch in ihre VLANs eingeteilt werden. Zudem wird ein VLAN für die Gäste benötigt.

VLANs Minimal für ZielerreichungStandard-VLANs Rafisa Dietikon
VLAN01_MGMT VLAN01_MGMT (172.16.1.0/24)
VLAN10_SRVAUTH VLAN10_SRVAUTH (172.16.10.0/24)
VLAN21_CLEMPL VLAN14_SRVEMPL (172.16.14.0/24)
VLAN22_CLLEARN VLAN15_SRVLEARN (172.16.15.0/24)
VLAN23_CLGUEST VLAN21_CLEMPL (172.16.21.0/24)
VLAN22_CLLEARN (172.16.22.0/24)
VLAN23_CLGUEST (172.16.23.0/24)
VLAN40_LP (172.16.40.0/24)
VLAN51_LAB01 (172.16.51.0/24)
VLAN52_LAB02 (172.16.52.0/24)
VLAN53_LAB02 (172.16.53.0/24)
VLAN54_LAB02 (172.16.54.0/24)
VLAN55_LAB02 (172.16.55.0/24)

Tabelle 6: Differenz der VLANs

Planen der Netzwerk-Dienste

Die Netzwerkdienste können auf verschiedenen Systemen arbeiten. Im Folgenden wird gezeigt, welches Netzwerkobjekt die Rolle der verschiedenen Netzwerkdienste übernehmen kann.

System DHCP DNS AD
Windows Server 2019Möglich (DHCP-Server) Möglich (Windows-Bereitstellungsdienste)Möglich (Active-Directory-Domänendienste)
Ubuntu Server Möglich (isc-dhcp-server)Möglich (tftpd-hpa) Möglich (samba)
pfSense Firewall möglich Nicht möglich Nicht möglich

Tabelle 7: Planen der Netzwerk-Dienste

Auch für das 802.1X-Protokoll wurde ein solcher Vergleich durchgeführt.

System SupplicantAuthenticatorAuthentication-ServerBenutzer-Backend
Windows Server 2019Nicht möglich Nicht möglich Möglich (NSP) Möglich (AD)
Ubuntu Server Nicht möglich Nicht möglich Möglich (FreeRADIUS) Möglich (daloRADIUS)
pfSense Firewall Nicht möglich Nicht möglich Möglich (FreeRADIUS) Möglich
Zyxel Switch Nicht möglich Möglich Nicht möglich Nicht möglich
Unifi Access Point Nicht möglich Möglich Nicht möglich Nicht möglich
ArbeitsplatzrechnerMöglich Nicht möglich Nicht möglich Nicht möglich

Tabelle 8: Planen der RADIUS-Dienste

Planen Proxmox

Um die Sicherheit des Servers zu erhöhen, so dass er störungsfrei und ununterbrochen läuft, können einige Änderungen auf Hardware- und Softwareebene vorgenommen werden.

  • Hardware RAID: Wie dem IST-Zustand entnommen werden kann, stehen auf dem Server 2 Platten mit je 300GB Speicher zur Verfügung. Der Server unterstützt nur 2 Hardware-Raids, 0 und 1. Bei RAID 0 werden mehrere Disks zu einem Stripe-Volume kombiniert. Dabei werden die Daten auf alle Disks des Sets geschrieben. RAID 0 verfügt weder über Parity-Informationen, noch über Redundanz, noch über Fehlerkorrekturen. Durch Kombination der 2 Platten könnte ein Speichervolumen von 600GB erreicht werden. Bei Ausfall einer Platte sind die Daten verloren.

RAID 1 besteht aus einer exakten Kopie der Daten auf 2 oder mehreren Disks. Die Daten werden auf 2 oder mehrere Disks gespiegelt. Bei 2 Disks verliert man mit dem Mirroring aber eine Platte der erhöhten Datensicherheit. Mit RAID 1 wäre ein Speichervolumen von 300GB erreichbar.

  • Redundante Netzteile: Das PC wurde für Server gebaut, die ununterbrochen laufen müssen, d.h. es unterstützt Dual-Netzteil.
  • Monitoring Software: Um die Sicherheit auf der Ebene der Software zu erhöhen, wäre eine der Optionen, eine Überwachungssoftware zu installieren, die mich benachrichtigt, wenn etwas Wichtiges passiert. Unter Linux stehen dafür Tools wie Munin und Monit zur Verfügung.
  • Hardening des Betriebssystems: Eine weitere Möglichkeit, die Sicherheit zu erhöhen, wäre das Hardening der Software oder des Betriebssystems selbst.
  • Verschlüsselung aller Zugänge: Alle Administrative Zugänge sollten über verschlüsselte Verbindungen erfolgen.

Planen VMs

Bei der Erstellung einer virtuellen Maschine in Proxmox hat man viele Möglichkeiten, bestimmte Hardwareressourcen zuzuweisen. Die Kenntnis dieser Ressourcen ist wichtig, um die richtige Hardware für bessere Kompatibilität und Leistung auszuwählen.

In der nachstehenden Tabelle sind Ressourcen-Kategorien mit möglichen Varianten:

Ressourcen Varianten
Disk Bus/Device* IDE
* SATA
* VirtIO Block
* SCSI
Disk Format * Raw Disk Image
* QEMU Image Format
* VMWare Image Format
CPU Variabel
RAM Variabel
Netzwerkadapter* Intel E1000
* VirtIO (paravirtualized)
* Realtek RTL8139

Tabelle 9: Ressourcen-Kategorien mit Varianten

1. Harddisk Bus/Device

  • IDE: Bietet sehr gute Unterstützung durch alle Betriebssysteme. Es ist nicht sehr performant und unterstützt nur 4 Devices.
  • SATA: Bietet sehr gute Unterstützung durch Betriebssysteme. Ist performant und bietet Unterstützung für 6 Device
  • VirtIO: Bis zu 14 Devices. Benötigt unter Windows spezielle Guest-Treiber, abgelöst durch SCSI.
  • SCSI: Sehr performant, bis 14 Devices. Benötigt unter Windows spezielle Guest-Treiber

2. Disk Format

  • Das QEMU-Image-Format ist ein Copy-on-Write-Format, das Snapshots und Thin Provisioning des Festplatten-Images gestattet.
  • Das Raw-Disk-Image ist ein Bit-zu-Bit-Image einer Festplatte. Dieses Format unterstützt kein Thin Provisioning oder keine Snapshots. Es kann abgesehen davon bis zu 10% schneller sein als das QEMU-Image-Format.
  • Das VMware-Image-Format macht nur für den VMWare-Export Sinn.

3. CPU

Wie im Ist-Zustand festgehalten, verfügt der physische Server, der auf dem Proxmox VE eingerichtet wird, über 1 Socket und 4 Cores mit je vier Threads, d.h. über 16 logische CPUs. Um eine bessere Auslastung der Ressourcen zu erhalten, können den VMs mehr CPUs zugeordnet werden, als physisch vorhanden sind. Man nennt das Überbuchen. Man muss aber berücksichtigen, dass auch der Proxmox-Server noch CPU-Ressourcen benötigt.

4. Memory

Der Proxmox-Server verfügt über 16GB RAM. Auch hier muss man beachten, dass nicht alles RAM den VMs zugesichert wird, da der Proxmox-Server auch noch Memory braucht.

5. Netzwerkadapter

Intel E1000: Es bietet hohe Kompatibilität an. Für den Intel e1000 gibt es Treiber für ziemlich alte und obskure Betriebssysteme.

rtl8139: Es ist einfacher zu emulieren als e1000, aber es bedeutet auch, dass das Betriebssystem innerhalb der VM möglicherweise zusätzliche Arbeit leisten muss, um die Bedingungen der Netzwerkkartenemulation zu erfüllen.

VirtIO: Es ist ein para-virtualisierter Treiber, d.h. es „weiss“, dass es in einer VM arbeitet und leitet den Netzwerkverkehr zwischen der VM und dem Host auf die einfachste Weise weiter.

Planen 802.1X

Rollen

  • Supplicant – Die Rolle erfüllen die PCs der User.
  • Authenticator – Für die Rolle braucht es einen 802.1X fähigen Switch und AP.
  • Authentication-Server – Die Rolle kann entweder ein Windows Server oder die Firewall erfüllen.
  • Benutzer-Backend – Die Rolle des Benutzer-Backend kann ein Active Directory unter Windows oder Linux, oder eine Benutzerliste auf der Firewall übernehmen.

Authentifizierung der Sicherheitsgruppen

In der Tabelle unten ist zu sehen, wie sich die Sicherheitsgruppen mit den VLANs verbinden können.

Sicherheitsgruppe Ziel-VLANLAN WLAN
Authentifizierung und Autorisierung 802.1XAccess-Port802.1XWPA2-Enterprise
Netadmins VLAN01_MGMT Möglich Möglich Möglich Möglich
Ausbildner VLAN21_EMPL Vorgegeben- Vorgegeben-
Lernende VLAN22_LEARN Vorgegeben- Vorgegeben-
Gäste VLAN23_GUEST Möglich Möglich Möglich Möglich

Tabelle 10: Authentifizierung der Sicherheitsgruppen

Planen Backup und Restore

Backup der VMs

Die Sicherung der virtuellen Maschinen kann auf 2 Arten erfolgen. Entweder kann die interne Funktion von Proxmox oder BackupPC verwendet werden. In der untenstehende Tabelle sind die Vor- und Nachteile der entsprechenden Lösungen aufgelistet:

BackupartVorgehen Vorteile Nachteile
BackupPC BackupPC stellt eine Verbindung zur VM her und sichert die Dateien, die zur Sicherung via BackupPC WebGUI markiert sind.Der Prozess ist automatisiert Einsatz mit Windows ist aufwändiger
Proxmox dump Auf dem internen Proxmox Storage wird ein Dump der kompletten VM erstellt. Die ganze VM wird gesichert, was den restore vereinfachtDer Restore der VMs auf dem anderen Server kann nur über Command-Line erfolgen.

Tabelle 11: Vor- und Nachteile von BackupPC und Proxmox dump

Backup der Firewall & Switch

Beim Switch und Firewall ist die Sicherung mit BackupPC nicht so einfach. Derzeit gibt es 2 Optionen, wie ich vorgehen kann:

1. Manuelles Sichern der Konfigurationen über das Webinterface von Switch und Firewall.

2. Ich nehme die Skripte eines meiner Arbeitskollegen, Sabareeshan Nadeswaran, der sie für seine IPA [2] geschrieben hat, nehme mir etwas Zeit, sie zu verstehen und implementiere sie dann in BackupPC.

Switch Script von Sabareeshan Nadeswaran:

#!/bin/bash

cd /home/rafisa-backup/backup/sw-fr-s01-01

ftp -n 172.21.1.4 «EOF

quote USER admin

quote PASS 1234

get config

quit

EOF

mv /home/rafisa-backup/backup/sw-fr-s01-01/config /home/rafisa-backup/backup/sw-fr-s01-01/sw-fr-s01-01.conf

Firewall Script von Sabareeshan Nadeswaran:

#!/bin/bash

/usr/bin/sshpass -p 1234 scp -oStrictHostKeyChecking=no admin@172.21.1.1:/conf/config.xml /home/rafisa-backup/backup/fw-fr-s01-01/fw-fr-s01-01.conf

Entscheiden

Netzwerk-Konzept

VLAN

Ich habe beschlossen, nur die minimale Anzahl von VLANs zu realisieren. Der Versuch, mit der maximalen Anzahl zu arbeiten, würde viel mehr Zeit für die Konfiguration in Anspruch nehmen, und da RADIUS skalierbar ist, sollte die Erweiterung von anfänglich 5 VLANs kein Problem sein. In der folgenden Tabelle sieht man die zu realisierende VLANs, sowie die geplanten Subnetze. Die IP-Ranges der Subnetze wurden konform zu den Firmenstandards vergeben [1]. Im Authentifizierungs-VLAN wird kein DHCP-Server benötigt, da dort alle zu realisierende Systeme über statische IPs verfügen.

VLAN Name KürzelFunktion VID IP-AdresseFW-Interface-NameDHCP-Server
VLAN Management 01
VLAN01 MGMT Management 01 172.21.1.0/24 VLAN01_MGMT ✔️
VLAN Server 10-19
VLAN10 SRVAUTH Server Authentifizierung10 172.21.10.0/24VLAN10_SRVAUTH
VLAN Clients 20-29
VLAN21 CLEPML Clients Ausbildner 21 172.21.21.0/24VLAN21_CLEMPL ✔️
VLAN22 CLLEARN Clients Lernende 22 172.21.22.0/24VLAN22_CLLEARN ✔️
VLAN23 CLGUEST Clients Guest (WLAN) 23 172.21.23.0/24VLAN23_CLGUEST ✔️

Tabelle 12: VLAN-Konzept

Netzwerk-Dienste

Ich habe entschieden als Benutzer-Backend ein Active-Directory unter Windows Server 2019 einzurichten, da in der Firma ebenfalls Windows Server 2019 zum Einsatz kommen. Dadurch wird der Transfer aus meiner Testumgebung in die produktive Umgebung erleichtert. Da für den AD Dienst unter Windows zwingend ein DNS-Server benötigt wird, soll dieser auf demselben Windows Server 2019 aufgesetzt werden. Da für jede Broadcast Domain ein eigener DHCP Dienst benötigt wird, soll das DHCP Feature von pfSense verwendet werden.

DienstSystem
AD Windows Server 2019
DNS Windows Server 2019
DHCP pfSense Firewall

Tabelle 13: Dienst-Konzept

IP-Zuteilung

Die Hostnames allen benötigten Systeme werden gemäss der Rafisa-Namenskonvention festgelegt [1]:

VLAN Kürzel/HostnameIP-AdresseFunktion Ort
VLAN Management
VLAN01 MGMT 172.21.1.0/24 Management
fw-zh-204-01 172.21.1.1 Firewall
sw-zh-204-01 172.21.1.2 Switch
prox-zh-204-01 172.21.1.20 Proxmox VE
uni-zh-ruga-01 172.21.1.15 Unifi Controller
ap-zh-204-01 172.21.1.164 Unifi Accesspoint
bkp-zh-205-02 172.21.1.99 Backup-Server
VLAN Authentifizierung
VLAN10 AUTH 172.21.10.0/24
dc-zh-204-02 172.21.10.10 DC1 Windows 2019

Tabelle 14: Hostname- und IP-Konzept

Zugriffsmatrix

Die Zugriffsmatrix für die einzelnen VLANs soll gemäss Firmenstandards [1] festgelegt werden.

VLAN0110212223WAN
01 ✔️ ✔️ ✔️ ✔️ ✔️ ✔️
10 ✔️ ✔️
21 ✔️ ✔️ ✔️ ✔️ ✔️
22 ✔️ ✔️ ✔️
23 ✔️ ✔️
WAN ✔️

Tabelle 15: Zugriffmatrix-Konzept

Ports Konfiguration der Switch und Firewall

Folgende Tabelle zeigt die geplanten Switch und Firewall Portkonfiguration:

Port Zustand
Firewall
igb0 Access
igb1 Ausgeschaltet
igb2 Ausgeschaltet
igb3 Tagged
Switch VLAN01 VLAN10VLAN21VLAN22VLAN23
1 Fixed Forbidden Forbidden Forbidden Forbidden
2 Forbidden Forbidden Forbidden Forbidden Forbidden
3 Forbidden Forbidden Forbidden Forbidden Forbidden
4 Forbidden Forbidden Forbidden Forbidden Forbidden
5 Forbidden Forbidden Forbidden Forbidden Forbidden
6 Forbidden Forbidden Forbidden Forbidden Forbidden
7 Forbidden Forbidden Forbidden Forbidden Forbidden
8 Forbidden Forbidden Forbidden Forbidden Forbidden
9 Forbidden Forbidden Forbidden Forbidden Forbidden
10 Forbidden Forbidden Forbidden Forbidden Forbidden
11 Forbidden Forbidden Forbidden Forbidden Forbidden
12 Fixed Forbidden Forbidden Forbidden Forbidden
13 Forbidden Forbidden Forbidden Forbidden Forbidden
14 Forbidden Forbidden Forbidden Forbidden Forbidden
15 Forbidden Forbidden Forbidden Forbidden Forbidden
16 Fixed Forbidden Forbidden Forbidden Forbidden
17 Forbidden Forbidden Forbidden Forbidden Forbidden
18 Forbidden Tagged Tagged Tagged Tagged
19 Forbidden Forbidden Forbidden Forbidden Forbidden
20 Forbidden Forbidden Forbidden Forbidden Forbidden
21 Forbidden Forbidden Forbidden Forbidden Forbidden
22 Forbidden Forbidden Forbidden Forbidden Forbidden
23 Tagged Tagged Tagged Tagged Tagged
24 Fixed Tagged Tagged Tagged Tagged
25 Forbidden Forbidden Forbidden Forbidden Forbidden
26 Tagged Tagged Tagged Tagged Tagged
27 Forbidden Forbidden Forbidden Forbidden Forbidden
28 Forbidden Forbidden Forbidden Forbidden Forbidden

Tabelle 16: Switch und Firewall Port-Konzept

Proxmox-Konzept

Die folgende Tabelle erläutert meine Entscheidungen zu Proxmox:

Plan EntscheidungBegründung
RAID RAID 1 RAID 1 ist meine Wahl, da es eine bessere Sicherheit bietet, falls eine der Festplatten ausfällt. Auch 300GB von RAID 1 sind mehr als genug (siehe unten im Kapitel „Konzept VMs“).
Netzteil Doppeltes Es ist nicht schwer zu implementieren, da nur ein weiteres Kabel angeschlossen werden muss, das den Fortschritt im Falle des Ausfalls eines Netzteils bewahrt.
Monitoring-ToolKeins Ich bin zu dem Schluss gekommen, dass ein Überwachungs-Dienst für einen so kurzen Zeitraum nicht erforderlich ist, zumal es Zeit kosten würde, es einzurichten.
Hardening Nicht nötig Eine Härtung des Betriebssystems oder der Software ist nicht notwendig, da ich mich entschieden habe, das Proxmox VE ISO zu installieren, welches eine angepasste Version von Debian ist, mit allen notwendigen Komponenten, um Proxmox zu betreiben.

Tabelle 17: Getroffene Entescheidungen zu Proxmox

Konzept VMs

Es wurde beschlossen, 2 VMs mit Windows Server 2019 zu erstellen. Die eine VM wird als Domain Controller eingerichtet. Auf den anderen VM wird der WLAN-Controller installiert. Es wäre auch möglich gewesen den Controller auf dem DC zu installieren. Die Installation von Fremdsoftware auf einem Domain Controller wird von Microsoft aber nicht empfohlen.

Mit Blick auf die Mindestanforderungen wurden die folgende Tabelle erstellt:

Windows 2019 (DC)
Ressourcen Werte
Disk Bus/Device SATA
Disk Format RAW Disk Image
Disk Grösse 40 GB
CPU 1 Socket 4 Cores
RAM 4 GB
Netzwerkadapter E1000
Windows 2019 (Unifi Network Application)
Ressourcen Werte
Disk Bus/Device SATA
Disk Format RAW Disk Image
Disk Grösse 40 GB
CPU 1 Socket 4 Cores
RAM 3 GB
Netzwerkadapter E1000

Tabelle 18: Hardware-Spezifikation für die VMs

Da für die beiden VMs nur 80GB Speicherplatz benötigt werden, reichen die geplanten 300GB auf dem Proxmox-Server aus.

Konzept 802.1X

Die RADIUS-Authentifizierung beginnt, wenn der Benutzer über den Authenticator Zugriff auf eine Netzwerkressource anfordert. Der Benutzer gibt einen Benutzernamen und ein Kennwort ein, die vom RADIUS-Server verschlüsselt werden, bevor sie durch den Authentifizierungsprozess geschickt werden. Der RADIUS-Server prüft dann die Richtigkeit, der vom Benutzer übermittelten Informationen. Der RADIUS-Server verwendet Authentifizierungsverfahren, um die Daten zu überprüfen, indem er die vom Benutzer bereitgestellten Informationen mit Active Directory-Servern abgleicht.

Der RADIUS-Server kann auf eine von zwei Arten antworten:

Access Accept bedeutet, dass dem Benutzer der Zugriff auf den RADIUS-Server gewährt wird.

Access Reject bedeutet, dass dem Benutzer jeglicher Zugriff auf das RADIUS-Protokoll verweigert wird.

Rollen

Die 802.1X erforderliche Rollen werden auf folgenden Systemen realisiert:

Rolle System
Supplicant Arbeitsplatzrechner
Authenticator Zyxel Switch

Unifi Access Point
Authentication-ServerWindows Server 2019
Benutzer-Backend Windows Server 2019

Tabelle 19: 802.1X Rollen-Konzept

Sicherheitsgruppen

In der Tabelle unten ist zu sehen, wie sich die Sicherheitsgruppen mit den VLANs verbinden können. Die grün markierten Möglichkeiten sollen realisiert werden.

Sicherheitsgruppe Ziel-VLANLAN WLAN
Authentifizierung und Autorisierung 802.1XAccess-Port802.1XWPA2-Enterprise
Netadmins VLAN01_MGMT Möglich Möglich Möglich Möglich
Ausbildner VLAN21_EMPL Vorgegeben- Vorgegeben-
Lernende VLAN22_LEARN Vorgegeben- Vorgegeben-
Gäste VLAN23_GUEST Möglich Möglich Möglich Möglich

Tabelle 20: Sicherheitsgruppen-Konzept

Es wurde beschlossen, Netadmins als Gruppe wie Ausbildner und Lernende hinzuzufügen, damit sie sich über 802.1X anmelden können. Als Reserve wurde jedoch beschlossen, auf dem Switch einen Access-Port (Port 1) zu erstellen, der zu VLAN01 führt. Der Grund dafür ist, dass es im Falle eines Ausfalls des Authentifizierungsservers keine Möglichkeit gibt, auf das Netzwerk zuzugreifen.

Für die Sicherheitsgruppe Gäste wurde beschlossen, nur ein Gastnetzwerk mit WPA2-Enterprise zu erstellen. Das heisst, sie benötigen nur das Passwort, um auf das Gästenetzwerk zuzugreifen. Grund dafür ist, dass Gäste keine Geschäftshardware besitzen, die in der Domäne angemeldet sind. Daher gibt es keinen Grund, 802.1X WLAN/LAN oder Access-Ports für sie zu erstellen.

AD Benutzer-Backend

Die OU Container für die AD Struktur sollen gemäss Firmenstandards [1] erzeugt werden:

OU=OU-RAFISA,DC=rafisa,DC=ipa

OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=ipa

OU=RAFISA-Accounts,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=ipa

OU=RAFISA-Computers,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=ipa

OU=RAFISA-Clients,OU=RAFISA-Computers,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=ipa

OU=RAFISA-Servers,OU=RAFISA-Computers,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=ipa

OU=RAFISA-Groups,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=ipa

OU=RAFISA-GlobalSecurityGroups-GS,OU=RAFISA-Groups,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=ipa

OU=RAFISA-LocalSecurityGroups-LS,OU=RAFISA-Groups,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=ipa

Backup-Konzept

Backup VMs

Es wurde beschlossen, sowohl vzdump als auch BackupPC zu kombinieren. Auf diese Weise lässt sich eine VM leicht wiederherstellen und wird auch automatisch gesichert. Vzdump optimiert das Backup, so dass nur Daten und nicht die gesamte Disk gesichert werden muss. Es wird geschätzt, dass die beiden Windows Server 2019 Installationen nicht wesentliche mehr als die minimalen 32GB benötigen werden, diese werden von Proxmox zusätzlich auf etwa die Hälfte komprimiert. Auf BackupPC steht 1TB Speicherplatz zur Verfügung. Im Rafisa Netzwerk werden die Daten mit ca.25MB/s übertragen.

Backup Switch und Firewall

Nach näherer Betrachtung der von Sabareeshan Nadeswaran erstellten Skripte wurde beschlossen, diese zu verwenden, da sie nicht schwer zu implementieren sind und eine automatische Sicherung ermöglichen.

Rahmenbedingungen

Rahmendbedingung Backup IPA
Applikatorische VorgabenBackupPC mit Pre- und Post-Backupscripts
Aufbewahrungsfrist Ab Tag 6 (12.04.22) bis Ende IPA
Datenmenge VM-1(dc-zh-204-01): Ab Tag 6 5x 16GB

VM-2(uni-zh-204-01): Ab Tag 6 5x 16GB

Switch: Ab Tag 6 5x 5KB

Firewall: Ab Tag 6 5x 34KB

Insgesamt werden also ca. 160GB benötigt.
Transferzeit Für VM-1 und VM-2 werden bei Transferrate von 25MB/s je ca.12 Minuten benötigt. Die Transferzeit für die Konfigs von Switch und Firewall sind so kurz, dass sie vernachlässigt werden.
SicherungsperiodezitätenJede Nacht zwischen 19:30 und 07:00. Jede Woche ein Full-Backup, während der Woche Inkrementelle Backups. Nach Abgabe der IPA wird das Backup gestoppt.

Tabelle 21: Backup-Rahmenbedingungen

Testkonzept

Testumgebung

Hauptziel ist es zu prüfen, ob alle wichtigen Aspekte des Projekts funktionieren. Da es viele Teile hat, kann nicht jedes Detail getestet werden. Nachfolgend sind die Systeme und die ganze Umgebung im Netzplan zu sehen.

Abbildung 6: Netzplan der Testumgebung

Testobjekte

  1. Backup Server
  2. Firewall
  3. Verschlüsselung/Web
  4. 802.1X
  5. Supplicants

Testfälle

Test-Nr.Name Beschreibung Erwartetes Resultat
#1 Backup Prüfen, ob BackupPC Server seit der Bereitstellung Backups erstellt hat Die Backups wurden täglich durchgeführt
#2 Restore Prüfen, ob Restore von den Backups von 1x Switch, 1x Firewall und 1x VM möglich sind Die Backups können auf die Geräte wiederherstellt werden
#3 Firewall Die Firewall Regeln anhand der Zugriffsmatrix testen. Die VLANs dürfen nur mit den korrekten Interfaces kommunizieren.
#4 Verschlüsselung der Zugänge Die Zugänge zu den Administrationsoberflächen sind verschlüsselt Im Browser wird angezeigt, dass es sich um eine verschlüsselte Verbindung handelt.
#5 802.1X LAN Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen. Nach der Windows-Anmeldung wird dem Benutzer über LAN das korrekte VLAN zugeteilt.
#6 802.1X WLAN Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen. Nach der Windows-Anmeldung wird dem Benutzer über WLAN das korrekte VLAN zugeteilt.
#7 802.1X: Neuer Benutzer LAN Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen für einen neuen Benutzer.Nach der Windows-Anmeldung wird ein neues Windowsprofil erstellt und dem Benutzer über LAN das korrekte VLAN zugeteilt.
#8 802.1X: Neue Benutzer WLAN Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen für einen neuen Benutzer.Nach der Windows-Anmeldung wird ein neues Windowsprofil erstellt und dem Benutzer über WLAN das korrekte VLAN zugeteilt.
#9 Benutzer Wechsel mit Abmeldung bei dem Gerät Es wird geprüft, ob ein Nutzer etwas unternehmen muss, bevor er mit einem anderen Nutzer tauscht. Der Benutzer #1 meldet sich ab und beim Anmelden wird Benutzer #2 in das richtige VLAN zugeteilt
#10 Benutzer Wechsel ohne Abmeldung bei dem GerätEs wird geprüft, ob ein Nutzer etwas unternehmen muss, bevor er mit einem anderen Nutzer tauscht. Der Benutzer #1 meldet sich nicht ab und beim Anmelden wird Benutzer #2 in das richtige VLAN zugeteilt
#11 Gast WLAN Die VLAN Zuteilung im Gast-Netz testen. Nach der Windows-Anmeldung wird dem Benutzer über WLAN das korrekte VLAN zugeteilt.

Tabelle 22: Testfälle

Was wird nicht getestet

Test-Nr.Name Was nicht getestet wird
#1 Backup Es wird nicht die aktive Funktionalität getestet, sondern ob Ergebnisse erzielt wurden, da das Testen der Backup-Funktion viel Zeit in Anspruch nehmen wird.
#2 Restore Es werden nicht alle VMs getestet.
#3 Firewall Es werden nicht alle Protokolle getestet. Sondern nur ICMP.
#4 Aufrufen einer verschlüsselten Seite Es wird nicht auf Zertifikatsfehler, wie sie z.B. durch selbst signierte Zertifikate entstehen, getestet
#5 802.1X LAN -
#6 802.1X WLAN -
#7 802.1X: Neue Benutzer LAN -
#8 802.1X: Neue Benutzer WLAN -
#9 Benutzer Wechsel mit Abmeldung bei dem Gerät -
#10 Benutzer Wechsel ohne Abmeldung bei dem Gerät-
#11 Gast WLAN Der Ping wird nicht getestet, da es bereits im Test #3 geprüft wird.

Tabelle 23: Was wird nicht getestet

Testmittel und Testmethoden

Hier werden die Testmittel (benötigte Hard- und Software) und die zum Einsatz kommenden Testmethoden beschrieben.

Test-Nr.Name Relevante Testmittel Testmethoden
#1 Backup bkp-zh-205-02 (BackupPC) Funktionstest, Sicherheitstest
#2 Restore bkp-zh-205-02 (BackupPC)

uni-zh-204-01 (Unifi Network Application)

sw-zh-204-01 (Zyxel Switch)
Sicherheitstest, Funktionstest, Integrationstest
#3 Firewall fw-zh-204-01 (pfSense) Sicherheitstest, Komponententest
#4 Aufrufen einer verschlüsselten Seite Pc-zh-204-01 (Win 19 Enterprise + Firefox Browser)

Sw-zh-204-01

Fw-zh-204-01

Bkp-zh-205-02

Prox-zh-204-01
Sicherheitstest
#5 802.1X LAN Dc-zh-204-01 (RADIUS)

Pc-zh-204-02 (Win10 Enterprise)
Systemtest
#6 802.1X WLAN Dc-zh-204-01 (RADIUS)

Pc-zh-204-02 (Win10 Enterprise)
Systemtest
#7 Neue Benutzer Erwartung LAN Dc-zh-204-01 (RADIUS)

Pc-zh-204-02 (Win10 Enterprise)
Systemtest, Abnahmetest
#8 Neue Benutzer Erwartung WLAN Dc-zh-204-01 (RADIUS)

Pc-zh-204-02 (Win10 Enterprise)
Systemtest, Abnahmetest
#9 Benutzer Wechsel mit Abmeldung bei dem Gerät Dc-zh-204-01 (RADIUS)

Pc-zh-204-02 (Win10 Enterprise)
Sicherheitstest, Komponententest
#10 Benutzer Wechsel ohne Abmeldung bei dem GerätDc-zh-204-01 (RADIUS)

Pc-zh-204-02 (Win10 Enterprise)
Sicherheitstest, Komponententest

Tabelle 24: Testmittel und Testmethoden

Arbeitspakete für die Realisierungsphase

In der untenstehenden Liste finden sich die geplanten Arbeitspakete für die Realisierungsphase:

<HTML><ol style=„list-style-type: decimal;“></HTML> <HTML><li></HTML><HTML><p></HTML>Switch einrichten<HTML></p></HTML> <HTML><ol style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>Basiseinrichtung<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>VLANs<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Firewall einrichten<HTML></p></HTML> <HTML><ol start=„3“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>Basiseinrichtung<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Interfaces<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Dienste<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Rules<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>BackupPC konfigurieren<HTML></p></HTML> <HTML><ol start=„7“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>Backup der VMs<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Backup der Firewall<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Backup des Switches<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Proxmox einrichten<HTML></p></HTML> <HTML><ol start=„10“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>Basiseinrichtung<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Netzwerk<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Unifi Network Application einrichten<HTML></p></HTML> <HTML><ol start=„12“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>VM Einrichtung<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Unifi Network Application<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Access Point und WLAN einrichten<HTML></p></HTML> <HTML><ol start=„14“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>Access Point adopten<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>WLAN-Konfiguration<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>User Backend einrichten<HTML></p></HTML> <HTML><ol start=„16“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>VM Einrichtung<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Active Directory<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Authentication-Server einrichten<HTML></p></HTML> <HTML><ol start=„18“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>Netzwerkrichtlinienserver<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>RADIUS-Clients einrichten<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Richtlinien einrichten<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Authenticators einrichten<HTML></p></HTML> <HTML><ol start=„21“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>Access Point<HTML></p></HTML><HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Switch<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML> <HTML><li></HTML><HTML><p></HTML>Supplicants einrichten<HTML></p></HTML> <HTML><ol start=„23“ style=„list-style-type: lower-alpha;“></HTML> <HTML><li></HTML><HTML><p></HTML>PC<HTML></p></HTML><HTML></li></HTML><HTML></ol></HTML> <HTML></li></HTML><HTML></ol></HTML>

Realisieren

Konfiguration des Switches

Erster Login

Die IP-Adresse des Zyxel-Switches lautet standardmässig 192.168.1.1. Um sich mit ihm verbinden zu können, muss man sich im selben Subnetz befinden. Danach gibt man in der Weboberfläche den Standard-Login und das Passwort von Zyxel ein.

Konfiguration

Aus Sicherheitsgründen muss das Password geändert werden, das ist möglich unter Management → Access Control → Logins

Für den weiteren Zugriff auf den Switch ist es wichtig, die IP-Adresse des Switches entsprechend der gemäss Planung vorgesehenen Adresse zu ändern. Basic Settings → IP Setup

VLAN Konfiguration

Unter Advanced Application → VLAN → VLAN Configuration → Static VLAN Setup wird die VLAN Konfiguration vorgenommen.

Hier werden alle VLANs mit der entsprechenden Portkonfiguration hinzugefügt, die bei der Entscheidungsphase gewählt wurden.

Beispiel für den VLAN10:

Option Wert
Active Yes
Name VLAN10_SRVAUTH
VLAN Group ID10
Ports fixed 18,23-24,26

forbidden 1-17,19-22,25,27-28

untagged 1-17,19-22,25,27-28

Tabelle 25: Beispiel der VLAN-Konfiguration für den VLAN10

In der untenstehenden Abbildung sieht man einen Beispielausschnitt der VLAN Konfiguration für das VLAN10:

Abbildung 7: Beispiel VLAN10 Port 17-28

Konfiguration als RADIUS Authenticator

Unter Advanced Application → AAA → RADIUS Server Setup wird der Switch als RADIUS Authenticator eingerichtet.

Unter Authentication Server wird die IP-Adresse von dem Authentication Server eingegeben und unter Shared Secret das Kennwort, das auch auf dem Authentication Server abgelegt wird.

Abbildung 8: RADIUS Authentication Server einrichten

Unter Advanced Application → Port Authentication → 802.1X wird 802.1X für einen Port aktiviert, indem unter Active das entsprechende Feld markiert wird:

Abbildung 9: 802.1X Port aktivieren

Am Port 18 können jetzt Supplicants angeschlossen werden.

Firewall

Serial Connection

Standardmässig lautet die IP-Adresse von pfSense 192.168.1.1. Um diese zu ändern, wird ein serieller Adapter verwendet, um die LAN-Schnittstelle zu konfigurieren. Nachdem die IP der Lan-Schnittstelle eingestellt ist, kann man sich mit dem Web-Interface verbinden, wo mit Hilfe des Setup Wizards weitere Konfigurationen möglich sind:

Option Wert
Hostname fw-zh-204-01
Domain rafisa.ipa
DNS 172.21.10.10
Time Server / ZoneEurope/Zurich
WAN Interface DHCP
LAN Interface 172.21.1.1
Admin Password ***********************

Tabelle 26: Firewall: Mögliche Konfigurationen durch den Setup Wizard

VLAN Konfiguration

Um ein VLAN zu konfigurieren, müssen Sie zunächst eine Schnittstelle dafür erstellen. Dazu wird eine optionale Schnittstelle an Port igb3 erstellt. Keine zugewiesene IP, da sie als Grundlage für VLANs dient.

Der nächste Schritt wäre die Einstellung von VLANs (Schnittstellen → VLANs). Durch Drücken der Schaltfläche „Hinzufügen“ öffnet sich das Konfigurationsfenster. Folgende Optionen sind möglich:

  • Parent Interface
  • VLAN Tag
  • VLAN Priority
  • Description

Für alle VLANs unter «Parent Interface» geht die neu erstellte opt1 VLAN-Schnittstelle.

Für VLAN Tag geht einer der in der Entscheidungsphase festgelegten VLAN, die 1, 10, 21, 22 und 23 sind.

VLAN Priority wird ausgelassen.

Unter Beschreibung steht der Name des VLANs.

Beispiel für den VLAN 10:

Abbildung 10: Beispiel VLAN10

Jetzt unter Interfaces können die VLANs gesehen und konfiguriert werden. Dort wird die statische IPv4 Addresse eingerichtet entsprechend der VLANs.

DHCP

Unter Services → DHCP Server lassen sich die DHCP Dienste für alle VLANs einrichten. Als Subnet Range für die Hosts wurden IP-Adressen zwischen 100 und 199 gewählt.

Abbildung 11: Beispiel DHCP für VLAN01

Rules

Für neu angelegte Schnittstellen können nun Regeln aufgestellt werden. Unter Firewall → Rules erscheinen die Schnittstellen. Die Regeln werden von oben nach unten abgelesen, sobald eine Regel zutrifft, wird diese gewählt. Das heisst, die Regeln oben haben Priorität. Zuoberst kommen die “Block» Regeln, die den Zugriff verweigern und danach zum Schluss eine «any to any» Regel. Die «any to any» wird benötigt, um den Zugriff zum WAN bzw. zum Upstream-Gateway zu ermöglichen.

Die Firewallregeln wurden gemäss der Zugriffsmatrix im Kapitel «Entscheiden» erstellt.

Beispiel für den VLAN22:

Abbildung 12: Firewallregeln für VLAN22

Verschlüsselung

Unter System → Advanced → Admin Access wird für das Webinterface HTTPS aktiviert.

Abbildung 13: Aktivierung HTTPS für Web-Interface

Proxmox

Installation

Als Boot-Medium wurde eine Boot-CD erstellt, auf die das Proxmox VE 7.1 ISO Image [10] gebrannt wurde. Während der Installation können im Setup Wizard folgende Einstellungen nach dem Konzept eingerichtet werden:

Option Wert
Country Switzerland
Timezone Europe/Zurich
Keyboard Layout de-ch
Management Interfaceenp11s0
Hostname prox-zh-204-01.rafisa.ipa
IP CIDR 172.21.1.20/24
Gateway 172.21.1.1
DNS 172.21.10.10

Tabelle 27: Proxmox: Einstellungen bei dem Setup Wizard

Network

Für die Zuordnung der VMs zu den VLANs werden entsprechende VLAN-Bridges und Netzwerkschnittstellen benötigt. Dies kann über die WebGUI oder CLI auf Proxmox erfolgen. Die Netzwerkkonfiguration sieht wie folgt aus:

<HTML><ul></HTML>
<HTML><li></HTML><HTML><p></HTML>auto lo<HTML></p></HTML>

<HTML><p></HTML>iface lo inet loopback<HTML></p></HTML>

<HTML><p></HTML>iface enp11s0 inet manual<HTML></p></HTML>

<HTML><p></HTML>iface enp21s0 inet manual<HTML></p></HTML>

<HTML><p></HTML>iface enx02215e6c9269 inet manual<HTML></p></HTML>

<HTML><p></HTML>auto vmbr0<HTML></p></HTML>

<HTML><p></HTML>iface vmbr0 inet static<HTML></p></HTML>

<HTML><p></HTML>address 172.21.1.20/24<HTML></p></HTML>

<HTML><p></HTML>gateway 172.21.1.1<HTML></p></HTML>

<HTML><p></HTML>bridge-ports enp11s0<HTML></p></HTML>

<HTML><p></HTML>bridge-stp off<HTML></p></HTML>

<HTML><p></HTML>bridge-fd 0<HTML></p></HTML>

<HTML><p></HTML>bridge-vlan-aware yes<HTML></p></HTML>

<HTML><p></HTML>bridge-vids 1-4094<HTML></p></HTML>

<HTML><p></HTML>auto vmbr10<HTML></p></HTML>

<HTML><p></HTML>iface vmbr10 inet manual<HTML></p></HTML>

<HTML><p></HTML>bridge-ports enp11s0.10<HTML></p></HTML>

<HTML><p></HTML>bridge-stp off<HTML></p></HTML>

<HTML><p></HTML>bridge-fd 0<HTML></p></HTML>

<HTML><p></HTML>bridge-vlan-aware yes<HTML></p></HTML>

<HTML><p></HTML>bridge-vids 1-4094<HTML></p></HTML>

<HTML><p></HTML>auto vmbr21<HTML></p></HTML>

<HTML><p></HTML>iface vmbr21 inet manual<HTML></p></HTML>

<HTML><p></HTML>bridge-ports enp11s0.21<HTML></p></HTML>

<HTML><p></HTML>bridge-stp off<HTML></p></HTML>

<HTML><p></HTML>bridge-fd 0<HTML></p></HTML>

<HTML><p></HTML>bridge-vlan-aware yes<HTML></p></HTML>

<HTML><p></HTML>bridge-vids 1-4094<HTML></p></HTML>

<HTML><p></HTML>auto vmbr22<HTML></p></HTML>

<HTML><p></HTML>iface vmbr22 inet manual<HTML></p></HTML>

<HTML><p></HTML>bridge-ports enp11s0.22<HTML></p></HTML>

<HTML><p></HTML>bridge-stp off<HTML></p></HTML>

<HTML><p></HTML>bridge-fd 0<HTML></p></HTML>

<HTML><p></HTML>bridge-vlan-aware yes<HTML></p></HTML>

<HTML><p></HTML>bridge-vids 1-4094<HTML></p></HTML><HTML></li></HTML><HTML></ul></HTML>

Image

Um die VMs erstellen zu können, werden Images von dessen OS benötigt. Die werden unter local storage → ISO Images auf dem Proxmox Server hochgeladen. Danach können die Images bei der VM Erstellung angewendet werden.

BackupPC

Script für den Switch

Für den Backup des Switches wurde ein Script aus der Arbeit von Sabareeshan Nadeswaran [2] übernommen und angepasst. Das angepasste Script sieht folgendermassen aus:

> #!/bin/bash

ftp -n 172.21.1.2 «EOF

quote USER *******

quote PASS *******

get config

Quit

EOF

mv /home/sysadmin/bin/config /home/sysadmin/bin/dump-fw-sw/sw-zh-204-01.conf

Das Skript funktioniert folgendermassen: In der ersten Zeile wird die Datei als ausführbare Bash-Datei definiert. Danach verbindet es sich über FTP mit dem Switch und gibt die Befehle zwischen EOF auf dem Switch ein. Nämlich das Einloggen, das Abrufen der Konfigurationsdatei und das Beenden am Ende. Nachdem die Verbindung beendet wurde, verschiebt es die Datei in den Dump-Ordner und benennt die Datei in einen identifizierbaren Namen um.

Script für die Firewall

Für den Backup des Firewalls wurde ein Script aus der Arbeit von Sabareeshan Nadeswaran übernommen und angepasst. Der Angepasste Script sieht folgendermassen aus:

> #!/bin/bash

/usr/bin/sshpass -p ****** scp -oStrictHostKeyChecking=no *******@172.21.1.1:/conf/config.xml /home/sysadmin/bin/dump-fw-sw/fw-zh-204-01.conf

Das Skript funktioniert folgendermassen: In der ersten Zeile wird die Datei als ausführbare Bash-Datei definiert. Danach verbindet es sich mit der Firewall über sshpass und kopiert die Konfigurationsdatei über scp in den Dump-Ordner.

Anpassungen für Backup der VMs

Um die VMs automatisch zu sichern, müssen einige Einstellungen vorgenommen werden. Auf dem Proxmox wird ein neuer Benutzer angelegt, rafisa-backup, der für die Ausführung der Befehle von BackupPC auf dem Proxmox zuständig ist.

Passwortlose Login

Auf dem Backup Server wird als Systembenutzer backuppc mit dem Befehl ssh-keygen -t rsa ein Schlüsselpaar erzeugt. Danach wird als backuppc-Benutzer auf BackupPC der Befehl ssh-copy-id rafisa-backup@prox-zh-204-01.rafisa.ipa ausgeführt und damit der Public-Key auf den Proxmox Server übertragen. Von jetzt an kann sich backuppc mit dem Private-Key passwortlos beim Proxmox Server anmelden.

Sudo Befehle

Auf dem Proxmox Server ist der Benutzer rafisa-backup berechtigt, die Befehle rsync und vzdump mit sudo ohne Passwort zu verwenden, um das Backup zu automatisieren und die Sicherung von Daten zu ermöglichen, die sudo-Rechte erfordern. Die Rechte werden mit den zwei folgenden Einträgen in der Datei /etc/sudoers zugewiesen:

Abbildung 14: Sudo-Rechte für rafisa-backup

Unifi Controller

VM

Im Proxmox Interface wird mit Create VM eine neue VM erstellt. Mit Hilfe des Setup Wizards wird die VM gemäss Konzept erzeugt.

Windows 2019 (Unifi Network Application)
Ressourcen Werte
Disk Bus/Device SATA
Disk Format RAW Disk Image
Disk Grösse 40 GB
CPU 1 Socket 4 Cores
RAM 3 GB
Netzwerkadapter E1000

Tabelle 28: Hardware-Spezifikation der Unifi Controller VM

Für die VM wird das Windows Server 2019 Image angewendet. Wichtig ist dass die VM der richtigen Bridge zugeteilt wird. Der Unifi Controller soll wie der Access Point im Management VLAN stehen und wird deswegen der Bridge vmbr0 (VLAN01) zugeteilt.

Abbildung 15: Zusammenfassung der Konfiguration für uni-zh-204-01

Installation

Die Unifi Network Application (Unifi Controller) kann unter https://www.ui.com/download-software/ heruntergeladen und danach ausgeführt werden.

Erstes Setup

Bei dem Start des Programmes wird ein Startfenster der Unifi Network Application geöffnet. Nach ca 5-10 Sekunden erlaubt die Applikation eine Web GUI zu öffnen.

Abbildung 16: Unifi Network Application Startfenster

Bei dem Ersten Start wird eine Installation durchgeführt, folgende Parameter sind zu konfigurieren.

Option Wert
Account Admin
WiFi Name 802.1X.rafisa.ipa
Country or territorySwitzerland
Timzone (UTC+02:00) Europe/Zurich

Tabelle 29: Unifi Network Application: Setup Wizard Parameter

Konfiguration des Access Points als RADIUS Authenticator

Unter Einstellungen → Profile muss ein neues RADIUS-Profil erstellt werden. Unter Authentifizierungsserver wird die IP-Adresse des Authentifizierungsservers sowie das Shared Secret eingegeben, das ebenfalls auf dem Authentifizierungsserver hinterlegt wird.

Unter Einstellungen → WiFi muss das WiFi konfiguriert werden. Im Abschnitt Sicherheit wird das Security Protocol als WPA2 Enterprise festgelegt. Dadurch kann das zuvor erstellte RADIUS-Profil ausgewählt werden.

Abbildung 17: WPA2-Enterprise RADIUS Profil

Gast WLAN

Für das Gast WLAN wird ein neues Netzwerk erstellt, das VLAN-only ist. Als VLAN ID wird 23 eigetragen. Danach wird ein neues WiFi Netzwerk erstellt, wo dann das VLAN-Only Netzwerk eingetragen wird. Dann wird noch Anzeigename angepasst zu 802.1X.rafisa.ipa – GAST.

Abbildung 18: Gast WiFi

AP

Nachdem der Access Point an entsprechenden Port angeschlossen ist, wird er eingeschaltet. Man muss warten, bis die LED-Leuchte konstant weiss leuchtet. Wenn dies der Fall ist, muss im Web-GUI der Unifi Network Application die Registerkarte Devices geöffnet werden.

In der Liste kommt der Access Point vor als UAP-AC-Pro mit dem Status Pending Adoption. Man drückt in der Liste auf den Access Point. Im folgenden Fenster kann man den AP adopten.

Nachdem der Access Point in der Controller-Software registriert (adopted) wurde, können Anpassungen gemäss Konzept vorgenommen werden.

Option Wert
Device Nameuni-zh-204-01
IP 172.21.1.164

Tabelle 30: Access-Point Parameter

User Backend

Als User Backend nach Konzept wurde soeben Windows Server 2019 gewählt.

VM

Im Proxmox Interface wird mit Create VM eine neue VM erstellt. Mit Hilfe des Setup Wizards wird die VM gemäss Konzept erzeugt.

Windows 2019 (DC)
Ressourcen Werte
Disk Bus/Device SATA
Disk Format RAW Disk Image
Disk Grösse 40 GB
CPU 1 Socket 4 Cores
RAM 4 GB
Netzwerkadapter E1000

Tabelle 31: Hardware-Spezifikation der User Backend VM

Für die VM wird das Windows Server 2019 Image angewendet. Wichtig ist dass die VM der richtigen Bridge zugeteilt wird. Der Domain Controller soll wie im Authentifizierungs VLAN stehen und wird deswegen der Bridge vmbr10 (VLAN10) zugeteilt.

Konfiguration

Im Server-Manager wird unter Lokaler Server → Ethernet die IP-Adresse angepasst. Der Hostname muss nach dem Namenskonzept im Server-Manager unter Lokaler Server → Computername angepasst werden.

Abbildung 19: Server Manager von dc-zh-204-01

Active Directory

Nach der Windows Server 2019 Installation muss über das Server Dashboard die Active Directory Rolle hinzugefügt werden.

Während der Installation wird der Name der Domäne als rafisa.ipa gesetzt. Für alle anderen Einstellungen wird der Default gewählt.

In Active Directory werden nach Konzept die Organisationseinheiten erstellt, in welche dann die Gruppen und Benutzer hinzugefügt werden.

Abbildung 20: AD Struktur

Authentication-Server

Im Windows Server 2019 Dashboard unter Verwalten → Rollen und Features hinzufügen muss eine neue Rolle, Network Policy Server, installiert werden. Die Installation erfolgt, ohne dass etwas konfiguriert werden muss.

Clients

Im neu installierten Netzwerkrichtlinienserver müssen die zwei Authenticators (AP + Switch) eingetragen werden. Mit dem Rechtsklick auf RADIUS-Clients ist es möglich neue Authenticator zu erstellen und anschliessend direkt zu konfigurieren.

Abbildung 21: RADIUS-Clients

Bei der Konfiguration müssen folgende Optionen festgelegt werden:

Option Wert
Aktiviert Ob der RADIUS-Client aktiv oder inaktiv ist.
Anzeigename zur Identifizierung
Adresse (IP oder DNS) IP-Adressen der Authenticators (Switch und Access Point)
Gemeinsamer geheimer SchlüsselGemeinsamer Schlüssel, der auf dem Switch und dem Zugangspunkt für 802.1X eingegeben wurde.

Tabelle 32: RADIUS-Client Konfigurations-Optionen

Beispiel für den Switch:

Abbildung 22: RADIUS-Client Konfiguration

Richtlinien

Die Richtlinien unter Richtlinien → Netzwerkrichtlinien sind zuständig für die Zuweisung der Benutzer in die korrekten VLANs. Folgende Konfigurationen sind notwendig:

Option Wert
Richtlinienname Die Richtliniennamen wurden zur besseren Erkennbarkeit nach dem «802.1X [wired/wireless] [GRUPPE]» Format erstellt.
Bedingungen Hier werden die Bedingungen erfasst, die der Supplicant erfüllen muss, um das korrekte VLAN zugewiesen zu bekommen. Aktuell sind die Bedingungen die Client IP-Adresse der Authenticators sowie die AD Sicherheitsgruppe.
AuthentifizierungsmethodenMicrosoft: Geschütztes EAP (PEAP)
RADIUS-Attribute Diese werden angewendet, wenn die Bedingungen der Verbindungsanforderung entsprechen und die Richtlinie Zugriff gewährt.

Folgende Attribute sind wichtig:

Tunnel-Medium-Type, Tunnel-Pvt-Group-ID, Tunnel-Type

Tabelle 33: Notwendige Richtlinien-Konfigurationen

Beispiel der Konfiguration für «802.1X wireless CLEMPL»:

Abbildung 23: Beispiel für der Richtlinie „802.1X wireless CLEMPL“

Supplicant

Damit der Supplicant (Windows 10) 802.1X verwenden kann, müssen Anpassungen vorgenommen werden. Bei Windows Diensten müssen folgende Dienste eingeschaltet werden:

  • Für LAN: Automatische Konfiguration (verkabelt)
  • Für WLAN: Automatische WLAN-Konfiguration

LAN

Unter dem LAN Adapter ist neue Registerkarte zu sehen, Authentifizierung.

Abbildung 24: Neue Registerkarte bei dem Ethernet Adapter

In der neue Registerkarte sind folgende Änderungen vorzunehmen:

Option Wert
IEEE 802.1X-Authentifizierung aktivieren Den Hacken setzen
Methode für die Netzwerkauthentifizierung Geschütztes EAP (PEAP)
Für diese Verbindung eigene Anmeldeinformationen für jede Anmeldung speichernDen Hacken setzen
Zusätzliche Einstellungen…
Authentifizierungsmodus Benutzerauthentifizierung
Einmaliges Anmelden für dieses Netzwerk aktivieren Unmittelbar vor der Benutzeranmeldung ausführen

Tabelle 34: Änderungen die für 802.1X Authentifizierung zu tun sind

WLAN

Bei dem Supplicant müssen keine weiteren Anpassungen für den 802.1X WLAN-Gebrauch vorgenommen werden.

Kontrollieren

Testdurchführung

In diesem Kapitel sind die Testprotokolle der Testfälle zu finden.

Backup Server

Testfall Nr. #1
Beschreibung Prüfen, ob BackupPC Server seit der Bereitstellung Backups erstellt hat.
Testperson Timafei Pabiarzhyn
Testzeitpunkt 19.04.2022, 18:32
Vorgehen 1. Verbinden mit dem Web-Interface von BackupPC: Aufrufen der URL https://bkp-zh-205-02.rafisa.ipa von pc-zh-204-01

2. In der Registerkarte «Host Summary» ist die Anzahl der Full und Incremental Backups ersichtlich.
Voraussetzung Die Backup Clients mit den Scripts wurden eingerichtet.
Erwartetes Resultat Am 19.04.22 sollten für alle Systeme ein Full und 6 Incremental Backups vorliegen.
OK / nicht OK Nicht OK
Aufgetretene Fehler / Bemerkungen Für die VM dc-zh-204-01 liegen nur 4 Incremental Backups vor.
Fazit und Empfehlungen Auf den ersten Blick konnte nicht herausgefunden werden, warum zwei Incremental Backups nicht gemacht worden sind. Für die Fehlersuche müssen die Log-Files tiefer untersucht werden.

Tabelle 35: Testfall #1: Prüfen, ob BackupPC Server seit der Bereitstellung Backups erstellt hat

Testfall Nr. #2
Beschreibung Prüfen, ob Restore von den Backups von 1x Switch, 1x Firewall und 1x VM möglich sind.
Testperson Timafei Pabiarzhyn
Testzeitpunkt 20.04.2022, 13:13
Vorgehen Restore des Switches: Auf der BackupPC Web-Oberfläche wird unter Host Summary → dump-sw-fw.rafisa.ipa → Backup Summary das letzte Backup ausgewählt. Die gesicherte Switch-Konfiguration befindet sich unter /home/sysadmin/bin/dump_sw-fw. Mit einem Linksklick wird sie heruntergeladen. Auf der Web-Oberfläche des Switches wird unter Management → Maintanance → Restore Configuration nach der Konfigurationsdatei gefragt. Nach dem die Datei gewählt wurde, wird auf den Knopf «Restore» gedrückt.

Restore des Firewalls: Auf der BackupPC Web-Oberfläche wird unter Host Summary → dump-sw-fw.rafisa.ipa → Backup Summary das letzte Backup ausgewählt. Die gesicherte Firewall-Konfiguration befindet sich unter /home/sysadmin/bin/dump_sw-fw. Mit einem Linksklick wird sie heruntergeladen. Auf der Web-Oberfläche der Firewall wird unter Diagnostics → Backup & Restore → Backup & Restore → Restore Backup nach der Konfigurationsdatei gefragt. Nachdem die Datei ausgewählt wurde, wird auf den Knopf «Restore Configuration» und danach «Ok» gedrückt. Die Firewall wird dann rebooten.

Restore der VM: Auf der BackupPC Web-Oberfläche wird unter Host Summary → vm-uni-zh-204-01.rafisa.ipa → Backup Summary das letzte Backup ausgewählt. Über den Knopf «Restore selected files» wird eine Seite geöffnet, wo unter «Option 1: Direct Restore» der Restore gestartet werden kann. Sobald der Restore fertig ist, kann auf der Proxmox Web-Oberfläche unter local → Backups das Backup der VM wiederherstellt werden, indem die VM gewählt und auf das Knopf «Restore» gedrückt wird.
Voraussetzung Die Backups wurden von BackupPC durchgeführt.
Erwartetes Resultat Die Backups können auf die jeweiligen Systeme wiederherstellt werden.
OK / nicht OK OK
Aufgetretene Fehler / Bemerkungen Keine Fehler sind aufgetreten.
Fazit und Empfehlungen Die Wiederherstellung der Systeme konnte durchgeführt werden.
Switch
Firewall
VM

Tabelle 36: Testfall #2: Prüfen, ob Restore von den Backups von 1x Switch, 1x Firewall und 1x VM möglich sind

Firewall

Testfall Nr. #3
Beschreibung Die Firewall Regeln anhand der Zugriffsmatrix testen. 
Testperson Timafei Pabiarzhyn
Testzeitpunkt 14.04.2022, 13:05
Vorgehen pc-zh-204-01 wird nacheinander in die VLANs 1,21,22 und 23 angemeldet, wo dann ein ping an die Firewall-Schnittstellen 01,10,21,22,23 und die Internetadresse «8.8.8.8» gesendet wird.

Mit dc-zh-204-01 wird die VLAN 10 getestet, indem die Firewall Schnittstellen 01,10,21,22,23 und die Internetadresse «8.8.8.8» mit ping geprüft werden.
Voraussetzung Die Firewall Regeln wurden eingerichtet.
Erwartetes Resultat Die Firewall Regeln funktionieren korrekt.
OK / nicht OK OK
Aufgetretene Fehler / BemerkungenKeine Fehler sind aufgetreten.
Fazit und Empfehlungen Die Firewall Regeln wurden korrekt eingerichtet.

Tabelle 37: Testfall #3: Die Firewall Regeln anhand der Zugriffsmatrix testen.

Testfall Nr. #4
Beschreibung Die Zugänge zu den Administrationsoberflächen sind verschlüsselt
Testperson Timafei Pabiarzhyn
Testzeitpunkt 14.04.2022, 13:34
Vorgehen Die Webinterfaces von folgenden Systemen wurden von pc-zh-204-01 in VLAN01 aufgerufen:

prox-zh-204-01 (https://prox-zh-204-01.rafisa.ipa)

uni-zh-204-01(https://uni-zh-204-01.rafisa.ipa)

bkp-zh-205-02(https://bkp-zh-205-02.rafisa.ipa)

fw-zh-204-01(https://fw-zh-204-01.rafisa.ipa)

sw-zh-204-01(https://sw-zh-204-01.rafisa.ipa)
Voraussetzung Https wurde bei den Weboberflächen eingerichtet.
Erwartetes Resultat Die Seiten werden geladen, und der Browser zeigt eine verschlüsselte Seite.
OK / nicht OK Nicht OK
Aufgetretene Fehler / BemerkungenDie Administrations-Oberfläche des Switches sw-zh-204-01 konnte nicht verschlüsselt aufgerufen werden, da die Firmware in der Version 4.30 kein TLS 1.2 unterstützt. Modernere Browser weisen TLS kleiner 1.2 ab.
Fazit und Empfehlungen Alle Seiten wurden erfolgreich über https aufgerufen, ausser sw-zh-204-01. Da es für diesen Switch keine neuere Firmware Version gibt, wird empfohlen diesen Switch nicht produktiv einzusetzen.

Tabelle 38: Testfall #4: Die Zugänge zu den Administrationsoberflächen sind verschlüsselt

802.1X

Testfall Nr. #5
Beschreibung Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen. LAN
Testperson Timafei Pabiarzhyn
Testzeitpunkt 14.04.2022, 14:23
Vorgehen Der pc-zh-204-02 wird am Port 18 des Switches angeschlossen. Beim Windows-Anmeldebildschirm melden sich folgende User nacheinander an und wieder ab:

* a.pabiarzhyn (Netadmins)
* f.muster (CLEMPL)
* h.peter (CLLEARN)
Voraussetzung Pc-zh-204-02 wurde als Supplicant eingerichtet. Pc-zh-204-02 ist nicht mit WLAN verbundens. Sw-zh-204-01 wurde als Authenticator eingerichtet. Die Richtlinien für die drei Gruppen wurden bei dem Authentication-Server erstellt. Die drei Benutzer existieren im User-Backend.
Erwartetes Resultat Der Befehl ipconfig zeigt bei den drei Usern die Adressen aus entsprechenden VLANs:

* a.pabiarzhyn (Netadmins): 172.21.1.X
* f.muster (CLEMPL): 172.21.21.X
* h.peter (CLLEARN): 172.21.22.X
OK / nicht OK OK
Aufgetretene Fehler / BemerkungenKeine Fehler sind aufgetreten
Fazit und Empfehlungen Die VLAN Zuweisung über LAN funktioniert.

Tabelle 39: Testfall #5: Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen. LAN

Testfall Nr. #6
Beschreibung Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen. WLAN
Testperson Timafei Pabiarzhyn
Testzeitpunkt 14.04.2022, 15:37
Vorgehen Der pc-zh-204-02 wird vor dem Windowslogin am WLAN 802.1X.rafisa.ipa mit den entsprechenden User-Credentials angemeldet. Danach melden sich folgende User beim Windows-Anmeldebildschirm nacheinander an und wieder ab:

* a.pabiarzhyn (Netadmins)
* f.muster (CLEMPL)
* h.peter (CLLEARN)
Voraussetzung Pc-zh-204-02 wurde als Supplicant eingerichtet. Pc-zh-204-02 ist nicht an LAN angeschlossen. Ap-zh-204-01 wurde als Authenticator eingerichtet. Die Richtlinien für die drei Gruppen wurden bei dem Authentication-Server erstellt. Die drei Benutzer existieren im User-Backend.
Erwartetes Resultat Der Befehl ipconfig zeigt bei den drei Usern die Adressen aus entsprechenden VLANs:

* a.pabiarzhyn (Netadmins): 172.21.1.X
* f.muster (CLEMPL): 172.21.21.X
* h.peter (CLLEARN): 172.21.22.X
OK / nicht OK OK
Aufgetretene Fehler / BemerkungenKeine Fehler sind aufgetreten
Fazit und Empfehlungen Die VLAN Zuweisung über WLAN funktioniert. Es sollte nach einer Lösung gesucht werden, bei der die WLAN-Anmeldung automatisch über das Windows Login erfolgen kann.

Tabelle 40: Testfall #6: Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen. WLAN

Testfall Nr. #7
Beschreibung Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen für einen neuen Benutzer. LAN
Testperson Timafei Pabiarzhyn
Testzeitpunkt 19.04.2022, 14:36
Vorgehen Auf dem Authentifizierungsserver wird ein neuer Benutzer erstellt und einer der bestehenden Gruppen zugewiesen. Am pc-zh-204-02 meldet sich der Benutzer über LAN beim Windows-Anmeldebildschirm an.
Voraussetzung Pc-zh-204-02 wurde als Supplicant eingerichtet. Pc-zh-204-02 ist nicht mit WLAN verbunden. Sw-zh-204-01 wurde als Authenticator eingerichtet. Die Richtlinien für die Gruppe, zu die der neue Benutzer zugewiesen wird, wurde bei dem Authentication-Server erstellt.
Erwartetes Resultat Nach der Windows-Anmeldung wird ein neues Windowsprofil erstellt und dem Benutzer über LAN das korrekte VLAN zugeteilt.
OK / nicht OK OK
Aufgetretene Fehler / BemerkungenKeine Fehler sind aufgetreten
Fazit und Empfehlungen Ein neuer Benutzer muss vor der ersten Anmeldung über LAN keine besonderen Schritte unternehmen.

Tabelle 41: Testfall #7: Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen für einen neuen Benutzer. LAN

Testfall Nr. #8
Beschreibung Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen für einen neuen Benutzer. WLAN
Testperson Timafei Pabiarzhyn
Testzeitpunkt 19.04.2022, 15:58
Vorgehen Auf dem Authentifizierungsserver wird ein neuer Benutzer erstellt und einer der bestehenden Gruppen zugewiesen. Am pc-zh-204-02 meldet sich der Benutzer über WLAN und danach beim Windows-Anmeldebildschirm an.
Voraussetzung Pc-zh-204-02 wurde als Supplicant eingerichtet. Pc-zh-204-02 ist nicht an LAN angeschlossen. Ap-zh-204-01 wurde als Authenticator eingerichtet. Die Richtlinien für die Gruppe, zu die der neue Benutzer zugewiesen wird, wurde bei dem Authentication-Server erstellt.
Erwartetes Resultat Nach der Windows-Anmeldung wird ein neues Windowsprofil erstellt und dem Benutzer über WLAN das korrekte VLAN zugeteilt.
OK / nicht OK OK
Aufgetretene Fehler / BemerkungenKeine Fehler sind aufgetreten
Fazit und Empfehlungen Ein neuer Benutzer muss vor der ersten Anmeldung über WLAN keine besonderen Schritte unternehmen.

Tabelle 42: Testfall #8: Die VLAN Zuteilung anhand der Zugehörigkeit zu einer Sicherheitsgruppe testen für einen neuen Benutzer. WLAN

Testfall Nr. #9
Beschreibung Es wird geprüft, ob ein Nutzer etwas tun muss, bevor er mit einem anderen Nutzer tauscht. Mit Abmeldung
Testperson Timafei Pabiarzhyn
Testzeitpunkt 19.04.2022, 16:41
Vorgehen Am pc-zh-204-02 ist h.peter über LAN auf dem PC Angemeldet. H.peter meldet sich bei dem PC ab und danach logt sich f.muster ein. Es wird geprüft, ob die VLAN von 22 zu 21 gewechselt wurde.

Am pc-zh-204-02 ist h.peter über WLAN auf dem PC Angemeldet. H.peter meldet sich bei dem PC und WLAN ab und danach logt sich f.muster ein. Es wird geprüft, ob die VLAN von 22 zu 21 gewechselt wurde.
Voraussetzung Pc-zh-204-02 wurde als Supplicant eingerichtet. Ap-zh-204-01 und sw-zh-204-01 wurden als Authenticators eingerichtet. Die Richtlinien für Gruppen wurden bei dem Authentication-Server erstellt. Die Benutzer existieren im User-Backend.
Erwartetes Resultat In beiden Fällen nach der Abmeldung wird der nächste Benutzer in das korrekte VLAN zugewiesen.
OK / nicht OK OK
Aufgetretene Fehler / BemerkungenKeine
Fazit und Empfehlungen Nach sauberer Abmeldung scheint die VLAN Zuweisung korrekt zu funktionieren.

Tabelle 43: Testfall #9: Es wird geprüft, ob ein Nutzer etwas tun muss, bevor er mit einem anderen Nutzer tauscht. Mit Abmeldung

Testfall Nr. #10
Beschreibung Es wird geprüft, ob ein Nutzer etwas tun muss, bevor er mit einem anderen Nutzer tauscht. Ohne Abmeldung
Testperson Timafei Pabiarzhyn
Testzeitpunkt 19.04.2022, 17:22
Vorgehen Am pc-zh-204-02 ist h.peter über LAN auf dem PC Angemeldet. H.peter meldet sich bei dem PC nicht ab und danach logt sich f.muster ein. Es wird geprüft, ob die VLAN von 22 zu 21 gewechselt wurde.

Am pc-zh-204-02 ist h.peter über WLAN auf dem PC Angemeldet. H.peter meldet sich bei dem PC und WLAN nicht ab und danach logt sich f.muster ein. Es wird geprüft, ob die VLAN von 22 zu 21 gewechselt wurde.
Voraussetzung Pc-zh-204-02 wurde als Supplicant eingerichtet. Ap-zh-204-01 und sw-zh-204-01 wurden als Authenticators eingerichtet. Die Richtlinien für Gruppen wurden bei dem Authentication-Server erstellt. Die Benutzer existieren im User-Backend.
Erwartetes Resultat In beiden Fällen wird der nächste Benutzer in das korrekte VLAN zugewiesen.
OK / nicht OK Nicht OK
Aufgetretene Fehler / BemerkungenNach der Anmeldung von dem zweiten Benutzer wurde VLAN nicht auf das korrekte geändert.
Fazit und Empfehlungen Die Benutzer müssen sich abmelden und die Verbindung zum WLAN trennen, damit der nächste Benutzer dem richtigen VLAN zugewiesen wird.

Tabelle 44: Testfall #10: Es wird geprüft, ob ein Nutzer etwas tun muss, bevor er mit einem anderen Nutzer tauscht. Ohne Abmeldung

Testfall Nr. #11
Beschreibung Gast WLAN
Testperson Timafei Pabiarzhyn
Testzeitpunkt 20.04.2022, 08:43
Vorgehen Der pc-zh-204-02 wird vor dem Windowslogin am WLAN 802.1X.rafisa.ipa – GAST angemeldet. Danach melden sich folgende User beim Windows-Anmeldebildschirm nacheinander an und wieder ab:

* a.pabiarzhyn (Netadmins)
* f.muster (CLEMPL)
* h.peter (CLLEARN)
Voraussetzung Pc-zh-204-02 wurde als Supplicant eingerichtet. Pc-zh-204-02 ist nicht an LAN angeschlossen. Ap-zh-204-01 wurde als Authenticator eingerichtet. Die Richtlinien für die drei Gruppen wurden bei dem Authentication-Server erstellt. Die drei Benutzer existieren im User-Backend.
Erwartetes Resultat Der Befehl ipconfig zeigt bei den drei Usern die Adressen aus entsprechende VLAN:

* a.pabiarzhyn (Netadmins): 172.21.23.X
* f.muster (CLEMPL): 172.21.23.X
* h.peter (CLLEARN): 172.21.23.X
OK / nicht OK OK
Aufgetretene Fehler / BemerkungenKeine Fehler sind aufgetreten
Fazit und Empfehlungen Die VLAN Zuweisung über Gast-WLAN funktioniert.

Tabelle 45: Testfall #11: Gast WLAN

Auswerten

Die IPA ist 80% Dokumentieren und 20% Realisieren. Genau die 80% - Dokumentieren, sind meine Schwäche. In Laufe des Projektes hatte ich immer Stress, da ich das Dokumentieren sehr unterschätzt habe. Deswegen konnte ich nur teilweise die Soll-Zeiten einhalten. Jedoch konnte ich trotzdem die Arbeit fertigstellen.

Die Projektmethode IPERKA habe ich gewählt aus dem Grund, da ich sie im Vergleich zu den anderen Projektmethoden am besten kenne und ich nicht experimentieren wollte. Alles in allem bin ich mit meiner Wahl zufrieden, bin aber neugierig, ob es eine Projektmethode gibt, die noch effizienter ist.

Einige Probleme sind in Laufe des Projekts aufgetreten, die behoben werden konnten. Jedoch ist mir aufgefallen, dass Abnahmeprotokolle wichtig sind. Auf dem Backup-Server sind zwei Probleme aufgetreten, die hätten verhindert werden können, wenn BackupPC korrekt installiert worden wäre. Ich hätte Zeit sparen können, wenn ich den Server selbst überprüft hätte, um sicher zu sein, dass alles wie gewünscht installiert worden ist.

In der Testing-Phase zeigten sich ein paar Probleme, die gelöst werden müssen, bevor das System produktiv wird:

  • Die Benutzer können auf den Geräten nicht dynamisch gewechselt werden. Die Benutzer müssen sich zuerst abmelden und erst danach kann ein anderer Benutzer anmelden. Ansonsten bleibt die zugewiesene IP-Adresse des Benutzers #1. Eine konkrete Lösung für das Problem habe ich nicht gefunden, ausser auf zwei Arten. Mit einer organisatorischen Richtlinie, in welcher vorgeschrieben wird, dass die Benutzer sich immer abmelden müssen. Oder mit einer technischen Richtlinie, wo es ein Skript erstellt wird, das beim Benutzerwechsel die Benutzer automatisch von WLAN und LAN abmeldet.
  • Es wurde festgestellt, dass durch WLAN und LAN beliebige Geräte in das interne Netz gelangen können, also auch Geräte, die nicht in der Domäne sind. Dieses Problem könnte man mittels Zertifikaten lösen, die per GPO auf die Geschäftsgeräte verteilt werden. Ich hatte nicht die Zeit, um mich mit dem Problem zu beschäftigen.

Bis auf die zwei Probleme, scheint die Lösung zu funktionieren.

Schlussfolgerung und Fazit

Der letzter Projekttag ist nun gleich vorbei und ich werde die Dokumentation signieren. Das heisst aber nicht, dass es vorbei ist, denn in nur 2 Wochen ist Termin für Präsentation, Fachgespräch und Demonstration. Also ein paar Tage ausruhen und zurück an die Arbeit.

Ich würde mich freuen, wenn ich bei Implementierung helfen kann.

Generell fand ich die IPA sehr anstrengend, die zehn Tage für die Realisierung und Dokumentation eines so komplexen Projekts waren sehr kurz. Ich bin sehr zufrieden, dass es mir gelungen ist, eine funktionierende Gesamtlösung zu erarbeiten.

Literaturverzeichnis

[1] R. I. GmbH, «Firmenstandards für das Netzwerk der Rafisa Informatik GmbH,» 2021. [Online]. Available: https://wiki.rafisa.net/doku.php?id=intern:standards:standards.

[2] S. Nadeswaran, «Konzipierung, Aufbau und Anbindung des Netzwerkes für einen externen Firmenstandort (IPA 2021),» 2021.

[3] L. Cotar, «Deployment Server (IPA 2021),» 2021.

[4] «Make Use Of,» [Online]. Available: https://www.makeuseof.com/check-system-details-and-hardware-information-on-linux/.

[5] «Zyxel Networks,» [Online]. Available: https://www.zyxel.com/products_services/8-24-48-port-GbE-Smart-Managed-Switch-GS1920-Series/specification.

[6] «Ubiquity - Simplifying IT,» [Online]. Available: https://dl.ui.com/datasheets/unifi/UniFi_AC_APs_DS.pdf.

[7] «PC Engines,» [Online]. Available: https://www.pcengines.ch/apu4d2.htm.

[8] «Microsoft Documentation,» [Online]. Available: https://docs.microsoft.com/en-us/windows-server/get-started/hardware-requirements.

[9] «Debian GNU/Linux Installation Guide,» [Online]. Available: https://www.debian.org/releases/jessie/amd64/ch03s04.html.en.

[10] P. VE, «Proxmox,» 2021. [Online]. Available: https://www.proxmox.com/en/downloads?task=callelement&format=raw&item_id=638&element=f85c494b-2b32-4109-b8c1-083cca2b7db6&method=download&args[0]=8362171061e723e815cdc5893be1fe09. [Zugriff am 8 April 2022].

[11] Wikipedia, «Wikipedia,» 2022. [Online]. Available: https://de.wikipedia.org/wiki/Wikipedia:Hauptseite.

Teil 3 – Anhang

Glossar

Die Definitionen im Glossar sind grösstenteils an die Definitionen in Wikipedia [11] angelehnt.

Begriff Definition
Authentication-ServerDer AS stellt dem Authenticator einen Authentifizierungsdienst zur Verfügung. Dabei handelt es sich meistens um einen RADIUS-Serverdienst.
Authenticator Der Authenticator steht zwischen Supplicant und zu schützendem Netzwerk. Der Authenticator prüft die Authentizität des Supplicants und gewährt diesem bei erfolgreicher Kontrolle den Zugriff auf das Netzwerk. Als Authenticator kommen Switches oder Access Points in Betracht. Die Gültigkeit der Credentials werden meistens bei einem Authentication-Server abgefragt.
IEEE 802.1X Der IEEE-Standard beschreibt eine Methode zur Authentifizierung und Autorisierung in Netzwerken.
NPS Der Network Policy Server (NPS) oder auch Netzwerkrichlinienserver ist ein von Microsoft entwickelter RADIUS-Server. Er übernimmt die Authentifizierung und Autorisierung in 802.1X-Netzwerken.
pfSense pfSense ist eine auf FreeBSD basierende Firewall-Distribution. Das pf im Namen kommt vom Paketfilter-Tool pf.
Proxmox VE Proxmox VE ist eine Virtualisierungsplattform auf der Basis von Debian Linux. Neben Virtuellen Maschinen auf der Basis von KVM können auch Linux Container aufgesetzt werden.
RADIUS Der Remote Authentication Dial-In User Service (RADIUS) ist ein Client-Server-Protokoll zur Authentifizierung und Autorisierung z.B. in 802.1X-Netzwerken.
rsync Rsync ist gleichzeitig ein Netzwerkprotokoll und ein Programm zur Synchronisation von Daten in einem Netzwerk.
SSL/TLS Transport Layer Security (TLS) oder der Vorgänger Secure Sockets Layer (SSL) ist ein Protokoll zur verschlüsselten Übertragung von Daten in Netzwerken.
Supplicant Ein Supplicant ist ein Gerät, dass in der Lage ist, sich über 802.1X zu authentifizieren.
User-Backend Die durch den Authentifizierungs-Server zu überprüfenden Credentials können direkt auf dem AS oder in externen User-Backend, über das mit Datenbanktreibern zugegriffen werden kann. Als User-Backend kommt z.B. eine Active Directory
VLAN Ein VLAN oder Virtual Local Area Network ist ein logisches Teilnetz innerhalb eines Netzwerkes. Ein VLAN trennt physische Netzwerke auf, da Layer 2 Frames nicht in andere VLANs weitergeleitet werden.

Tabelle 46: Glossar

Weitere Materialien

Firmenstandards für die VLANs s und für das Namenskonzept der Rafisa Dietikon

Subnetz-Konzept

Alle Standorte erhalten ein /24 Netz aus dem grösseren privaten Netz 172.16/12, dh. 172.16.0.0/16
bis 172.31.0.0/16. Die VLANs werden dann in die jeweiligen /24-Subnetze unterteilt, also z.B.
172.16.1.0/24, 172.16.2.0/24 usw.

Netzadressbereich CIDR-NotationVerkürzte CIDR-
Notation
Anzahl AdressenAnzahl Netze
gemäß Netzklasse
(historisch)
172.16.0.0 bis
172.31.255.255
172.16.0.0/12 172.16/12 220 = 1.048.576 Klasse B: 16
private Netze mit
jeweils 65.536
Adressen;
172.16.0.0/16 bis
172.31.0.0/16

VLANs der Rafisa Dietikon

zh.rafisa.org - 172.16.0.0/12

VLAN Name KürzelFunktion VID IP-AdresseFW-Interface-NameDHCP-Server
VLAN Management 01
VLAN01 MGMT Management 01 172.16.1.0/24 VLAN01_MGMT
VLAN Server 10-19
VLAN10 SRVAUTH Server Authentifizierung10 172.16.10.0/24VLAN10_SRVAUTH
VLAN14 SRVEMPL Server Ausbildner 14 172.16.14.0/24VLAN14_SRVEMPL
VLAN15 SRVLEARN Server Lernende 15 172.16.15.0/24VLAN15_SRVLEARN
VLAN Clients 20-29
VLAN21 CLEPML Clients Ausbildner 21 172.16.21.0/24VLAN21_CLEMPL ✔️
VLAN22 CLLEARN Clients Lernende 22 172.16.22.0/24VLAN22_CLLEARN ✔️
VLAN23 CLGUEST Clients Guest (WLAN) 23 172.16.23.0/24VLAN23_CLGUEST ✔️
VLAN Drucker 40
VLAN40 LP Drucker 40 172.16.40.0/24
VLAN Labor 50-59
VLAN51 LAB01 Labor 01 51 172.16.51.0/24VLAN51_LAB01 ✔️
VLAN52 LAB02 Labor 02 52 172.16.52.0/24VLAN52_LAB02 ✔️
VLAN53 LAB03 Labor 03 53 172.16.53.0/24VLAN53_LAB03 ✔️
VLAN54 LAB04 Labor 04 54 172.16.54.0/24VLAN54_LAB04 ✔️
VLAN55 LAB05 Labor 05 55 172.16.55.0/24VLAN55_LAB05 ✔️

In der Tabelle oben sind alle VLAN’s aufgelistet, welche das Netzwerk-Team immer auf der FW und auf den Switches standardmässig konfiguriert. Der Interface-Name bildet sich aus dem VLAN Namen und dem Kürzel. Im VLAN01_MGMT sind die Switches oder die FW selber enthalten. Auch der unifiController und der Backup-Server sind dort inbegriffen. Wie der Name schon sagt ist im VLAN Server alle virtuellen Server enthalten. VLAN Clients ist selbsterklärend. Alle Drucker sind im VLAN40_LP vorhanden. Alle Labors sind im VLAN Labor. Es werden alle Geräte ausser welche im VLAN Clients und VLAN Labor sind, mit einer statischen IPv4 Adresse vergeben. Der Rest erhält seine Netzwerkkonfigurationen via DHCP-Server von der FW. Dieser Firmenstandard ist vom September 2020. Auf diesem baut sich meine IPA auf, selbst wenn sich die Norm sich laufend ändert.

Berechtigungsmatrix

Die Matrix wird Zeile nach Spalte gelesen (Zugriff von Zeile nach Spalte erlaubt/nicht erlaubt)

VLAN01101415212223405152535455WANVPN-EXT
01 ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️
10 ✔️ ✔️ ✔️
14 ✔️ ✔️
15 ✔️ ✔️
21 ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️
22 ✔️ ✔️ ✔️ ✔️ ✔️
23 ✔️ ✔️
40 ✔️ ✔️
51 ✔️ ✔️
52 ✔️ ✔️
53 ✔️ ✔️
54 ✔️ ✔️
55 ✔️ ✔️
WAN ✔️
VPN-EXT ✔️ ✔️

Das VLAN01_MGMT hat überall Zugriff. VLAN10_SRVAUTH darf nach draussen und zu den VPN-Server der externen Standorte. Die Ausbildner haben Zugang zu allen anderen VLANs ausser VLAN01_MGMT. Die Lernende haben Zugang nach draussen, in VLAN10_SRVAUTH, VLAN15_SRVLEARN und dem VLAN40_LP.

IP-Zuteilung der Geräte der Rafisa Standort Dietikon

Die folgende Tabelle zeigt die IP-Zuteilung der Geräte am Standort Dietikon. Sie dient als Ausgangspunkt für das Erstellen des L3-Plans.

VLAN Kürzel/HostnameIP-AdresseFunktion Ort
VLAN Management
VLAN01 MGMT 172.16.1.0/24 Management
fw-zh-ruga-01 172.16.1.1 Firewall
prox-zh-ruga-01 172.16.1.21 Proxmox VE Node
prox-zh-ruga-02 172.16.1.22 Proxmox VE Node
uni-zh-ruga-01 172.16.1.30 Unifi Controller
ap-zh-01 172.16.1.31 Unifi Accesspoint
ap-zh-02 172.16.1.32 Unifi Accesspoint
ap-zh-03 172.16.1.33 Unifi Accesspoint
ap-zh-04 172.16.1.34 Unifi Accesspoint
ap-zh-05 172.16.1.35 Unifi Accesspoint
bkp-zh-r02b-01 172.16.1.100 Backup-Server zh.rafisa.org
VLAN Authentifizierung
VLAN10 AUTH 172.16.10.0/24
dc-zh-ruga-02 172.16.10.22 DC1 zh.rafisa.org
dc-zh-ruga-04 172.16.10.24 DC2 zh.rafisa.org
VLAN Server Ausbildner
VLAN14 SRVEMPL 172.16.14.0/24
fs-zh-ruga-01 172.16.14.21 Fileserver zh.rafisa.org
VLAN Server Lernende
VLAN15 SRVLEARN 172.16.15.0/24
fs-zh-ruga-01 172.16.15.21 Fileserver zh.rafisa.org

Rafisa Namenskonzept

Benutzer

Benutzernamen setzen sich zusammen aus dem ersten Buchstaben des Vornamens plus den Nachnamen. Sollten sich bei neuen Nutzern gleichlautende Benutzernamen ergeben, wird die Anzahl Buchstaben des Vornamenkürzels um 1 erhöht. Bei identischen Vor- und Nachnamen wird das Benutzerkürzel um eine fortlaufende Nummer, beginnend bei 01 ergänzt.

Beispiele:

  • h.muster → Hans Muster
  • he.muster → Hedwig Muster
  • her.muster → Herta Muster
  • h.muster01 → Hans Muster
Geräte

Der Gerätename setzt sich zusammen aus einem Kürzel für die Funktion, dem Kürzel für den physikalischen Standort sowie einer fortlaufenden Nummer, beginnend bei 01.

Beispiele:

  • dc-zh-ruga-01
  • sw-zh-r02a-03
Kürzel für die Funktionsbezeichnungen
KürzelFunktion
bkp Backup Server
dc Domain Controller
ds Deployment Server
dw Firewall
nb Notebook
pc PC
prox Proxmox VE Server
sw Switch
Physikalische Standorte

er physikalische Standort setzt sich zusammen aus dem Kürzel für den Standort sowie einer internen Raumangabe. Bei Geräten, welche in einem Rack stehen, werden anstelle der Raumangabe das Kürzel für das Rack angegeben.

Beispiele:

  • zh-ruga
  • zh-201
Kürzel für die Standorte
KürzelStandortbezeichnung
be Bern
fr Fribourg
zh Zug
zh Zürich
Kürzel für die internen Räume
Zürich
KürzelOrt
200 Raum 200 im 2. Stock
201 Raum 201 im 2. Stock
Kürzel für Racks
Zürich
KürzelRacknummer
ruga Rack A im Untergeschoss
rugb Rack B im Untergeschoss
r02a Rack A im 2. Stock
r02b Rack B im 2. Stock
r03a Rack A im 3. Stock
r03b Rack B im 3. Stock
r03c Rack C im 3. Stock
r03d Rack D im 3. Stock
r04a Rack A im 4. Stock

AD-Struktur

Die AD-Struktur ist sehr einfach gehalten. Es gibt Container für die Benutzeraccounts, die Geräte sowie die Gruppen. Bei den Geräten werden Clients und Server unterschieden, bei den Gruppen lokale und globale Sicherheitsgruppen.

OU=OU-RAFISA,DC=rafisa,DC=org
OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=org
OU=RAFISA-Accounts,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=org
OU=RAFISA-Computers,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=org
OU=RAFISA-Clients,OU=RAFISA-Computers,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=org
OU=RAFISA-Servers,OU=RAFISA-Computers,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=org
OU=RAFISA-Groups,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=org
OU=RAFISA-GlobalSecurityGroups-GS,OU=RAFISA-Groups,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=org
OU=RAFISA-LocalSecurityGroups-LS,OU=RAFISA-Groups,OU=RAFISA,OU=OU-RAFISA,DC=rafisa,DC=org

de.bkp/intern/ipa/tp2022/ipa_tp2022.txt · Zuletzt geändert: 2022/09/27 11:05 von 127.0.0.1