VirtualBox Vorlagen

Debian: Dienen als Server, Firewall oder generell Rechner, die keine graphische Oberfläche benötigen (sollte schon in Virtualbox als debian-bullseye-server vorhanden sein)
Arch: Rechner im LAN, Verwaltung der Server von hier aus über SSH/Weboberflächen (Befehl zum Herunterladen in der nächsten Zeile)
scp 192.168.3.200:~/Dokumente/lan-host.ova ~/Dokumente

Tag 1

Aufbau des Labors

Eine Debian Maschine soll uns als Firewall dienen
Diese soll über einen Bridgeadapter eine pseudo-öffentliche IP im Schulungsnetzwerk erhalten
Ein zweiter Netzwerkadapter vom Typ "internes Netzwerk" soll als LAN der Labore dienen
Ein Host mit einer graphischen Oberfläche im LAN der Firewall soll als Verwaltungsrechner dienen
Wenn die virtuellen Maschinen so konfiguriert sind, können sie hochgefahren werden
Nun muss die Netzwerkeinstellung wie im Schaubild konfiguriert werden:

Als erstes muss man "physisch" auf der Firewall die statischen IPs konfigurieren
für die statische IP muss die Datei /etc/network/interfaces bearbeitet werden (Distributions abhängig)
vim /etc/network/interfaces

auto lo
iface lo inet loopback

auto enp0s3
iface enp0s3 inet static
 address 192.168.3.1xx/24
 gateway 192.168.3.254

auto enp0s8
iface enp0s8 inet static
 address 172.16.1xx.1/24

ifdown -va ; ifup -va
Als Kontrolle kann man ip addr show ausführen
Ab hier kann man vom LAN Host aus auf die Firewall zugreifen (Befehle ab hier beziehen sich auf LAN Host!)
Dazu muss NetworkManager gestoppt werden, damit dieser Dienst nicht in unsere temporäre Netzwerkkonfiguration pfuscht
systemctl stop NetworkManager
Wir vergeben uns eine temporäre IP Adresse, um auf die Firewall per SSH zugreifen zu können
ip addr add 172.16.1xx.2/24 dev enp0s3
Nun sollte der Remote-Zugriff auf die Firewall möglich sein
ssh kit@172.16.1xx.1
Damit Hosts im LAN automatisch eine IP-Adresse erlangen, konfigurieren wir nun einen DHCP Server (Befehle ab hier finden auf der Firewall statt!)
apt install isc-dhcp-server
Falls dieser Befehl einen Fehler in der Namensauflösung schmeist, dann muss ein richtiger Nameserver eingetragen werden
vim /etc/resolv.conf

nameserver 1.1.1.1 # Als Beispiel. Man kann auch jeden anderen validen Nameserver verwenden

Nach der Installation des DHCP Servers beschwert sich systemd, dass er den Dienst nicht starten kann, weil er noch nicht richtig konfiguriert ist.
Das ist nicht weiter schlimm, da wir ihn wie folgt einstellen:
vim /etc/default/isc-dhcp-server

DHCPDv4_CONF=/etc/dhcp/dhcpd.conf
INTERFACESv4="enp0s8"

vim /etc/dhcp/dhcpd.conf

option domain-name-servers 1.1.1.1;
default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
subnet 172.16.1xx.0 netmask 255.255.255.0 {
	range 172.16.1xx.2 172.16.1xx.10;
	option routers 172.16.1xx.1;
}

Hostzugriff absichern

Ab hier wird wieder mit dem LAN Host weitergearbeitet
Bootsicherheit/-hacking
GRUB Passwort einrichten

Remotezugriff mit SSH

Da man nicht immer physisch an einer Maschine anwesend sein kann, empfiehlt es sich Hosts über SSH zu steuern
Der Datenverkehr ist dabei verschlüsselt, damit es beide Maschinen vor potentiellen Angreifern schützt, die den Verkehr mitschneiden

SSH-Schlüssel mit Passwort generieren

Man sollte Passwort-Authentifikation vermeiden soweit es geht
Bei SSH kann man stattdessen mit Schlüsselpaaren arbeiten, die wie folgt generiert werden
ssh-keygen
Den privaten Schlüssel sollte man mit einer Passphrase verschlüsseln für erhöhte Sicherheit
Danach sollten folgende Dateien da sein
ls ~/.ssh

id_rsa id_rsa.pub

