Linux: rendere lo spegnimento non eseguibile per sicurezza

Oggi ho spento per errore una macchina di produzione perché pensavo di essere sulla mia macchina locale. Lo so, errore per principianti :-(

Come soluzione per non succedere di nuovo, stavo pensando di rimuovere l'autorizzazione all'esecuzione per il comando di spegnimento poiché quella macchina dovrebbe essere sempre accesa.

È una buona idea? Riesci a vedere qualche effetto collaterale indesiderato nel farlo?

Saluti, Dan

Completamente un altro approccio su come essere avvisati che si lavora sulla macchina di produzione è quello di contrassegnare il terminale. Ad esempio, il user@machine:~#testo potrebbe essere rosso in macchine di produzione, verde in fase di sviluppo, ecc. Ecco un bel tutorial su come effettuare questa operazione: Prompt Bash colore

Il miglior consiglio che posso darti è di non accedere come root a meno che tu non abbia bisogno dell'accesso di root e assicurati di avere una password di root / sudo diversa su ogni macchina.

Rendere inaccessibile l'arresto è un'opzione ma non è buona. O alias shutdowna shutdown -ae touch /etc/shutdown.allowochmod a-x /sbin/shutdown

Inoltre, dove finisce? Hai intenzione di non consentire l'arresto, il riavvio e l'iniz?

Alcuni punti da considerare:

1. Cosa stavi facendo come root su un sistema di produzione durante i tempi di produzione? Configura i tuoi sistemi in modo da non dover essere root su di essi per il lavoro quotidiano. Non dovresti mai essere root su un sistema di produzione senza un'ottima ragione.
2. Impara la lezione importante. Quando sei root devi controllare due volte prima di premere invio. SUDO non è una protezione se scrivi la password per continuare, senza pensarci. La colorazione rapida, come menzionato da mkudlacek, è uno strumento molto utile per aiutarti a non essere nel sistema sbagliato.
3. Non scherzare con gli strumenti integrati. È probabile che interrompa gli aggiornamenti e farà impazzire i nuovi assunti. Se vuoi cambiare qualcosa usa il tuo file alias.

Non penso che scherzare con le autorizzazioni shutdownsia il modo di gestire la situazione. Fondamentalmente hai appena imparato una lezione. Chin up.

Ho fatto lo stesso tipo di cose: ottenere lunghe catene di sessioni SSH, quindi fare confusione con i percorsi su una delle macchine che mi hanno sottoposto, interrompendomi. Ho fallito una richiesta rsync, portando a una distruzione sistematica di un sistema dall'altra parte del mondo. Ho funzionato rm -rf / pathsu un server di produzione. (Quella volta ho imparato come funzionavano i restauri.)

Quindi, molto più vecchio e, si spera, un po 'più saggio, ora ho regole rigide che mi impongo.

• Tutti i prompt di root terminano con un #, indipendentemente dalle altre informazioni in essi contenute.
• Ogni volta che mi viene richiesto #, mi siedo letteralmente sulle mie mani prima di premere il tasto Invio.
• Se c'è qualche dubbio su ciò che sto per fare o su dove sono veramente o su come ci sono arrivato, mi annullo e lo ricostruisco di nuovo da una condizione di partenza nota.
• Quando commetto un errore (e li faccio ancora, anche se diventano sempre meno frequenti e più oscuri col passare del tempo), capisco immediatamente cosa ho fatto, che ho avuto un impatto e vado a confessare loro i miei peccati . Quindi lascia cadere tutto il resto e annulla la damange il più rapidamente e nel miglior modo possibile.

La natura del mio lavoro mi richiede di dedicare molto tempo a molte richieste di root diverse, ma grazie ai miei errori in passato mantengo una consapevolezza situazionale molto migliore rispetto a quando ho iniziato.

Se stai usando Ubuntu, prova Molly-guard. Come discusso in questa domanda simile .

Dipende davvero. Potresti provare a racchiudere il comando ma significa che se esegui aggiornamenti o aggiornamenti che influenzano quel file eseguibile, potresti dimenticartene e far rovinare un aggiornamento. Giocare con i comandi di spegnimento del sistema può essere un PITA, specialmente se hai nuovi assunti o un sostituto che finisce per non sapere che stavi giocando con i binari di sistema.

Personalmente guarderei a racchiudere il comando in uno script che identifica il sistema per nome e ti fa confermare che è quello che vuoi davvero fare prima di eseguire il binario effettivo, o che devi digitare una certa sequenza di lettere per confermare l'arresto prima che esegua il binario. Questo dovrebbe dare una pausa.

Si potrebbe considerare di impostare il prompt dei comandi per includere il nome del computer, almeno sui server. Potrebbe solo aiutare a impedire che altri comandi vengano eseguiti sulla macchina sbagliata in futuro. È più efficace se i nomi delle macchine sono colorati per farli risaltare e potresti persino colorare i codici per identificare i ruoli del server.

Un modo è di non utilizzare sue / o accedere direttamente a root. Meglio accedere direttamente all'account E avere una password diversa per rootil computer locale e la chiave ssh.

Ovviamente, oltre a guardare il prompt rosso "#".

Sì, rimuovere il bit di esecuzione dal comando shutdown è il modo più semplice e sicuro per prevenire arresti accidentali, specialmente se si dispone di un ambiente desktop come KDE sulla macchina e si desidera impedire arresti accidentali durante la disconnessione.

Per quanto riguarda le nuove persone che sono confuse, penso che la prima cosa che faranno sarebbe ls -l /sbin/shutdownscoprire perché non funziona (specialmente se hanno la buona abitudine di completare i nomi degli eseguibili). Ovviamente, dovresti dire loro di eventuali modifiche che hai apportato.

Per maggiore sicurezza, è possibile aggiungere una riga per /etc/rc.localrimuovere il bit di esecuzione dal comando shutdown in modo da non dimenticare di ripristinarlo dopo un riavvio.

puoi semplicemente rimuovere / sbin / dal percorso di root. in questo modo è necessario digitare il percorso completo per eseguirlo e di solito risolve gli incidenti.