Se un server è compromesso, un utente malintenzionato potrebbe aggiungere la propria chiave pubblica a authorized_keys. Come viene impedito? Chi dovrebbe avere quale accesso al file?
If a server is compromised, an attacker could add his own public key to authorized_keys. How is this prevented?
La modifica del file authorized_keys di un utente da parte di un utente malintenzionato viene impedita da a impedire che il sistema venga compromesso al punto da consentire all'utente malintenzionato di modificare i file critici arbitrari in primo luogo e in misura minore assicurando che questo file critico disponga di autorizzazioni che non consentano agli utenti arbitrari di modificarne il contenuto.
Who should have what access to the file?
Solo l'utente proprietario del file deve avere accesso in scrittura (incluso nelle sue directory madri), ma l'accesso in lettura è in linea di massima sicuro poiché il file contiene solo dati di chiavi pubbliche. (La chiave privata corrispondente è memorizzata nel sistema da cui l'utente si connette.) In pratica, non c'è motivo di impostare nulla di più permissivo di 0600, e il server SSH dovrebbe rifiutare il file se ha permessi che gli permettono di essere modificato o sostituito da qualcuno diverso dal proprietario.
Considera lo scenario che stai descrivendo. L'utente malintenzionato, in questo caso, ha già accesso root o in modo efficace, in quanto è in grado di modificare il file authorized_keys di un utente. A quel punto, non c'è motivo di fare qualcosa di banale come installare una chiave SSH aggiuntiva che consenta l'accesso come tale utente; come già sottolineato, è molto meglio installare un server SSH personalizzato (che ha tutte le registrazioni cancellate, per uno, e probabilmente tenta di mascherarsi o nascondersi contro l'amministratore, per due).
L'unico scenario in cui mi sembra significativo anche prendere in considerazione la possibilità di modificare il file authorized_keys di un utente è se l'utente malintenzionato è riuscito ad accedere solo all'account dell'utente e desidera eseguire cosa possono fare per mantenere l'accesso almeno a quell'account. Ma se l'utente guarda quel file, a meno che l'utente abbia qualcosa come dozzine di chiavi legittimamente autorizzate, la linea in più rischia di risaltare come un pollice dolente.
E anche in uno scenario del genere, nella grande maggioranza dei casi ci sono probabilmente modi migliori per garantire un accesso continuo al sistema compromesso.
Se l'autore dell'attacco è in grado di ottenere un accesso equivalente alla radice, ci sono molti, molti modi per garantire un accesso continuo che è molto più difficile da rilevare, per non parlare della pulizia, anche da parte di un utente vigile o amministratore di sistema. p>
Dai un'occhiata a questa risposta esistente.
Considera il caso d'uso del server nel tuo scenario, in particolare la frequenza e le diverse sessioni SSH e eserciti il principio del minimo privilegio di conseguenza.
La maggior parte degli scenari di compromissione che vengono in mente derivano da un indefinito irrigidimento (vale a dire per quanto riguarda gli account utente) e / o altri difetti di configurazione.
Se un server è compromesso, è fondamentalmente game over. Puoi eseguire il ripristino da backup o reinstallazioni note e puoi eseguire alcune analisi post-morte per scoprire come hanno ottenuto l'accesso, ma il sistema è protetto e non dovrebbe essere riparato ma reinstallato.
Quindi, nulla impedisce a un utente malintenzionato che ha acquisito i privilegi di superutente di modificare authorized_keys . Normalmente, solo l'utente a cui appartiene questo file (e root, ovviamente) dovrebbe essere in grado di accedervi.
le modifiche possono accadere e morderti, sempre.
Il controllo con i record salvati su un altro computer è obbligatorio.
vedi ad esempio OSSEC
Leggi altre domande sui tag authorization access-control ssh system-compromise