Enterprise Backup mit BackupPC

IPA 2023

31.03.23 - 19.04.2023

Kandidat: Yannis Nay

Inhalt

Teil 1 - Umfeld und Ablauf

1 Projektorganisation und Aufgabenstellung

1.1 Personen und Adressen

1.2 Aufgabestellung

Enterprise Backup mit BackupPC

Ausgangslage

In der Rafisa Informatik GmbH werden zurzeit 86 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.

Die IT-Infrastruktur der Rafisa wird zusammen mit den Lernenden stetig weiterentwickelt und den neuen technologischen und Sicherheits-Anforderungen angepasst. Als Backup-Lösung wurden bisher Windows-Server-Backup und verschiedene bash-basierte Skripts eingesetzt. Mit wachsender Heterogenität der IT-Infrastruktur entsteht in der Rafisa der Bedarf nach einer komplexeren Backup-Lösung. In der vorliegenden IPA sollen die Grundlagen für die Einführung der Open Source Backup-Lösung BackupPC erarbeitet werden.

Detaillierte Aufgabenstellung

1.2.1 Ziel des zu realisierenden Systems

Das Ziel des Projektes besteht im Aufbau eines Backup-Systems in einer virtuellen Testumgebung auf der Basis der Backup-Suite „BackupPC“. BackupPC stellt Backuparten über die Protokolle rsync, rsyncd, smb, ftp, tar und archive zur Verfügung. Zudem lassen sich vor und nach den Backups Pre- und Post-Backupscripts ausführen. Das System soll folgende Backup-Anforderungen abdecken:

* Backup der Active Directory auf einem Domain Controller

* Backup des Home-Verzeichnisses auf einem Windows-Fileserver

* Backup eines Linux-Datenbankservers mit MariaDB (MySQL)

* Backup des Konfigurations-Verzeichnisses des Datenbank-Servers (/etc)

* Backup eines Proxmox-VM-Images

* Backup der Switch-Konfiguration

* Backup der Firewall-Konfiguration

Vom Einrichten des Backup-Jobs bis zum Ende der 10 tägigen IPA gelten eine RPO sowie eine RTO von 24 Stunden. Zudem ist ein Script zu erstellen, das den Admin des Systems nach dem Push-Prinzip über die Resultate der Backup-Versuche informiert.

1.2.2 Anforderungen

1.2.2.1. Anforderungen an die Testumgebung

Netzwerk

In einer zur Verfügung gestellten GNS3-Umgebung soll ein Test-Netzwerk 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 Firmenstandards eingerichtet

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

* Das Testnetzwerk ist in einem Netzwerkdiagramm dokumentiert

* Die Schnittstellen der GNS3-Umgebung zur Systemumgebung sind bekannt und dokumentiert

* Der Zugriff auf die GNS3-Umgebung ist möglichst effizient organisiert (Copy-Paste zwischen den Systemen möglich, optimaler Einsatz der virtuellen Konsolen)

Hosts

Für alle einzurichtenden Hosts gelten folgende Anforderungen

* Die eingesetzten virtuellen Ressourcen (HD, CPU, RAM) sind als Gegenstand der Planung zu begründen

* Die IP-Adressierung der Systeme erfolgt gemäss Firmenstandards

* 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 abgesichert

Windows Domain Controller

Es ist eine Basisinstallation des Windows 2019 Servers durchzuführen. Auf dem Server ist ein Active-Directory-Service einzurichten und der Server zum Domain Controller hochzustufen. Die AD-Struktur soll sich an den Firmenstandards orientieren. Es ist ein Testuser anzulegen, das Heimverzeichnis ist gemäss Firmenstandards einzurichten, freizugeben und mit Testdaten zu versehen.

Proxmox VE-Plattform

Es soll die aktuelle stabile Proxmox-VE Plattform eingerichtet werden. Als VM für das Testing des Image-Backups ist ein Linux zu installieren. Die Auswahl der Distribution ist als Gegenstand der Planung zu begründen.

Linux Datenbankserver

Als Datenbankserver soll ein Debian Linux in der Version 11 mit der aktuellen Version von MariaDB installiert werden. Es sind mehrere Testdatenbanken anzulegen.

Cisco Switch

Für den Cisco Switch ist das bestehende Cisco-Switch-Template zu verwenden. Alle geplanten VLAN sind eingerichtet. Der Switch verfügt über einen administrativen Zugang im entsprechenden VLAN

pfSense Firewall

Für die pfSense Firewall ist das bestehende pfSense-Template zu verwenden. Alle geplanten VLAN sind eingerichtet. Die FW verfügt über einen administrativen Zugang im entsprechenden VLAN. Alle FW-Rules sind gemäss Firmenstandard eingerichtet.

1.2.2.2 Anforderungen an das Backup-System

Für das Backup-System soll BackupPC in der aktuell für Debian 11 paketierten Version installiert werden. Das Backup-System soll folgenden Anforderungen genügen:

* Verwendete virtuelle Ressourcen (HD, CPU, RAM) sind als Gegenstand der Planung zu begründen

* Alle administrativen Zugänge zum Server sind bestmöglich gesichert

* Die benötigten Zugänge zu den Client-Systemen und -Daten sind bestmöglich gesichert

* Die Backupdaten sind bestmöglich gesichert

* Für jedes zu sichernde System ist in der Planung eine Strategie festzulegen, die von der Wiederherstellung einzelner Dateien bis zum Bare-Metal Restore reicht

* Bei den Backups ist sicherzustellen, dass die Integrität der Backup-Daten gewährleistet ist (Backup von Live-Systemen!)

* Installationen und Einrichtungen auf den Clientsystemen sind minimal zu halten und zu begründen

* Der Backup-Admin soll über den Verlauf jedes Backups informiert werden

1.2.3 Verlangte Dokumentationen

* Inventar der unter Mittel und Methoden aufgeführten Hardware

* Kurzbeschreibungen der unter Mittel und Methoden aufgeführten Software und Services

* Beschreibung der Backup-Suite BackupPC mit ihren Hauptfeatures

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

* Netzwerkdiagramm der Testumgebung

1.2.4 Testing

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

1.3 Mittel und Methoden

Hardware

* Dedizierter HP ProLiant Server

* Windows 10 Arbeitsplatzrechner für das Testing

Software und Services

* Proxmox VE-Plattform

* GNS3-VM

* GNS3-Templates: Windows 2019 Server, Linux Debian 11, Cisco Switch, pfSense-Firewall

* Backup-Lösung BackupPC

* Labor-Netzwerk: VLAN56_LAB06, Gateway: 172.16.56.1/24, DHCP aktiviert

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

1.4 Durchführungsblock

Startblock 7, KW13: 27.03.2023 – 31.03.2023
PA-Durchführung: 27.03.2023 – 28.04.2023
Einreichung bis: 24.02.2023

1.5 Vorkenntnisse

* Network-Services: Switches, Firewalls, VLAN, VPN

* Linux Debian/Ubuntu

* Windows Server 2019

* BackupPC

* GNS3

1.6 Vorarbeiten

Installation GNS3 Web-Launcher

1.7 Neue Lerninhalte

* Backupscripts erstellen

* Sichern von administrativen Zugängen (SSH, HTTPS)

1.8 Arbeiten in den letzten 6 Monaten

* Verantwortlicher Network-Services (Firewall, Switches, VLAN, VPN)

* Einarbeitung Backup-Systeme und BackupPC

* Netzwerksimulationen mit GNS3

2 Projektaufbauorganisation

Die Prüfungskomission 19 bildet zusammen mit dem Chefexperten den Auftraggeber. Im Lenkungsauschuss sind der Hauptexperte, der Nebenexperte, der Validexperte sowie der Fachvorgesetzte. Der Kandidat übernimmt die Projektleitung.

2.1 Personen

Fachvorgesetzter: Egil Rüefli
Lernender: Yannis Nay

2.2 Rollen

Projektleiter: Yannis Nay
Auftraggeber: Prüfungskommission 19, Chefexperte
Lenkungsausschuss: Hauptexperte, Nebenexperte, Validexperte, Fachvorgesetzer

2.3 Aufgaben

Der Projektleiter ist für die komplette Realisierung und Dokumentation der IPA zuständig.
Der Auftraggeber gibt den Auftrag für die Durchführung des Projekts. Der Lenkungssauschuss ist für die Formulierung des Projektauftrags, Ressourcenzuteilung und die Überwachung des Projektes zuständig.

2.4 Verantwortung

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

2.5 Projektorganigramm

2.6 Projektmethode IPERKA

Für die IPA wird die Projektmethode IPERKA verwendet. IPERKA ist eine Methode, die das systematische Herangehen an ein Projekt fördert. Sie besteht aus sechs Phasen, die nacheinander durchgeführt werden sollen. Der erste Schritt ist Informieren. Es geht dort darum Informationen zu sammeln und diese auszuwerten. Danach geht es zum Planen, wo Lösungsvarianten erarbeitet werden. Nach der Planung geht es zur Entscheidung. Dort setzt man sich mit den Lösungsvarianten auseinander und wählt die beste Option. Dann kommt man zum Realisieren, wo man sich strikt an die Planung halten soll. Sobald das Projekt realisiert ist, kommt man zur Kontrolle. Bei der Kontrolle setzt man sich mit einem erstellten Testkonzept auseinander und führt die Tests durch. Zum Schluss kommt man noch zum Auswerten, wo man das ganze Projekt beurteilt und Verbesserungsmöglichkeiten sucht.

2.7 Organisation der Arbeitsergebnisse

2.7.1 Ordnerstruktur

Es wurde auf OneDrive eine Ordnerstruktur von 10 Tagen erstellt, wo die täglichen Dokumentationen und der Zeitplan abgespeichert werden. Auf diesen OneDrive Ordner haben nur ich und mein Ausbildner Zugriff.

2.7.2 Sicherung der praktischen Arbeitsergebnisse

