Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
chef-os-hardening — Dieses Chef-Cookbook bietet zahlreiche sicherheitsbezogene Konfigurationen und sorgt für einen umfassenden Basisschutz. | Kitploit
Tools/GitHubGitHub/dev-sec/chef-os-hardening
Cloud-Infrastruktur-SicherheitKonfigurationsprüfungDevSecOpsAuthentifizierung
GitHubdev-sec/chef-os-hardening

chef-os-hardening

Dieses Chef-Cookbook bietet zahlreiche sicherheitsbezogene Konfigurationen und sorgt für einen umfassenden Basisschutz.

Repository anzeigen
4521326vor 1 MonatVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Webseite
Teilen

os-hardening (Chef-Cookbook)

Supermarket Tests

Beschreibung

Diese Cookbook bietet zahlreiche sicherheitsrelevante Konfigurationen und sorgt für einen umfassenden Basisschutz.

Es konfiguriert:

  • Konfiguriert die Paketverwaltung, z. B. erlaubt nur signierte Pakete
  • Entfernt Pakete mit bekannten Problemen
  • Konfiguriert das pam- und pam_limits-Modul
  • Konfiguration der Shadow-Passwort-Suite
  • Konfiguriert Systempfad-Berechtigungen
  • Deaktiviert Core-Dumps über Soft-Limits
  • Beschränkt Root-Logins auf die Systemkonsole
  • Setzt SUIDs
  • Konfiguriert Kernel-Parameter über sysctl

Es wird nicht:

  • Systempakete aktualisieren
  • Sicherheitspatches installieren

Anforderungen

  • Chef >= 14.13.11

Plattform

  • Ubuntu 20.04, 22.04, 24.04, 26.04
  • CentOS Stream 9, 10
  • AlmaLinux 8, 9, 10
  • Rocky Linux 8, 9, 10
  • Oracle Linux 8, 9, 10
  • Debian 13
  • Fedora 43, 44

