Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
chef-os-hardening — This chef cookbook fornisce numerose configurazioni relative alla sicurezza, offrendo una protezione di base a tutto tondo. | Kitploit
Strumenti/GitHubGitHub/dev-sec/chef-os-hardening
Sicurezza dell'Infrastruttura CloudAudit di ConfigurazioneDevSecOpsAutenticazione
GitHubdev-sec/chef-os-hardening

chef-os-hardening

This chef cookbook fornisce numerose configurazioni relative alla sicurezza, offrendo una protezione di base a tutto tondo.

Vedi Repository
45213261 mese faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Sito web
Condividi

os-hardening (Chef cookbook)

Supermarket Tests

Descrizione

Questo cookbook fornisce numerose configurazioni relative alla sicurezza, offrendo una protezione di base completa.

Configura:

  • Configura la gestione dei pacchetti, ad esempio consente solo pacchetti firmati
  • Rimuove i pacchetti con problemi noti
  • Configura il modulo pam e pam_limits
  • Configurazione della suite shadow password
  • Configura i permessi dei percorsi di sistema
  • Disabilita i core dump tramite limiti soft
  • Limita i login di Root alla console di sistema
  • Imposta i SUID
  • Configura i parametri del kernel tramite sysctl

Non:

  • Aggiorna i pacchetti di sistema
  • Installa le patch di sicurezza

Requisiti

  • Chef >= 14.13.11

Piattaforma

  • 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

Attributi

  • ['os-hardening']['components'][COMPONENT_NAME] - consente il controllo preciso su quali componenti devono essere eseguiti tramite la ricetta predefinita. Vedi sotto per maggiori dettagli
  • ['os-hardening']['desktop']['enable'] = false true se questo è un sistema desktop, ad esempio Xorg, KDE/GNOME/Unity/etc
  • ['os-hardening']['network']['forwarding'] = false true se questo sistema richiede l'inoltro dei pacchetti (ad esempio Router), false altrimenti
  • ['os-hardening']['network']['ipv6']['enable'] = false
  • ['os-hardening']['network']['arp']['restricted'] = true true se si desidera che il comportamento di annuncio e risposta ad ARP sia limitato, false altrimenti
  • ['os-hardening']['env']['extra_user_paths'] = [] aggiungi percorsi aggiuntivi alla variabile PATH dell'utente (il valore predefinito è vuoto).
  • ['os-hardening']['env']['umask'] = "027"
  • ['os-hardening']['env']['root_path'] = "/" dove è montata la root
  • ['os-hardening']['auth']['pw_max_age'] = 60 età massima della password
  • ['os-hardening']['auth']['pw_min_age'] = 7 età minima della password (prima di consentire qualsiasi altra modifica della password)
  • ['os-hardening']['auth']['pw_warn_age'] = 7 numero di giorni prima del raggiungimento dell'età massima della password per avvisare dell'imminente modifica
  • ['os-hardening']['auth']['uid_min'] = 1000 limite inferiore degli UID assegnati da useradd
  • ['os-hardening']['auth']['uid_max'] = 60000 limite superiore degli UID assegnati da useradd
  • ['os-hardening']['auth']['gid_min'] = 1000 limite inferiore dei GID assegnati da groupadd
  • ['os-hardening']['auth']['gid_max'] = 60000 limite superiore dei GID assegnati da groupadd
  • ['os-hardening']['auth']['retries'] = 5 il numero massimo di tentativi di autenticazione, prima che l'account venga bloccato per un certo periodo
  • ['os-hardening']['auth']['lockout_time'] = 600 tempo in secondi che deve trascorrere, se l'account è stato bloccato a causa di troppi tentativi di autenticazione falliti
  • ['os-hardening']['auth']['timeout'] = 60 timeout di autenticazione in secondi, quindi il login terminerà se questo tempo trascorre
  • ['os-hardening']['auth']['allow_homeless'] = false true se si desidera consentire l'accesso agli utenti senza home
  • ['os-hardening']['auth']['pam']['passwdqc']['enable'] = true true se si desidera utilizzare un controllo password forte in PAM utilizzando passwdqc
  • ['os-hardening']['auth']['pam']['passwdqc']['options'] = "min=disabled,disabled,16,12,8" impostare su qualsiasi riga di opzioni (come stringa) che si desidera passare a passwdqc
  • ['os-hardening']['auth']['pam']['passwdqc']['template_cookbook'] = 'os-hardening' impostare sul nome del cookbook da cui viene ottenuto il template per il file /usr/share/pam-configs/passwdqc
  • ['os-hardening']['auth']['pam']['tally2']['template_cookbook'] = 'os-hardening' impostare sul nome del cookbook da cui viene ottenuto il template per il file /usr/share/pam-configs/tally2
  • ['os-hardening']['auth']['pam']['system-auth']['template_cookbook'] = 'os-hardening' impostare sul nome del cookbook da cui viene ottenuto il template per il file /etc/pam.d/system-auth-ac
  • ['os-hardening']['security']['users']['allow'] = [] elenco di cose che un utente può fare. Può contenere: change_user
  • ['os-hardening']['security']['kernel']['enable_module_loading'] = true true se si desidera poter modificare i moduli del kernel una volta che il sistema è in esecuzione (ad esempio modprobe, rmmod)
  • ['os-hardening']['security']['kernel']['disable_filesystems'] = ['cramfs', 'freevxfs', 'jffs2', 'hfs', 'hfsplus', 'squashfs', 'udf', 'vfat'] elenco di moduli del file system del kernel che sono nella blacklist per il caricamento (ad esempio non sono utilizzati e possono essere disabilitati). Impostare su [] per evitare completamente questa blacklist
  • ['os-hardening']['security']['kernel']['enable_sysrq'] = false
  • ['os-hardening']['security']['kernel']['enable_core_dump'] = false
  • ['os-hardening']['security']['suid_sgid']['enforce'] = true true se si desidera ridurre i bit SUID/SGID. Esiste già un elenco di elementi configurati che vengono cercati, ma è possibile aggiungere anche i propri
  • ['os-hardening']['security']['suid_sgid']['blacklist'] = [] un elenco di percorsi a cui devono essere rimossi i bit SUID/SGID
  • ['os-hardening']['security']['suid_sgid']['whitelist'] = [] un elenco di percorsi i cui bit SUID/SGID non devono essere modificati
  • ['os-hardening']['security']['suid_sgid']['remove_from_unknown'] = false true se si desidera rimuovere i bit SUID/SGID da qualsiasi file che non sia esplicitamente configurato in una blacklist. Questo farà sì che ogni esecuzione di Chef cerchi nei file system montati i bit SUID/SGID che non sono configurati nella blacklist predefinita e in quella dell'utente. Se trova un bit SUID/SGID, verrà rimosso, a meno che questo file non sia nella whitelist.
  • ['os-hardening']['security']['suid_sgid']['dry_run_on_unknown'] = false come remove_from_unknown sopra, solo che i bit SUID/SGID non vengono rimossi. Verrà comunque eseguita una ricerca nei file system per individuare i bit SUID/SGID, ma verranno solo stampati nel log. Questa opzione è consigliata solo quando si configura per la prima volta remove_from_unknown per i bit SUID/SGID, in modo da poter vedere i file che vengono modificati e apportare modifiche alla whitelist e alla blacklist.
  • ['os-hardening']['security']['packages']['clean'] = true rimuove i pacchetti con problemi noti.
  • ['os-hardening']['security']['packages']['list'] = ['xinetd','inetd','ypserv','telnet-server','rsh-server'] elenco di pacchetti da rimuovere, per impostazione predefinita rimuoviamo i seguenti pacchetti:
    • xinetd (NSA, Capitolo 3.2.1)
    • inetd (NSA, Capitolo 3.2.1)
    • tftp-server (NSA, Capitolo 3.2.5)
    • ypserv (NSA, Capitolo 3.2.4)
    • telnet-server (NSA, Capitolo 3.2.2)
    • rsh-server (NSA, Capitolo 3.2.3)
  • ['os-hardening']['security']['selinux_mode'] = 'unmanaged' impostare su unmanaged se si desidera lasciare la configurazione selinux così com'è. Impostare su enforcing per applicarla o permissive per SELinux permissivo.

