Linux - Security und Firewall Labor: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(17 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 8: Zeile 8:
 
{{#drawio:linux-sec-fire-00.1}}
 
{{#drawio:linux-sec-fire-00.1}}
  
−
= VirtualBox Vorlage =
+
= VM Vorlage =
−
* Ein Debian 12 Server wurde mit Standardprogrammen [[Debian Template|vorbereitet]]
+
*[[VM Vorlage Linux - Security und Firewall Labor]]
−
* Für neue Server sollte immer ein '''vollständinger''' Klon mit '''neuen MAC-Adressen''' erzeugt werden
 
  
 
= Hostzugriff absichern =
 
= Hostzugriff absichern =
−
* Falls man physischen Zugriff zur Maschine hat, kann die Authentifzierung von ''root'' beim Booten umgangen werden
+
*[[Hostzugriff absichern Linux - Security und Firewall Labor]]
−
* [[Linux boot hacking|Bootsicherheit/-hacking]]
 
−
* Das wollen wir an der Firewall verhindern
 
−
* [[Grub2 Password|GRUB Passwort einrichten]]
 
  
 
= Remotezugriff mit [[:Kategorie:SSH|SSH]] =
 
= Remotezugriff mit [[:Kategorie:SSH|SSH]] =
−
* Da man nicht immer physisch an einer Maschine anwesend sein kann, empfiehlt es sich Hosts über SSH zu steuern
+
*[[Remotezugriff mit - Linux - Security und Firewall Labor]]
−
* 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 =
 
= Router Firewall =
−
* Hardwareanpassungen, damit die Dienste später auch genug Ressourcen haben:
+
*[[Router Firewall - Linux - Security und Firewall Labor]]
−
** 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'' '''
 
−
<pre>
 
−
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
 
−
</pre>
 
−
 
 
−
* '''ifdown -va ; ifup -va'''
 
−
* bzw.
 
−
* '''systemctl restart networking'''
 
−
* Als Kontrolle kann man '''ip addr show''' ausführen
 
  
 
=Firewall=
 
=Firewall=
Zeile 67: Zeile 23:
 
*[[iptables firewall]]
 
*[[iptables firewall]]
  
−
== DHCP ==
+
= DHCP =
 
*[[DHCP Linux - Security und Firewall Labor]]
 
*[[DHCP Linux - Security und Firewall Labor]]
  
Zeile 74: Zeile 30:
  
 
= DNS für das Labor einrichten =
 
= DNS für das Labor einrichten =
−
{{#drawio:linux-sec-fire-02}}
+
*[[DNS für das Labor einrichten - Linux - Security und Firewall Labor]]
  
−
== 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=
 
 
*[[DNS Linux - Netzwerk und Serveradministration - Skript]]
 
*[[DNS Linux - Netzwerk und Serveradministration - Skript]]
−
==SFTP Server==
+
=SFTP Server=
 
*[[SFTP Server Linux - Security und Firewall Labor]]
 
*[[SFTP Server Linux - Security und Firewall Labor]]
  
 
=Strongswan IPSEC=
 
=Strongswan IPSEC=
 
*[[Strongswan IPSEC Linux - Security und Firewall Labor]]
 
*[[Strongswan IPSEC Linux - Security und Firewall Labor]]
−
 
+
=Wireguard=
 +
*[[Wireguard Server for Roadwarrior]]
  
 
= [[Openvpn Grundlagen|OpenVPN]] =
 
= [[Openvpn Grundlagen|OpenVPN]] =
 
*[[OpnVPN Linux - Security und Firewall Labor]]
 
*[[OpnVPN Linux - Security und Firewall Labor]]
 +
 +
=Crowdsec=
 +
*[[Crowdsec Grundsätzliches]]
 +
*[[Crowdsec Einordnung]]
 +
*[[Crowdsec Installation und Handling]]
 +
*[[Crowdsec SSH Bruteforce Beispiel]]
  
 
= Fail2ban für SSH/SFTP einrichten =
 
= Fail2ban für SSH/SFTP einrichten =
−
*'''apt install iptables fail2ban'''
+
*[[Fail2ban für SSH/SFTP einrichten]]
−
* Plan ist es den DNS Server als Angreifer auf den SFTP Server zu starten
 
−
* [[Fail2ban ssh]]
 
  
 
= [[Proxy Konzepte|Proxies]] =
 
= [[Proxy Konzepte|Proxies]] =
 
== SOCKS Proxy ==
 
== SOCKS Proxy ==
−
 
+
*[[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.lab1''xx''.sec
 
−
* '''curl --socks5 localhost:8080 www.lab1''xx''.sec
 
−
* Unterschiedliche IPs sollten unter ''/var/log/apache2/access.log'' zu sehen sein
 
  
 
== [[Squid ACL Basic|Squid als Standard Proxy]] ==
 
== [[Squid ACL Basic|Squid als Standard Proxy]] ==
Zeile 132: Zeile 77:
 
== [[Apparmor]] ==
 
== [[Apparmor]] ==
 
== [[SELinux]] ==
 
== [[SELinux]] ==
−
* Als Angriffsziel modifizieren wir den Apache2 Server: [[Command Injection Proof of Concept]]
+
*[[SELinux - Linux - Security und Firewall Labor]]
−
* 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 =
 
= HIDS =
−
 
+
*[[HIDS - Linux - Security und Firewall Labor]]
−
{{#drawio:linux-sec-fire-05}}
 
−
 
 
−
== [[Aide Konfiguration|AIDE]] ==
 
−
*[[Aide Linux - Security und Firewall Labor]]
 
−
 
 
−
== [[Tripwire]] ==
 
−
*[[Tripwire Linux - Security und Firewall Labor]]
 
  
 
= [[Was ist GSM|Greenbone]] Security/Vulnerability Manager (''Hacking & Security'' Seite 161) =
 
= [[Was ist GSM|Greenbone]] Security/Vulnerability Manager (''Hacking & Security'' Seite 161) =
−
 
+
*[[GSM Linux - Security und Firewall Labor]]
−
* 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 =
 
= Portscanning =
Zeile 187: Zeile 90:
  
 
= IP bei zuvielen Anfragen sperren =
 
= IP bei zuvielen Anfragen sperren =
−
 
+
*[[nftables 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
 
−
    }
 
−
    ...
 
−
}
 

Aktuelle Version vom 13. April 2025, 12:17 Uhr

Ziel

physischer Netzwerkplan

logischer Netzwerkplan

VM Vorlage

Hostzugriff absichern

Remotezugriff mit SSH

Router Firewall

Firewall

DHCP

Switch

DNS für das Labor einrichten

SFTP Server

Strongswan IPSEC

Wireguard

OpenVPN

Crowdsec

Fail2ban für SSH/SFTP einrichten

Proxies

SOCKS Proxy

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

HIDS

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

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

Abgerufen von „http://wiki.ixheim.de/index.php?title=Linux_-_Security_und_Firewall_Labor&oldid=61651“