Zur Sicherung der praktischen Arbeitsergebnisse wird täglich am Ende des Tages ein Backup der Proxmox-VM gemacht. Da das Projekt auf einer Proxmox-Umgebung läuft, benutzt man das integrierte Backup-Feature des Proxmox. Die GNS3-VM wird auf eine externe Festplatte abgespeichert, die mein Vorgesetzter jeden Tag als Absicherung mit nach Hause nehmen wird.

2.7.3 Restore der praktischen Arbeitsergebnisse

Das Restore von den Backup-Images zurück auf meine Testumgebung hat fehlerlos funktioniert.

2.8 Firmenstandards für das Netzwerk der Rafisa Informatik GmbH

Für meine Arbeit wird Bezug genommen auf die Firmenstandards. Diese wurden vorgängig abgegeben. Das Dokument heisst: «Firmenstandards für das Netzwerk der Rafisa Informatik GmbH» [1]. Die Firmenstandards betreffen folgende Bereiche:

• Subnetz-Konzept
• VLANs der Rafisa Dietikon
• Berechtigungsmatrix
• IP-Zuteilung der Geräte der Rafisa Dietikon
• Rafisa Namenskonzept
• 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 Dokumentenpool von PKorg zu finden.

3 Zeitplan

4 Arbeitsprotokoll

Teil 2 – Projekt

5 Kurzfassung IPA-Bericht

Als Backup-Lösung in der Rafisa wurden bisher Windows-Server-Backup und verschiedene bash-basierte Skripts eingesetzt. Mit wachsender Heterogenität der IT-Infrastruktur entstand der Bedarf nach einer komplexeren Backup-Lösung. In der vorliegenden IPA wurden die Grundlagen für die Einführung der Open Source Backup-Lösung BackupPC erarbeitet.

Die wichtigsten Backup-Arten wurden mit BackupPC realisiert. Ein Netzwerk gemäss den Firmenstandards wurde in einer GNS3-Umgebung aufgebaut. Auf diesem Netzwerk wurden die wesentlichsten Systeme aufgesetzt. Darunter eine Firewall, ein Layer3-Switch, ein Domain-Controller, ein Datenbank-Server und ein Proxmox-Server mit virtuellen Maschinen. Für die Ziel-Systeme wurden optimierte und sichere Backup-Jobs erarbeitet. Für die Firewall wurde mit Rsync die Config gesichert. Für den Switch wurde ein Skript erstellt, das mit SCP die Config auf den Backup-Server lädt und dieser dann über Rsync die Daten absichert. Für den Datenbank-Server wurde ein Skript kreiert, das alle Datenbanken in ein skalierbares Format abspeichert und dann per Rsync transferiert. Auf dem gleichen Server wird das «/etc» Verzeichnis mit Rsync gespeichert. Auf dem Proxmox-Server wurde mit einem Skript ein Dump-Befehl der VM ausgeführt und dieser Dump wird über Rsync gesichert. Der Domain-Controller wurde mit SMB gesichert. Ein Pre-Dump Skript führt auf dem DC ein System-State-Backup aus, das dann auf den zu speichernden Share transferiert wird. Zudem wurde mit Hilfe eines Bash-Scripts ein Messaging-System eingerichtet, über das der Admin nach Durchführung der Jobs informiert wird.

Das System wurde vollumfänglich getestet. Durch das Testing der Backup-Jobs wurde sichergestellt, dass die Realisierung robust ist. Jeder Backup-Job sowie dessen Restore hat funktioniert. Es gibt Verbesserungsmöglichkeiten für den Domain-Controller-Job und den Proxmox-Server-Job.

6 Informieren

In der vorliegenden IPA sollen die Grundlagen für die Einführung der Open Source Backup-Lösung BackupPC erarbeitet werden. Im Teil Informieren wird der IST-Zustand der Arbeitsumgebung erhoben.

6.1 Erfassung der zur Verfügung gestellten Hardware

Um das Backup-Projekt realisieren zu können, wurde ein VLAN-Netz zu Verfügung gestellt. Die Arbeit wird auf einem Proxomx-Server realisiert. Im Folgenden wird die zu Verfügung gestellte Hardware dokumentiert.

Die Spezifikationen des Proxomx-Servers und meines Windows 10 Computers sind wie folgt:

6.2 Erfassung der einzusetzenden Software und Services

6.2.1 Proxmox VE

Proxmox Virtual Environment (Proxmox VE oder PVE) ist eine Open-Source-Software, die als Server für das Virtualisierungsmanagement fungiert. Als Hypervisor ist es in der Lage, Betriebssysteme wie Linux und Windows auf x64-Hardware auszuführen. Diese Debian-basierte Linux-Distribution enthält einen modifizierten Linux-Kernel und ermöglicht das Deployment und Management von virtuellen Maschinen (KVM) und Containern (LXC) durch eine Web-Konsole und Befehlszeilen-Tools. Proxmox VE bietet auch eine webbasierte Management-Oberfläche und ermöglicht die Einrichtung von HA-Lösungen (High Availability) durch die Verbindung mehrerer Proxmox Nodes.

6.2.2 GNS3

GNS3 ist eine Netzwerk-Simulationssoftware, die es Benutzern ermöglicht, komplexe Netzwerk-Topologien mithilfe von virtuellen Maschinen und realen Netzwerkgeräten zu erstellen und zu simulieren. Sie wird häufig von Netzwerktechnikern, IT-Profis und Studenten genutzt, um Netzwerke zu entwerfen, zu testen und zu beheben. Mit GNS3 können Benutzer Netzwerk-Topologien erstellen, die aus virtuellen Routern, Switches und anderen Netzwerkgeräten bestehen, und dann verschiedene Konfigurationen und Szenarien testen und experimentieren, um ein besseres Verständnis dafür zu erlangen, wie Netzwerke funktionieren.
Diese Netzwerkgeräte kann man vielseitig anpassen. Wie zum Beispiel die Festplatten Anzahl und Grösse, der Arbeitsspeicher, die Anzahl an CPU-Kernel, die Anzahl an Netzwerkkarten und Disk-Images. GNS3 kann lokal installiert werden.

6.2.3 GNS3-Server – GNS3-Client

GNS3 besteht aus zwei Komponenten: dem GNS3-Client und dem GNS3-Server.

Der GNS3-Client wird auch als GNS3-all-in-one bezeichnet. Er bietet eine GUI-basierte Oberfläche zum Erstellen, Konfigurieren, Testen und Beheben von virtuellen Netzwerken. Er muss auf dem lokalen System installiert werden.

Der GNS3-Server wird auch als GNS3-VM bezeichnet. Er speichert und betreibt alle virtuellen Geräte. Sie können den GNS3-Server direkt auf dem lokalen System als Anwendung installieren oder eine virtuelle Maschine erstellen und den GNS3-Server darauf installieren.

Wenn Sie den GNS3-Server auf einer virtuellen Maschine installieren, haben Sie zwei Möglichkeiten, die virtuelle Maschine zu speichern. Sie können die virtuelle Maschine auf einem lokalen oder remote System speichern.

6.2.3.1 Templates

GNS3-Templates sind vorkonfigurierte VMs. Sie sind dazu gedacht, Zeit zu sparen und den Prozess der Erstellung komplexer Netzwerk-Topologien zu vereinfachen. Die Templates enthalten vorgefertigte Netzwerkgeräte und Konfigurationen wie Router, Switches, Firewalls und Server, die schnell und einfach an die spezifischen Bedürfnisse eines Netzwerks angepasst werden können. GNS3-Templates sind für eine Vielzahl von Netzwerkanbietern wie Cisco, Juniper, Fortinet und anderen verfügbar. Benutzer können auch ihre eigenen benutzerdefinierten Templates mithilfe des GNS3 Template Editors erstellen, mit dem sie die in das Template aufzunehmenden Geräte und Konfigurationen definieren können.

Für die Arbeit werden Debian 11 Templates sowie Windows Server 2019 Templates, Cisco Switch Templates und Pfsense-Firewall Templates benutzt.

Abbildung 1: General Settings gns3 vm

Die wichtigsten Konfigurationen (CPU und RAM) macht man in den General Settings. Unter dem Tab HDD kann man weitere Festplatten einbinden. Im Tab CD/DVD kann man ein ISO-Image einbinden und im Tab Network kann man weitere Netzwerkkarten erstellen.

6.2.4 GNS3-Server im Betrieb

Im Betrieb steht eine VM mit einer GNS3-Instanz zur Verfügung, die über ein Webinterface erreicht werden kann.
Auf der untenstehenden Abbildung kann man erkennen das auf der GNS3-VM für die einzurichtenden VMs ein Speicherplatz von 480 GB vorhanden ist.

6.2.5 BackupPC

BackupPC ist eine Backup-Software, die es ermöglicht, jegliche Operating-Systeme oder Peripheriegeräte auf Festplatten oder Tapes zu sichern. Zur Übertragung der Daten können sowohl das SMB-Protokoll für Windows-Freigaben als auch das Rsync-Protokoll verwendet werden. Durch die Verwendung von Pre- und Post-Backup-Skripten können zusätzliche Funktionen integriert werden. Zu den Hauptfunktionen zählen ein webbasiertes Administrations-Interface zum Konfigurieren von Backups, Analysieren von Logfiles, manuellem Starten und Stoppen von Backups sowie zum Durchsuchen und Wiederherstellen von Backup-Daten.
Ein weiteres Merkmal ist die Datendeduplizierung, bei der identische Dateien von verschiedenen Backups eines Clients oder von unterschiedlichen Clients nur einmal gespeichert werden, was Speicherplatz und Disk I/O einspart. Die Datenmenge wird weiter durch Kompression reduziert. Durch die Deduplizierung werden nur neue Dateien komprimiert, was die CPU-Belastung reduziert.
BackupPC ist eine Open-Source-Software, die auf Github gehostet und unter einer GPL-Lizenz verteilt wird. Es ist keine Client-Software erforderlich.

Abbildung 2: edit hosts

