Linux - Security und Firewall Labor

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

Ziel

physischer Netzwerkplan

logischer Netzwerkplan

VirtualBox Vorlage

  • Ein Debian 12 Server wurde mit Standardprogrammen vorbereitet
  • Für neue Server sollte immer ein vollständinger Klon mit neuen MAC-Adressen erzeugt werden

Hostzugriff absichern

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
  • Jeder Host soll über das SSH-Protokoll administrierbar sein
  • Generieren Sie einen SSH-Schlüssel mit der Passphrase, z.B. 123Start$
  • hinterlegen Sie den öffentlichen Schlüssel für die Nutzer kit und root auf der Firewall
  • Der SSH-Server sollte nach Sicherstellung des Zugriffs über autorisierte SSH-Schlüssel keine Passwort-Authentifizierung mehr zulassen: SSH-Server Hardening
  • Am Ende sollte jeder Host über ssh user@ip.oder.host.name erreichbar sein

Router Firewall

  • Hardwareanpassungen, damit die Dienste später auch genug Ressourcen haben:
    • 4 GB RAM
    • 4 CPUs
    • 3 Netzwerkkarten
  • Als nächstes setzen wir den Hostnamen der äußeren Router Firewall und konfigurieren die statischen IP
  • hostnamectl set-hostname firewall
  • 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''.1''xx''/24
  gateway 192.168.''HS''.254

 auto enp0s8
 iface enp0s8 inet static
  address 172.18.1''xx''.1/24
 
 auto enp0s9
 iface enp0s9 inet static
  address 10.88.1''xx''.1/24
 auto enp0s10

 iface enp0s10 inet static
  address 172.16.1''xx''.1/24
  • ifdown -va ; ifup -va
  • bzw.
  • systemctl restart networking
  • Als Kontrolle kann man ip addr show ausführen

Firewall

DHCP

Switch

DNS für das Labor einrichten

Vorbereitungen

  • VirtualBox Server-Vorlage mit neuen MAC-Adressen klonen
  • Der Host soll im DMZ-Netzwerk liegen
  • IP-Adresse herausfinden über das DHCP-Log oder die Konsole
  • SSH-Schlüssel des Kit Hosts für User kit und root hinterlegen
  • statische IP-Adresse nach dem Netzwerkplan setzen (/etc/network/interfaces)
  • Hostname ändern zu dns
  • SSH-Server anpassen

Nameserver

SFTP Server

Strongswan IPSEC


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:
  1. Pakete, die für das andere LAN bestimmt sind müssen durch den VPN-Tunnel gezwungen werden
  2. Dadurch werden die Pakete beim Forwarden als ipsec-Pakete markiert, was wir durch ein Modul freischalten können
  3. Aus-/Eingehende ESP-Pakete müssen erlaubt werden
  4. 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

LANDEV="enp0s8"
DMZDEV="enp0s9"
WANDEV="enp0s3"
LAN="172.16.1xx.0/24"
DMZ="10.0.1xx.0/24"
WANIP="192.168.3.1xx"
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
		iptables -A INPUT -p tcp --dport 2222 -i $LANDEV -s $LAN -j ACCEPT
		iptables -A INPUT -i $WANDEV -p esp -j ACCEPT
		iptables -A INPUT -m multiport -p udp --dport 500,4500 -i $WANDEV -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 -o $WANDEV -p esp -j ACCEPT
		iptables -A OUTPUT -m multiport -p udp --dport 500,4500 -o $WANDEV -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 -m multiport -p tcp --dport 22,53,2222 -o $DMZDEV -d $DMZ -j ACCEPT
		iptables -A OUTPUT -m multiport -p udp --dport 53 -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 -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 2222 -i $WANDEV -o $DMZDEV -d $SFTPSERVER -j ACCEPT
		iptables -A FORWARD -m multiport -p tcp --dport 80,443 -i $LANDEV -j ACCEPT
		iptables -A FORWARD -m multiport -p tcp --dport 53,80,443 -i $DMZDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -p udp --dport 53 -i $LANDEV -j ACCEPT
		iptables -A FORWARD -p udp --dport 53 -i $DMZDEV -o $WANDEV -j ACCEPT
		iptables -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT
		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: "

 		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:2222

		iptables -t nat -A POSTROUTING -s $LAN -o $WANDEV -d $RIGHTNET -j RETURN
		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

		# Internetzugriff für alle mit dynamischer IP
		iptables -t nat -A POSTROUTING -o $WANDEV -j MASQUERADE
		;;
	*)
		echo "usage: $0 start|stop"
		;;
esac

OpenVPN

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

Proxies

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 kit@sftp
  • curl www.lab1xx.sec
  • curl --socks5 localhost:8080 www.lab1xx.sec
  • Unterschiedliche IPs sollten unter /var/log/apache2/access.log zu sehen sein

Squid als Standard Proxy

  • Ein einfacher Proxy soll eingerichtet werden
  • Über die Source-IP wird kontrolliert, ob ein Client den Proxy benutzen darf
  • Weitere ACLs können den Zugriff auf bestimmte Webseiten blockieren

Transparenter Proxy

  • Clients im LAN sollen nicht die Möglichkeit haben den Proxy zu umgehen, indem sie den Eintrag aus dem Browser entfernen
  • Über Firewall-Regeln können die Webanfragen auf den Proxy geleitet werden

Virenscanning mit ClamAV in Squid

  • Durch Installieren von Stammzertifikaten auf den Browsern der Clients, soll Squid die Möglichkeit haben die Inhalte der Webseiten zu scannen
  • Der Proxy kann so dann verhindern, dass Clients sich Viren herunterladen

Suricata

Mandatory Access Control

Apparmor

SELinux

  • Als Angriffsziel modifizieren wir den Apache2 Server: Command Injection Proof of Concept
  • 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
  • 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

HIDS

AIDE

Tripwire

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

  • Kali Vorlage auf den realen Host ziehen
  • Neue Maschine hinzufügen mit Netzwerkbrücke
  • Benutzer/Passwort: kali/kali
  • sudo -i
  • apt update
  • apt install gvm
  • GVM initialisieren und das Passwort merken, aufschreiben oder in eine Datei speichern
  • gvm-setup
  • gvm-check-setup
  • Die Initialisierung der Datenbank kann einige Stunden dauern
  • Die Datenbank kann auch manuell geupdatet werden
  • 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>

Portscanning

  • Die Effektivität der Firewall soll mit nmap getestet werden
  • Für einen Vergleich scannen wir einmal mit Default-Policy accept und einmal mit drop

IP bei zuvielen Anfragen sperren

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
    }
    ...
}
Abgerufen von „http://wiki.ixheim.de/index.php?title=Linux_-_Security_und_Firewall_Labor&oldid=61597“