Rinomina / etc / passwd e / etc / shadow per motivi di sicurezza [chiuso]

Ho un server Il mio server è sicuro, ma immaginiamo un buon hacker che entri. Ora può esaminare /etc/passwde /etc/shadow. Vorrei rinominare quei file /etc/passwdin qualcosa del genere /etc/xxanoda.

Pensavo di poter fare un collegamento, ma per un hacker sarà facile farlo ls -l.

È possibile rinominare quei file e avere ancora un sistema operativo in esecuzione, senza problemi di compatibilità, o è completamente inutile? Solo per la ricerca della conoscenza.

Lo standard di gerarchia dei filesystem per i sistemi unix-like include /etc/passwdin una posizione fissa e, di conseguenza, gli strumenti sono normalmente codificati per cercarlo. Mentre in teoria è possibile ricompilare tutte le utilità pertinenti per cercare in una nuova posizione, qualsiasi utente malintenzionato può sempre cercare stringhe in quei file binari per individuare il nuovo file o utilizzare espressioni regolari per trovare file con passwdcontenuti simili.

Il shadowfile dovrebbe essere leggibile solo da root(e possibilmente da un gruppo chiamato shadow). Se un utente malintenzionato è riuscito a ottenere l'accesso root al sistema, ha il controllo completo e se è in grado di leggere i file passwd / shadow è piuttosto irrilevante a quel punto.

Esistono alcune situazioni in cui è possibile che i file non presenti nei luoghi previsti possano essere utili, ad esempio se si dispone di un server Web configurato in modo errato che consente a qualcuno di richiederlo http://myserver/../../etc/passwd, ma in generale questo tipo di indiretta richiederà molto lavoro per un vantaggio minimo in termini di sicurezza.

La cosa migliore che sarebbe sarebbe "completamente inutile" come dici tu. (Non fornisce un ostacolo aggiuntivo per un intruso)

/etc/passwd contiene nomi di account, ma chiunque abbia accesso shell al sistema sarà in grado di trovarli.

/etc/shadowcontiene informazioni riservate (hash della password) ma è leggibile solo per root. Se un intruso è riuscito a ottenere i privilegi di root, come si scrive il disastro ?

Nei moderni Unices (e simili a Unix, incluso Ubuntu), /etc/passwdnon contiene segreti. Rinominare ciò comporterebbe più problemi di quanti ne valga la pena, dato il numero di utilità da ricostruire per cercarlo nella nuova posizione.

/etc/shadowè un'altra questione, poiché ci sono segreti in quel file, ma rinominarlo non sarà di aiuto. È leggibile solo da root, quindi anche se un hacker entra nel sistema come un altro utente, non è sufficiente per accedere al file. Questo è il motivo per cui le password sono state rimosse /etc/passwdin primo luogo: tutti devono essere in grado di leggere /etc/passwd, ma solo root deve essere in grado di ottenere le password effettive, quindi le password sono state spostate in un file che solo root poteva leggere.

Se l'hacker non avere radici, poi una ridenominazione non ti salva. Un semplice ricorsivo greppotrebbe fornire all'hacker un elenco di file in un /etc/shadowformato simile, e quindi l'hacker deve solo esaminarli per trovare i dati che desidera. Lo hai ritardato di alcune ore al massimo, e probabilmente meno: ancora una volta, non vale la pena il tempo necessario per modificare e ricompilare tutte le utility che dipendono dalla /etc/shadowposizione.

Non puoi semplicemente rinominare questi file. Molti processi e programmi li cercheranno, poiché questo è uno standard nei sistemi Linux. Quello che puoi fare è proteggere il tuo server nel modo corretto.

Sebbene sia probabilmente inutile rinominare i file /etc/passwde /etc/shadow, se si desidera maggiore sicurezza, è possibile esaminare PAM (moduli di autenticazione collegabili) e NSS (Name Service Switch). Come qui.

PAM può essere utilizzato per aggiungere moduli di autenticazione che, invece di leggere la loro anomalia di autenticazione dai file standard, la leggono da un'altra fonte, come da LDAP o da un database. Usarlo significherebbe che /etc/shadowpuò essere quasi completamente eliminato.

NSS integra PAM rendendo parte della risoluzione dei nomi (come i gruppi a cui appartiene questo utente) indipendente dai file standard ( /etc/passwd, /etc/groups). Usarlo significherebbe che il tuo file passwd conterrà potenzialmente solo un'opzione di fallback per root e nient'altro. L'uso delle chiavi SSH per convalidare l'accesso root eliminerebbe anche la necessità di avere una password di root all'interno del file shadow (anche se potrebbe essere desiderato se la connessione SSH si interrompe).

In alternativa, se non desideri autenticare i tuoi utenti tramite un database separato o un host ldap, puoi anche creare i tuoi moduli PAM e NSS, che leggono i loro dati da un file non standard, anche se non consiglierei questa opzione.

Quando vuoi provare a usarli, non dimenticare di mantenere una sorta di fallback su un livello di autenticazione noto e funzionante, altrimenti puoi bloccarti fuori dal sistema, anche con root.

Nota che non tutte le applicazioni supportano PAM (molte di esse lo fanno comunque). Tuttavia, NSS può essere utilizzato per implementare l'autenticazione per le app che non supportano PAM e alcuni siti che ho letto su NSS suggeriscono effettivamente questo approccio. Ciò significa tuttavia che il modulo NSS fornirà la password (potenzialmente) con hash a chiunque possa accedere al livello di autenticazione NSS, che è quasi sempre qualcosa che si desidera evitare (è praticamente lo stesso che dare accesso in lettura non root al file shadow )! Quindi, se segui questo approccio, assicurati sempre che NSS sia usato solo per fornire all'utente i dati di base (come il contenuto di /etc/passwd) e che PAM sia usato come livello di autenticazione.