Das Erste, was man auf dem BackupPC GUI machen soll, ist einen Host zu erstellen. Entweder schreibt man die IP des Ziel-Systems rein oder man erstellt in der Shell eine Namensauflösung zur IP-Adresse. Der Vorteil des Erstellens eines Hostnamen unter «/etc/hosts» ist das man mehrere Hostnamen für das gleiche System benutzen kann. Dies ermöglicht es, dass man mehr als ein Backup-Job pro Ziel-System einrichten kann. Des Weiteren sind Hostname übersichtlicher als IP-Adressen.

}

Abbildung 3: select hosts

Danach wählt man einen Host aus. Hier sieht man nun die Standard-Page wo man Backup-Aktionen ausführen kann. Man sieht auch den Status der letzen Backups.

Abbildung 4: select xfer method

Unter Edit Config kann man die Art des Backups sowie die Schedule konfigurieren.

6.2.5.1 Backup-Protokolle

Diese Protokolle bietet BackupPC an.

SMB- SMB (Server Message Block) ist ein Protokoll zur Netzwerkfreigabe von Dateien, Druckern und anderen Ressourcen in einem Netzwerk. Es wird hauptsächlich in Windows-Umgebungen eingesetzt und ermöglicht es, Dateien und Ordner zwischen Windows-Rechnern und anderen Geräten auszutauschen.

Rsync- Synchronisation und Backup-Software. Es nutzt ein eigenes Protokoll, um Dateien zwischen verschiedenen Systemen abzugleichen und zu übertragen. Dabei werden nur die veränderten Teile der Dateien übertragen, was die Übertragung schneller macht, und Bandbreite spart. Rsync kann auch mit SSH verschlüsselt werden, um die Sicherheit der Übertragung zu gewährleisten.

Rsyncd- Rsyncd ist ein Daemon, der das Rsync-Protokoll nutzt, um Dateien zwischen verschiedenen Systemen zu synchronisieren. Es wird oft verwendet, um Dateien auf einem entfernten Server zu sichern oder um Dateien zwischen verschiedenen Servern zu synchronisieren.

Tar- Tar (Tape Archiver) ist ein Dateiarchivierungsprogramm, das hauptsächlich in Unix- und Linux-Umgebungen verwendet wird. Es ermöglicht das Zusammenfassen von mehreren Dateien und Verzeichnissen in einem einzelnen Archiv. Dabei werden auch Metadaten wie Zugriffsrechte und Zeitstempel gespeichert. Tar kann auch mit Kompressionsprogrammen wie gzip oder bzip2 verwendet werden, um den Platzbedarf der Archive zu reduzieren.

6.2.5.2 Pre- und Post-Backup-Skripts

Mit diesen Funktionen kann man vor und nach den Backups oder Restores Bash-Skripts ausführen. Dieses Vorgehen bietet sich an, wenn man beispielsweise vor dem Backup Datenbankdumps auf den Zielsystemen ausführen will.

6.3 Layer3-Plan der Einbettung der Testumgebung

Dieser Plan zeigt die Umgebung des Proxmox-Servers an auf dem meine Testumgebung eingerichtet ist. Wie man sehen kann, ist der Proxmox im VLAN-Netz 56 was für Labor-Umgebungen bestimmt ist. Dies bedeutet das mein Projekt vom Firmen-Netz isoliert ist. Wenn also ein technisches Problem vorliegt, lässt sich der Schaden somit minimieren.

7 Planen

7.1 Planen der VLAN

Für das Erstellen der Testumgebung gemäss den Firmenstandards, werden nur drei VLANs benötigt. In das MGMT VLAN kommt der Backup-Server, die Switches, die Firewall und der Proxmox-Server.
In das VLAN SRVAUTH kommt der Domain-Controller (DC) und ins VLAN SRVEMPL kommt der Datenbank-Server.

7.2 Planen der VMs

In der Testumgebung werden diverse VMs erstellt dabei ist es wichtig zu wissen wie viele Ressourcen man den einzelnen Plattformen zuteilen will. Dabei werden die empfohlenen Anforderungen jeweiliger Systeme berücksichtigt. Die IP-Adressen und Namen werden an die Firmen-Standards angepasst.

Die Anforderungen beziehen sich auf das Operating System und nicht auf die Funktion der VM. [1] [2] [3]

7.3 Planen der Backup-Jobs

7.3.1 Backup der Active Directory auf einem Domain Controller

Die Information zu den ungefähren Speicheranforderungen stammt aus den Vorarbeiten und vom Erfragen des Backup-Teams der Rafisa.

Da heutzutage viele DCs virtualisiert sind, ist eine bevorzugte Backuplösung das Backup eines Server-Images. Da in einem Forest dauernd ActiveDirectory(AD)-Informationen ausgetauscht werden, ist bei einem Image-Backup nicht gewährleistet, dass die Daten konsistent sind.
Um ein Image-Backup zu erstellen, würde man über eine Pre-Dump-Skript auf dem Proxmox das Programm VZdump ausführen und das Image danach mit Rsync auf den Backup-Server transferieren.

Eine andere Lösung wäre, dass Windows-Server-Backup Feature zu benutzen. Damit kann man ein System-State-Backup erstellen. Dieses System-State-Backup lässt sich auf eine Festplatte auf dem DC abspeichern, freigeben und dann per SMB auf den Backup-Server spielen.

7.3.2 Backup des Home-Verzeichnisses auf einem Windows-Fileserver

Die simpelste Lösung um einen Share/Home Verzeichnis zu backuppen ist SMB. Das einzige Problem bei dieser Methode ist, dass viele kleine Files und Ordner die Backupdauer verlängern.
Auf BackupPC würde man einen simplen SMB-job aufsetzen ohne Pre/Post-Dump. [4]

Man könnte auch Rsync auf der Client-Maschine installieren. Doch Rsync wird nicht voll von Windows unterstützt und man muss einen ziemlichen Umweg gehen, um es benutzen zu können. Des Weiteren entstehen Kommunikation Probleme, wenn BackupPC Unix Befehle benutzt und diese Windows nicht versteht.
Das Gleiche für Rsync. Man erstellt einen simplen Job.

7.3.3 Backup eines Linux-Datenbankservers mit MariaDB (MySQL) und /etc

Auf einem Debian System setzt man am besten Rsync ein. Als BackupPC-Job kann man einen Pre-Dump Command ausführen der einen Dump der Datenbanken erstellt. Dadurch wird die Daten-Integrität gewährleistet.

7.3.4 Backup des Konfigurations-Verzeichnisses des Datenbank-Servers (/etc)

Auch hier ist der Backup-Job direkt über Rsync ausführbar.

7.3.5 Backup eines Proxmox-VM-Images

Rsync ist auch hier die beste Option. Man muss einen Pre-Dump Skript erstellen, wo ein VZ-Dump kreiert wird. Den Dump spielt man dann auf den Backup-Server.

7.3.6 Backup der Switch-Konfiguration

Für das Backup der Switch-Config kann die Arbeit eines Kollegen benutzt werden. Ein Arbeitskollege hat ein Bash-Skript auf dem Backup-Server erstellt. [5]

Dieses Skript führt ein FTP-Kommando aus, das sich auf den Switch verbindet, die Config ausliest und diese in einem Verzeichnis auf dem Backup-Server abspeichert. Diese sichert BackupPC dann. Das Problem an diesem Skript ist das Logindaten in Clear-Text versendet werden. Das ist ein ziemliches Sicherheitsrisiko.

Man kann einen ähnlichen Weg finden aber mit SSH, dem Public-Key-Verfahren und dem SCP-Command. Dies führt zu einem verschlüsselten Daten-Transfer. Auf dem Backup-Server erstellt man in der BackupPC-Umgebung ein Verzeichnis wie z.B. /var/lib/backuppc/backups/sw-zh-lab06/ wo man dann die Switch-Configs reinschreibt. Diese werden dann mit Rsync ausgelesen und abgespeichert.

7.3.7 Backup der Firewall-Konfiguration

Auch hier gibt es eine Arbeit von Nadeswaran, die man benutzen könnte.

Das Skript wird auf dem Backup-Server ausgeführt, dieses verbindet sich mit der Firewall und kopiert über SCP die Daten auf ein definiertes Verzeichnis. Danach wird es über Rsync abgespeichert.

Eine elegantere Lösung ist, auf der Firewall Rsync zu installieren. Danach kann man sich per SSH auf die Firewall verbinden und das Config-File auslesen und transferieren.

7.4 Planen BackupPC-VM

7.4.1 Ressourcen

Die Ressourcen-Planung ist beim Backup-Server sehr wichtig. Im Kapitel 7.7 wird deshalb eine Ressourcenplanung vorgenommen. Das Backup soll auf eine ZFS formatierte und verschlüsselte Platte abgespeichert werden.

7.4.2 Security

Das WebGUI von BackupPC wird nur über HTTPS gehosted. Die Festplatte des Backup-Servers wird extra verschlüsselt. Dabei wird eine neue Platte erzeugt, verschlüsselt und automatisch angebunden. Diese verschlüsselte Platte wird mit einem Passwort geschützt. Beim Aufstarten des Backup-Servers muss man dann zuerst das Passwort zur Decryption eingeben, weil diese automatisch beim Booten an /var/lib/backuppc angebunden wird.
Um sich auf Clients zu Verbinden wird fast nur SSH benutzt. Bei Backup-Jobs mit SMB wird keine SSH-Verbindung aufgebaut. Um weitere Sicherheit zu gewährleisten, wird mit Public und Private Keys ohne Passwort Eingabe gearbeitet. Dabei wird auf dem Backup-Server ein Key-Paar generiert und der Public-Key wird dann auf die Client-Geräte verteilt. Wenn sich dann der BackupPC-User mit seinem Private-Key verbinden möchte, wird er sich ohne Passworteingabe über SSH einloggen können. Die Backup-Users werden auf allen Systemen nur minimale Berechtigungen besitzen. Dies wird durch die Sudoers-Liste und mit Windows-Gruppen gewährleistet.

