it-swarm-pt.tech

Truques de segurança da linha de comando

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 rm safety .

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 o que comando fará ".

34
deadprogrammer

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

45
andyhky

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

  • Feche 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?'
14
Peter

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 corporativos do Shell, 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" 
 Clear-Host 
 write-Host "Aviso: O PowerShell está sendo executado como administrador." 
} 
 
 $ utilities = $ null 
 if ([IntPtr] :: size * 8 -eq 64) 
 {
 $ Host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
 $ Utilities = "$ {env: programfiles (x86) }\Utilitários "
} 
 Else 
 {
 $ Host.UI.RawUI.WindowTitle =" Windows PowerShell (x86) "
 $ Utilitários = "$ {env: programfiles}\Utilities" 
} 
 if ((Test-Path $ utilities) - e! ($ env: path -match $ utilities.Replace ("\", "\\"))) 
 {
 $ env: path = "$ utilitários; $ {env: path} "
} 
} 
 
 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) {'>>' }) + '>' 
} 
10
Brian Reiter

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 login como um usuário normal e depois use Sudo su - root para 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.
  • Nenhum comando é sempre executado sem entender exatamente o que ele faz. Se você está fazendo isso sem saber o que faz, você está jogando roleta russa com seu sistema.
  • Antes pressionando 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 recebe Sudo nos meus sistemas, não porque eu sou um BOFH , mas porque sem preparação e treinamento, isso é como dando 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 cd no diretório primeiro e, em seguida, uso 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.

10
Avery Payne

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

Saiba quando evitar multitarefa.

6
ojblass

Existem poucas coisas importantes que você deve conhecer 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 potencial para desconectar sua sessão (regra do fw, desligamento incorreto, etc ...). Verifique se há um failover para retornar (especialmente se você estiver fora do local)

5
l0c0b0x

Verifique se o nome do host do sistema em que estou está no prompt do 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 - alguma variante de rm) no Shell errado, causando várias coisas no sistema ativo a ser excluído, em vez de coisas de dentro do chroot. Desde então, eu sempre fiz

export PS1="(chroot) $PS1"

sempre que eu estava trabalhando dentro de um chroot.

5
Tim

Regra 1 - faça backups

Regra 2 - NUNCA adicione wrappers "molly guard" aos comandos padrão, crie sua própria versão, com certeza, mas não substitua o nome, apenas morda você quando você está 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.

4
LapTop006

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

4
trent

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 US.

Por quê? Bem simples. O modo GUI geralmente possui uma rede de segurança interna, 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 assim que se provar valer a pena.

4
Maximus Minimus

Em vez de aliasar rm para rm -i, não seria melhor alias dizer remover ou remover com 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.

3
DBMarcos99

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 você passa para a empresa 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 é, a coisa MAIS importante:

Mantenha backups regulares.

3
jns

Se você usa o bash, tente o seguinte:

TMOUT=600

na tua /root/.bashrc ou 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.

2
Andrew Ferrier

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.

2
jjnguy

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 é essencial usar coisas embutidas como Sudo em vez de fazer login como root. Um bom e simples whoami 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.

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

Um alias altamente recomendado para você ter, se você usar a CLI do mysql.

2
jldugger

Ter uma conexão secundária com a máquina em que você está trabalhando pode ser útil caso você encerre sua sessão principal ou faça algo bobo que a bloqueie ... 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 Prompt de qualquer maneira. Má prática, talvez.

2
Alex

Se você usar várias variantes de um sistema operacional, esteja muito ciente 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 processos. Não mesmo. Na página página man : killall é usado pelo shutdown (1M) para eliminar todos os processos ativos não diretamente relacionados ao procedimento de desligamento.

1
Greg Work

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.

1
Kyle Brandt

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.

1
Bill Weiss

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'.

1
Zac Thompson

Para regex complexo, especialmente os comandos 'find' colocam echo 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 adicionar manualmente os casos do Edge que o regex não captou.

1
Martin Beckett

usuário root:
Não seja raiz, a menos que você precise.
Se o fornecedor disser que precisa executar como root, diga-lhe que você é o cliente e que deseja executá-lo como não raiz.
Quantos pacotes de software disponíveis na prateleira 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 depois usar 'rm! $'. A maior ameaça é não estar onde você pensa que está. Eu quase digite 'hostname' tantas vezes quanto 'ls'!

muletas:
um prompt padrão ajuda muito, 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 espero script do wrapper apenas para definir seu caminho, Prompt e alias com '-i'

encontre problemas:
usar um caminho completo ajuda, mas nos casos em que isso não é 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, untar, etc:
exemplo: cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
o uso de '&&' pode impedir que um arquivo tar seja extraído por cima nesse caso (embora, nesse 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 rsync)

1
ericslaw

Eu evito o * 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.

1
Annika Backstrom

No caso de algo como:

ls * .php
eco rm * .php
rm * .php

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

$ ^ 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 precisará digitar * .php e lançar um espaço na hora errada)

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

0
Red Five

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 o último Word.)

0
Mikel

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 apelido rm fica no seu caminho.

0
gbarry

Use bash e defina PS1 = '\ u @\h:\w>'. Isso se expande para o nome de usuário @ nome do host:/full/working/directory/path> Como 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 de fundo é facilmente a melhor resposta :-)

0
dr-jan