Trucchi di sicurezza della riga di comando [chiuso]

La riga di comando e gli script sono pericolosi. Fai un piccolo errore di battitura con rm -rf e sei in un mondo ferito. Confondere prod con stage nel nome del database mentre si esegue uno script di importazione e si viene disossati (se si trovano sullo stesso server, il che non va bene, ma succede). Lo stesso vale per notare troppo tardi che il nome del server in cui è stato inviato non è quello che pensavi fosse dopo aver eseguito alcuni comandi. Devi rispettare il Hole Hawg .

Ho alcuni piccoli rituali prima di eseguire comandi rischiosi, come fare un triplo controllo del server in cui mi trovo. Ecco un interessante articolo sulla sicurezza dei rm .

Quali piccoli rituali, strumenti e trucchi ti tengono al sicuro sulla riga di comando? E intendo cose oggettive, come "first run ls foo *, guarda l'output di quello e poi sostituisci ls con rm -rf per evitare di eseguire rm -rf foo * o qualcosa del genere", non "assicurati di sapere cosa comando farà ".

Uno che funziona bene è usare diversi colori di sfondo sulla shell per server di prod / staging / test.

Avere in mente un piano di rientro prima di iniziare.

• ZIP su un file / directory invece di eliminarlo immediatamente
• imposta il router (Cisco) per riavviare in 'x' numero di minuti e non 'wr' subito
• assicurati che l'interfaccia che stai cambiando non sia quella su cui sei entrato nel sistema. Questa potrebbe essere l'interfaccia del router su cui telnet o la porta Ethernet su cui VNC.
• mai accedere come 'root'
• fare un backup. controlla che sia buono. fare un altro.
• chiedi a qualcuno di cui ti fidi "Sto per fare qualcosa di stupido qui?"

Ho una soluzione a bassa tecnologia per alcuni di questi.

Ho sviluppato l'abitudine innata di fare quanto segue (quando si pianifica di lavorare come root):

• Innanzitutto, accedi come un normale utente, quindi utilizza sudo su - rootper passare a root. Lo faccio come preparazione mentale, per ricordarmi che ho camminato mentalmente in un'area molto pericolosa e che avrei dovuto essere vigile e in guardia in ogni momento. Per quanto possa sembrare divertente, questo piccolo rituale da solo mi ha risparmiato un sacco di dolore semplicemente rinforzando il fatto che non posso essere negligente .
• Ogni comando viene digitato ma il tasto [Invio] non viene mai premuto. Mai .
• Nessun comando viene mai eseguito senza capire esattamente cosa fa. Se lo stai facendo senza sapere cosa fa, stai giocando alla roulette russa con il tuo sistema.
• Prima di premere il tasto [Invio], il comando escluso dalla CLI viene esaminato attentamente a occhio. Se c'è qualche esitazione, qualche accenno di potenziale problema, viene riesaminato di nuovo. Se l'esitazione persiste, il comando viene lasciato sulla linea e io alt-F2 su un'altra console per consultare le pagine man, ecc. Se in una sessione grafica, apro un browser e faccio qualche ricerca.
• Nessun utente comune viene mai consegnato sudoai miei sistemi, non perché sono un BOFH , ma perché senza preparazione e addestramento, è come dare una pistola carica a una scimmia. All'inizio è divertente e divertente, fino a quando la scimmia non guarda la canna e stringe ...

Quando utilizzo rm, vado sempre cdprima alla directory, quindi uso un prefisso di ./per assicurarmi che la directory sia corretta, ad es

cd /usr/some/directory ; rm ./targetfile

oppure specifico l'intero percorso del file

rm /usr/some/directory/targetfile

che è un PITA ma ... meglio prevenire che curare.

Questo è specifico per Windows Powershell.

Come criterio aggiungiamo quanto segue la macchina profile.ps1 su ciascun server. Ciò garantisce che siano vere le seguenti condizioni:

1. Le finestre della console di amministrazione PowerShell hanno un colore di sfondo rosso scuro
2. L'amministratore viene aggiunto al titolo
3. Il messaggio "Avviso: Powershell è in esecuzione come amministratore." è scritto all'avvio
4. La barra del titolo ha il prefisso "Amministratore:"
5. Le utility standard (come gli script di shell aziendali, vim e infozip) sono nel percorso.