7.4.3 Benachrichtigungen

Es ist wichtig zu wissen, ob ein Backup-Job funktioniert hat oder nicht. Um das zu ermöglichen, muss bei jedem Job der Backup-Administrator benachrichtigt werden. Dies kann man lösen in dem man ein Mailing-System einrichtet das bei jedem Job als Post-Dump-Query eine Mail verschickt, die alle wichtigen Informationen über das Backup beinhaltet.

7.5 Netzwerk-Konzept

7.5.1 VLANs

Es sollen nur die benötigten VLANs eingerichtet werden. Keines der zu erstellenden VLANs braucht einen DHCP-Server, weil ich nur Server-Zonen aufbauen werde und diese müssen alle eine statische IP-Adresse besitzen. Deshalb macht es keinen Sinn in diesen Netzen die DHCP-Funktion zu aktivieren.

7.5.2 IP-Zuteilung

Die Hostnamen aller benötigten Systeme werden gemäss der Rafisa-Namenskonvention festgelegt.

7.5.3 Zugriffsmatrix

Die Zugriffsmatrix der einzelnen VLANs soll gemäss Firmenstandards umgesetzt werden.
✔️ steht für Zugriff erlaubt.
❌ steht für nicht erlaubt.

7.5.4 Ports Konfiguration der Switch und Firewall

In der Tabelle findet sich die Portkonfiguration der Switch und Firewall.
Fixed – VLAN-ID erhält Pakete.
Forbidden – VLAN-ID erhält keine Pakete.
Tagged – Alle VLAN-IDs werden gesendet.

8 Entscheiden

8.1 Konzept VMs

Für meine virtuelle Umgebung brauche ich insgesamt 6 VMs. Ausschliesslich des Switches werden alle aufgelistet. Da der Speicher dynamisch alloziert wird, wird den VMs mehr Speicherplatz zur Verfügung gestellt als sie minimal benötigen. Die GNS3-Umgebung hat einen gesamten Speicherplatz von 480GB.

8.1.1 DC und Fileserver - dc-zh-lab06-01

Die Funktionen DC und Fileserver werden auf der gleichen VM realisiert. In der VM werden zwei Festplatten zu je 40 GB erstellt. Auf der zweiten Festplatte wird das Home-Verzeichnis des Backup-Users erstellt und freigegeben. In dieses Verzeichnis wird das System-State-Backup eingespielt. Damit können dann beide Backup-Jobs gleichzeitig durchgeführt werden.

8.1.2 Debian 11 Datenbankserver - db-zh-lab06-01

Der Datenbankserver wird mit MariaDB in der Version 10.11.2 aufgesetzt.

8.1.3 Proxmox VE - prox-zh-lab06-01

Zuerst wird eine Debian Maschine aufgesetzt und dann wird das Proxmox-Paket darauf installiert. In der Proxmox-Umgebung wird eine VM erstellt. Für die Realisierung des Image-Backups wird ein TinyCore Linux installiert. Dieses ist eine schmale, ressourcensparende Distribution. Mit einem Pre-Dump-Command wird das Image auf dem Proxmox erstellt und danach auf den Backup-Server transferiert.

8.1.4 Pfsense - fw-zh-lab06-01

Die Pfsense Firewall wird gemäss Firmenstandard aufgesetzt. Drei Netzwerk-Interfaces werden erstellt, eines fürs das WAN, eines für das LAN und eines für die VLANs.

8.1.5 Switch – sw-zh-lab06-01

Der Switch ist eine virtuelle Maschine mit dem CiscoIOS-OS. Der Switch wird mit 12 Ports belegt.

8.1.6 AD Benutzer-Backend

Auf ad-zh-lab06-01 werde ich eine OU-Struktur gemäss den Firmenstandards aufbauen.

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

8.2 Backup & Restore Konzept

8.2.1 Rahmenbedingungen

Die Transferrate wurde mit dem Programm Iperf getestet.

Im Pre-Dump des DC-Backup-Jobs wird ein Windows-System-State-Backup ausgeführt. Dieses Backup dauert ungefähr eine Stunde. Der Backup-Job wird erst durchgeführt, sobald das ST-Backup durchgelaufen ist.

8.2.2 Sicherungsperiodizitäten

Ab der Einrichtung des Backup-Jobs werden im Scheduler mit der folgenden Konfiguration jeder Nacht gestartet.

Abbildung 5: Schedule BackuPC Backup-Server

Damit wird jede Woche ein Full Backup erstellt und unter der Woche ein Incremental-Backup. Die Blackout-Period bezieht sich auf die Zeit, in der BackupPC keine Backup-Jobs durchführen darf.

8.3 BackupPC Konzept

Der BackupPC-Backup-Server wird auf einem Debian-System realisiert. Dieser erhält zur Sicherheit eine Festplatte von 200 GB, obwohl nur 141GB benötigt werden. Sobald die Grundkonfigurationen durchgeführt wurden, wird BackupPC installiert. Dort erstellt man dann einen User für das WebGUI und das Passwort. Standard-Konfigurationen werden dann unter «/var/lib/backuppc» vorgenommen. Der Standard-User für alle Backup-Jobs wird BackupPC genannt. Unter «/etc/hosts» werden alle IP-Adressen der Backup-Targets eingetragen und mit Host-Namen betitelt. Dies vereinfacht das Arbeiten mit den Hosts im WebGUI.

Ein SSH-Key-Pair wird generiert. Falls SSH noch nicht installiert ist muss man es zuerst noch installieren.

Die Festplatte wird zu einer virtuellen Platte umgewandelt und mit Luks verschlüsselt. Dann wird sie auf XFS formatiert. Danach wird die virtuelle Platte so konfiguriert das sie bei Systemstart automatisch gemounted wird. Die virtuelle Festplatte wird unter «/var/lib/backuppc» angebunden.

8.3.1 Backup-Job für DC + Fileserver

Auf dem DC wird ein User mit dem Namen BackuPC erstellt. Dieser wird der Windows-Backup-Admin Gruppe hinzugefügt, mehr Berechtigungen erhält er nicht. Über PowerShell wird SSH installiert damit man von BackupPC aus den Pre-Dump-Command ausführen kann. Danach spielt man den Public-Key des Backup-Servers auf den DC.

$sshPath -q -x -l backuppc $host wbadmin start systemstatebackup-backuptarget:\\servername\sharedfolder\ -quiet

Dieser Pre-Dump-Command wird ausgeführt und danach wird über SMB der Share des Home-Verzeichnisses sowie der Share des Backups transferiert.

8.3.2 Backup-Job für Datenbankserver

Beim Datenbank-Server wurde entschieden jede Datenbank einzeln abzuspeichern. Als erstes muss man den Public-Key des Backup-Server auf den DB-Server spielen. Der Pre-Dump sieht wie folgt aus:

ssh -q -l root «ip-adresse» databases=`mysql -e „show databases;“ | tr -d „|“ | grep -v Database` ; for i in $databases; do mysqldump $i > /tmp/„$i“.sql; done

Sobald der Pre-Dump durchgeführt wurde, wird dann per rsync der /tmp Ordner gebackuppt.

8.3.3 Backup-Job für Proxmox-Server

Über den Pre-Dump wird eine SSH-Verbindung aufgebaut und dann ein VZ-Dump der VM gemacht. Pro VM im Proxmox sollte ein Host erstellt werden. Über Rsync wird dann der VZ-Dump abgespeichert.

8.3.4 Backup-Job für Switch

Die Variante von Nadeswaran benutzt ein Bash-Skript über FTB. In diesem Skript sind wichtige Login-Daten vorhanden die einfach auszulesen sind. Dies ist meiner Meinung nach ein grosses Sicherheitsrisiko. Deshalb wird die Verbindungs-Art auf SSH geändert. Mit SSH wird der Verbindungsaufruf verschlüsselt.

Den Public-Key auf den Switch zu spielen ist für ein CiscoIOS-Switch komplizierter als ein simpler Command. Deshalb werde ich dafür die Anleitung eines meiner Arbeitskollegen benutzen. [6] Sobald die SSH-Verbindung aufgebaut ist, kann man den Pre-Dump ausführen. Das Backup ist hier ein bisschen anders da rsync nicht auf dem Switch vorhanden ist. Deshalb lädt man das Config-File des Switches in ein erstelltes Verzeichnis im Backup-Server. Unter /var/lib/backuppc/backup/Switch/switchname/ wird dann das Config-File geschrieben. Danach wird es simpel über Rsync gesichert.

In einer grösseren Umgebung würde ich das Skript skalierbar machen. So, dass nicht nur ein Switch gebackuppt wird, sondern alle vorhandenen Switches mit einem Loop eingelesen werden.

8.3.5 Backup-Job für Firewall

Auch hier gibt es ein Skript eines Arbeitskollegen [5], dass ich benutzen könnte, dass ähnlich wie beim Switch funktioniert. Dieses liest über SSH die Config aus und lädt sie auf den Backup-Server, wo sie dann über Rsync abgespeichert werden kann. Das alles kann ich aber ganz simpel umgehen da ich auf der Pfsense-Firewall Rsync installieren kann. Das bedeutet ich muss nur den Public-Key zuschicken und den Ort der Config abspeichern. Die Config findet man unter /conf/. Was zu beachten ist, ist dass man den RsyncClientPath vom Standard ändern muss, da Rsync in ein anderes Verzeichnis gespeichert wird. Und zwar ist das Verzeichnis /usr/local/bin/rsync anstatt /usr/bin/rsync.

Auf der Firewall muss ein Backupuser erstellt werden und bei diesem muss man auf dem Firewall-GUI den Public-Key reinschreiben.

8.4 Testkonzept

8.4.1 Soll-Netzplan der Testumgebung

8.4.2 Testobjekte

Backupserver
Firewall
Proxmomx-Server
Datenbank-Server
DomainController
Switch

8.4.3 Testfälle

