Quanto è sicuro NOPASSWD in modalità sudo senza password?

NOPASSWD non ha un impatto significativo sulla sicurezza. Il suo effetto più ovvio è quello di fornire protezione quando l'utente lascia la propria workstation incustodita: un utente malintenzionato con accesso fisico alla propria workstation può quindi estrarre dati, eseguire azioni e installare malware con le autorizzazioni dell'utente, ma non elevare il proprio accesso a root. Questa protezione è di uso limitato perché l'utente malintenzionato può installare un programma di tipo keylogger che registra la password dell'utente al successivo inserimento in un prompt sudo o in uno screensaver.

Tuttavia, richiedendo la password si alza la barra per l'attaccante. In molti casi, la protezione da aggressori non sofisticati è utile, in particolare negli scenari di workstation non presidiate in cui l'attacco è spesso un'opportunità e l'utente malintenzionato potrebbe non sapere come trovare e configurare malware discreto con breve preavviso. Inoltre è più difficile nascondere il malware quando non hai i permessi di root - non puoi nasconderlo da root se non hai root.

Ci sono alcuni scenari realistici in cui la mancanza di una password protegge anche contro attaccanti sofisticati. Ad esempio, un laptop rubato: il laptop dell'utente viene rubato, completo di chiavi SSH private; o il ladro riesce a indovinare la password per il file chiave (magari con la forza bruta), o ottiene l'accesso ad essi da un dump della memoria di un agente chiave. Se viene rilevato il furto, questo è un segnale per indagare sulle attività recenti sull'account dell'utente, e questo significa che deve essere rilevato un malware piantato. Se l'utente malintenzionato aveva solo l'accesso a livello utente, qualsiasi cosa avesse fatto lascerebbe tracce nei log; se l'utente malintenzionato ha ottenuto la password dell'utente e ha eseguito sudo, tutti i log sono ora compromessi.

Non so se i lati negativi di NOPASSWD bilanciano i lati positivi per il tuo caso d'uso. Devi bilanciarlo contro tutti gli altri fattori della tua situazione. Ad esempio, sembra che tu permetti ma non imponga di avere password diverse. Puoi invece utilizzare un database di account centralizzato? Di quanto contenimento hai bisogno tra i tuoi sistemi? State considerando alternative ad Ansible che supporterebbero diverse password sudo? Hai preso in considerazione altri meccanismi di autenticazione?

Ci sono due casi specifici per cui non vuoi sudo senza password:

1. Questo è un meccanismo di difesa contro utenti malintenzionati che hanno accesso a un account amministrativo. Questo può essere dovuto allo sfruttamento o a un amministratore che lascia la sua workstation incustodita senza bloccare la sessione.
2. Dovendo ri-emettere la password quando si utilizza sudo, gli utenti impulsivi hanno il tempo di pensarci due volte prima di eseguire effettivamente l'azione.

Informazioni sull'automazione:

Sono d'accordo che puoi farlo senza password, ma non richiedendo la password sudo stai dando TUTTO l'accesso al tuo strumento di automazione. Ora pensa a cosa è effettivamente richiesto lo strumento? Ha davvero bisogno di tutti questi accessi? Probabilmente no.

Sudo ha una bella funzionalità che ti permette di configurare comandi specifici con il flag NOPASSWD all'interno del file sudoers:

username myhost = (root) NOPASSWD: /sbin/shutdown
username myhost = (root) NOPASSWD: /sbin/reboot

Given the facts ssh is done via keys, keys are password protected and all user accounts have passwords (so su bob is impossible without a password)

Siamo chiari qui. Le password utilizzate per proteggere le chiavi SSH e le password degli account utente NON SONO GLI STESSI .

NOPASSWD consente semplicemente all'utente di eseguire comandi come un altro utente senza inserire la sua password. Non influisce sul fatto che l'utente deve inserire la sua password quando SSH-ing nel sistema.

Ansible può usare varie cose per l'automazione: come sudo con una password sudo, o NOPASSWD. Oppure usa su, suexec, doas o altro.

Oggi parliamo di:

become: yes
become_user:root
become_method: sudo

Ricorda che idealmente dovrebbe essere usato per l'automazione (infra come codice), non per l'uso interattivo. Gli utenti umani potrebbero comunque utilizzare le password, incidentalmente potrebbero incappare in politiche di scadenza.

Ansible Tower e AWX possono memorizzare tutti i tipi di credenziali crittografate e delegare il loro uso per lavori specifici, senza perdite di chiavi o password.

Un'alternativa è l'uso di chiavi ssh temporanee (firmate). Hashicorp Vault può gestire quelli

Ci sono pro e contro nell'avere l'utente a inserire una password per accedere a sudo.

Pro: migliore protezione se qualcuno ottiene l'accesso a un account amministratore. ad esempio attraverso un terminale sbloccato o qualche tipo di exploit.

Con: l'utente sta inserendo una password in testo semplice che viene criptata in transito, ma poi decifrata prima che raggiunga la shell dell'utente. Ad esempio, qualcuno potrebbe manomettere lo script bashrc per eseguire un keylogger. A seconda della configurazione e delle abitudini degli utenti che potrebbero consentire l'uso della password per l'accesso diretto all'account utente su questa macchina e forse anche su altre macchine. Le persone riutilizzano le password troppo spesso.