Um den öffentlichen Schlüssel auf der Firewall abzulegen kann man einen der folgenden Befehle verwenden:
ssh-copy-id kit@172.16.1xx.1

bzw. diesen Befehl falls der Ordner .ssh schon im Homeverzeichnis vom Benutzer kit existiert:

scp ~/.ssh/id_rsa.pub kit@172.16.1xx.1:~/.ssh/authorized_keys
Nun sollte nicht mehr das Passwort des remoten Benutzers abgefragt werden
Damit man nicht jedes mal den privaten Schlüssel entsperren muss, sollte man sich einen SSH Agent konfigurieren
Um die Administration der Firewall einfacher zu machen kann man sich auch den öffentlichen Schlüssel zum root-User kopieren
su -
mkdir .ssh
cp ~kit/.ssh/authorized_keys ~/.ssh

SSH-Daemon auf Firewall absichern: Anderer Port, kein Root Login über Passwort

Im Moment kann jeder, der das Passwort des kit-Nutzers kennt, sich an der Firewall anmelden
Um das zu verhindern kann man den SSH Daemon folgerdermaßen konfigurieren
vim /etc/ssh/sshd_config

...
Port 2222
AddressFamily inet
ListenAddress 172.16.107.1
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
...

Tag 2

Automatischer Start der Firewall

Man kann über eigene Service-Dateien eine iptables-Firewall beim Bootprozess starten
vim /etc/systemd/system/firewall.service

[Unit]
Description=Firewall
After=network.target

[Service]
RemainAfterExit=yes
ExecStart=firewall start
ExecStop=firewall stop
User=root

[Install]
WantedBy=multi-user.target

systemctl enable --now firewall

Internet Zugriff für LAN mit iptables

Der Rechner darf mit sich selbst über das Loopback-Interface kommunizieren
Pakete aus dem LAN müssen auf die IP der Firewall umgeschrieben werden
alle Pakete bis auf SSH, DNS und Web sollen verworfen werden
ICMP darf innerhalb des Netzwerks und von innen nach außen zum Testen der Verbindungen funktionieren
Firewall soll nicht auf ICMP antworten
Wenn ein Paket verworfen wird, soll es unter /var/log/syslog geloggt werden
vim /usr/local/sbin/firewall

#!/bin/bash

LANDEV="enp0s8"
WANDEV="enp0s3"
LAN="172.16.1xx.0/24"
WANIP="192.168.3.1xx"

case $1 in
	start)
		echo "starte Firewall"
		iptables -F
		iptables -F -t nat

		iptables -P INPUT DROP
               iptables -A INPUT -i lo -j ACCEPT
		iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
		iptables -A INPUT -p tcp --dport 2222 -i $LANDEV -s $LAN -j ACCEPT
		iptables -A INPUT -p icmp --icmp-type echo-request -i $LANDEV -j ACCEPT
		iptables -A INPUT -j LOG --log-prefix "iptables drop INPUT: "

		iptables -P OUTPUT DROP
               iptables -A OUTPUT -o lo -j ACCEPT
		iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
		iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
		iptables -A OUTPUT -j LOG --log-prefix "iptables drop OUTPUT: "

		iptables -P FORWARD DROP
		iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
		iptables -A FORWARD -m multiport -p tcp --dport 80,443 -i $LANDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -p udp --dport 53 -i $LANDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -p icmp --icmp-type echo-request -i $LANDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -j LOG --log-prefix "iptables drop FORWARD: "

		iptables -t nat -A POSTROUTING -s $LAN -o $WANDEV -j SNAT --to-source $WANIP
		;;
	stop)
		echo "stoppe Firewall"
		iptables -F
		iptables -F -t nat
		iptables -P INPUT ACCEPT
		iptables -P OUTPUT ACCEPT
		iptables -P FORWARD ACCEPT
		;;
	*)
		echo "usage: $0 start|stop"
		;;
esac

Stateful Firewall: Establish und Related, um den Zustand von TCP/UDP Verbindungen zu beobachten, Conntrack als Visualisierung
Connection Tracking anpassen, kann man über Kernelparameter ähnlich wie bei net.ipv4.ip_forward
Parameter dazu findet man unter dem Ordner /proc/sys/netfilter

Dienste wie DNS, Webserver in der DMZ erstellen

Hier kommt die generelle Konfiguration, um der DMZ Internetzugriff zu gewähren
Virtualbox um einen Adapter erweitern für die DMZ
DHCP Konfiguration anpassen
vim /etc/default/isc-dhcp-server