Controllo dei componenti inclusi

default.rb include altri componenti in base agli attributi di autodetect ohai del sistema. Ad esempio, non esegue selinux su sistemi non RHEL. È possibile sovrascrivere questo comportamento e forzare l'esecuzione o meno dei componenti impostando gli attributi in node['os-hardening']['components'] a livello di override. Esempio

root@kitploit:~
# qualche file di attributi
# non includere sysctl e auditd
override['os-hardening']['components']['sysctl'] = false
override['os-hardening']['components']['auditd'] = false

# forza l'inclusione di selinux
override['os-hardening']['components']['selinux'] = true

Nell'implementazione attuale i diversi componenti si trovano nelle diverse ricette. Vedi le ricette disponibili o default.rb per i possibili nomi dei componenti.

Utilizzo

Aggiungi le ricette alla run_list, dovrebbe essere l'ultima:

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

Configura gli attributi:

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

Test locali

Test locali

Si prega di installare chef-dk, VirtualBox o VMware Workstation e Vagrant.

Il linting viene verificato con rubocop e foodcritic:

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

I test unit/spec vengono eseguiti con chefspec:

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

I test di integrazione vengono eseguiti con test-kitchen e inspec:

root@kitploit:~
$ chef exec rake kitchen
.....
# oppure puoi usare direttamente kitchen
$ kitchen test

Test CI dei fork

Puoi abilitare il test del tuo fork in Travis CI. Per impostazione predefinita otterrai linting, test spec e test di integrazione con kitchen-dokken.

I test di integrazione con kitchen-dokken non coprono tutto poiché vengono eseguiti nell'ambiente container. I test di integrazione completi possono essere eseguiti utilizzando DigitalOcean.

Se desideri avere test di integrazione completi per il tuo fork, dovrai aggiungere le seguenti variabili d'ambiente nelle impostazioni del tuo fork:

  • DIGITALOCEAN_ACCESS_TOKEN - token di accesso per DigitalOcean
  • CI_SSH_KEY - parte privata di una chiave ssh, disponibile su DigitalOcean per le tue istanze, in forma codificata base64 (ad esempio cat id_rsa | base64 -w0 ; echo)
  • DIGITALOCEAN_SSH_KEY_IDS - ID in DigitalOcean di CI_SSH_KEY, vedi questo per maggiori informazioni

Collaboratori + Ringraziamenti

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

Questo cookbook si basa principalmente su guide di:

  • 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 (Tedesco)

Grazie a tutti voi!!

Contribuire

Vedi linee guida per i contributori.

Licenza e Autore

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

Concesso in licenza secondo la Apache License, Versione 2.0 (la "Licenza"); non è possibile utilizzare questo file se non in conformità con la Licenza. È possibile ottenere una copia della Licenza all'indirizzo

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

Salvo quanto richiesto dalla legge applicabile o concordato per iscritto, il software distribuito secondo la Licenza è distribuito su base "COSÌ COM'È", SENZA GARANZIE O CONDIZIONI DI ALCUN TIPO, esplicite o implicite. Vedere la Licenza per il linguaggio specifico che disciplina i permessi e le limitazioni previste dalla Licenza.

Scarica lo strumento