Qual è lo scopo dei file / etc / shadow e shadow cache nel sistema operativo Linux?

Qual è lo scopo del file / etc / shadow nel sistema operativo Linux? Inoltre, è lo stesso per i client SUSE? Esiste un file di cache shadow che viene mantenuto a che scopo?

Fin dall'inizio, i sistemi operativi in ​​stile Unix e Unix (incluso Linux) hanno sempre archiviato le password come hash crittografici (1). Questi hash erano originariamente archiviati /etc/passwd, ma questo file doveva essere leggibile in tutto il mondo per rendere le informazioni disponibili per altri scopi - anche una semplice ls -lnecessità di leggere /etc/passwdper convertire l'id utente numerico di ciascun proprietario del file nel loro nome utente per la visualizzazione. Tuttavia, avere le password con hash in un file leggibile in tutto il mondo ha permesso agli utenti malintenzionati di ottenere facilmente quegli hash e di provare a generare password utilizzabili (2) per gli account di altri utenti.

Per evitare questo, le password hash sono stati poi spostati in un file leggibile solo da root (e, occasionalmente, un gruppo privilegiato di amministratori), /etc/shadow. Ciò nasconde gli hash dagli utenti normali del sistema mantenendoli disponibili a fini di autenticazione dell'utente.

Note :

1. Pedante, lo so, ma le password memorizzate non sono crittografate. Sono sottoposti a hash usando un algoritmo di hash crittograficamente sicuro (almeno dal momento in cui è stato scritto). Le principali distinzioni qui rilevanti sono che gli hash sono a lunghezza fissa (la lunghezza del testo crittografato varia in base alla lunghezza del testo che è stato crittografato) e non reversibile (il testo crittografato può essere decrittografato; il testo hash non può).

2. Poiché gli hash sono a lunghezza fissa, esiste un numero infinito di input che corrisponderanno a qualsiasi data rappresentazione hash. Un utente malintenzionato potrebbe pertanto trovare una password funzionante che non è necessariamente la stessa della password dell'utente proprietario, sebbene ciò sia molto improbabile, date le dimensioni dei moderni hash crittografici.

Il /etc/shadowfile è stato creato per motivi di sicurezza e contiene la password crittografata di ogni utente.

Inizialmente, la password crittografata era archiviata in /etc/passwd. /etc/passwddoveva essere leggibile dal mondo in modo che il sistema potesse mappare gli userid ai nomi degli utenti e che gli utenti potessero scoprire informazioni l'uno sull'altro, ad esempio la home directory dell'altro utente o il loro numero di telefono, tradizionalmente memorizzati nel campo "gecos" e visualizzato dall'utilità "dito".

Ma poi le persone hanno capito che questo era un problema di sicurezza. Chiunque abbia abbastanza tempo potrebbe fare quello che viene chiamato un attacco bruteforce , generando programmaticamente password crittografate per ogni possibile password. Se l'attaccante lo ha fatto senza effettivamente tentare di accedere tramite telneto ssh, il sistema non può sapere che è stato attaccato.

Quindi la password crittografata è stata spostata nella nuova creazione /etc/shadow, che è leggibile solo da root.

Contiene inoltre altre informazioni che il /etc/passwdfile non supportava relative all'account e alla password dell'utente, ad es. Quando la password è stata modificata l'ultima volta e quando scadrà.

Vedi man 5 shadow( versione web ) per tutti i dettagli sul formato del file.

Non posso dire se è lo stesso per SUSE, senza sapere con quale versione di SUSE hai a che fare. Ad esempio, il sistema SUSE può utilizzare Blowfish anziché MD5.

Hai anche insinuato che stavi mescolando il tuo /etc/shadowfile con un sistema che eseguiva una diversa distribuzione Linux, ma non hai detto quale fosse l'altra distribuzione.

Vedi ad esempio Problemi di migrazione del file shadow da SuSE 9.3 a Ubuntu Server x86_64 .

Per provare a capirlo, apri /etc/shadowe vedi se il campo della password crittografata inizia con $1$o $2$. Se contiene $1$, è MD5 e compatibile con la maggior parte delle altre distribuzioni. Se contiene $2$, probabilmente è Blowfish secondo i file shadow Blowfish su Debian .