8.4.4 Was nicht getestet wird

8.4.5 Relevante Testmittel und Methoden

8.5 Arbeitspakete

1. VMs einrichten
   1. Firewall OS installieren
   2. Debian 11 OS installieren x 3
   3. Windows Server 2019 OS installieren
2. Firewall konfigurieren
   1. Standardkonfiguration
   2. Interfaces
   3. Dienste
   4. Rules
   5. Ssh aktivieren und public Key dem User ausstatten
   6. Rsync installieren
3. Switch konfigurieren
   1. VLANs einrichten
   2. SSH einrichten
4. BackupPC
   1. Standardkonfiguration
   2. BackuPC installieren
   3. BackupPC konfigurieren
   4. SSH Key-Paar erstellen
   5. WebGUI mit HTTPS
   6. Virtuelle Festplatte verschlüsseln
5. Datenbank-Server
   1. Standardkonfiguration
   2. MariaDB installieren
   3. Datenbanken erstellen
6. Active Directory Domain Controller
   1. DC-Komponenten installieren
   2. Windows Server Backup installieren
   3. Backupc User mit Berechtigungen erstellen
   4. SSH über Powershell installieren
7. Proxmomx Server
   1. Standardkonfiguration
   2. Proxmox installieren
   3. Proxmox konfigurieren
8. Backup-Jobs
   1. Für DC und Fileserver
   2. Für Datenbankserver und /etc
   3. Für Proxmox-Server
   4. Für die Switch Config
   5. Für die Firewall Config
9. Benachrichtigungs-System
   1. E-Mail-Programm installieren
   2. Skript erstellen und einfügen
   3. Post-Dump Skript bei allen Backup-Jobs einfügen

9 Realisieren

Um auf die VMs zugreifen zu können benutze ich den Gns3WebClient. Für eine saubere Installation habe ich auf der Firewall ein simples LAN mit DHCP erstellt. Damit werden alle VMs eine Internet-Verbindung haben. Erst danach passe ich das LAN und die respektiven VLANs an.

9.1 Aufsetzen der benötigten VMs

Abbildung 6: GNS3-Umgebung

9.1.1 Firewall OS

Für die Installation werden die Default-Einstellungen benutzt. Das Einzige, was man manuell eingeben muss, sind die Netzwerkinformationen. Diese werden währen der Netzwerk-Konfiguration beschrieben. [7]

Abbildung 7: Specs Firewall

Auf dem GUI kann man die wichtigsten Hardwareinformationen herauslesen.

9.1.2 Debian OS

Für meine Realisierung muss ich Debian 11 drei Mal installieren. Für alle drei Systeme ist die Installation gleich. Das Einzige, was anders ist, sind die Hardwarekomponenten und die Systemnamen. Bei der Installierung wird keine grafische Oberfläche ausgewählt.
Es werden immer zwei Benutzer angelegt: root und sysadmin. Diese erhalten das Rafisa-Standard Passwort.

Bei allen wird bei der Partitionierung «Geführt – vollständige Festplatte verwenden» ausgewählt
Beim Partitionierungsschema wird die Option «Alle Dateien auf eine Partition» ausgewählt. Damit wird das gesamte Root-System auf eine einzige Partition installiert.

Beim Debian-Archiv Spiegelserver habe ich für alle «debian.ethz.ch» ausgewählt.

Bei der zu installierenden Software. Es wird kein Debian-Desktop-Environment und GNOME installiert da diese auf einem Server unnötig Ressourcen brauchen würden und ein Sicherheitsrisiko darstellen würden. Und SSH-Server auswählen. Der SSH-Server wird benötigt für die passwortlose Verbindung und die Standard-Systemwerkzeuge sind sehr nützlich (wie z.B less oder nano).

Abbildung 8: Basisinstallation Debian Server-Umgebung

Der GRUB-Bootloader soll auf der Festplatte mit dem OS installiert werden.

Nach der Installation sollten geschaut werden das alle Pakete up-to-date sind. Um das zu erreichen kann man den Command «apt update && apt full-upgrade» eingeben.

9.1.3 Windows Server 2019 OS

Die Standard-Edition wird installiert. Man wählt Custom-Install aus. Danach wählt man eine Festplatte aus die zum C-Drive werden soll.
Der Standard User ist Administrator. Es wird das Rafisa-Standard Passwort verwendet.

9.2 Firewall

Als erstes wird das LAN erstellt, um einen Anschlusspunkt bei Notfällen zu haben. Der DHCP-Server wird aktiviert für einen einfacheren Zugang.

Abbildung 9: Netzwerkkonfiguration Firewall

Dabei geht man auf das User-Interface der Firewall und wählt «2) Set Interfaces» aus. Man muss das LAN ändern. Die Adresse wird 192.168.1.1/24 man braucht keinen Upstream oder IPV6.

Nun kann man auf das GUI zugreifen und die VLAN-Interfaces erstellen.

Das Erste, was man aktivieren kann, ist SSH. Unter «System→Advanced→AdminAccess». Dort wählt man SSH aus und wählt aus, dass man sich nur über den Public-Key einloggen kann. Dies erhöht die Sicherheit und minimiert die Angriffsmöglichkeiten auf die Firewall.

Abbildung 10: SSH-Einstellungen Firewall

9.2.1 Interfaces

Zuerst werden nun die Interfaces erstellt dann kann man auf diesen die Rules anpassen. Dies wird alles gemäss den Firmenstandards aufgebaut.
Unter «Interfaces→Assingments→VLANs» Erstellt man nun die VLANs für die Testumgebung.

Abbildung 11: VLAN Konfiguration Firewall

Als Parent Interface wird das neu erzeugte OPT-Interface ausgewählt. Dieses Interface bildet den VLAN-Trunk auf meiner Firewall. Der VLAN-Tag soll mit dem Namen des VLANs übereinstimmen. Die Priority kann übersprungen werden und die Description soll den VLAN-Namen enthalten.

Danach muss man die Interfaces unter «Interfaces→Assignments» aktivieren.

Nun muss man noch die Netzwerkadressen der VLANs anpassen und diese aktivieren.
Der Name wird angepasst und der IPv4 Type auf Static gesetzt.

Abbildung 12: General Configuration Firewall

Das Netzwerk wird eingegeben und das Subnet definiert.

Abbildung 13: Static IP Configuration Firewall

Am Schluss stehen auf der Firewall die folgenden fünf Interfaces zur Verfügung:

Abbildung 14: Final VLAN Configuration Firewall

9.2.2 Rules

Jetzt kommt man zu den Rules. Eine Deny Any-Any Rule ist leider nicht möglich umzusetzen, da diese das WAN blockiert. Deshalb erstellt man einen Alias mit allen VLANs und setzt diese in eine Inverted-Pass -Rule.
Unter «Firewall→Aliases→IP» wird ein Alias mit allen VLAN-Netzwerken erstellt.

Abbildung 15: Alias Erstellung Firewall

Damit kann man nun auf allen VLAN-Interfaces die Rules erstellen. Unter «Firewall→Rules→[Interface]» fügt man jetzt die Regeln ein. Die Regel habe ich «allow any but all VLANs» benannt. Mit dieser Regel kommt man überall hin ausser auf alle VLANs im Netzwerk. Dies ermöglicht es über das WAN-Interface in das Internet zu gelangen. Danach kann man VLANs auf die man zugreifen darf darüber setzen. Diese Regel muss man aber nicht im MGMT-VLAN einsetzen da dieses VLAN überall Zugriff haben soll. Deshalb reicht dort eine Pass Any-Any Rule.

Um eine Pass-Any-Any Rule zu erstellen, stellt man das Protokoll auf «any». Die Source und Destination bleibt auf «any».

Bei der «Allow any but all VLANs» Rule ändert sich die Source und Destination.

Abbildung 16: allow any but all Firewall

Die Source ist immer das VLAN, wo die Rule eingerichtet wird. Die Destination ist inverted und ein «Single host or alias» und zwar Alle_VLANs.

Bei einer Pass Rule wo ein VLAN auf das andere zugreifen darf, wird bei der Destination das andere VLAN eingetragen.

Abbildung 17: Pass Rule Firewall

Damit diese Rule nicht von der «Allow any but all VLANs» Rule blockiert wird muss diese über der Rule eingefügt werden, weil Pfsense die Rules von oben nach unten liest.

Sobald alle Rules gemäss der Zugriffsmatrix angepasst wurden, ist man mit der Konfiguration der Firewall fertig.

9.3 Switch

Um den Switch zu konfigurieren, benutze ich die Anleitungen eines Arbeitskollegen, der sich mit dem CiscoIOS auseinandergesetzt hat. [6]

9.3.1 Basiskonfiguration

Sobald man auf dem Switch ist, gibt man «enable» ein. Und danach «configure terminal»
Zuerst ändert man den Hostnamen. Mit dem Command «hostname sw-zh-lab01-01».
Mit «interface vlan 1» geht mat in das Config des VLANs. Dort gibt man «ip address 172.23.1.2 255.255.255.0» ein. Somit hat der Switch nun im VLAN01_MGMT die IP 172.23.1.2. Mit dem Command «no shutdown» verhindert man noch das sich das VLAN nicht einfach plötzlich ausschaltet.
«ip default-gateway 172.23.1.1» um den Switch die Firewall als Gateway einzugeben. Zudem muss man auch die Default-Route mit eingeben. «ip route 0.0.0.0 0.0.0.0 172.23.1.1»

Jetzt muss man mit «copy running-config startup-config» alles noch abspeichern. Sonst wird bei einem Reboot die Config verworfen.

9.3.2 VLANs