Attribute

  • ['os-hardening']['components'][COMPONENT_NAME] - ermöglicht die feingranulare Steuerung darüber, welche Komponenten über das Standard-Rezept ausgeführt werden sollen. Weitere Details siehe unten
  • ['os-hardening']['desktop']['enable'] = false true, wenn es sich um ein Desktop-System handelt, d. h. Xorg, KDE/GNOME/Unity/etc
  • ['os-hardening']['network']['forwarding'] = false true, wenn dieses System Paketweiterleitung benötigt (z. B. Router), andernfalls false
  • ['os-hardening']['network']['ipv6']['enable'] = false
  • ['os-hardening']['network']['arp']['restricted'] = true true, wenn das Verhalten des Ankündigens und Antwortens auf ARP eingeschränkt werden soll, andernfalls false
  • ['os-hardening']['env']['extra_user_paths'] = [] fügt zusätzliche Pfade zur PATH-Variable des Benutzers hinzu (Standard ist leer).
  • ['os-hardening']['env']['umask'] = "027"
  • ['os-hardening']['env']['root_path'] = "/" wo root eingehängt ist
  • ['os-hardening']['auth']['pw_max_age'] = 60 maximales Passwortalter
  • ['os-hardening']['auth']['pw_min_age'] = 7 minimales Passwortalter (bevor eine andere Passwortänderung erlaubt wird)
  • ['os-hardening']['auth']['pw_warn_age'] = 7 Anzahl der Tage vor Erreichen des maximalen Passwortalters, an denen vor der bevorstehenden Änderung gewarnt wird
  • ['os-hardening']['auth']['uid_min'] = 1000 untere Grenze der UIDs, die von useradd vergeben werden
  • ['os-hardening']['auth']['uid_max'] = 60000 obere Grenze der UIDs, die von useradd vergeben werden
  • ['os-hardening']['auth']['gid_min'] = 1000 untere Grenze der GIDs, die von groupadd vergeben werden
  • ['os-hardening']['auth']['gid_max'] = 60000 obere Grenze der GIDs, die von groupadd vergeben werden
  • ['os-hardening']['auth']['retries'] = 5 die maximale Anzahl von Authentifizierungsversuchen, bevor das Konto für einige Zeit gesperrt wird
  • ['os-hardening']['auth']['lockout_time'] = 600 Zeit in Sekunden, die vergehen muss, wenn das Konto aufgrund zu vieler fehlgeschlagener Authentifizierungsversuche gesperrt wurde
  • ['os-hardening']['auth']['timeout'] = 60 Authentifizierungs-Timeout in Sekunden, sodass die Anmeldung beendet wird, wenn diese Zeit überschritten wird
  • ['os-hardening']['auth']['allow_homeless'] = false true, um Benutzern ohne Home-Verzeichnis die Anmeldung zu erlauben
  • ['os-hardening']['auth']['pam']['passwdqc']['enable'] = true true, wenn Sie eine starke Passwortprüfung in PAM mit passwdqc verwenden möchten
  • ['os-hardening']['auth']['pam']['passwdqc']['options'] = "min=disabled,disabled,16,12,8" auf eine beliebige Optionszeile (als Zeichenkette) setzen, die Sie an passwdqc übergeben möchten
  • ['os-hardening']['auth']['pam']['passwdqc']['template_cookbook'] = 'os-hardening' auf den Namen der Cookbook setzen, aus der die Vorlage für die Datei /usr/share/pam-configs/passwdqc bezogen wird
  • ['os-hardening']['auth']['pam']['tally2']['template_cookbook'] = 'os-hardening' auf den Namen der Cookbook setzen, aus der die Vorlage für die Datei /usr/share/pam-configs/tally2 bezogen wird
  • ['os-hardening']['auth']['pam']['system-auth']['template_cookbook'] = 'os-hardening' auf den Namen der Cookbook setzen, aus der die Vorlage für die Datei /etc/pam.d/system-auth-ac bezogen wird
  • ['os-hardening']['security']['users']['allow'] = [] Liste der Dinge, die einem Benutzer erlaubt sind. Kann enthalten: change_user
  • ['os-hardening']['security']['kernel']['enable_module_loading'] = true true, wenn Sie Kernelmodule ändern dürfen möchten, sobald das System läuft (z. B. modprobe, rmmod)
  • ['os-hardening']['security']['kernel']['disable_filesystems'] = ['cramfs', 'freevxfs', 'jffs2', 'hfs', 'hfsplus', 'squashfs', 'udf', 'vfat'] Liste der Kernel-Dateisystemmodule, die für das Laden auf die Blacklist gesetzt werden (z. B. sind sie ungenutzt und können deaktiviert werden). Setzen Sie dies auf [], um diese Blacklist vollständig zu vermeiden
  • ['os-hardening']['security']['kernel']['enable_sysrq'] = false
  • ['os-hardening']['security']['kernel']['enable_core_dump'] = false
  • ['os-hardening']['security']['suid_sgid']['enforce'] = true true, wenn Sie SUID/SGID-Bits reduzieren möchten. Es gibt bereits eine Liste von Elementen, nach denen gesucht wird, aber Sie können auch eigene hinzufügen
  • ['os-hardening']['security']['suid_sgid']['blacklist'] = [] eine Liste von Pfaden, deren SUID/SGID-Bits entfernt werden sollen
  • ['os-hardening']['security']['suid_sgid']['whitelist'] = [] eine Liste von Pfaden, deren SUID/SGID-Bits nicht verändert werden sollen
  • ['os-hardening']['security']['suid_sgid']['remove_from_unknown'] = false true, wenn Sie SUID/SGID-Bits von jeder Datei entfernen möchten, die nicht explizit in einer blacklist konfiguriert ist. Dadurch wird jeder Chef-Lauf die eingehängten Dateisysteme nach SUID/SGID-Bits durchsuchen, die nicht in der Standard- und Benutzer-Blacklist konfiguriert sind. Wenn ein SUID/SGID-Bit gefunden wird, wird es entfernt, sofern sich diese Datei nicht in Ihrer whitelist befindet.
  • ['os-hardening']['security']['suid_sgid']['dry_run_on_unknown'] = false wie remove_from_unknown oben, nur dass SUID/SGID-Bits nicht entfernt werden. Es durchsucht weiterhin die Dateisysteme nach SUID/SGID-Bits, gibt sie aber nur in Ihrem Log aus. Diese Option wird nur empfohlen, wenn Sie remove_from_unknown für SUID/SGID-Bits zum ersten Mal konfigurieren, damit Sie die Dateien sehen können, die geändert werden, und Anpassungen an Ihrer whitelist und blacklist vornehmen können.
  • ['os-hardening']['security']['packages']['clean'] = true entfernt Pakete mit bekannten Problemen.
  • ['os-hardening']['security']['packages']['list'] = ['xinetd','inetd','ypserv','telnet-server','rsh-server'] Liste der zu entfernenden Pakete, standardmäßig entfernen wir die folgenden Pakete:
    • xinetd (NSA, Kapitel 3.2.1)
    • inetd (NSA, Kapitel 3.2.1)
    • tftp-server (NSA, Kapitel 3.2.5)
    • ypserv (NSA, Kapitel 3.2.4)
    • telnet-server (NSA, Kapitel 3.2.2)
    • rsh-server (NSA, Kapitel 3.2.3)
  • ['os-hardening']['security']['selinux_mode'] = 'unmanaged' auf unmanaged setzen, wenn die SELinux-Konfiguration unverändert bleiben soll. Auf enforcing setzen, um zu erzwingen, oder auf permissive für permissives SELinux.