Se stai usando Ubuntu, il primo risultato di ricerca di Google per Ubuntu Blowfish potrebbe essere un buon punto di partenza.

Gli utenti sono elencati nel /etc/passwdfile. Questo file contiene molte informazioni utilizzate da systemm non solo per consentire agli utenti di accedere.

Ogni riga corrisponde a una voce dell'utente e diversi campi sono separati da due punti. Il primo file è il login, è seguito dalla password corrispondente.

Le password crittografate erano archiviate in questo campo. Tuttavia, il /etc/passwdfile deve essere leggibile da tutti sul sistema, quindi la crittografia non impedisce attacchi di forza bruta, come è stato detto da @Mikel. La soluzione era quella di spostare le password cifrate in radice file di sola lettura: /etc/shadow.

Pertanto, /etc/shadowcontiene le password crittografate degli utenti del sistema. Il sistema sa che deve controllare le password in questo file quando i campi password /etc/passwdcontengono solo una x (che significa " attraversa a / etc / shadow")

Vediamo se riesco a ottenere tutti i voti positivi del mondo, da quando ho scritto quella che è diventata Linux Shadow Password Suite nel '87;)

Il /etc/passwdfile originale conteneva un hash modificato basato su DES della password in chiaro. Al momento della crypt()creazione della funzione, si riteneva (e questo è stato affermato dai creatori del sistema operativo UNIX) che gli attacchi contro l'hash della password sarebbero stati impossibili, a causa del numero di possibili password e dell'uso di un 12 bit (4.096 valori possibili) "sale". Ogni possibile password in chiaro aveva 4.096 possibili valori con hash e con 64 bit di risultato con hash, che ha dato un totale di 2 ^ 72 possibili hash di password.

Come menzionato da un altro poster, è /etc/passwdstato anche utilizzato da varie utility per mappare tra nomi utente e valori UID (il /etc/groupfile fornisce la funzione analoga per i gruppi) e ciò richiedeva che fosse leggibile in tutto il mondo.

Negli anni '80 divenne ovvio che gli attacchi del dizionario contro l'hash della password archiviato nel /etc/passwdfile stavano diventando fattibili e /etc/shadowfu introdotto in AT&T UNIX in una versione precedente di System V. Ho documentato quali manpage ho usato per scrivere la libreria Shadow originale, e io ' da allora dimenticato, ma era sicuramente una prima versione di System V, probabilmente SVR3.2.

Ciò che AT&T fece e ciò che implementai per SCO Xenix (l'originale SCO Xenix, non l'ultimo SCO Xenix malvagio) nel '87 che alla fine entrò in uso su Linux, fu semplicemente spostare la password con l'hash /etc/shadow. Ciò ha impedito l'attacco drive-by, in cui un utente non privilegiato ha acquisito una copia /etc/passwde ha eseguito un attacco contro di esso. Se hai familiarità con il motivo per cui ho scritto Shadow in primo luogo, ho avuto un utente che scaricava il mio /etc/passwdfile tramite UUCP nei giorni in cui usavamo ancora UUCP per quasi tutto.

Quando Linux è stato creato ed è diventato ampiamente diffuso, c'erano molti strumenti per attaccare gli hash delle password. Le implementazioni ad alte prestazioni di crypt()erano una strada, e gli attacchi basati su dizionario tramite strumenti come Crack e Libcrack erano altri. Il porto iniziale è stato fatto da Nate Holloway e Floria La Roche (ho dato loro credito, non so se qualcuno ha svolto il lavoro prima di loro).

Alla fine l'uso di crypt()hash basati su, anche in un file protetto, non era più sicuro e MD5sono state apportate modifiche all'hash basato su originali . MD5alla fine fu considerato troppo debole e furono usati hash più recenti.

In teoria, potrebbe essere archiviato un hash abbastanza forte /etc/passwd. Scarsa sicurezza operativa significa che molti sistemi hanno i loro /etc/shadowfile disponibili attraverso vari vettori di attacco: "Ho rubato i file di backup" è probabilmente il più semplice.