====== IEEE 802.1X - Authentifizierung für LAN und WLAN - IPA Timafei ===== ====== Sicherung der Arbeitsergebnisse ====== * Ordner 01 - 10 auf OneDrive, für Ausbildner freigegeben (Printscreen der Ordnerstruktur und Freigabe) * Backups der Konfigs der Switches und der Firewall auf BackupPC * Backup der VMs auf BackupPC * Backup von /etc/network/interfaces auf prox-zh-202-01 auf BackupPC ====== Informieren ====== ===== Erfassung der zur Verfügung gestellten Hardware ===== ==== Hardware Server und PCs ==== * Mit welchen Mitteln wurde Hardware erfasst, Programme, Befehle, Internetseite des Herstellers ^ Gerät ^ Modellbezeichnung ^ CPU ^ Memory ^ HD ^ NW-Adapter ^ RAID Levels ^ | Proxmox-Server | | | | | | | | Backup-Server | | | | | | | | Arbeitsplatzrechner 1 | | | | | | | | Arbeitsplatzrechner 2 | | | | | | | ==== Hardware Switches ==== * Mit welchen Mitteln wurde Hardware erfasst, Programme, Befehle, Internetseite des Herstellers ^ Gerät ^ Modellbezeichnung ^ Übertragungsrate ^ Anzahl Ports ^ | Switch 01 | | | | | Switch 02 | | | | | Switch 03 | | | | | Switch 04 | | | | ==== Hardware Access-Point ==== * Mit welchen Mitteln wurde Hardware erfasst, Programme, Befehle, Internetseite des Herstellers ^ Gerät ^ Modellbezeichnung ^ Anzahl Ports ^ WLAN-Standards ^ Frequenzbänder ^ Verschlüsselungsmöglichkeiten ^ | Access-Point | | | | | | ==== Hardware Firewall ==== * Mit welchen Mitteln wurde Hardware erfasst, Programme, Befehle, Internetseite des Herstellers ^ Gerät ^ Modellbezeichnung ^ CPU ^ Memory ^ Festplatte ^ Netzwerk-Interfaces ^ Übertragungsrate ^ | Firewall | | | | | | | ===== Erfassung der einzusetzenden Software und Services ===== ==== Die Virtualisierungsplattform Proxmox VE ==== * Zusammenfassung((https://www.proxmox.com/de/proxmox-ve)) * Features(((https://www.proxmox.com/de/proxmox-ve/funktionen)) * KVM & Container * Webmanagement * HA-Cluster * Virtuelle Netzwerke * Storages * Backup * Firewall ==== Der Backup-Server BackuPC ==== In der Rafisa kommt die Backuplösung BackupPC((https://backuppc.github.io/backuppc/)) zum Einsatz. Dabei handelt es sich um eine freie Disk-zu-Disk Backup-Suite, die in PHP geschrieben ist. Als Übertragungsarten stehen ''smb'' für das Backup von Windows-Shares, sowie ''rsync'' für die Sicherung der Daten mit Hilfe des rync-Protokolls zur Verfügung. Zusätzlich lassen sich die Funktionalitäten mit Pre- und Post-Backupscripts erweitern. Die Hauptfeatures der Lösung sind: * 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 nur moderat beansprucht * Open-Source: BackupPC wird auf Github gehostet und unter einer GPL-Lizenz verteilt * Es wird keine clientseitige Software benötigt {{:team:egil-rueefli:backuppcserversummary.png?800|}} Im Rahmen von Vorarbeiten wurde gemeinsam mit dem Team SRB (ServiceRestoreBackup) ein Backupserver auf der Basis von BackupPC installiert. Der ''SLA #001: Backup und Restore'' v.01((https://wiki.rafisa.net/doku.php?id=sla:sla-backup-and-restore)) entnimmt man, dass folgende Backuparten zur Verfügung stehen: * Backup von SMB-Shares * File-Backup von Serversystemen * Image Backup von Proxmox-VMs * Backup von Datenbank-Systemen * Backup der Konfigurationsdateien von Switches und Firewalls (im Aufbau) In der vorliegenden Arbeit soll also mit dem Backup der Konfigurationsdateien von Switches und Firewall also ein Betrag zur Erweiterung des Backup-Angebots geleistet werden. In der Planung müssen folgende Punkte berücksichtigt werden: Festlegen von Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten ==== pfSense Firewall ==== pfSense ist eine auf dem Betriebssystem FreeBSD basierende Firewall-Distribution. pfSense lässt sich komplett über ein Webinterface verwalten. Zusätzlich ist der Zugriff über SSH oder über einen seriellen Port möglich. Die eingesetzten Kerntechnologien sind OpenSSL, PHP und Python. Über ein Paketsystem lassen sich die Funktionen der Firewall stark erweitern. Die Hauptfeatures von pfSense sind((https://www.netgate.com/solutions/pfsense-plus/features.html)): * VPN Server * High Availability * Load Balancing * Traffic Shaping * Captive Portal * UTM Device * Firewall / Router * DNS / DHCP Server * IDS / IPS * Transparent Caching Proxy * Web Content Filter In der Planung sollen Policies für die Konfiguration des Paketfilters und die Möglichkeiten zur Realisierung der VPN-Site-to-Site-Anbindung näher untersucht werden. ==== UniFi Network Application ==== * Controller entweder als Software-Lösung für Windows/Linux/Mac OXS oder als HW-Controller (Cloudkey) * Java-Paket * Zentrale Verwaltung aller Unify-Geräte über ein Web-Interface * Passiver Controller: Die Access-Points werden durch Controller konfiguriert, danach laufen sie autonom, Controller kann auch abgeschaltet werden, ausser man nutzt Guest-Portal-Funktion((https://wlanport.de/information/news-co/ubiquiti-unifi-controller-vor-und-nachteile-eines-passiven-controllers)) * Vorteile passiver Controller -> wenn Controller nicht läuft, laufen AP's weiter, kein Single Point of Failure * Nachteile passiver Controller -> Informationen über die Funkeigenschaften der Accesspoints und der verbundenen Clients nicht zur Steuerung genutzt. Z.B. sucht AP beim Start einen geeigneten Funkkanal und bleibt auf diesem -> Keine Optimierung durch Controller möglich * Version des Intstallierten Controllers erwähnen * Hauptfeatures des Controllers((https://www.bossinfo.ch/wp-content/uploads/UniFi_AP_DS.pdf)): * 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 ==== Take base requirements -> enstscheiden ==== Debian Linux 11 ==== describe debian, base requirements -> entscheiden ==== Windows 10 Enterprise ==== describe ===== Der Standard IEEE 802.1X ===== den prozess beschreiben ===== Firmenstandards für die VLANs der Rafisa Dietikon ===== * reinkopieren ===== L3-Plan IST-Zustand des Projektumfelds ===== Als Gateway haben die Geräte 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.53.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 L3-Diagramm festgehaltenen System verfügen über statische IP-Adressen. ---- {{drawio>team:sabareeshan-nadeswaran:rafisa_zh_l3netzplan_01}} ---- ^ FQDN ^ IP-Adresse ^ OS ^ Services ^ Service-Team ^ Owner ^ ^ Server ^^^^^^ | prox-zh-ruga-01.zh.rafisa.org | 172.16.1.21/24 | Proxmox VE | Virtualisierungsplattform | Team Server Services | RS | | prox-zh-ruga-02.zh.rafisa.org | 172.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 2019 | DC/AD, DNS | Team Server Services | RS | | dc-zh-ruga-04.zh.rafisa.org | 172.16.10.24/24 | Windows Server 2019 | DC/AD, DNS | Team Server Services | RS | | fs-zh-ruga-01.zh.rafisa.org | 172.16.14.21/24 | Windows Server 2019 | Fileserver Employees | Team Server Services | RS | | fs-zh-ruga-01.zh.rafisa.org | 172.16.15.21/24 | Windows Server 2019 | Fileserver 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 Services | ER | | uni-zh-ruga-01.zh.rafisa.org | 172.16.1.30/24 | Ubuntu 20.04 LTS | Ubiquiti WLAN Controller | Team Network Services | ER | | ap-zh-01-05.zh.rafisa.org | 172.16.1.31-35/24 | AirOS | AP, WPA-Enterprise Radius Auth | Team Network Services | ER | ^ Firewall ^^^^^^ | fw-zh-ruga-01.zh.rafisa.org | VLAN 172.16.1.1/24\\ WAN 46.140.45.118 | pfSense (BSD) | VLAN-Routing, Filtering, VPN Concentrator, DHCP | Team Network Services | ER | ====== Planen ====== ===== Planen der VLAN ===== Auf Firmenstandards bezugnehmen -> Maximalvariante, Minimalvariante, Zwischenlösungen -> Varianten erarbeiten, z.B. wie bei Saba: ^ VLANs Minimal für Zielerreichung ^ Standard-VLANs Rafisa Dietikon ^ | Management | VLAN01_MGMT (172.16.1.0/24)| | Employees | VLAN21_CLEMPL (172.16.21.0/24) | | Learners | VLAN22_CLLEARN (172.16.22.0/24) | | WIFI | | | Printers | VLAN40_LP (172.16.40.0/24) | | | VLAN10_SRVAUTH (172.16.10.0/24) | | | VLAN14_SRVEMPL (172.16.14.0/24) | | | VLAN15_SRVLEARN (172.16.15.0/24) | | | VLAN23_CLGUEST (172.16.23.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) | ===== Planen der Netzwerk-Dienste ===== * DHCP, DNS, AD * Supplicant, Authenticator, Authentication-Server, Benutzer-Backend IPA Lea Kapitel 8.1.1 ===== Planen der Proxmox-Umgebung ===== * Partitionierung, Storage * Security: Raid, Dual-Netzteil, Monitoring, Hardening des OS und der Dienste, Proxmox-Cluster -> HA-Failover usw. ===== Planen der Server-VM ===== * Hardware Ressourcen der VMs IPA Lea 8.1.3 ===== Planen von 802.1x ===== * LAN / WLAN, Sicherheitsgruppen, Gast-Wlan ^ Sicherheitsgruppe ^ Ziel-VLAN ^ LAN ^ ^ WLAN ^ ^ | Authentifizierung und Autorisierung | | 802.1X | Access-Port | 802.1X | WPA2-Enterprise | | Ausbildner | VLAN21_EMPL | vorgegeben | - | vorgegeben | - | | Lernende | VLAN22_LEARN | vorgegeben | - | vorgegeben | - | | Netadmins | VLAN01_MGMT | möglich | möglich | möglich | möglich | | Gäste | VLAN23_GUEST | möglich | möglich | möglich | möglich | ===== Planen von Backup und Restore ===== * rsync vs. vzdump (IPA Lea Kapitel 8.1.7) * FTP vs. SSH (IPA Saba Kapitel 8.5) ==== Backupvarianten ==== Die Aufgabe besteht darin, die Configs via BackupPC im PULL-Verfahren automatisch zu sichern. === Switches === * Im Knowledge-Base Artikel von Zyxel werden 2 Möglichkeiten erwähnt((https://kb.zyxel.com/KB/searchArticle!gwsViewDetail.action?articleOid=015782&lang=EN#)): 1. die Konfig Via commandline vom Switch aus auf einen tftp Server kopieren -> Problem: geht nur manuell 2. Via snmp auf tftp-Server Problem: Geht nur bei grossen Switches von Zyxel, in der Rafisa sind auch kleine 1920er im Einsatz * In weiterem Artikel((https://community.zyxel.com/en/discussion/3496/gs1900-and-gs1920-config-backup-to-tftp-with-snmp-commands)) wird die Möglichkeit erwähnt, per SSH das Konfig-File zu sichern -> via BackupPC mit einem Prebackup-Script machbar * Es gibt auch die Möglichkeit, das Konfig-File per FTP-Zugriff zu sichern -> via BackupPC mit einem Prebackup-Script machbar. * Mit BackupPC sind also die Möglichkeiten FTP vs. SSH-Backups ^ Backupart ^ Vorgehen ^ Vorteile ^ Nachteile ^ | FTP-Backup | Prebackup-Script: 1. FTP-Login Switch 2. get config (Konfig-File wird in lokales Verzeichnis auf BackupPC gespeichert)\\ BackupPC-Rsync: Rsync dieses Verzeichnisses durch BackupPC | FTP ist stabil und erprobt, keine weiteren Kommandos benötigt | unverschlüsselte Übertragung | | SSH-Backup | Prebackup-Script: 1. SSH-Login Switch 2. show running-config -> Umleitung in ein lokales File auf BackupPC\\ BackupPC-Rsync: Rsync dieses Verzeichnisses durch BackupPC | Verschlüsselte Übertragung möglich | zusätzlicher Befehl auf Switch (show running-config) und Umleitung in ein lokales File -> kompliziert und umständlich, zusätzlicher Output muss aus Konfig-File entfernt werden | === Firewall === * manueller Backup aus dem GUI möglich -> Problem: nicht automatisch * Konfig File ist auf pfSense in der Datei /conf/config.xml gespeichert * Zugriff nur über SSH möglich -> scp (secure copy kann verwendet werden) ^ Backupart ^ Vorgehen ^ Vorteile ^ Nachteile ^ | SSH-Copy | Prebackup-Script: Mit dem Befehl ''scp'' das Konfig-File in ein lokales Verzeichnis auf BackupPC kopieren\\ BackupPC-Rsync: Rsync dieses Verzeichnisses durch BackupPC | Backup ist verschlüsselt | keine | ====== Entscheiden ====== ===== Netzwerkkonzept ===== ==== VLAN ==== ==== Subnetze ==== ==== Dienste (AD, DNS, DHCP, Supplicants, Authenticator, Authentication-Server, Benuter-Backend) ==== ==== Netzplan der Testumgebung ==== ===== Konzept die Virtualisierungsumgebung ===== ==== Sicherheitskonzept (Raid, Stromversorung, Monitoring, Backups usw) ==== ==== Basiseinrichtung (Partitionierung, Storages (local, local-lvm), Verschlüsselung Webgui) ==== ===== Konzept für die Server-VMs ===== ==== VM1 (Funktion, Ressourcen usw.) ==== ==== VM2 (Funktion, Ressourcen usw.) ==== ===== Konzept für 802.1x ===== ===== Backupkonzept ===== ===== Backup und Restore ===== ==== Backupvariante für Switches und Firewall ==== Für die Switches wird das FTP-Backup gewählt. Das Backup-File kann mit einem bewährten, stabilen Verfahren gesichert werden. Es werden zudem keine zusätzlichen Switch-Befehle oder aufwändige Umleitungen der Ausgabe auf dem Switch in ein lokales File benötigt. Der Nachteil des unverschlüsselten Transfers der Dateien ist nicht schlimm, da sich die FTP-Zugänge aller Switches im gut gesicherten Management-VLAN befinden. Das Copy via FTP wird mit Hilfe eines Prebackup-Scripts realisiert, das das in ein lokales Verzeichnis auf dem BackupPC kopiert. Danach wird es mit dem BackupPC-Rsync in ein BackupPC-Archiv abgelegt. Für die Firewall wird mit einem Prebackup-Script das Backup-File über ''scp'' in eine lokales Verzeichnis kopiert und danach ebenfalls mit BackupPC-Rsync in ein BackupPC-Archiv verschoben. ==== Rahmenbedingungen Backup und Restore ==== ^ Rahmenbedingung ^ Backup IPA ^ Vorschlag produktive Umgebung ^ | Datenmenge | sehr gering, ca. 1MB (3x Textfile für Switches, 1x Textfile für FW) || | Transferzeiten | sehr klein, bei ca. 35MB/sec (Auskunft Team Backup und Restore) || | Aufbewahrungsfrist | bis Ende IPA | 90 Tage (s. SLA Backup und Restore) | | Sicherungsperiodizitäten | jede Nacht zwischen 09:30 und 07:00 (s. SLA Backup und Restore), jede Woche ein Full-Backup, während der Woche inkrimentelle Backups || | Applikatorische Vorgaben | BackupPC mit Pre- und Postbackupscripts || ===== Testkonzept ===== ===== Arbeitspakete ===== ===== Meilensteine ===== ====== Realisieren ====== ===== Backup und Restore ===== ==== Backup der VM ===== Für das Backup der VM wird mit Hilfe eines Prebackup-Scripts ein Dump erstellt und dieser Dump danach mit der BackupPC-Methode rsync auf den Backup-Server überspielt. Anschliessend wird der Dump auf dem Proxmox-Server über eine Postbackup-Script wieder gelöscht. Damit sich die Scripts von BackupPC aus einloggen können und die benötigten Rechte erhalten, wird auf Proxmox ein Backup-User (rafisa-backup) angelegt. Dieser wird mit dem Recht ausgestattet, die jeweiligen Befehle auszuführen. Damit vom Backup-Server aus ein Login ohne Passwort erfolgen kann, muss der öffentliche Schlüssel des BackupPC-System-Users (backuppc) auf dem Proxmox-Server hinterlegt werden. - Anlegen des Benutzers rafisa-backup auf Proxmox-Server - Hinterlegen des öffentlichen Schlüssels des BackupPC-System-Users - Konfiguration von ''sudo'' -> Ausführen der Backup-Befehle als rafisa-backup Auf dem Proxmox-Server wird zunächst der User rafisa-backup erstellt mit dem Kommando ''adduser rafisa-backup''. Danach wird getestet, ob sich der User rafisa-backup vom Backup-Server aus auf dem Proxmox-Server einloggen kann. Auf Proxmox wird unter ''/home/rafisa-backup' das Verzeichnis ''.ssh'' angelegt. Auf BackupPC wechselt man mit ''su - backuppc'' ins Home-Verzeichnis des BackupPC-System-Users. Danach wird der öffentliche Schlüssel mit dem Befehl ''ssh-copy-id rafisa-backup@prox-zh-204-01.rafisa.ipa'' von BackupPC auf den Proxmox-Server übertragen. Der Key wird auf dem Proxmox-Server ins File ''/home/rafisa-backup/authorized-keys'' geschieben:\\ {{:team:egil-rueefli:backup_01.png?600|}}\\ Danach wird das Passwordless-Login getestet (z.B. im Testing).\\ Das sudo-Utility ist unter Proxmox noch nicht installiert. Mit dem Befehl ''apt install sudo'' wird das nachgeholt. Im Konfigurationsfile ''/etc/sudoers'' werden unter dem Eintrag für ''root'' folgende zwei Einträge angelegt:\\ {{:team:egil-rueefli:backup_02.png?600|}}\\ Damit erhält der Benutzer ''rafisa-backup'' das Recht, die Befehle ''rsync'' und ''vzdump'' ohne Eingabe eines Passwortes als root-User auszuführen. ====== Kontrollieren ====== ====== Auswerten ====== ====== Glossar ====== ^ Begriff ^ Erklärung ^ | KVM | | | Linux Container | | | Debian Linux | | | Proxmox VE | | | Datendeduplikation | | | LVM | | | rsync | | | VPN-Server | | | Captive Portal | | | UTM | | | Transparent Proxy | | | IDS | | | VLAN | Unterscheidung Port basiert vs. Tagged((https://www.thomas-krenn.com/de/wiki/VLAN_Grundlagen)) | | LACP | |