Steuerung der enthaltenen Komponenten

default.rb bindet andere Komponenten basierend auf den ohai-Autoerkennungsattributen Ihres Systems ein. Z. B. wird SELinux auf Nicht-RHEL-Systemen nicht ausgeführt. Sie können dieses Verhalten überschreiben und Komponenten zur Ausführung erzwingen oder verhindern, indem Sie Attribute in node['os-hardening']['components'] auf der Override-Ebene setzen. Beispiel

root@kitploit:~
# einige Attributdatei
# sysctl und auditd nicht einbeziehen
override['os-hardening']['components']['sysctl'] = false
override['os-hardening']['components']['auditd'] = false

# selinux zur Einbindung erzwingen
override['os-hardening']['components']['selinux'] = true

In der aktuellen Implementierung befinden sich verschiedene Komponenten in den verschiedenen Rezepten. Siehe die verfügbaren Rezepte oder default.rb für mögliche Komponentennamen.

Verwendung

Fügen Sie die Rezepte zur run_list hinzu, es sollte zuletzt stehen:

root@kitploit:~
"recipe[os-hardening]"

Attribute konfigurieren:

root@kitploit:~
"security" : {
  "kernel" : {
    "enable_module_loading" : true
  }
},

Lokales Testen

Lokales Testen

Bitte installieren Sie chef-dk, VirtualBox oder VMware Workstation und Vagrant.

Linting wird mit rubocop und foodcritic geprüft:

root@kitploit:~
$ chef exec rake lint
.....

Unit-/Spec-Tests werden mit chefspec durchgeführt:

root@kitploit:~
$ chef exec rake spec
.....

Integrationstests werden mit test-kitchen und inspec durchgeführt:

root@kitploit:~
$ chef exec rake kitchen
.....
# oder Sie können kitchen direkt verwenden
$ kitchen test

CI-Testen von Forks

Sie können das Testen Ihres Forks in Travis CI aktivieren. Standardmäßig erhalten Sie Linting, Spec-Tests und Integrationstests mit kitchen-dokken.

Integrationstests mit kitchen-dokken decken nicht alles ab, da sie in der Container-Umgebung ausgeführt werden. Vollständige Integrationstests können mit DigitalOcean ausgeführt werden.

Wenn Sie vollständige Integrationstests für Ihren Fork wünschen, müssen Sie die folgenden Umgebungsvariablen in den Einstellungen Ihres Forks hinzufügen:

  • DIGITALOCEAN_ACCESS_TOKEN - Zugriffstoken für DigitalOcean
  • CI_SSH_KEY - privater Teil eines SSH-Schlüssels, der auf DigitalOcean für Ihre Instanzen verfügbar ist, in base64-codierter Form (z. B. cat id_rsa | base64 -w0 ; echo)
  • DIGITALOCEAN_SSH_KEY_IDS - ID in DigitalOcean von CI_SSH_KEY, siehe dies für weitere Informationen

Mitwirkende + Danksagung

  • Dominik Richter arlimus
  • Bernhard Weisshuhn bkw
  • Christoph Hartmann chris-rock
  • Edmund Haselwanter ehaselwanter
  • Patrick Meier atomic111
  • Artem Sidorenko artem-sidorenko

Diese Cookbook basiert größtenteils auf Anleitungen von:

  • Arch Linux wiki, Sysctl hardening
  • Ubuntu Security/Features
  • NSA: Guide to the Secure Configuration of Red Hat Enterprise Linux 5
  • Deutsche Telekom, Group IT Security, Security Requirements (German)

Vielen Dank an alle!!

Mitwirken

Siehe Mitwirkungsrichtlinie.

Lizenz und Autor

  • Autor:: Dominik Richter [email protected]
  • Autor:: Deutsche Telekom AG

Lizenziert unter der Apache License, Version 2.0 (die "Lizenz"); Sie dürfen diese Datei nur in Übereinstimmung mit der Lizenz verwenden. Eine Kopie der Lizenz erhalten Sie unter

root@kitploit:~
http://www.apache.org/licenses/LICENSE-2.0

Sofern nicht durch geltendes Recht vorgeschrieben oder schriftlich vereinbart, wird die unter der Lizenz verteilte Software auf einer "WIE BESEHEN"-Basis verteilt, OHNE GEWÄHRLEISTUNGEN ODER BEDINGUNGEN JEGLICHER ART, weder ausdrücklich noch stillschweigend. Siehe die Lizenz für die spezifischen Berechtigungen und Einschränkungen unter der Lizenz.

Tool herunterladen