DHCPDv4_CONF=/etc/dhcp/dhcpd.conf
INTERFACESv4="enp0s8 enp0s9"

vim /etc/dhcp/dhcpd.conf

option domain-name-servers 1.1.1.1;
default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
subnet 172.16.1xx.0 netmask 255.255.255.0 {
	range 172.16.1xx.2 172.16.1xx.10;
	option routers 172.16.1xx.1;
}
subnet 10.0.1xx.0 netmask 255.255.255.0 {
	range 10.0.1xx.2 10.0.1xx.10;
	option routers 10.0.1xx.1;
}

Firewall Regeln für Zugriff auf das Internet für DMZ einrichten

vim /usr/local/sbin/firewall

#!/bin/bash

DMZDEV="enp0s9"
LANDEV="enp0s8"
WANDEV="enp0s3"
LAN="172.16.1xx.0/24"
DMZ="10.0.1xx.0/24"
WANIP="192.168.3.1xx"

case $1 in
	start)
		echo "starte Firewall"
		iptables -F
		iptables -F -t nat

		iptables -P INPUT DROP
		iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
		iptables -A INPUT -p tcp --dport 2222 -i $LANDEV -s $LAN -j ACCEPT
		iptables -A INPUT -p icmp --icmp-type echo-request -i $LANDEV -j ACCEPT
		iptables -A INPUT -j LOG --log-prefix "iptables drop INPUT: "

		iptables -P OUTPUT DROP
		iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
		iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
		iptables -A OUTPUT -p tcp --dport 22 -o $DMZDEV -d $DMZ -j ACCEPT
		iptables -A OUTPUT -j LOG --log-prefix "iptables drop OUTPUT: "

		iptables -P FORWARD DROP
		iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
		iptables -A FORWARD -m multiport -p tcp --dport 80,443 -i $LANDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -p udp --dport 53 -i $LANDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -m multiport -p tcp --dport 80,443 -i $DMZDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -p udp --dport 53 -i $DMZDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -p icmp --icmp-type echo-request -i $LANDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -j LOG --log-prefix "iptables drop FORWARD: "

		iptables -t nat -A POSTROUTING -s $LAN -o $WANDEV -j SNAT --to-source $WANIP
		iptables -t nat -A POSTROUTING -s $DMZ -o $WANDEV -j SNAT --to-source $WANIP
		;;
	stop)
		echo "stoppe Firewall"
		iptables -F
		iptables -F -t nat
		iptables -P INPUT ACCEPT
		iptables -P OUTPUT ACCEPT
		iptables -P FORWARD ACCEPT
		;;
	*)
		echo "usage: $0 start|stop"
		;;
esac

[Bearbeiten]

Tag 3

DNS für das Labor einrichten

Die folgenden Befehle geschehen auf dem DNS Server
apt install bind9
dig ist ein praktisches Tool, um die DNS Auflösung zu testen
dig +short @127.0.0.1 xinux.net

194.59.156.162

Wenn das funktioniert hat, sollte man den Nameserver auf den lokalen Host setzen
vim /etc/resolv.conf

nameserver 127.0.0.1

Damit andere den Nameserver benutzen können, müssen die Antwort-Optionen angepasst werden
vim /etc/bind/named.conf.options

options {
        directory "/var/cache/bind";
        dnssec-validation no;
        allow-recursion { 0.0.0.0/0; };
};

Nun wollen wir unsere eigenen Zonen definieren, wobei die Antwort davon abhängt aus welchem Netz die Anfrage kommt
vim /etc/bind/named.conf.local

acl intern { 172.16.1xx.0/24; localhost; 10.0.100.0/24; };
acl extern { any; };

view intern {
	match-clients { intern; };
	zone "lab1xx.sec" {
		type master;
		file "intern/lab1xx.sec";
	};
};

view extern {
	match-clients { extern; };
	zone "lab1xx.sec" {
		type master;
		file "extern/lab1xx.sec";
	};
};

Die eigentliche Zuweisung von Name zu IP geschieht in den folgenden Dateien
vim /var/cache/bind/intern/lab1xx.sec

$TTL 300
@       IN SOA  dns.lab1xx.sec. technik.xinux.de. (2023041702 14400 3600 3600000 86400)
        IN NS   dns
dns     IN A    10.0.1xx.2
www     IN A    10.0.1xx.3
sftp	 IN A    10.0.1xx.4
fw      IN A    172.16.1xx.1

vim /var/cache/bind/extern/lab1xx.sec