$ currentPrincipal = New-Object Security.Principal.WindowsPrincipal ([Security.Principal.WindowsIdentity] :: GetCurrent ())
& {
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        (Get-host) .UI.RawUI.Backgroundcolor = "DarkRed"
        Clear-Host
        write-host "Avviso: PowerShell è in esecuzione come amministratore`n"
    }

    $ utilities = $ null
    if ([IntPtr] :: size * 8 -eq 64)
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
        $ utilities = "$ {env: programfiles (x86)} \ Utilities"
    }
    altro
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x86)"
        $ utilities = "$ {env: programfiles} \ Utilities"
    }
    if ((Test-Path $ utilities) -and! ($ env: path -match $ utilities.Replace ("\", "\\")))
    {
        $ env: path = "$ utilities; $ {env: path}"
    }
}

funzione Prompt
{
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        if (! $ host.UI.RawUI.WindowTitle.StartsWith ("Amministratore:"))
        {$ Host.UI.RawUI.WindowTitle = "Amministratore:" + $ host.UI.RawUI.WindowTitle}
    }
    'PS' + $ (if ($ nestedpromptlevel -ge 1) {'>>'}) + '>'
}

Sono d'accordo con tutte le risposte di cui sopra, ma devo sottolineare questo suggerimento molto, molto importante:

Sapere quando evitare il multitasking.

Mi assicuro che il nome host del sistema in cui mi trovo sia nel prompt bash (o altra shell). Se sono chroot, mi assicuro che ce la faccia anche lì in qualche modo.

Una volta stavo installando un sistema Gentoo da un'altra distribuzione Linux live e accidentalmente ho eseguito un comando piuttosto distruttivo (non ricordo cosa fosse ATM - una variante di rm) nella shell sbagliata, causando un mucchio di cose sul sistema live cancellato, piuttosto che roba all'interno del chroot. Da allora, l'ho sempre fatto

export PS1="(chroot) $PS1"

ogni volta che lavoravo in un chroot.

Ci sono alcune cose importanti di cui tenere conto prima di apportare una modifica al server:

• Assicurati di essere sul server giusto

• Fai attenzione a ** quante persone saranno interessate da questa azione * (se commetti un errore o no)

• Prima di digitare il tasto 'Invio', tenere presente la possibilità di annullare

• Chiediti se questo comando ha il potenziale di disconnettere la tua sessione (regola fw, cattivo arresto, ecc ...). Assicurati che ci sia un failover in cui tornare (specialmente se sei fuori sede)

Se non l'hai già fatto alias da rm a rm -i

Regola 1: eseguire backup

Regola 2 - Non aggiungere MAI wrapper "molly guard" ai comandi standard, crea la tua versione, certo, ma non assumere il nome, ti morderà solo quando sei su un sistema che non hai impostato.

Trucchi rapidi come colori diversi per la radice e l'albero delle directory (parziale) sono di grande aiuto, ma assicurati di poter lavorare senza di essi.

Questo può sembrare controintuitivo e meno ardente, ma il miglior consiglio di sicurezza da riga di comando che ho è: se un'alternativa in modalità GUI è disponibile e pratica, allora USARLO .

Perché? Abbastanza semplice. La modalità GUI di solito ha una rete di sicurezza integrata, sotto forma di "avvertimento - stai per ingannare il freeblefrop, sei sicuro di volerlo fare?" Anche se no, ti rallenta, dando più spazio per il tempo di pensare. Ti consente di ricontrollare più facilmente le opzioni prima di impegnarti, puoi fare uno screenshot degli stati prima e dopo, ti protegge dai refusi; tutte cose buone, utili e utili.

Nel classico caso del temuto "rm -rf", pensi che sia più facile emetterlo accidentalmente da una GUI o da una CLI?

Alla fine, non c'è da vergognarsi nel ricorrere alla GUI. Non previene infallibilmente gravi catastrofi; è altrettanto possibile essere trigger-trigger in una GUI come in una CLI; ma se ti salva una volta si è dimostrato utile.

Usa il buon senso e non eseguire comandi che non capisci. Questo è tutto un buon consiglio. Se hai voglia di farti male scrivendo il percorso assoluto di tutto ciò che passi a RM, o eseguendo qualsiasi cosa tramite sudo, sentiti libero. Preferirei su -c allora. Almeno non memorizza nella cache la password. Non mi sentirei a mio agio con qualsiasi utente normale autorizzato a eseguire operazioni con privilegi di root senza verifica della password.

Ci sono alcune cose che puoi mettere nel tuo ~ / .bashrc per rendere le cose un po 'più sicure, come:

alias srm='rm -i'

Ti permette di avere un'alternativa sicura di rm, ...

Ma alla fine, puoi e rovinerai sempre. L'altro giorno ho avuto uno script di configurazione defunto chown la mia intera cartella / usr / bin, rompendo diverse cose. Sì, una semplice "installazione" di qualsiasi tipo di software con un bug può danneggiare il sistema. Non sei MAI sicuro, qualunque cosa tu faccia. Quello a cui sto arrivando è la cosa più importante:

Mantieni backup regolari.

Invece di aliasing da rm a rm -i, non sarebbe meglio alias dire rimuovere o saferemove (e usare quelli come strumento di cancellazione preferito). Quindi, quando si utilizza una scatola che non ha avuto questa configurazione, non viene fatto alcun danno.

Assicurati di non eseguire mai il comando che trovi online a meno che tu non comprenda appieno quello che stanno facendo.

Il tuo sistema potrebbe essere diverso da quello del poster e ciò potrebbe causare un mondo di dolore.

Un ovvio per la sicurezza della riga di comando dal punto di vista Unix / Linux è l'uso corretto dell'account root.
Un rm -rf come root è generalmente più pericoloso che come utente, e usare cose integrate come sudo piuttosto che accedere come root è vitale. Un simpatico whoami di solito aiuterà per la schizofrenia o personalità multiple.

Questo e anteporre l'eco a qualsiasi comando di filechanging, specialmente se vuoi assicurarti di avere una corrispondenza glob o regex corretta.

Avere una connessione secondaria nella macchina su cui stai lavorando può essere utile nel caso in cui tu uccida la tua sessione primaria o fai qualcosa di stupido che la blocca ... elaborazione pesante ecc.

In questo modo hai ancora accesso alla macchina e puoi terminare la sessione principale.

La maggior parte dei commenti sopra si riferisce a rm, ma ho fatto alcune cose stupide anche con altri comandi ...

ifconfig per smantellare la rete - ahi, questo richiede la presenza fisica per risolvere.

Per quanto riguarda gli script, di solito lavoro in due finestre. Il primo che uso per scrivere lo script, il secondo per testare ogni riga mentre lo scrivo. Procedendo lentamente e con attenzione posso assicurarmi che ogni riga funzioni come mi aspetto mentre scrivo il codice, avendo cura di mantenere le stesse variabili, ecc.

Personalmente, non trovo i suggerimenti extra per cose come rm -i davvero di aiuto. Faccio la maggior parte dei miei errori quando v. Stanco, stressato, ecc. Che sono i momenti in cui sbatterò e ignorerò comunque il messaggio. Cattiva pratica forse.

Se usi bash, prova questo:

TMOUT=600

nel tuo /root/.bashrco simili. Ti disconnette automaticamente dopo 10 minuti, riducendo la possibilità di passare a un terminale di root che hai lasciato accidentalmente aperto e digitare qualcosa di stupido.

Sì, lo so che dovresti usare sudo per eseguire i comandi di root - questa è solo una rete di sicurezza in più nel caso in cui decidessi di giocare rischioso un giorno.

# Allow only UPDATE and DELETE statements that specify key values
alias mysql="mysql --safe-updates"`

Un alias altamente raccomandato da avere se si usa mai l'interfaccia della riga di comando mysql.

Invece di ls uso echo in modo da poter vedere il comando completo dopo che la shell ha espanso tutto. Inoltre, raddoppia sempre le variabili che rappresentano i file in modo che le tue cose funzionino con nomi di file che potrebbero avere schede o spazi.

Evito il *glob come argomento proprio quando possibile. Anche se intendo davvero "rimuovere tutto in questa directory", cerco di essere più specifico, cioè. rm *.php. È il controllo preventivo del danno nel caso in cui avessi accidentalmente eseguito lo stesso comando fuori dalla cronologia in un'altra directory.

Un ottimo modo per farti pensare a quello che stai facendo è aggiungere qualcosa di simile a bashrc di root (cshrc, qualunque cosa):

unset PATH

In questo modo, devi fare / bin / rm invece di semplicemente "rm". Quei personaggi extra potrebbero farti pensare.

Per regex complessi, in particolare i comandi 'trova' mettono l'eco in primo piano e li catturano in un file. Quindi puoi controllare che stai davvero cancellando / spostando / etc esattamente quello che pensi di essere prima di eseguire il file con 'source'.

È anche utile per aggiungere manualmente quei casi limite che il regex non ha raccolto.

Un po 'di meta per alcuni degli altri post: uso i soliti passaggi echo / ls suggeriti per primi, per assicurarmi che il comando selezioni il set di file che voglio o che venga interpretato in altro modo dalla shell come previsto.

Ma poi uso le funzionalità di modifica della cronologia dei comandi della shell per recuperare il comando precedente e modificare solo le parti che devono variare.

Non aiuta affatto digitare ciascuno di questi comandi in modo indipendente ...

$ ls *.bak
$ echo rm *.bak
$ rm * .bak

... perché ho accidentalmente digitato uno spazio nell'ultima riga e cancellato tutti i file. Recupererei sempre la riga precedente e rimuoverei semplicemente l'eco.

utente root: non
essere root a meno che non sia necessario.
Se il fornitore afferma che deve essere eseguito come root, informa che sei il cliente e che desideri eseguirlo come non root.
Quanti pacchetti software sono disponibili sullo scaffale "solo perché è più facile"?

abitudine:
non usare mai '*' con remove senza guardarlo tre volte È meglio prendere l'abitudine di usare ls -l TargetPattern , quindi usare 'rm! $'. La più grande minaccia non è essere dove pensi di essere. Scrivo quasi "hostname" tutte le volte che "ls"!

stampelle:
un prompt standard aiuta molto, così come gli alias come "alias rm = 'rm -i'", ma spesso non ho il pieno controllo delle macchine in cui mi trovo, quindi uso uno script wrapper di attesa semplicemente per impostare il tuo percorso , prompt e alias con '-i'

trova problemi:
usare un percorso completo aiuta, ma nei casi in cui ciò non sia possibile, cd in una posizione più sicura e ANCHE usa '&&' per assicurarti che il 'cd' abbia successo prima di trovare, rimuovere, tar, untar, etc:
esempio: l' cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
uso di '&&' può impedire che un file tar venga estratto su di sé in questo caso (anche se in questo caso 'rsync' sarebbe meglio)

rimuove:
non rimuovere mai in modo ricorsivo se puoi aiutarlo, specialmente in uno script. trova e rimuovi con -type f e -name 'pattern' Vivo ancora nel timore di alimentare 'niente' con xargs ... tar e untar per spostare le cose (usa invece rsync)

Se si utilizzano più varianti di un sistema operativo, prestare molta attenzione alle differenze di sintassi; ciò che è ragionevolmente sicuro su una variante unix è estremamente pericoloso in un'altra.

Esempio: killall

Linux / FreeBSD / OSX - uccide tutti i processi corrispondenti al parametro passato. ad esempio: "killall apache" uccide tutti gli apache, lasciando soli tutti gli altri processi.

Solaris: uccide tutti i processi. No davvero. Dalla pagina man : killall è usato da shutdown (1M) per uccidere tutti i processi attivi non direttamente correlati alla procedura di spegnimento.

Invece di

rm foo*

uso

rm -i foo*

Questo è pratico con una manciata di file, ma non con, diciamo, un intero tarball. Ecco perché l'aliasing rmti ostacolerà .

Eseguire prima il comando con echo è una buona idea, ma è ancora soggetto a errori di battitura.

Prova a usarlo con un'espansione come! $.

echo foo*
rm -rf !$

! $ Si espande fino all'ultima parola dell'ultimo comando, quindi è equivalente a

echo foo*
rm -rf foo*

C'è anche! *, Che si espande a tutti gli argomenti fino all'ultimo comando.

Anzi, potresti farlo in questo modo se preferisci

echo rm -rf foo*
!*

(Se stai usando ksh, non bash, puoi digitare Esc + punto per inserire invece l'ultima parola.)

Nel caso di qualcosa di simile:

ls * .php
echo rm * .php
rm * .php

È possibile utilizzare l'operatore di sostituzione, in questo modo:
$ ls * .php
<elenco dir>

$ ^ ls ^ echo rm (sostituisce ls nel comando precedente con echo rm, mantenendo uguale il resto della riga di comando)

$ ^ echo rm ^ rm (sostituisci echo rm con solo rm, quindi non devi digitare nuovamente * .php e lanciare uno spazio nel momento sbagliato)

^ = shift-6, per chi non lo conosce.

Usa bash e imposta PS1 = '\ u @ \ h: \ w>'. Questo si espande in nomeutente @ nome host: / full / working / directory / percorso> Come menzionato in altre risposte, è possibile utilizzare aspettarsi di configurare l'ambiente ogni volta che si accede se non è possibile aggiornare i file .profile o .bash_profile. La modifica dei colori di sfondo è comunque la risposta migliore :-)

Ah sì. Quel secolare trucco di inviare a qualcuno un file tramite IRC chiamato "-rf", quindi finisce nella loro directory ~. Un piccolo "rm -rf" più tardi (invece di "rm - -rf") e molte risate sono seguite mentre imparano una dura lezione sul non eseguire IRC come root.

Invece di utilizzare rm -rf <dir>mettere -rfalla fine in questo modo: rm <dir> -rf. Pensa a come rimuovere la sicurezza dopo aver mirato e prima di sparare. In questo modo si è protetti se si ha uno slittamento del tasto Invio mentre si digita il nome della directory (o si utilizza il completamento della scheda) e si hanno directory con nomi simili.