Im Globalen-Konfigurationsmodus erstellt man VLANs mit «vlan x» und dann «end» die Range liegt bei 1 – 4094. Man erstellt die VLANs 10,14 und 4094.
Nun muss man einen oder mehrere Trunks erstellen. Im Globalen-Konfigurationsmodus «interface giagbitEthernet 2/3» und 3/0 für Trunk 11 und 12. Im Config gibt man «switchport trunk encap dot1q» ein, danach «switchport mode trunk» und noch «switchport nonegotiate». «end». Damit wird die Enkapsulierung auf dot1q umgestellt, was für Trunk nötig ist sowie der Port auf ein Trunk umgestellt. Das automatische Verhandeln wird ausgeschaltet.
Das native-vlan muss von 1 auf 4094 geändert werden, damit man das VLAN 1 benutzen kann. Mit «interface range gigabitEthernet 2/2 – 3» und «switchport trunk native vlan 4094» ändert man die Konfiguration.

Sobald man alles Konfiguriert hat kann man mit «sh int t» das Resultat kontrollieren.

Abbildung 18: VLAN Interfaces Switch

Jetzt müssen noch die Access-Ports verteilt werden. Dort wählt man wie beim Trunk die gewollten Interfaces aus. In der Config gibt man dann «switchport mode access» und «switchport access vlan x» ein.

Abbildung 19: VLAN Zuteilung Switch

Die Portnummern im GNS3-Template und intern auf dem Switch stimmen nicht überein. Deshalb gibt es eine Liste, mit der man die Ports von Gns3 mit dem CiscoIOS vergleichen kann.

Da ich in meiner Doku nicht mit dem Port 0 schaffe muss man noch +1 bei dem Gns3 Port rechnen.

Damit sollte das Netzwerk jetzt aufgebaut sein.

9.4 Datenbankserver

9.4.1 Standardkonfiguration

Als erstes wird eine statische IP-Adresse vergeben. Unter «/etc/network/interfaces» kann man diese ändern.

Und dann startet man die Networking-Services neu. Mit «systemctl restart networking.service» und falls das nicht klappt, kann man das System neustarten.

9.4.2 Installation MariaDB

Als erstes installiert man den mariaDB-Server.

«apt install mariadb-server» Installiert den Dienst.
«mysql_secure_installation» Ist ein Security Skript, um den Zugang zu erschweren.

Mit «mysql» öffnet man die Mysql-Konsole. Mit «create databse x;» erstellt man eine Datenbank. Will man einen Table erstellen muss man mit «use [db name]» eine Datenbank auswählen und dann mit «create table x (ID int, test varchar(255));» eine Tabelle erstellen.

Abbildung 20: Datenbanken MariaDB-Server

Die eingekreisten Namen sind die Datenbanken, die ich erstellt habe.

9.5 Proxmomx-Server

9.5.1 Basiskonfiguration

Wie schon bei den anderen Debian-Geräten ändert man die IP unter «/etc/network/interfaces»

9.5.2 Installation Proxmox

Um das Proxmox VE repository hinzuzufügen, gibt man

«echo „deb [arch=amd64] http://download.proxmox.com/debian/pve bullseye pve-no-subscription“
> /etc/apt/sources.list.d/pve-install-repo.list»

ein. Danach fügt man den repository-key ein.

«wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg

# verify

sha512sum /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg

7fb03ec8a1675723d2853b84aa4fdb49a46a3bb72b9951361488bfd19b29aab0a789a4f8c7406e71a69aabbc727c936d3549731c4659ffa1a08f44db8fdcebfa /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg»

Mit «apt update && apt full-upgrade» updated man die Paketlisten.

9.6 DC + File-Server

9.6.1 Basiskonfiguration

Als erstes muss man die IP-Konfiguration des Windows-Servers anpassen.

Abbildung 21: IP-Konfiguration DC-Server

Im ServerManager unter «Local Server» kann man den Computer-Namen anpassen.

9.6.2 DC

Jetzt muss man den Windows-Server zu einem DC aufsetzen. Unter Manage → «Add Roles and Features» werden die Server Rollen «Active Directory Domain Services” und “DNS-Server” ausgewählt.

Unter Features noch das Windows-Server-Backup hinzufügen. Danach kann man alles installieren.
Sobald die Installation fertig ist, kann man den Server zu einem DC befördern.

Abbildung 22: DC Promotion DC-Server

Jetz kann man eine neue Forest-Domäne mit dem Namen «rafisa.ipa» erstellen. Danach muss man ein Passwort für den Domänen-Restore auswählen. Das sind alle Konfigurationen, die man vornehmen muss.

9.6.3 Organisation Unit

Sobald der Server zu einem DC befördert wurde, werden mit dem Tool «Active Directory Users and Computer» die OUs gemäss den Firmenstandards erstellt.

Abbildung 23: OU Struktur DC-Server

So sollte die OU gemäss Rafisa-Standard aussehen.

9.6.4 Backup User

Um später dann den Backup-Job durchzuführen, brauche ich einen Benutzer, mit dem ich mich anmelden kann, und der genügend Berechtigungen hat, um ein Backup auszuführen. Unter Rafisa-Accounts erstelle ich den User BackupPC.

Das Passwort soll nie ablaufen da der Backup-Job sonst nicht funktionieren will, sobald es abläuft. Dann muss man das Passwort auf dem Windows-Server sowie dem Backup-Server anpassen. Der Account wird der Gruppe Backup-Operator hinzugefügt. Diese Gruppe ermöglicht es dem User ein System-State Backup zu bewilligen.

Abbildung 24: Backuppc-User Gruppen DC-Server

9.6.5 Festplatte einbinden

Der Domain-Controller verfügt über zwei Festplatten. Die zweite muss man aber noch formatieren. Mit einem Rechtsklick auf das Windows Symbol kommt man zum Disk Manager.

Darauf wird man gleich angefragt die Disk zu initialisieren.

Mit einem Rechtsklick auf die «Unallocated» Ressource kann man den Wizard öffnen der die Festplatte formatieren wird. Die Standard-Optionen sind zufriedenstellend und man muss nur die Disk benennen.

Sobald der Wizard fertig ist wird man aufgerufen die Disk zu formatieren. Sobald alles erledigt ist, sollte es wie unten aussehen.

Abbildung 25: Disk Initialisiert DC-Server

9.6.6 Sharing

Auf der neuen Platte wird ein Ordner erstellt mit dem Namen Daten. Dieser Ordner mitsamt Unterordner wird freigestellt. Dabei geht man zu den «Properties» des Ordners auf «Sharing». Dort wählt man «Advanced Sharing» aus. Dabei gibt man allen Usern die Vollberechtigung.

Man geht zu «Security» und fügt den Backup-User hinzu und gibt diesem Vollberechtigung. Nun ist der Domain-Controller bereit um den Backup-Job einzurichten.

Dem Backuppc-User wird «E:/Daten» als Home-Verzeichnis vergeben.

Abbildung 26: Backuppc Home DC-Server

Somit ist das Backup eines ST-Backup sowie eines Home-Verzeichnisses gewährleistet.

9.6.7 DNS-Hostnames

Um die Namensauflösung im Testnetzwerk zu ermöglichen, müssen auf dem Domain-Controller im DNS-Manager alle Hosts eingetragen werden. Der DNS-Manager wird im Server-Manager unter Tools gestartet. Danach fügt man in der Fordward Lookup Zone für jeden Host im Netzwerk einen neuen Host-Eintrag (A-Record) hinzu.

Abbildung 27: DNS Namensauflösung DC-Server

9.7 BackupPC

9.7.1 Basiskonfiguration

Zuerst wird eine statische IP eingerichtet. Unter «/etc/network/interfaces» wird die Netzwerkkonfiguration erstellt.

Sobald das Interfaces-File angepasst ist, kann man es abspeichern. Danach muss man noch den Netzwerk-Service neustarten. «systemctl restart networking.service».

Nun installiert man BackupPC mit dem Befehl «apt install backuppc»
Während der Installation kommt dann diese Meldung:

Abbildung 28: Automatic User Configuration Backup-Server

Der User BackupPC wurde erstell mit einem arbiträrem Passwort. Das Passwort kann man mit dem oben angezeigten Command ändern.

9.7.2 Datensicherung

Die zweite Festplatte wird verschlüsselt und an BackupPC angebunden. Als erstes wird die verschlüsselte Platte erzeugt:

«apt install cryptsetup»

«sudo dd if=/dev/urandom bs=1M count=8 of=/dev/vdb»

«sudo cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/vdb» hier muss man ein Passwort eingeben.

«cryptsetup luksOpen /dev/vdb backuppc-crypt»

Danach wird diese Platte auf XFS formatiert:

«Install xfsprogs»

«modprobe -v xfs»

«mkfs.xfs /dev/mapper/backuppc-crypt»

Anschliessend wird die Platte eingebunden und die Backuppc Verzeichnisse auf die Platte kopiert:

«mkdir /root/backuppc»

