|
|
| (14 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 8: |
Zeile 8: |
| {{#drawio:linux-sec-fire-00.1}} | | {{#drawio:linux-sec-fire-00.1}} |
|
| |
|
| = Servervorlage = | | = VM Vorlage = |
| * Für VMs als Server empfiehlt es sich eine Vorlage zu erstellen, die schon minimal konfiguriert ist | | *[[VM Vorlage Linux - Security und Firewall Labor]] |
| * Der Nutzer ''root'' soll das Passwort ''radler'' haben
| |
| * Ein Benutzer ''kit'' mit dem Passwort ''kit'' soll angelegt werden
| |
| * die Vorlage soll '''keine''' graphische Oberfläche haben (Bei der Installation abwählen)
| |
| * Ein [[:Kategorie:SSH|SSH]]-Server soll aber für die Remoteverwaltung installiert werden
| |
| ==Umsetzung==
| |
| * [[Debian Template]]
| |
| * [[Anpassen der Virtuellen Maschinen Netzwerk und Serveradministration]]
| |
|
| |
|
| = 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 73: |
Zeile 23: |
| *[[iptables firewall]] | | *[[iptables firewall]] |
|
| |
|
| == DHCP ==
| | = DHCP = |
| *[[DHCP Linux - Security und Firewall Labor]] | | *[[DHCP Linux - Security und Firewall Labor]] |
|
| |
|
| Zeile 80: |
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]] |
|
| |
|
| Zeile 111: |
Zeile 51: |
|
| |
|
| = 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 145: |
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 200: |
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
| |
| }
| |
| ...
| |
| }
| |