$TTL 300
@       IN SOA  dns.lab1xx.sec. technik.xinux.de. (2023041702 14400 3600 3600000 86400)
        IN NS   dns
dns     IN A    192.168.3.1xx
www     IN A    192.168.3.1xx
sftp	 IN A    192.168.3.1xx
fw      IN A    192.168.3.1xx

Verschlüsseln des Datenverkehrs zwischen den Laboren mit VPNs

Ziel: LANs zwischen Laboren können sich anpingen, wenn eine VPN Verbindung besteht.

Als Vorbereitung benötigen wir einen SFTP-Server, um den Pre-Shared-Key und die Zertifikate auszutauschen:
- VLAN: DMZ
- Netzwerk: 10.0.1xx.4/24
- Hostname: sftp
- Firewall sollte von TCP Port 22 auf den SSH Port des SFTP-Servers zulassen
- sftp.labxx.sec sollte auflösbar sein (auf intern und extern achten)
vim /usr/local/sbin/firewall

...
iptables -A FORWARD  -p tcp --dport 22  -i $WANDEV -o $DMZDEV -d $SFTPSERVER -j ACCEPT
...
iptables -t nat -A PREROUTING -j DNAT -d $WANIP -p tcp --dport 22 --to $SFTPSERVER:2222
...

SSH Daemon lauscht auf TCP Port 2222, aber sollte Passwortauthentifikation für die Gruppe sftponly zulassen
vim /etc/ssh/sshd_config

...
Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes
Match Group sftponly
        PasswordAuthentication yes
        ChrootDirectory /srv/sftp/%u
        ForceCommand internal-sftp
        AllowTcpForwarding no

Für die Einrichtung des SFTP-Servers sollten folgende Ordner und Benutzer angelegt werden
mkdir -p /srv/sftp
groupadd sftponly
useradd -G sftponly -d /srv/sftp/gast -s /bin/false gast
mkdir -p /srv/sftp/gast/ablage
chown gast /srv/sftp/gast/ablage
passwd gast
Der Partner mit dem man die VPN aufbauen will, sollte das Passwort für den SFTP Account erfahren
Nun kann man die IPSec Implementation Strongswan auf der Firewall installieren
apt install strongswan
Die Verbindungen werden unter der Datei /etc/ipsec.conf konfiguriert

IPSec Site-to-Site aufbauen mit PSK

Diese Einstellung kann auf beiden Seite gleich angewendet werden (bis auf die IPs)
vim /etc/ipsec.conf

conn site2site-psk
     authby=secret
     keyexchange=ikev2
     left=192.168.3.1xx
     leftsubnet=172.16.1xx.0/24
     mobike=no
     right=192.168.3.1yy
     rightsubnet=172.16.1yy.0/24
     ike=aes256-sha256-modp4096!
     esp=aes256-sha256-modp4096!
     auto=start

Nun sollte über den SFTP-Server der PSK ausgetauscht werden:

Partner 1

Eine Seite generiert einen Schlüssel, z.B. head /dev/random | tr -dc A-Za-z0-9 | head -c 20
Dieser Schlüssel muss auf dem SFTP-Server abgespeichert werden.

Partner 2

Nun kann sich die Gegenseite den Schlüssel holen
sftp gast@sftp.lab1yy.sec
get ipsec.secret
Danach sollte der Schlüssel wieder vom SFTP Server gelöscht werden

Beide

Wenn beide Seiten den Schlüssel haben, kann man nun diese in die Datei ipsec.secrets eintragen
vim /etc/ipsec.secrets

192.168.3.1xx 192.168.3.1yy  : PSK "hierdertotalgeheimeschlüssel"

Auf der Firewall noch in der INPUT-Kette UDP Port 500 und 4500 freischalten
vim /usr/local/sbin

...
iptables -A INPUT -m multiport -p udp --dport 500,4500 -i $WANDEV -j ACCEPT
...

Nun sollte man die IPSec Verbindung aufbauen können
ipsec up site2site-psk
Den Status der Verbindung kann man mit ipsec statusall checken
Falls die Verbindung steht sollte ein Ping in das gegenüberliegende Netz auch funktionieren
ping 172.16.1yy.2

IPSec Site-to-Site aufbauen mit Zertifikat

Partner 1 wartet auf eine eingehende Verbindung mit passenden Zertifikat, wobei die IP egal sein darf
Commonname/FQDN im Zertifikat sollte fw1xx sein
Austausch der Zertifikate und der Anträge über den SFTP Server
PSK-VPN-Verbindung abbauen
ipsec down site2site-psk