«cp -avr /var/lib/backuppc/* /root/backuppc/»

«mount /dev/mapper/backuppc-crypt /var/lib/backuppc»

«cp -avr /root/backuppc/* /var/lib/backuppc/»

Als nächstes wird der Mount-Point für die Platte definiert:

In /etc/fstab

/dev/mapper/backuppc-cryp /var/lib/backuppc xfs defaults0 0

Als letztes wird in /etc/crypttab der Mount-Point für das verschlüsselte System festgelegt. Folgender Eintrag wird erstellt:

backuppc-crypt /dev/vdb none

Nach dem Neustart wird das Passwort zum Entschlüsseln der Platte abgefragt.

Abbildung 29: Mount Point der verschlüsselten Platte Backup-PC

9.7.3 Webserver

Um auf das BackupPC Webinterface zugreifen zu können muss man unter «/etc/backuppc/apache.conf» die Linie «Require local» mit einem # auskommentieren. Damit kann man von jeglicher IP aus sich auf das Webinterface verbinden.

Danach gibt man zweit Commands ein, um HTTPS-Verbindungen zu ermöglichen.
«a2ensite default-ssl.conf»
«a2enmod ssl»

Mit «systemctl reload apache2» den Web-Server neustarten. Damit kann man nun über HTTPS auf das Webinterface zugreifen.

9.8 Backup-Jobs

9.8.1 Hosts

Auf dem Backup-Server werden die Hosts eingerichtet. Unter «/etc/hosts» werden sie eingetragen. Damit ist es einfacher die Hosts im Web-Interface zu unterscheiden da man ansonsten nur die IPs als Hostnamen hat.

Abbildung 30: BackupPC Hosts Backup-Server

So sollten die Hosts eingetragen werden.

9.8.2 SSH-Keys

Alle Backup-Jobs, die über Rsync fungieren, verbinden sich über SSH. Dafür brauche man aber eine passwortlose Verbindung. Diese kann man ermöglichen, indem man ein SSH-Key Paar generiert und den Public-Key verteilt. So kann sich der BackupPC automatisch mit seinem Private-Key anmelden.

Über «su – backuppc» wird man zum Backup-User. Mit diesem generiert man sich das Key-Paar.
«ssh-keygen -t rsa» legt die Keys unter «/var/lib/backuppc/.ssh/id.rsa» ab.

9.8.3 DC + Fileserver

Um unter Windows den OpenSSH-Server zu installieren, werden in der WindowsPowershell als Administrator die folgenden Befehle ausgeführt:

Nun verbindet man sich vom Backup-Server aus auf die Windows-Umgebung. Mit «scp .ssh/id_rsa.pub 172.23.10.31:» kopiert man den Public-Key in den SSH-Ordner. Jetzt erstellt man ein Text-File mit dem Namen «authorized_keys» und kopiert den Public-Key in das File. Nun sollte die passwortlose Verbindung funktioniert haben.

Auf dem Backup-Web-Interface erstellt man einen neuen Host.

Unter «Edit Config» wird ein Pre-Dump erstellt.

$sshPath -q -x -l backuppc $host wbadmin start systemstatebackup -backupTarget:\\DC-ZH-LAB06-01\Daten\Backup\ -quiet

Dieser führt ein Systemstate-Backup aus und speichert es in einem Ordner des Shares ab.

Im «Xfer» wird die «XferMethod» SMB ausgewählt. Der «SmbShareName» ist «Daten» und darunter kommt das Login des Users für das Backup.

Abbildung 31: Xfer DC-Backup-Job Backup-Server

9.8.4 Datenbank-Server

Auf dem DB-Server wird sudo installiert und ein backuppc Account erstellt. Im Sudoers-File wird dann angepasst welche Befehle der backuppc-User ausführen darf. Für die Vereinfachung der Realisierung bekommt er die Vollberechtigung.
«apt install sudo»
«adduser backuppc» noch Passwort usw. eingeben.
«nano /etc/sudoers»

Dort gibt man dann «backuppc ALL=(ALL) NOPASSWD:ALL» ein. Dies ermöglicht es dem backuppc Befehle ohne Passwortabfrage auszuführen.

Mit «/etc/init.d/sudo restart» wird der Service neugestartet.

Vom Backup-Server aus als User Backuppc kopiert man die SSH-ID auf das Zielsystem. Im Falle des DB-Servers ist es:»ssh-copy-id backuppc@172.23.14.5»

Auf dem Backup-Server wird nun der Command «ssh-copy-id backuppc@172.23.14.5» eingegeben. Damit soll das passwortlose SSH-Login funktionieren. Um das Backup zu ermöglichen, muss man immer zuerst mindestens einmal sich mit der Konsole mit SSH auf das Zielsystem einloggen. Damit wird der Backup-Server autorisiert sich über SSH einzuloggen. Dies muss man für jeden unterschiedlichen Host-Namen einzeln machen. (z.B. für den Datenbank-Server wäre es ein SSH-Login mit «172.23.14.5» und «db-zh-lab06-01».

Auf dem DB-Server wird im home-Verzeichnis des backuppc ein DB-Backup Verzeichnis erstellt, wo nachher dann die Dumps abgespeichert werden.
«mkdir /home/backuppc/db_backup»

9.8.4.1 Backup-Job

Auf dem Backuppc-Webinterface wird nun unter «Edit Hosts» der DB-Server angelegt.

Unter dem DB-Server Host wird nun im «Edit Config» als Pre-Dump das DB-Dump Skript eingefügt.

ssh -q -l backuppc 172.23.14.5 databases=`sudo mysql -e „show databases;“ | tr -d „|“ | grep -v Database` ; for i in $databases; do sudo mysqldump $i > /home/backuppc/db_backup/„$i“.sql; done

Unter «Xfer» Passt man drei Einstellungen an. Als «XferMethod» wird Rsync ausgewählt. Der «RsyncShareName» wird «/home/backuppc/db_backup/» und der «RsyncSshArgs» wird von root auf backuppc angepasst.

Abbildung 32: Xfer DB-Backup-Job Backup-Server

/etc

Das /etc Verzeichnis muss auch noch gesichert werden. Da alles schon vorkonfiguriert ist, muss man nur noch einen neuen Host im Backup-Server einrichten.

Auf dem Backup-Interface soll der neue Host eingetragen werden. Und zugleich soll der Host-Key abgespeichert werden. Deshalb macht man eine SSH-Verbindung auf den neu erstellten Host.

Jetzt kommt die Konfiguration des «Xfer».

Abbildung 33: Xfer DB-Backup-etc-Job Backup-Server

Alles ist gleich wie bei den Datenbanken, ausser dass der Share-Name «/etc» ist.

9.8.5 Proxmox

Abbildung 34: Anpassung Host-IP Proxmox-Server

Der Localhost under /etc/hosts muss angepasst werden, von 127.0.0.1 zu 172.23.1.21.

echo „deb [arch=amd64] http://download.proxmox.com/debian/pve bullseye pve-no-subscription“ > /etc/apt/sources.list.d/pve-install-repo.list

Mit diesem Befehl fügt man die Proxmox-Repository hinzu. Danach updated man die Repository via «apt update && apt full-upgrade».
Mit «apt install pve-kernel-5.15» wird der Proxmox-Kernel installiert. Das System wird neugestartet.

Um die Proxmox VE Pakete zu installieren wird der Befehl «apt install proxmox-ve postfix open-iscsi» ausgeführt. Dann muss man den Debian Kernel entfernen, um zukünftige Probleme mit Upgrades zu vermeiden:
«apt remove linux-image-amd64 ‘linux-image-5.10*’» «update grub»

Wenn man kein Dual-OS System haben will, kann man mit «apt remove os-prober» verhindern, dass unnötige Boot-Optionen aktiviert werden.

Jetzt sollte die Proxmox-Umgebung am Laufen sein. Zu erreichen ist sie unter «https://172.23.1.21:8006».
Auf diesem System setzt man ein TinyCore OS auf, um das Backup eines VZ-Dumps zu testen. Auf dem lokalen Proxmox Speicher muss man das ISO-Image des TinyCores raufladen.

Abbildung 35: Upload TinyCore ISO Proxmox-Server

TinyCore wird mit den folgenden Spezifikationen aufgesetzt:

Abbildung 36: TinyCore Speccs Proxmox-Server

Nach dem Erzeugen der VM muss man in den Optionen noch die «KVM hardware virtualization» ausschalten. Sobald das Desktop-Environment steht, kann man den TinyCore-Installer aufstarten und damit das Betriebssystem auf die Platte installieren.

In der Proxmox-Shell wird sudo mit dem Command «apt install sudo» installiert. Den User Backuppc erzeugt man mit «adduser backuppc».
Danach wird im Sudoers-File der User Backuppc eingefügt:

Auf dem Backup-Server wird der Host angepasst. Eine SSH-Verbindung wird aufgebaut. Mit «ssh-copy-id» den Private-Key auf den Proxmox-Server laden. Sobald das passwortlose Login funktioniert, kann man sich auf das Webinterface begeben.

Im Config-Editor wird als Pre-Dump der untenstehende Command eingegeben:

$sshPath -q -x -l backuppc $host sudo vzdump 100 –mode snapshot

Als «Xfer» wird Rsync ausgewählt. Der Rsync-Sharename ist «/var/lib/vz/dump/».

Abbildung 37: Xfer Proxmox-Backup-Job Backup-Server

9.8.6 Firewall

Auf dem Webinterface der Firewall wird der Backup-User «backuppc» erstellt. Der User muss der Gruppe «Admins» zugehören damit er das Config-File kopieren kann.

Der Public-Key wird hier eingefügt und nicht per «ssh-copy-id» auf das System gespielt.
Vom Backup-Server aus muss eine Verbindungen über SSH aufgebaut werden, damit der Host-Key Eintrag erstellt wird. Jetzt wird auf dem WebGUI der Host eingetragen.

Danach wird im «Xfer» unter «Edit Config» des Hosts, das Protokoll Rsync ausgewählt. Dabei ist zu beachten das der «RsyncClientPath» anders ist. Der Share-Name ist «/conf/» und der Backup-User wird von root auf backuppc geändert.

Abbildung 38: Xfer Firewall-Backup-Job Backup-Server

9.8.7 Switch

Da CiscoIOS Rsync nicht unterstützt wird muss ich das Config-File per SCP auf den Backup-Server spielen und dann das File mit Rsync speichern. Deshalb erstelle ich unter «/var/lib/backuppc/» ein Backup Verzeichnis und darin ein weiteres Verzeichnis mit dem Hostnamen. Also «var/lib/backuppc/backup/sw-zh-lab06-01».

Auch hier benutze ich die Anleitung von Fapio Pagotto. [6] Um einen SSH-Key eintragen zu können muss man zuerst einen Domain-Name definieren und einen Host-Key erstellen.
«enable» conf t» «ip domain-name rafisa.ipa»
«enable» «conf t» «crypto key generate rsa modulus 2048»

Nun wird SSH-2 aktiviert da SSH-1 zu unsicher ist.
«ip ssh version 2»
Nun konfiguriert man über den Virtual-Teletype das man sich nur über SSH verbinden darf und das nur lokale Authentifizierung möglich ist.
«line vty 0 4» «transport input ssh» login local» «exit»
Man kann die SSH-Authentifizierung über Passwort und Tastatur ausschalten. Dies macht man mit den Commands:
«no ip ssh authenticate user password» «no ip ssh server authenticate user keyboard»

Nun kann man den Public-Key eintragen. Da das CiscoIOS nur 72 Zeichen pro Zeile lesen kann, muss man den Public-Key auf dem Backup-Server auf je 72 Zeichen auslesen lassen und diese hinüber kopieren.
«fold -b -w 72 /var/lib/backuppc/.ssh/id_rsa.pub»

Auf dem Switch geht man auf: «ip ssh pubkey-chain» als Backup-User «username backuppc» und gibt «key-string» ein.

Der Backup-User braucht erhöte Berechtigungen, diese ergibt man mit «username backuppc privilege 15»
Danach den SCP-Server aktivieren mit «ip scp server enable» «end».
«copy running-config startup-config»

Man muss sich vom Backup-Server aus über SSH mit allen Host-Namen verbinden, damit die Host-Keys eingetragen werden. Beim CiscoIOS-Switch ist die SSH-Verbindung aber anders. Da es nur einen älteren Algorithmus unterstützt und dieser SSH nicht automatisch auswählt, muss man diesen bei der Verbindungs-Anfrage definieren.
«ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 backuppc@sw-zh-lab06-01»

Sobald die passwortlose Verbindung steht, kann man auf das Backuppc-GUI wechseln.

9.8.7.1 Backup-Job

Unter «Edit Hosts» wird wieder der Host eingefügt.

Im «Edit Config» wird ein Pre-Dump erstellt.

scp -i /var/lib/backuppc/.ssh/id_rsa -oKexAlgorithms=+diffie-hellman-group1-sha1 172.23.1.2:startup-config /var/lib/backuppc/backup/sw-zh-lab06-01/sw.config

Dieser kopiert die Config-Datei auf den Backup-Server. Da das Rsync auf dem BackupPC selbst ausgeführt wird, muss der Host angepasst werden, damit sw-zh-lab06-01 auf den Backup-Server geleitet wird.

Um sich dann passwortlos vom localhost per ssh auf den localhost zu verbinden, muss man mit «cat id_rsa.pub > authorized_keys» ,wenn man als backuppc im «/var/lib/backuppc/.ssh/» Verzeichnis ist, den Public-Key ins «Authorize_keys-File» kopieren.

Im «Xfer» wird die Methode angepasst, der Share-Name und das «RsyncSshArgs» von root auf backuppc geändert.

Abbildung 39: Xfer Switch-Backup-Job Backup-Server

9.9 Benachrichtigungs-System

Es ist von Nutzen zu wissen, ob ein Backup-Job erfolgreich durchgeführt wurde oder nicht. [8]

9.9.1 Basiseinrichtung-Mail-Server

Um die Benachrichtigung einzurichten, muss zunächst der Mail-Server Exim4 als Internet-Server zum Versenden von Mails konfiguriert werden. Dies lässt sich über den Befehl dpkg-reconfigure exim4-config erledigen.

9.9.2 Einrichtung Benachrichtigungs-Script

Danach müssen dem Server für den Mailversand gültige Konteninformationen mitgegeben werden. Diese trägt man in die Datei /etc/exim4/passwd.client ein:

Danach wird auf dem Backup-Server unter /usr/local/share/backuppc/bin ein Script mit dem selbst gewählten Namen email-notify.sh erstellt. Dieses Script wurde mit Hilfe einer Anleitung unter <https://unix.stackexchange.com/questions/386661/shell-script-for-backuppc-notification-not-working geschrieben. Es ist im Anhang aufgelistet.

Schliesslich wird das Script mit folgendem Pre-Dump-Befehl ausgeführt:

/usr/local/share/backuppc/bin/email-notify.sh $xferOK $host $type $client $hostIP $share $XferMethod $sshPath $cmdType

Das Script übergibt als Parameter die Umgebungsvariablen des gerade ausgeführten Jobs.

Abbildung 40: E-Mail-Nachricht Backup-Server

Falls es funktionert hat, erhält man eine Email.

10 Kontrollieren

10.1 Durchführung und Auswertung der Tests

Es ist zu prüfen, ob alle wichtigen Aspekte des Projektes funktionieren. Es soll erkenntlich sein welche Operationen funktionieren und wo es Verbesserungsmöglichkeiten gibt.

10.1.1 Testprotokolle

10.1.2 Testszenario 2

Abbildung 41: GNS3 Angepasstes Test-Umfeld

Die IP des Backup-Servers wurde angepasst, so dass der Server mit dem DC kommunizieren kann.

11 Auswerten

11.1 Gesamtbilanz

In dieser Arbeit sollten die Grundlagen gelegt werden für die Einführung von BackupPC in der Rafisa.
Es wurden Backup-Jobs für folgende Systeme aufgesetzt und getestet:

• Pfsense-Firewall
• CiscoIOS-Switch
• Datenbank-Server
• Proxmox-Server-VM
• Windows-Domain-Controller

Bei allen Jobs wurde das Backup sowie das Restore getestet. Sämtliche Tests sind dokumentiert und erfolgreich verlaufen. Insgesamt wurde das Projekt erfolgreich durchgeführt.

11.2 Verbesserungsmöglichkeiten

Ich konnte mehrere Backup-Jobs, effizienter und sicherer umsetzen. Für die Datenbanken habe ich sogar ein skalierbares Skript erstellt. Für die Firewall konnte ich Rsync umsetzen, was mir ein Skript gespart hat. Was mich gefreut hat ist das ich alles realisieren konnte, was mir vorgeschrieben wurde.

Das Skript für die Proxmox-Umgebung ist noch nicht skalierbar und ist noch nicht für die Inbetriebnahme bereit. Man müsste es noch ausbessern, so dass man nicht für jede VM einen einzelnen Backup-Job einrichten muss.
Ich finde die Dokumentation unübersichtlich es wäre interessant eine Kurzzusammenfassung, mit den wichtigsten Daten jedes Kapitels, zu schreiben und diese am Anfang des Kapitels einzufügen. Ich habe viele kleine Flüchtigkeitsfehler begangen. Solange ich sie aber dokumentiere sollte meine Arbeit keinen Schaden davon genommen haben. Diese sollte ich in der Zukunft jedoch verbessern. Der Zeitdruck war ein garantierter Grund für diese Flüchtigkeitsfehler.

Was ich leider zu spät realisiert habe, ist das der Cisco-Switch der Grund für die niedrige Datenübertragungsrate war. Dies ist aber nur ein Problem in der virtuellen Umgebung und hat mir das Installieren erschwert sowie das Testen der Backups. Die Lösung wäre, einen besser funktionierendes Switch-Template als Switch zu benutzen und das CiscoIOS-Template als zu testende Maschine anzuschliessen.

12 Schlusswort und Bilanz

Es hat ein wenig gedauert, bis ich in die Fahrt kam. Das Dokumentieren und Planen der Arbeit lag mir schwer da ich nicht daran gewohnt war meine eigenen Aufträge zu planen. Was mir auch nicht gelungen ist, ist professionell zu schreiben. Ich muss mir das angewöhnen. Ich musste viele Texte umschreiben, weil es nicht Formell genug war. Beim Realisieren kam ich angenehm voran, da ich in diesem Bereich am meisten Erfahrung habe. Alles aber zu dokumentieren hat sehr viel Zeit in Anspruch genommen. Des Weiteren war die Virtuelle-Umgebung sehr langsam im Datenaustausch (Das Problem habe ich dann später entdeckt) was dazu geführt hat das ich unter meinen zu realisierenden Arbeiten abwechseln musste. Ich habe nicht erwartet das es so knapp wurde mit der Zeit. Viele Arbeiten haben viel länger gedauert als ich es mir vorgestellt und geplant hatte. Dank dieser Arbeit habe ich vieles Neues über Unix basierte Systeme gelernt, sowie viele mir zuvor noch unbekannte SSH-Funktionen. Wie z.B. das passwortlose Login über die asymmetrische Key-Verteilung.

Ich bin sehr zufrieden, dass ich dieses Projekt erfolgreich abgeschlossen habe. Es war eine tolle Möglichkeit, meine Fähigkeiten und Kenntnisse zu erweitern und mich selbst herauszufordern. Trotz einiger Herausforderungen und Hürden konnte ich das Projekt termingerecht abschliessen.

13 Quellenverzeichnis

Teil 3 – Anhang

14 Glossar

15 Weitere Materialien

15.1 Messaging-Skript

#!/bin/bash

# script to send simple email

# Email To ?

EMAIL=„y.nay@rafisa.ch“

FROM=„backuppc@stiftung.ifa“

# Email text/message

EMAILMESSAGE=„/tmp/emailmessage.txt”

# Grab the status variables

xferOK=$1

host=$2

type=$3

client=$4

hostIP=$5

share=$6

XferMethod=$7

sshPath=$8

cmdType=$9

# Check if backup succeeded or not.

if $xferOK == 1; then

STATUS=„SUCCESS“

else

STATUS=„FAILED“

fi

# email subject

SUBJECT=“[BackupPC] $STATUS for host: $client„

# Email text/message

echo „Filesystem backup for $host $STATUS“ > $EMAILMESSAGE

echo “„ »$EMAILMESSAGE

echo „Type: $type“ »$EMAILMESSAGE

echo „Client: $client“ »$EMAILMESSAGE

echo „Host: $host“ »$EMAILMESSAGE

echo „Host IP: $hostIP“ »$EMAILMESSAGE

echo „Share: $share“ »$EMAILMESSAGE

echo „XferMethod: $XferMethod“ »$EMAILMESSAGE

echo „sshPath: $sshPath“ »$EMAILMESSAGE

echo „cmdType: $cmdType“ »$EMAILMESSAGE

# send an email using /bin/mail

/bin/mail -aFrom:„$FROM“ -s „$SUBJECT“ „$EMAIL“ < $EMAILMESSAGE