Best practice per hardening sudo?

La tua domanda è piuttosto ampia e tocca diversi argomenti. Potrebbe essere meglio prendere alcuni dettagli e metterli in una domanda separata.

Is it enough to forbid su and allow sudo in order to keep the traceability of the administrator actions?

... can sudo command have utility without a strong sudoer configuration ? which ones ?

% non sostituito% co_de ha un paio di vantaggi rispetto a sudo .

• Ogni su può usare la sua password personale. In questo modo non è necessario ridistribuire la password di root se è stata modificata.

• sudoer può essere configurato per registrare l'attività. Se la tua configurazione sudo scrive in una posizione remota, diventa difficile per qualcuno coprire le loro tracce.

Tuttavia, l'accesso illimitato al syslog è ancora "non limitato".

• Se non utilizzi un server root remoto, le tracce possono essere facilmente coperte.

• Per comodità, la gente spesso usa syslog per ottenere una shell interattiva. Ciò ti consente di ottenere il completamento automatico di sudo -s nelle directory con restrizioni. Sfortunatamente, i benefici di bash sono nulli se a una persona è consentito eseguire syslog . Inoltre ci sono molte alternative a sudo -s che possono consentire l'esecuzione di comandi senza registrazione specifica.

(I can imagine a scenario where a user does a lot of sudo actions before deleting his bash_history)

sudo -s non deve essere utilizzato come strumento di traccia cronologia. È solo per comodità dell'utente.

Is there another source beside .bash_history useful to keep traceability? can such a file be updated by an administrator (with sudo)?

Qualsiasi file sul server può essere aggiornato da una persona con accesso bash_history illimitato. (sia tramite root o sudo )

Come tracciare l'attività di un su utente può essere l'oggetto di una domanda diversa. Credo che le configurazioni avanzate di SELinux possano farlo, ma probabilmente non è pratico. Non conosco altro modo per tracciare l'attività di un root utente.

Come ho detto se si dispone di una registrazione che dovrà essere scritta su un server di log remoto per impedire che vengano cancellati dall'hacker.

is it possible to restrict sudo -i and sudo -s in the configuration ?

Per rispondere alla lettera, questo può essere possibile, ma va oltre lo scopo di questo post. Prendi in considerazione la possibilità di creare una nuova domanda.

Tuttavia, questo non risolverà il tuo problema. Ad esempio, uno potrebbe usare root invece di sudo su . Uno potrebbe usare sudo -s o aggiornare sudo sudoers , ecc.

L'unico modo per risolverlo è "limitare" le abilità crontab usando una lista bianca. Come hai detto, questo non è così comune, ma è certamente l'unico modo per raggiungere l'obiettivo di una tracciabilità affidabile con qualsiasi livello di dettaglio.

Spero che questo aiuti. Sentiti libero di chiedere chiarimenti sulla mia risposta o posta una domanda più specifica se hai nuove domande basate su ciò che hai imparato finora.

Affrontando la tua ultima frase, in realtà faccio qualcosa con quello spirito sul mio server SSH. Ho due utenti lì: ssh_user e sudo_user . Solo ssh_user è autorizzato ad accedere, ma non è sudoer e deve emettere un comando su sudo_user per fare le cose. Ciò fornisce una linea di difesa aggiuntiva: anche se l'utente malintenzionato ottiene le credenziali di ssh_user (ad esempio rubando i miei file di configurazione putty), non otterrà immediatamente l'accesso a sudo o /etc/shadow sul server e dovrà brute-forza la password di sudo_user o esegui un exploit sul sistema per ottenere l'accesso root.

Ovviamente, una volta che l'autore dell'attacco ha accesso all'account ssh_user , il server è compromesso, ma mi aspetto che questo trucco mi dia un po 'di tempo in più per reagire prima che il danno effettivo sia fatto.

Per questo:

Log on with root and normal user using the same password seems to be a bad practice.

sudo può essere configurato per chiedere la password dell'utente "target", o per una password di root, invece della password dell'utente in esecuzione. Quindi per un singolo utente è possibile avere password distinte e non privilegiate. Per gli amministratori multipli, che dovrebbero tutti avere password distinte per accesso privilegiato e amministratore, è più difficile ed è probabilmente più semplice creando utenti aggiuntivi con uid 0.

Da sudoers (5) :

[sudo] validates the invoking user's credentials, not the target user's (or root's) credentials. This can be changed via the rootpw, targetpw and runaspw flags, described later.