Quais são as formas recomendadas de defender uma instalação remota *nix de um administrador desajeitado?

Quais são as formas recomendadas de defender uma instalação remota *nix de um administrador desajeitado?

De vez em quando (geralmente por muito tempo), tenho dificuldade em executar um comando que estraga completamente uma máquina Linux.

Mais recentemente, montei acidentalmente novamente a partição raiz (pensando que era a nova unidade USB que acabei de formatar) e, em seguida, comecei a chown recursivamente a partição para mim mesmo (novamente, apenas tentando me conceder acesso de usuário à unidade USB ). Assim que percebi o que tinha feito (no meio do progresso), abortei, mas o estrago estava feito. Muitos programas principais não pertenciam mais ao root, então a máquina estava essencialmente em um estado zumbificado. Algumas funções do usuário (ssh, rsync) ainda funcionavam, mas o nível de administração estava totalmente bloqueado. Não foi possível montar, desmontar, reconectar às sessões de tela, reiniciar, etc.

Se a máquina estivesse na sala aqui comigo, “consertá-la” (reinstalá-la) teria sido trivialmente fácil. Mas não é. Está na casa do meu irmão. Ele não gosta muito que eu o acompanhe nos reparos / reinstalações, e eu entendo isso. Então, irei lá em alguns dias para consertar o dano que causei (e espero instalar algo mais resistente a erros administrativos).

Digo tudo isso para fazer a pergunta: Quais são as formas recomendadas de proteger uma instalação contra a falta de controle do administrador?

Coisas não consideradas, ou consideradas e descartadas rapidamente:

  1. Fortaleça o administrador para não executar comandos estúpidos: uma ótima ideia, mas não funcionará, porque, como ser humano, ocasionalmente farei coisas que percebo posteriormente serem uma má ideia. O que estou procurando fazer é me superar com antecedência, então quando eu fizer algo estúpido, a máquina recusará e eu perceberei "Oh merda! Isso poderia ter sido muito ruim (TM)! Não vamos fazer isso de novo."

Coisas que considerei:

  1. Montar a partição raiz somente leitura: protegeria a raiz contra alterações, o que pode ter efeitos negativos se se espera que as partes sejam graváveis, mas não são. Também não protegeria necessariamente a partição de ser montada novamente em outro lugar como leitura e gravação.
  2. Use uma imagem raiz compactada somente leitura de algum tipo com uma camada gravável semelhante a uma união acima dela, para que nenhuma alteração seja realmente feita na raiz e uma reinicialização elimine qualquer erro: Isso seria bom/bom se nenhuma alteração fosse necessária ser feito como root, e talvez /etc possa ser recarregado/preenchido a partir de um arquivo persistente em outro lugar.
  3. Use btrfs com snapshots regulares (diários, talvez), para que, se ocorrer um erro, a recuperação seja mais fácil: ainda pode ser abaixo do ideal, pois exigiria intervenção direta do usuário e não sei se poderia orientar outra pessoa. as alterações para reverter o oops.
  4. Use uma distribuição Linux/BSD mais "ao vivo"/"embutida", projetada mais com estabilidade/previsibilidade/segurança em mente, em vez de uma distribuição mais genérica

Do jeito que as coisas estão agora, provavelmente usarei a opção 4 para instalar um sistema um pouco mais limitado do que a instalação completa do Debian que estava usando. Mas como apenas um servidor de arquivos e cliente de torrent, ele deve funcionar bem e, como uma máquina remota, defender a máquina de mim mesmo é um grande trunfo.

Responder1

A dura verdade é que nada pode protegê-lo de sua própria estupidez. Não há interface DWIM (faça o que quero dizer). O computador não consegue distinguir entre o que é intencional e o que é acidental. Não importa quanta abstração você acumule, o comando perdido errado pode destruir tudo.

A resposta simples édiminua a velocidade e preste atenção no que você está fazendo.

Responder2

Execute sua instalação em uma máquina virtual. Tire uma foto de um estado bom conhecido. Tire fotos antes de fazer qualquer coisa arriscada. Não faça quase nada no ambiente host. Se você errar, conecte-se ao ambiente host e restaure o instantâneo.

Responder3

Nada impede que você dê um tiro no pé. Você "pensou" que a partição raiz é um pendrive. Você poderia facilmente confundir uma máquina importante com uma VM descartável. (Acontece com os melhores de nós)

O importante é tornar redundante o serviço que seus computadores fornecem.

Neste caso, você poderia ter duas versões do Linux instaladas em duas partições separadas. Você pode dizer ao seu irmão para inicializar o outro. (Apenas uma ideia)

O mais importante é que você faça backups e tenha uma estratégia de restauração.

Nesse caso, como você assumiu a responsabilidade pelo PC do seu irmão, você deve fazer backups contínuos de todos os dados que puder e manter várias cópias com você.

Você também pode fornecer ao seu irmão uma unidade USB Linux para inicializar, com um servidor SSH e uma senha definida. E configure seu PC para inicializar a partir de USB. Depois, em caso de emergência, basta pedir para ele inserir o pendrive e reiniciar o PC.

Responder4

Não faça coisas como usuário root. Configure o sudo para permitir que sua conta normal faça coisas de root, mas com uma senha. Isso lhe dá uma última chance de ver o que você realmente está fazendo.

Mas quando você executa como root, configure aliases para comandos comuns que forçam o uso interativo. por exemplo, alias rm="rm -i"avisará rmantes da remoção. Você pode substituir explicitamente por -f(uma decisão consciente) se realmente quiser rm *(seria então rm -f *).

Você não disse o que era FS no USB. Geralmente eles são VFAT. Você pode montá-los com opções para fazer com que cada arquivo pareça pertencer a um usuário específico. Então você nunca precisará correr chown -r ...e, assim, eliminar a possibilidade de erro.

Deixe o prompt do shell root em vermelho, para lembrá-lo de que você está executando com privilégios elevados.

Geralmente, dificulta as coisas para você como root, com obstáculos como solicitações de senha, etc.

Agora, depois de consertá-lo, você pode obter acesso a outra máquina como esta e usá-la findpara mostrar os programas SUID/SGID. Em seguida, faça com que o disco danificado corresponda àquele com o chmodcomando.

informação relacionada