Partner 1

Zertifizierungsstelle erstellen
mkdir ~/ca
cd ~/ca
openssl genrsa -aes256 -out ca.key 4096
openssl req -new -key ca.key -x509 -days 3650 -out ca.crt
IPSec-Zertifikat erstellen und signieren
openssl genrsa -out fw1xx.key 4096
Einen Certificate Signing Request erstellen
openssl req -new -key fw1xx.key -out fw1xx.csr
openssl x509 -req -days 730 -in fw1xx.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out fw1xx.crt
Zertifikat der Zertifizierungsstelle Partner 2 zukommen lassen (ca.crt)

conn site2site-cert
     authby=rsasig
     keyexchange=ikev2
     left=192.168.3.1yy
     leftcert="fw1yy.crt"
     leftsubnet=172.16.1yy.0/24
     right=192.168.3.1xx
     rightid="CN=fw1xx"
     rightsubnet=172.16.1xx.0/24
     ike=aes256-sha256-modp4096!
     esp=aes256-sha256-modp4096!
     auto=add

Partner 1

Signiert den Antrag
openssl x509 -req -days 730 -in fw1yy.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out fw1yy.crt
Schickt diesen zurück bzw. hinterlegt ihn auf dem SFTP Server (fw1yy.crt)
Konfigurieren der Verbindung
vim /etc/ipsec.conf

conn site2site-cert
     authby=rsasig
     keyexchange=ikev2
     left=192.168.3.1xx
     leftcert="fw1xx.crt"
     leftsubnet=172.16.1xx.0/24
     right=0.0.0.0 # Egal welche IP,...
     rightid="CN=fw1yy" # ...aber der Commonname muss stimmen
     rightsubnet=172.16.1yy.0/24
     ike=aes256-sha256-modp4096!
     esp=aes256-sha256-modp4096!
     auto=add

Beide

Damit Strongswan die Zertifikate findet, müssen diese an genau diesen Stellen liegen
find /etc/ipsec.d/ -type f

/etc/ipsec.d/private/fw1xx.key
/etc/ipsec.d/certs/fw1xx.crt
/etc/ipsec.d/cacerts/ca.crt

Diese müssen von Strongswan neu eingelesen werden
ipsec rereadall
Ob die Zertifikate erfolgreich geladen wurden lässt sich folgendermaßen überprüfen
ipsec listcerts
Ansonsten muss Strongswan neugestartet/geladen werden, falls der letzte Befehl nichts ausgibt
systemctl restart strongswan-starter
ipsec restart

Partner 2

Nur von dieser Firewall aus kann die Verbindung gestartet werden, da die andere Seite die IP nicht kennt
ipsec up site2site-cert

[Bearbeiten]

Tag 4

Firewall als nftables (Der Nachfolger von iptables) schreiben

Tag 5

OpenVPN Site-to-Site aufbauen
OpenVPN mit User-Authentication einrichten

HIDS

AIDE
Tripwire

Tag 6

Fail2ban für SSH einrichten

NIDS

Suricata
Snort

Tag 7

Squid Proxy konfigurieren (Application und transparent)
Virenscanning mit ClamAV in Squid

Tag 8

Angriffe mit nmap versuchen
System anpassen, anschauen wo was Alarm schlägt

Linux - Security und Firewall Plan - Linkai

Inhaltsverzeichnis

VirtualBox Vorlagen

Tag 1

Aufbau des Labors

Hostzugriff absichern

Remotezugriff mit SSH

SSH-Schlüssel mit Passwort generieren

SSH-Daemon auf Firewall absichern: Anderer Port, kein Root Login über Passwort

Tag 2

Automatischer Start der Firewall

Internet Zugriff für LAN mit iptables

Dienste wie DNS, Webserver in der DMZ erstellen

Firewall Regeln für Zugriff auf das Internet für DMZ einrichten

Tag 3

DNS für das Labor einrichten

Verschlüsseln des Datenverkehrs zwischen den Laboren mit VPNs

IPSec Site-to-Site aufbauen mit PSK

Partner 1

Partner 2

Beide

IPSec Site-to-Site aufbauen mit Zertifikat

Partner 1

Partner 2

Partner 1

Beide

Partner 2

Tag 4

Tag 5

HIDS

Tag 6

NIDS

Tag 7

Tag 8

Navigationsmenü

Suche