Truques de segurança da linha de comando [fechados]

A linha de comando e o script são perigosos. Faça um pequeno erro de digitação com rm -rf e você estará em um mundo de mágoa. Confunda prod com estágio no nome do banco de dados durante a execução de um script de importação e você será desossado (se eles estiverem no mesmo servidor, o que não é bom, mas acontece). O mesmo vale para perceber tarde demais que o nome do servidor em que você compartilhou não é o que você pensava após brincar com alguns comandos. Você tem que respeitar o Hole Hawg .

Eu tenho alguns pequenos rituais antes de executar comandos arriscados - como fazer uma verificação tripla no servidor em que estou. Aqui está um artigo interessante sobre segurança de empresas .

Que pequenos rituais, ferramentas e truques o mantêm seguro na linha de comando? E eu quero dizer coisas objetivas, como "primeira execução ls foo *, observe a saída disso e substitua ls por rm -rf para evitar a execução de rm -rf foo * ou algo parecido", não "verifique se você sabe qual comando fará ".

Um que funciona bem é usar cores de fundo diferentes no seu shell para servidores de produção / teste / teste.

Tenha em mente um plano de recuperação antes de começar.

• ZIP um arquivo / diretório em vez de excluí-lo imediatamente
• configure o roteador (cisco) para reiniciar em 'x' número de minutos e não 'wr' imediatamente
• verifique se a interface que você está alterando não é a que você inseriu no sistema. Pode ser a interface do roteador para a qual você telnetou ou a porta Ethernet VNC.
• nunca faça login como 'root'
• faça um backup. verifique se está bom. faça outro.
• pergunte a alguém em quem você confia: 'Estou prestes a fazer algo idiota aqui?'

Eu tenho uma solução de baixa tecnologia para alguns deles.

Eu desenvolvi o hábito inato de fazer o seguinte (ao planejar trabalhar como raiz):

• Primeiro, faça o login como um usuário normal e, em seguida, use sudo su - rootpara mudar para o root. Faço isso como uma preparação mental, um lembrete para mim de que entrei mentalmente em uma área muito perigosa e que deveria estar alerta e alerta o tempo todo. Por mais engraçado que pareça, este pequeno ritual sozinho me salvou uma tonelada de tristeza, simplesmente reforçando que eu não posso ser descuidado .
• Cada comando é digitado, mas a tecla [Return] nunca é pressionada. Nunca .
• No comando é sempre executada sem entender exatamente o que ele faz. Se você está fazendo isso sem saber o que faz, está jogando roleta russa com o seu sistema.
• Antes de pressionar a tecla [Return], o comando que foi acionado na CLI é cuidadosamente examinado a olho nu. Se houver alguma hesitação, qualquer indício de possível problema, ele será reexaminado novamente. Se essa hesitação persistir, o comando é deixado na linha e eu pressiono Alt-F2 em outro console para consultar as páginas de manual, etc. Se em uma sessão gráfica, inicio um navegador e faço algumas pesquisas.
• Nenhum usuário comum é entregue sudoa meus sistemas, não porque sou um BOFH , mas porque sem preparação e treinamento, é como dar uma arma carregada a um macaco. É divertido e divertido a princípio, até que o macaco olha para o cano e aperta ...

Ao usar rm, eu sempre vou cdao diretório primeiro e, em seguida, use um prefixo de ./para garantir que o diretório esteja correto, ou seja,

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

ou eu especifico o caminho inteiro do arquivo

rm /usr/some/directory/targetfile

que é uma PITA, mas ... é melhor prevenir do que remediar.

Este é específico para o Windows Powershell.

Como política, adicionamos o seguinte ao perfil da máquina.ps1 em cada servidor. Isso garante que o seguinte seja verdadeiro:

1. As janelas do console do PowerShell do administrador têm uma cor de fundo vermelho escuro
2. O administrador é adicionado ao título
3. A mensagem "Aviso: o PowerShell está sendo executado como administrador". é escrito na inicialização
4. A barra de título é prefixada com "Administrador:"
5. Utilitários padrão (como scripts de shell corporativos, vim e infozip) estão no caminho.

