Blog
Nessus vs OpenVAS - ein Vergleich
- Details
- Written by Super User
- Category: Penetration testing
- Hits: 3531
Im Verlauf dieses Tutorials betrachten wir sowohl die Verwendung von Nessus als auch OpenVAS. Doch warum sollten wir uns zwei der führenden Vulnerability Scannern widmen? Sind die Ergebnisse nach dem Durchlaufen eines Scans so unterschiedlich, dass sich ein Vergleich lohnt? Obwohl OpenVAS als Abspaltung von Nessus entstanden ist, also beide eine gemeinsame technische Basis mitbringen, ist die Entwicklung unterschiedlich vorangeschritten. Nessus gilt unter den Vulnerability Scannern als weltweit führende kommerzielle Lösung. OpenVAS hingegen stellt die Open Source Lösung dar. Die Programmteile sind unter GPL lizensiert und seit 2019 wird der openVAS Scanner als Bestandteil des Greenbone Vulnerability Management (GVM) geführt. Trotz der gemeinsamen Wurzeln weisen die Schwachstellenscanner teils erhebliche Unterschiede auf, wie wir später sehen werden.
1. Installation von Nessus und erster Scan
2. Installation von OpenVAS und erster Scan
3. Vergleich
4. Fazit
1. Installation von Nessus und erster Scan:
1.1 Bevor wir uns mit der Installation von Nessus widmen bringen wir unser System mit dem folgenden Befehl auf den neusten Stand:
sudo apt-get update && apt-get upgrade -y
1.2 Da wir Nessus auf einem Kali Linux Rechner verwenden wollen, wählen wir die Debian Version für die Installationsdatei aus. Dazu navigieren wir zur Herstellerseite www.tenable.com/products/nessus/nessus-essentials und laden die entsprechende Datei herunter.
1.3 Ist der Download beendet, wechseln wir ins Downloadverzeichnis und öffnen die Paketverwaltung um Nessus zu installieren
sudo dpkg -i Nessus-10.3.0-debian9_amd64.deb
1.4 Nach Abschluss der Installation starten wir den Nessus Daemon mit dem Befehl
sudo /bin/systemctl start nessusd.service
1.5 Nun steht dem Start nichts mehr im Wege und wir öffnen die folgenden Webseite mit unserem Browser:
https://127.0.0.1:8834
1.6 Wir akzeptieren den Sicherheitshinweis und geben den zuvor beantragten Lizenzschlüssel für die Nessus Essentials Version ein.
1.7 Anschließend können wir einen Benutzeraccount für die Weboberfläche anlegen. Ist dies geschehen, startet der Download der Plugins.
1.8 Nach dem Download der Plugins und dem Eintragen des Benutzernamens samt Password navigieren wir auf die Seite "Scan Templates". Dort wählen wir "Basic Network Scan" aus und füllen die geforderten Eingaben aus.
Unter dem Menüauswahl "Discovery" verwenden wir den "Port Scan" welcher alle Ports abfragt. Nachdem wir unseren Scan vorbereitet haben speichern wir diesen ab. Er ist nun unter der Menüpunkt "My Scans" zu finden. Dort klicken wir auf den Play-Symbol um den Scan zu starten.
Nach dem Durchlaufen des Scans erhalten wir die Ergebnisse
2. Installation von OpenVAS und erster Scan
2.1 Mit dem folgendem Befehl updaten wir unser System und installieren OpenVAS
sudo apt-get update && apt-get install openvas -y
2.2 Nach dem Durchlaufen der Installation erscheint uns als nächstens das Passwort. Der hierzu gehörende Username lautet:"admin". Sinnigerweise können wir das Passwort bereits beim ersten Start ändern. Dazu später.
2.3 Um sicherzustellen, dass die Installation fehlerfrei durchlaufen ist nutzen wir den folgenden Befehl:
sudo gvm-check-setup
2.4 Die Installation ist nun einsatzbereit und können an dieser Stelle den Browser verwenden, um zum Dashboad zu gelangen
http://127.0.0.1:9392
2.5 Wie anfangs angesprochen, ändern wir unser Passwort unter "my settings" und klicken zudem auf den Notizblock oben links. Sind die Eingaben getätigt schließen wir das Fenster mit "save".
2.6 Um sobald als möglich loszulegen wechseln wir die Ansicht, indem wir auf die Button "Scans" klicken. Dort benutzen wir das Task Wizard Symbol um einen ersten Scan durchzuführen. Nach Angabe der IP Adresse des zu scannenden Host starten wir den Scan wie abgebildet.
2.7 Das Durchlaufen des Scans dauert nun eine Weile. Die Scandauer ist variabel und ein vulnerables System wir metasploitable mit vielen Sicherheitslücken dauerte ungefähr eine Stunde.
2.8 Nach Beenden das Scans stellt OpenVAS einen Report zur Verfügung. Diesen rufen wir auf, indem auf der oberen Leiste auf "Scans" -> "Reports" und anschließend den Report aus der Liste auswählen. Es erscheint zunächst eine Übersicht mit grundlegenden Informationen.
2.9 Die Ausgabe der ermittelten Schwachstellen erhalten wir durch das Wechseln auf den Reiter "Results".
2.10 Unterhalb der Menüleiste am oberen Rand erhalten wir die Möglichkeit einen Report zu exportieren. Um beispielsweise ein PDF zu erhalten wählen wir das Downloadsymbol mit dem Pfeil nach unten und verwenden anschließend .pdf als Ausgabeformat.
3. Im folgenden Vergleich gehen wir auf die Vor- und Nachteile beider Produkte ein und weisen anschließend auf die Unterschiede bei der Erkennung von Schwachstellemn hin.
3.1 Pro/Cons Nessus:
+ niedrige falsch / positiv Rate
+ niedrige Responsetime bei neu entdeckten Schwachstellen
+ moderne Benutzeroberfläche
+ fertige Templates für große Sicherheitslücken
+ Berücksichtigung von 72K CVEs
- hohe Kosten für professionelle User
- keine Open Source Software
3.2 Pro/Cons OpenVAS:
+ kostenlos
+ Integration in andere Sicherheitslösungen
+ höhere Gesamtanzahl an sicherheitsrelevanten Hinweisen
- Probleme mit falsch-positiven Ergebnissen
- Berücksichtigung von mur 26K CVEs
- keine Policy Management
3.3 Anzahl der Ergebnisse bei Nessus/OpenVAS:
High: 10
Medium: 25
Low: 2
Log: 72
Critical: 10
High: 5
Medium: 24
Low: 5
Info: 124
3.4 Auffälligkeiten bei der Untersuchung der Ergebnisse: die Durchsicht von "kritischen" oder Hinweisen der Stufe "hoch" in der Ergebnisliste der Schwachstellenanalyse zeigt eklatante Unterschiede unter beiden Programmen auf. An folgender Stelle sei eine Auswahl an Auffälligkeiten aufgezeigt, die bei der Analyse von Metaspolitable entstanden sind.
Folgende Einträge fehlen in den Ergebnissen bei OpenVAS:
- NSF Exported Share Information Disclosure Port: 2049 / udp
- NFS Shares World Readable Port: 2049 / tcp
- Samba Badlock Vulnerability Port: 445 / tcp
Folgende Einträge fehlen in den Ergebnissen bei Nessus:
- TWiki XSS and Command Execution Vulnerabilities Port; 80 / tcp
- Possible Backdoor: Ingreslock
- Distributed Ruby Multiple Remote Code Execution Vulnerabilities Port:8787/tcp
Die Auswahl gibt einen Hinweis darauf, dass selbst bei kritischen Sicherheitslücken die Ergebnisse nicht übereinstimmen. Dabei werden Schwachstellen entweder gar nicht erwähnt oder sie finden sich in unterschiedlichen Kategorien wieder.
Auffallend ist bei der Sortierung der Ergebnisse zudem, dass etliche Schwachstellen unter Nessus einen deutlich niedrigeren Score aufweisen als OpenVAS. So rangiert beispielsweise die Unreal IRCd (6697/tcp) Schwachstelle unter Nessus in der Rubrik "Info", während sie in OpenVAS als "high" eingestuft wird. Gleichsam verhält es sich mit einem FTP Server. Laut OpenVAS weist dieser in der laufenden Version eine Backdoor Vulnernability auf, während Nessus hingeben nur einen Hinweis auf einen laufenden Dienst ausgibt.
4. Fazit:
Angesichts der teils deutlichen Unterschiede bei der Bedienung, dem Workflow und Umfang an detektierten Schwachstellen kann keine Entweder-oder Empfehlung gegeben werden. Ratsam ist deshalb eine Nutzung bzw. die Kombination beider Produkte bei der Schwachstellenanalyse. Bei der Anzahl der detektierten von Schwachstellen bei Metasploitable punktet OpenVAS während Nessus eine zuverlässigere Erkennungsrate bietet.
Proxmox - Bonds/Bridges/VLANs
- Details
- Written by Super User
- Category: Proxmox
- Hits: 4369
In den bisherigen Beiträgen zur Konfiguration von Proxmox berücksichtigten wir zunächst nur das Hinzufügen von Bridges zu unserem Setup. Auch war es bisher so, dass nur eine Netzwerkkarte die Kommunikation übernahm. Im Folgenden setzen wir eine Dual Netzwerkkarte mit zwei Netzwerkports in unseren Host ein. Damit sind wir in der Lage zwei Verbindungen zu einem Bond zusammenzufassen, welches in der Terminologie als Link Aggregation bezeichnet wird.
Einem Bond liegen in unserem Fall zwei Netzwerkinterfaces zu Grunde, welche auch für das Management unserer PVE zur Verfügung stehen. Wo vormals die vmbr0 als standardmäßige Bridge konfiguriert war, tritt an dessen Stelle nun ein bond0, welches IP Adresse und Gateway übernimmt. Außerdem werden neben einem Bond auch VLANs zu unserem Setup hinzugefügt.
Schematisch sieht unser Setup wie folgt aus:
Unser Vorhaben gliedert sich wie folgt:
1. Herstellen der Anfangskonfiguration
2. Herstellen der erweiterten Konfiguration
3. Konfiguration der OPNsense
4. Eingliederung der VMs in unser Setup
5. Konfiguration der Firewall-Regeln
6. Konfiguration des Switches
verwendete Hardware: Netgear GS308EP
1. Herstellen der Anfangskonfiguration
Im ersten Schritt stellen wir eine Anfangskonfiguration her mit nur einem Bond und einer Bridge vmbr0. In der PVE sähe das aus wie folgt:
1.1 Hinzufügen eines Bonds
"Network" -> "Create" -> "Linux Bond"
- Name: bond0
- slaves: Name der Netzwerk-Devices z.B. enp3s0f0 / enp320f01
- Bond mode: balance-xor
- Hash policy: layer2+3
1.2. Hinzufügen einer Bridge
"Netzwerk" -> "Create" -> "Linux Bridge"
- Name: vmbr0
- IPv4: 192.168.2.155/24 (gleiche Management IP wie gehabt)
- Gateway: unverändert
- VLAN aware: aktiv
- Bridge ports: bond0
- Comment: Proxmox Management
2. Herstellen der erweiterten Konfiguration
In der erweiterten Konfiguration fügen wir unserem Setup VLANs und weitere Bridges hinzu. Im Ergebnis sollte dies wie folgt aussehen
2.1. Hinzufügen von weiteren Linux VLANs
"Network" -> "Create" -> "Linux VLAN"
- Name: bond0.1 (Hinweis: an dieser Stelle müssen VLANs zu einem bestehenden Interface hinzugefügt werden. Dazu setzen wir das in Schritt 1 geschaffene bond0 Interface ein)
Es können nach Belieben weitere VLANs auf Basis unseres bond0 hinzugefügt werden, etwa bond0.10, bond0.20, bond0.30, etc.
2.2 Hinzufügen weiterer Linux Bridges
Sind alle VLANs in Schritt 2.1 hinzugefügt worden, können auf Basis der VLANS die zugehörigen Bridges erstellt werden.
"Network" -> "Create" -> "Linux Bridge"
- Name: vmbr1
- Bridge ports: bond0.10
Genauso verfährt man auch mit der nächsten Bridge. Je nachdem wie viele VLANs wir zur Verfügung haben, können weitere Bridges hinzugefügt werden.
- Name: vmbr2
- Bridge ports: bond0.20
etc.
3. Konfiguration der OPNsense
3.1 Hinzufügen der Bridges
In unserer PVE Umgebung werden nun sämtliche Netzwerkbrücken, die wir unter Punkt 2.1 erstellt haben, der OPNsense hinzugefügt. Dazu klicken wir unter "Add" -> "Network Device"
und wählen nacheinander einzeln jede vorhandene Bridge aus. Im Ergebnis sollte es so sein, dass wir der OPNsense die gleiche Anzahl an Netzwerk Devices wie vorhandene Bridges hinzufügen.
3.2 Assign Interfaces
Danach wechseln wir zur Konsole der OPNsense und wählen die Option "Assign interfaces" aus. Dann vergeben wir für jedes Interface ein Netzwerknamen. Sind alle Eingaben getätigt, erhalten wir folgendes Bild
3.3 Vergabe der IP-Adressen
Nun wählen wir eine VM aus, welche Zugang zur LAN Schnittstelle der OPNsense besitzen soll. Dazu reicht es aus das "Network Device" mit der entsprechenden Bridge zu versehen, hier vmbr1. Nach dem Aufrufen der Konfigurationsoberfläche im Browser, welche uns nun zur Verfügung steht, wechseln wir zur Option "Interfaces" -> [OPT1] und tätigen folgende Einstellungen:
- Enable: enable Interface
- IPv4 Configuration Type: Static IPv4
- IPv4 address: 192.168.20.1/24
Wurden in Schritt 2.2 weitere Bridges, etwa vmbr3, hinzugefügt wird wie für das Interface [OPT1] verfahren. Für die weiteren Interfaces werden IP-Adressen entsprechend der VLAN ID vergeben. Also für [OPT2] die Adresse 192.168.30.1/24, usw. Zusätzlich müssen jedes Interface (hier: [LAN] und [OPT1]) der DHCP Server eingerichtet werden. Dazu wechseln wir zu "Services" -> "DHCPv4" -> [LAN] und setzen den Haken auf "enable". Weiter unten braucht es noch die Einstellung zur Range, welche wir frei wählen können. Gleichermaßen verfahren wir mit den restlichen Interfaces.
4. Eingliederung der VMs in unsere Setup
Damit unsere VMs in das richtige VLAN Netz eingegliedert werden, müssen sie mit der entsprechenden Bridge versehen werden. Dazu gehen wir unter "pve" -> "VM" bzw. Container" -> "Network" und editieren das Netzwerkinterface unter Verwendung der richtigen Bridge.
5. Konfiguration der Firewall-Regeln
Für die Kommunikation der VMs ist es erforderlich, dass die Firewallregeln geändert werden. Zu Testzwecken reicht es aus, den ein- und ausgehenden Datenverkehr mit Hilfe einer "allow all" Regel zu versehen. Anschließend sollte von Seiten der VMs ein Ping ins Internet erfolgreich sein.
6. Konfiguration des Switches:
Bei der Verwendung eines Netgear Switches GS308EP, wie es bei unserem Setup der Fall ist, ist die Konfiguration in wenigen Schritten erledigt. Sind beide Netzwerkinterfaces der Proxmox Hosts mit dem Switch verbunden, können wir die Link Aggregation aktivieren. Die Einstellungen dazu sind unter der Option Switching -> Link Aggregation zu finden. Sind beispielsweise die Ports 1 und 2 für das LAG verwendet worden, sieht die Konfiguration wie folgt aus:
Für die Konfiguration der VLANs verwenden wir "Einfaches 802.1Q-VLAN". Die bei der LAG Einstellung benutzten Ports 1 und 2 müssen nun als Trunkport eingerichtet werden. Zusätzlich
müssen je nachdem welche Endgeräte für die VLANs verwendet werden sollen, die VLAN IDs vergeben werden.
Update: IOTA Hornet 1.2.1 Node - Einrichtung
- Details
- Written by Super User
- Category: Raspberry Pi
- Hits: 24944
Seit dem Release der Hornet Node in der Version 0.4.0, zu dem ich ein Beitrag schrieb (IOTA Hornet Node 0.4.0 - Einrichtung), hat sich im IOTA Universum einiges getan. Zur Zeit steht uns die Version 1.2.1 zur Verfügung, welche Teil des Chrysalis Netzwerks (IOTA 1.5) ist, das seit April 2021 online ist. Mit dieser Übergangslösung soll der Weg hin zu einem vollständig dezentralisierten Paymentsystem geebnet werden. Mit dem Betreiben einer eigenen Node, haben Nutzer schon jetzt die Möglichkeit Teil dieser Entwicklung zu werden. Nodebetreiber erhalten mit einer Hornet Node Zugang zum IOTA Netzwerk ohne sich auf andere Netzwerkteilnehmer vertrauen zu müssen. Des weiteren verhelfen sie dem IOTA Netzwerk sich zu einem hochverteilten und belastbaren Netzwerk zu etablieren. Zur Zeit fokusieren sich die Bestrebungen der Entwickler auf die Umsetzung des IOTA 2.0 Mainnet. Während der Zeitpunkt für die Fertigstellung des Coordicide noch aussteht, sind Bestandteile dafür im DevNet "Pollen" schon erkennbar.
1) Voraussetzungen
2) Installation
3) Post-Installation
1.) Voraussetzungen
1.1) zunächst schreiben wir mit dem Raspberry Pi Imager das Betriebssystem Raspbian OS Lite 64bit auf die Micro-SD Karte. Das Tool erlaubt uns zusätzlich auch einen Benutzer zu erstellen, welches wir an dieser Stelle auch gleich wahrnehmen. Da unser Raspberry Pi aus dem Internet erreichbar seinen soll, wählen wir ein sicheres Passwort. Zudem aktivieren wir in den Einstellungen den SSH Zugang.
1.2) Ist das Image auf die Micro-SD Karte geschrieben, können wir uns mit der entsprechenden IP Adresse auf unseren Raspberry Pi verbinden. Die IP-Adresse dazu finden wir bei Nutzung einer Fritzbox unter "Heimnetz" -> "Netzwerk"
1.3) Ist die Verbindung zu unserem Raspberry Pi korrekt hergestellt worden, gehen wir zurück zu unserer Fritzbox und erstellen dort die nötigen Portfreigaben. Diese lauten wie folgt:
Kommunikation zwischen Nodes TCP 15600
Autopeering UDP 14626
1.4) Bevor wir zur eigentlichen Installation schreiten, installieren und konfigurieren wir die Firewall auf unserem Raspberry Pi. Dazu verwenden wir folgende Befehle, welche wir der Reihe nach eingeben
sudo apt install ufw
sudo ufw allow 22
sudo ufw allow 15600/tcp
sudo ufw allow 14626/udp
sudo ufw allow 14265/tcp
sudo ufw allow 8081/tcp
sudo ufw enable
1.5) Sind die Einstellungen der Firewall getätigt, führen wir einen Reboot durch
sudo reboot
2.) Installation
2.1) Zu Beginn unserer Installation bringen wir unseren Raspberry Pi zunächst auf den neusten Stand. Das geschieht mit dem Befehl:
sudo su
sudo apt update && apt upgrade
2.2) Das Herunterladen des Keys zur Verifikation der Pakete geschieht mit dem Befehl:
wget -qO - https://ppa.hornet.zone/pubkey.txt | sudo apt-key add -
2.3) Mit dem folgenden Befehl werden die Paketquellen zu den Repositories hinzugefügt:
sudo sh -c 'echo "deb http://ppa.hornet.zone stable main" >> /etc/apt/sources.list.d/hornet.list'
2.4) Damit die Änderungen wirksam werden, verwenden wir den Befehl
sudo apt update
2.5) Die Installation der Hornet Node erfolgt mit dem Befehl
sudo apt install hornet
2.6) Damit die Node auch nach einem Reboot automatisch startet, benutzen wir den Befehl:
sudo systemctl enable hornet.service
3.) Postinstallation
3.1) Auch wenn unsere IOTA Hornet Node bereits lauffähig ist, verwenden wir noch weitere Schritte zur besseren Nutzbarkeit: Zunächst legen wir einen Benutzer an. Dazu geben wir folgendes ein:
hornet tool pwd-hash
Bei der darauf folgenden Passwortabfrage geben wir ein sicheres Passwort ein, welches uns später für die Nutzung der Weboberfläche dient. Ist das Passwort vergeben, erscheinen zwei Zeichenreihen, der Hash und der Salt. Beide müssen wir notieren bzw. in die Zwischenablage kopieren, um sie später in die Konfigurationsdatei zu importieren.
Your hash: .......
Your salt: .......
3.2) Dazu öffnen wir die Konfigurtationsdatei mit einem Editor:
sudo nano /var/lib/hornet/config.json
3.3) Unter der Option "dashboard" -> "auth" ersetzen wir die Nullen bei "passwordHash" und "passwordSalt" mit den neuen Hash bzw. Salt Daten.
3.4) Weiter unten in der Konfigurationsdatei ersetzen wir unter "Node" den Wert "Spammer" mit "Autopeering"
3.5) Um später das Webinterface korrekt anzeigen zu lassen, ändern wir abschließend noch den Wert unter "dashboard" -> "bindAddress" von localhost:8081 in <IP-Adresse>:8081, wobei wir als <IP-Adreesse> die Adresse unserer Node einsetzen.
3.6) Sind die Eingaben getätigt, speichern wir die Datei in unserem Editor und verlassen diesen. Als nächstens starten wir die Node mit:
sudo service hornet start
3.7) Um die Anzeige der Logs zu aktivieren dient uns der Befehl:
journalctl -fu hornet
3.8) Um abschließend das Webinterface aufzurufen, geben wir die IP-Adresse der Hornet Node im Browser ein. Unser Benutzername lautet "admin" und das Passwort haben wir weiter oben bereits vorgegeben.
Bis unsere Node Teil der IOTA Netzwerks wird, dauert es ein paar Minuten.
<IP-Adresse>:8081
Einzelnachweise:
https://wiki.iota.org/hornet/how_tos/hornet_apt_repository
Proxmox - OPNsense Grundkonfiguration
- Details
- Written by Super User
- Category: Proxmox
- Hits: 3896
Das folgende Proxmox Setup soll aufzeigen, wie grundlegende Netzwerkkomponenten in Proxmox eingerichtet werden. Neben dem Bereitstellen von VMs und Containern sind es auch die Bridges, welche beim Aufbau eines Netzwerks ein zentraler Bestandteil bilden. Proxmox erfordert in seiner aktuellen Version die Konfiguration einer Bridge für jede VM, welche im PVE erstellt wird. Auch ist es möglich, mehrere VMs über die gleiche Bridge anzubinden, sodass der beteiligte Datenverkehr über eben diese Bridge verläuft.
Eine Bridge kann einer physischen Netzwerkkarte zugeordnet werden, sodass ein Datenverkehr z.B. ins Internet möglich ist. Wird eine Bridge ohne physische Zuordnung konfiguriert kann kein Datenverkehr von angeschlossenen VMs außerhalb einer Node stattfinden. Die Bridge fungiert in diesem Fall als ein Switch. Die Nomenklatur zur Benennung von Bridges beginnt mit der Bezeichnung vmbrX. Bei Neuinstallation einer PVE Umgebung wird standardmäßig eine Bridge mit dem Namen vmbr0 erstellt.
In unserer Beispielkonfiguration sollen zwei Bridges die Kommunikation zwischen den VMs separieren. Dabei wird eine Bridge vmbr0 einem physikalischen Netzwerkadapter zugeordnet. An dieser hängen zwei VM, 1 und 2, welche direkt über einen Switch außerhalb der PVE Node kommunizieren können. Eine zweite Bridge, vmbr1, fungiert als einfacher Switch ohne physikalische Zuordnung. An vmbr1 sind die VMs 4 und 5 angeschlossen, welche den Datenverkehr über die Firewall, VM3, weiter an die Bridge vmbr0 leitet. Dementsprechend besitzt die Firewall zwei Netzwerkadapter, net0 und net1.
Durch die Verwendung weiterer Bridges, etwa vmbr2, können weitere isolierte Gruppen von Netzwerkteilnehmern geschaffen werden. Wird an unserer Firewall ein weiterer Netzwerkadapter hinzugefügt, kann dieser wiederum mit einem weitern Switch kommunizieren. Die neue Gruppe von VMs wären wie die Teilnehmer an vmbr1, isoliert.
Zur Umsetzung unseres Vorhabens gehen wir folgende Schritte durch:
1. Hinzufügen einer Bridge, vmbr1
2. Installation/Konfiguration der OPNsense Firewall
3. Anschluss weitere VMs an unser Setup
1. Hinzufügen einer Bridge, vmbr1
Zunächst fügen wir unserem Proxmox VE eine neue Bridge hinzu. Dazu klicken wir unter "pve" -> "System" -> "Network" auf "Create" und wählen
"Linux Bridge" aus. Wir belassen im neunen Fenster alle Eigenschaften wie vorgegeben und wählen "Create".
2. Installation/Konfiguration der OPNsense Firewall
- Um die OPNsense, welche wir als Firewall verwenden, zu installieren, erstellen wir zuerst eine eine VM, indem wir auf den Button "Create VM" klicken
- Im neuen Fenster muss ein beliebiger Name für die Firewall vergeben werden, etwa OPNsense.
- Nun binden wir das ISO-Image ein, indem wir dessen Storage auswählen. Dazu muss zuvor, falls noch nicht geschehen, das ISO Image zunächst hochgeladen werden. Alles andere belassen wir auf den Voreinstellungen
- Ebenso übernehmen wir die Einstellungen bei den verbliebenen Reitern und Bestätigen unsere Auswahl mit "Confirm"
- Nach Erstellung unserer VM fügen wir unserer VM einen weiteren Netzwerkadapter hinzu. Dazu klicken wir unter dem Menüpunkt "Hardware" und "Add" auf "Network Device". Anschließend wählen wir die neu hinzugefügte Bridge, vmbr1, aus und klicken auf "Add"
- Wir starten unsere VM und wechseln unsere Ansicht zur Console. Nach Durchlaufen des Bootvorgangs und Eingabe von Benutzername/Passwort (installer/opnsense) starten wir den Installationsprozess. Zunächst gelangen wir zur Installerseite, welche uns auffordert das Tastaturlayout auszuwählen. Anschließend wählen wir den UFS Installationsmodus aus und installieren OPNsense auf unsere Harddisk, welche wir ebenfalls auswählen. Nachdem wir zweimal bestätigen startet der Installationsprozess. Ist dieser beendet müssen wir einen Reboot durchführen.
Nach Durchlaufen der Installation und Eingabe von Benutzername/Passwort (root/opnsense) erhalten wir eine Übersicht der verwendeten Netzwerkadapter vtnet1 und vtnet0.
In unserem Fall verwendet das LAN Netzwerk vtnet1 und das WAN Netzwerk vtnet0. Die Zuordnung kann ggf. unter "Assign interfaces" angepasst werden. Dazu wählen den Menüpunkt (1) und durchlaufen die Konfiguration wie folgt:
Enter an option: 1
Do you want to configure LAGGs now? [y/N]:n
Do you want to configure VLANs now? [y/N]:n
Valid inerfaces are:
vtnet0
vtnet1
Enter the WAN interface name or 'a' for auto-detection:vtnet0
Enter the LAN interface name or 'a' for auto-detection:vtnet1
Enter the Optional interface 1 name or 'a' for auto-detection:Enter
The interfaces will be assigned as follows:
WAN -> vtnet0
LAN -> vtnet1
Do you want to proceed? [y/N]:y
Unter dem Unterpunkt "Set interface IP address" passen wir nach Bedarf die IP-Adresse des LAN und WAN Netzwerks an. In unserem Fall wurden für den WAN Netzwerk die Anfangseinstellungen korrekt eingesetzt, die wir deshalb übernehmen können. Exemplarisch sind die Einstellungen für das WAN Interface weiter unten angegeben. Die Einstellungen für das LAN Netzwerk können wie folgt gesetzt werden:
Enter an option: 2
Available interfaces:
1 - LAN (vtnet1 - static)
2 - WAN (vtnet0 - dhcp, dhcp6)
Enter the number of the interface to configure: 1
Configure IPv4 address LAN interface via DHCP? [y/N] n
Enter the new LAN IPv4 address. Press <ENTER> for none:
> 192.168.50.1
Subnet masks are entered as bit counts (like CIDR notation).
e.g. 255.255.255.0 = 24
255.255.0.0 = 16
255.0.0.0 = 8
Enter the new LAN IPv4 subnet bit count (1 to 32):
24
For a WAN, enter the new LAN IPv4 upstreeam gateway address.
For a LAN, press <ENTER> for none: Enter
Configure IPv6 address LAN interface via WAN tracking? [Y/n]n
Configure IPv6 address LAN interface via DHCP6? [y/N]n
Enter the new LAN IPv6 address. Press <ENTER> for none:Enter
Do you want to enable the DHCP sever on LAN? [y/N]:y
Enter the start address of the IPv4 client address range:192.168.50.50
Enter the end address of the IPv4 client address range:912.168.50.150
Do you want to change the web GUI protocol from HTTPS to HTTP? [y/N] n
Do you want to gernerate a new self-signed web GUI certificate? [y/N] n
Restore web GUI access defaults? [y/N] n
Enter an option: 2
Available interfaces:
1 - LAN (vtnet1 - static)
2 - WAN (vtnet0 - dhcp, dhcp6)
Enter the number of the interface to configure: 2
Configure IPv4 address WAN interface via DHCP? [y/N] y
Configure IPv6 address WAN interface via DHCP6? [y/N] n
Do you want to change the web GUI protocol from HTTPS to HTTP? [y/N] n
Do you want to gernerate a new self-signed web GUI certificate? [y/N] n
Restore web GUI access defaults? [y/N] n
Die OPNsense gibt die Konfiguration wie folgt wider:
3. Anschluss weitere VMs an unser Setup
Nach vollendeter Konfiguration der Firewall können nun je nach Belieben weitere VMs dem Netzwerk hinzugefügt werden. Für den Zugriff auf die Firewall ist es nötig eine VM im LAN Netzwerk der Firewall einzurichten. Dazu konfigurieren wir den Netzwerkadapter so, dass dieser Teilnehmer Mitglied des LAN Netzwerks wird, indem wir den Netzwerkadapter unter "Hardware" -> "Network Device" -> "Edit" auf "vmbr1" stellen. Sollen weitere Netzwerkteilnehmer hinzugefügt werden verfahren wir gleichsam und ändern jeweils den Netzwerkadapter.