$ currentPrincipal = Novo objeto Security.Principal.WindowsPrincipal ([Security.Principal.WindowsIdentity] :: GetCurrent ())
& {
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        (get-host) .UI.RawUI.Backgroundcolor = "DarkRed"
        host limpo
        write-host "Aviso: O PowerShell está sendo executado como um Administrador.`n"
    }

    $ utilitários = $ nulo
    if ([IntPtr] :: size * 8 -eq 64)
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
        $ utilities = "$ {env: arquivos de programas (x86)} \ Utilitários"
    }
    outro
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x86)"
        $ utilities = "$ {env: programfiles} \ Utilitários"
    }
    if ((Test-Path $ utilities) -e! ($ env: path -match $ utilities.Replace ("\", "\\"))))
    {
        $ env: caminho = "$ utilitários; $ {env: caminho}"
    }
}

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

Posso concordar com todas as respostas acima, mas devo enfatizar esta dica muito, muito importante:

Saiba quando evitar multitarefa.

Garanto que o nome do host do sistema em que estou esteja no prompt bash (ou outro shell). Se eu sou chroot, me certifico de que isso também chegue lá.

Uma vez eu estava instalando um sistema Gentoo a partir de outra distribuição Linux ao vivo e acidentalmente executei um comando bastante destrutivo (não consigo lembrar o que era ATM - uma variante dele rm) no shell errado, causando várias coisas no sistema ao vivo excluído, em vez de itens de dentro do chroot. Desde então, eu sempre fiz

export PS1="(chroot) $PS1"

sempre que eu estava trabalhando dentro de um chroot.

Há algumas coisas importantes a serem observadas antes de fazer uma alteração no servidor:

• Verifique se estou no servidor certo

• Esteja ciente de ** quantas pessoas serão afetadas por esta ação * (se você cometer um erro ou não)

• Antes de digitar a tecla 'enter', esteja ciente da possibilidade de desfazer

• Pergunte a si mesmo se esse comando tem o potencial de desconectar sua sessão (regra fw, desligamento incorreto, etc ...). Verifique se há um failover para retornar (especialmente se você estiver fora do local)

Se você ainda não o fez, alias rm para rm -i

Regra 1 - faça backups

Regra 2 - NUNCA adicione invólucros "molly guard" aos comandos padrão, faça sua própria versão, com certeza, mas não substitua o nome, isso apenas o morderá quando você estiver em um sistema que não configurou.

Truques de prompt, como cores diferentes para a raiz e a árvore de diretórios (parcial), são ótimos auxiliares, mas, novamente, garanta que você possa trabalhar sem eles.

Isso pode parecer contra-intuitivo e menos complicado, mas a melhor dica de segurança da linha de comando que tenho é: Se uma alternativa ao modo GUI estiver disponível e prática, USE-A .

Por quê? Bem simples. O modo GUI geralmente possui uma rede de segurança integrada, na forma de "aviso - você está prestes a snargle o freeblefrop, tem certeza de que deseja fazer isso?" Mesmo se não, você fica mais lento, dando mais espaço para o tempo de reflexão. Ele permite que você verifique as opções com mais facilidade antes de se comprometer com elas; você pode capturar imagens antes e depois dos estados, e protege contra erros de digitação; tudo de bom, útil e útil.

No caso clássico do temido "rm -rf", você acha que é mais fácil enviá-lo acidentalmente de uma GUI ou de uma CLI?

No final, não há vergonha em recorrer à GUI. Não evitará infalivelmente grandes desastres; é tão possível ser acionado em uma GUI quanto em uma CLI; mas se você salvar uma vez que se prove valer a pena.

Use o bom senso e não execute comandos que você não entende. Isso é um bom conselho. Se você sentir vontade de escrever o caminho absoluto de tudo o que passa para a rm ou executar qualquer coisa via sudo, fique à vontade. Eu preferiria su -c então. Pelo menos, não armazena em cache a senha. Eu não me sentiria confortável com qualquer usuário comum sendo permitido executar coisas com privilégios de root sem verificação de senha.

Existem algumas coisas que você pode colocar no seu ~ / .bashrc para tornar as coisas um pouco mais seguras, como:

alias srm='rm -i'

Permitindo que você tenha uma alternativa segura de rm, ...

Mas no final, você pode e sempre estragará tudo. No outro dia, eu tive um script de configuração extinto mostrando toda a minha pasta / usr / bin, quebrando várias coisas. Sim, um simples 'make install' de qualquer tipo de software com um bug pode danificar seu sistema. Você nunca está seguro, faça o que fizer. O que eu estou falando é o mais importante:

Mantenha backups regulares.

Em vez de aliasar rm para rm -i, não seria melhor alias dizer remover ou remover com mais segurança (e usá-los como sua ferramenta de exclusão preferida). Então, quando você usar uma caixa que não tenha essa configuração, nenhum dano será causado.

Certifique-se de nunca executar o comando encontrado on-line, a menos que compreenda completamente o que eles estão fazendo.

Seu sistema pode ser diferente do do pôster e isso pode causar um mundo de mágoa.

Um exemplo óbvio para a segurança da linha de comando na perspectiva Unix / Linux é o uso adequado da conta root.
Um rm -rf como root geralmente é mais perigoso do que como usuário, e o uso de coisas embutidas como sudo em vez de efetuar login como root é vital. Um whoami simples e agradável geralmente ajuda na esquizofrenia ou em várias personalidades.

Isso e o eco anterior a todos os comandos de troca de arquivos, especialmente se você quiser ter certeza de que um glob ou regex corresponde corretamente.

Ter uma conexão secundária com a máquina em que você está trabalhando pode ser útil no caso de você matar sua sessão principal ou fazer algo bobo que a trava ... processamento pesado etc.

Dessa forma, você ainda tem acesso à máquina e pode matar sua sessão principal.

A maioria dos comentários acima se refere à rm, mas também fiz algumas coisas estúpidas com outros comandos ...

ifconfig para derrubar a rede - ai, isso requer presença física para corrigir.

Quanto aos scripts, geralmente trabalho em duas janelas. O primeiro que eu uso para escrever o script, o segundo para testar cada linha enquanto eu o escrevo. Indo devagar e com cuidado, posso garantir que todas as linhas funcionem conforme o esperado, enquanto escrevo o código, cuidando para manter as mesmas variáveis, etc.

Pessoalmente, não encontro prompts extras para coisas como rm -i realmente ajudam. Cometo a maioria dos meus erros quando v. Cansado, estressado, etc., que são os momentos em que estarei batendo e ignorando o aviso de qualquer maneira. Má prática, talvez.

Se você usa o bash, tente o seguinte:

TMOUT=600

no seu /root/.bashrcou similar. Ele faz o logout automaticamente após 10 minutos, reduzindo a chance de você acessar um terminal raiz que acidentalmente deixou em aberto e digitar algo estúpido.

Sim, eu sei que você deve usar o sudo para executar comandos root - isso é apenas uma rede de segurança extra, caso você decida jogar com risco um dia.

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

Um alias altamente recomendado para você ter, caso você use a CLI do mysql.

Em vez de ls, uso echo para que eu possa ver o comando completo depois que o shell expandiu tudo. Além disso, sempre aspas variáveis ​​que representam arquivos, para que o seu material funcione com nomes de arquivos que possam ter tabulações ou espaços.

Eu evito a *glob como seu próprio argumento sempre que possível. Mesmo que eu realmente queira dizer "remova tudo neste diretório", tento ser mais específico, ie. rm *.php. É um controle preventivo de danos, caso eu acidentalmente execute o mesmo comando fora do histórico em outro diretório.

Uma ótima maneira de fazer você pensar sobre o que está fazendo é adicionar algo assim ao bashrc do root (cshrc, qualquer que seja):

unset PATH

Dessa forma, você precisa fazer / bin / rm em vez de apenas "rm". Esses caracteres extras podem fazer você pensar.

Para regex complexo, especialmente os comandos 'find' colocam eco na frente e os capturam em um arquivo. Então você pode verificar se realmente está excluindo / movendo / etc exatamente o que pensa que é antes de executar o arquivo com 'fonte'.

Também é útil para adicionar manualmente as bordas que o regex não captou.

Um pouco mais sobre algumas das outras postagens: Eu uso as etapas usuais de echo / ls sugeridas primeiro, para garantir que o comando esteja selecionando o conjunto de arquivos que eu quero ou sendo interpretado pelo shell como pretendido.

Mas então eu uso os recursos de edição do histórico de comandos do shell para recuperar o comando anterior e modificar apenas as partes que precisam variar.

Não ajuda em nada digitar cada um desses comandos independentemente ...

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

... porque digitei acidentalmente um espaço na última linha e excluí todos os arquivos. Eu sempre recuperava a linha anterior e simplesmente removia o 'eco'.

usuário root:
não seja root, a menos que você precise.
Se o fornecedor disser que precisa executar como root, diga que você é o cliente e que deseja executá-lo como não raiz.
Quantos pacotes de software disponíveis no mercado querem raiz "apenas porque é mais fácil"?

hábito:
nunca use '*' com remove sem olhar três vezes. É melhor criar o hábito de usar ls -l TargetPattern e , em seguida, usar 'rm! $'. A maior ameaça é não estar onde você pensa que está. Eu quase digito 'hostname' tantas vezes quanto 'ls'!

muletas:
um prompt padrão ajuda bastante, assim como aliases como "alias rm = 'rm -i'", mas geralmente não tenho controle total sobre as máquinas em que estou, então uso um script de wrapper esperado apenas para definir seu caminho , prompt e aliases com '-i'

encontre problemas: o
uso de um caminho completo ajuda, mas nos casos em que isso não for possível, coloque o CD em um local mais seguro e TAMBÉM use '&&' para garantir que o 'cd' seja bem-sucedido antes de você encontrar, remover, tar, desarmar, etc:
exemplo: o cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
uso de '&&' pode impedir que um arquivo tar seja extraído por cima nesse caso (embora, neste caso, 'rsync' seja melhor)

remove:
nunca remova recursivamente se você puder ajudá-lo, especialmente em um script. localize e remova com -type f e -name 'pattern' Ainda vivo com medo de alimentar 'nada' com xargs ... tar e untar para mover coisas (use o rsync)

Se você usar múltiplas variantes de um sistema operacional, ser muito conscientes das diferenças de sintaxe; o que é razoavelmente seguro em uma variante unix é extremamente perigoso em outra.

Exemplo: killall

Linux / FreeBSD / OSX - mata todos os processos correspondentes ao parâmetro passado. por exemplo: "killall apache" mata todos os apaches, deixando todos os outros processos em paz.

Solaris - mata todos os processos. Não mesmo. Na página do manual : killall é usado pelo shutdown (1M) para eliminar todos os processos ativos não diretamente relacionados ao procedimento de desligamento.

Ao invés de

rm foo*

usar

rm -i foo*

Isso é prático com um punhado de arquivos, mas não com, digamos, um pacote inteiro. É por isso que o aliasing rmficará no seu caminho.

Executar o comando com eco primeiro é uma boa ideia, mas ainda é propenso a erros de digitação.

Tente usá-lo com uma expansão como! $.

echo foo*
rm -rf !$

O! $ Se expande para a última palavra do último comando, portanto é equivalente a

echo foo*
rm -rf foo*

Há também! *, Que se expande para todos os argumentos até o último comando.

Na verdade, você poderia fazê-lo dessa maneira, se preferir

echo rm -rf foo*
!*

(Se você estiver usando o ksh, e não o bash, digite Esc + period para inserir a última palavra.)

No caso de algo como:

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

Você pode usar o operador de substituição, assim:
$ ls * .php
<dir list>

$ ^ ls ^ echo rm (isso substitui ls no comando anterior por echo rm, mantendo o restante da linha de comando igual)

$ ^ echo rm ^ rm (substitua echo rm por apenas rm, assim você não precisa digitar novamente * .php e lançar um espaço na hora errada)

^ = turno-6, para quem não conhece.

Use bash e defina PS1 = '\ u @ \ h: \ w>'. Isso se expande para o nome de usuário @ nome do host: / full / working / directory / path> Conforme mencionado em outras respostas, você pode usar o expect para configurar o ambiente sempre que efetuar login, se não puder atualizar os arquivos .profile ou .bash_profile. Alterar as cores do plano de fundo é facilmente a melhor resposta :-)

Ah sim. Esse velho truque de enviar a alguém um arquivo através do IRC chamado "-rf", para que ele acabe no diretório ~. Um pouco de "rm -rf" depois (em vez de "rm - -rf") e muitos risos se seguiram, enquanto eles aprendiam uma dura lição sobre não executar o IRC como root.

Em vez de usar rm -rf <dir>colocar o -rfno final assim: rm <dir> -rf. Pense nisso como remover a segurança depois de apontar e antes de disparar. Dessa forma, você estará protegido se você pressionar a tecla Enter enquanto estiver digitando o nome do diretório (ou usando o preenchimento de guias) e tiver diretórios com nomes semelhantes.