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

Question

De vez em quando (muitas vezes por um longo período), tenho dificuldade em executar um comando que estraga completamente uma máquina Linux.

Mais recentemente, eu acidentalmente montei novamente a partição raiz (pensando que era a nova unidade USB que acabei de formatar) e, em seguida, comecei a recursivamente a partição para mim (novamente, apenas tentando conceder acesso de usuário a o drive USB). Assim que percebi o que tinha feito (no meio do progresso), abortei, mas o estrago já estava feito. Muitos programas principais não eram mais de propriedade da raiz, 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 era totalmente bloqueado. Não foi possível montar, desmontar, reconectar a sessões de tela, reinicializar, etc.

Se a máquina estivesse na sala de estar aqui comigo, "reparar" (reinstalar) teria sido trivialmente fácil. Mas não é. Está na casa do meu irmão. Ele não é grande em mim andando com ele através de reparos / reinstalação, e eu entendo isso. Então, eu estou indo em alguns dias para consertar o dano que fiz (e espero instalar algo mais resistente a erros de administração).

Eu digo tudo isso para fazer a pergunta: Quais são as formas recomendadas de fortalecer uma instalação contra a inibição do administrador?

Coisas não consideradas ou consideradas e descartadas rapidamente:

1. Harden o administrador para não executar comandos estúpidos: Uma ótima idéia, mas não funciona, porque, como humano, eu ocasionalmente faço coisas que percebo que o fato é uma má idéia. O que eu estou querendo fazer é pensar em mim mesmo com antecedência, então quando eu fizer algo estúpido, a máquina recusará, e eu vou perceber "Oh merda! Isso poderia ter sido Muito Ruim (TM)! Não vamos fazer isso novamente. "

Coisas que eu considerei:

1. Monta a partição raiz como somente leitura: protegeria a raiz contra alterações, que podem ter efeitos negativos se as partes devem ser graváveis e não são. Também não necessariamente protegeria a partição de ser montada novamente em outro lugar como leitura-gravação.
2. Use uma imagem-raiz de somente leitura compactada com uma camada gravável semelhante a uma união acima, para que nenhuma alteração seja realmente feita na raiz e uma reinicialização elimina quaisquer falhas: Isso seria OK / bom se não houver alterações alguma vez precisa ser feito para fazer o root, e talvez o / etc possa ser recarregado / preenchido a partir de um arquivo persistente em algum outro lugar.
3. Use btrfs com instantâneos regulares (diariamente, talvez), para que, se ocorrer um erro, a recuperação seja mais fácil: pode ainda estar abaixo do ideal, pois exigiria intervenção direta do usuário, e não sei se poderia andar outra pessoa através das mudanças para reverter o oops.
4. Use uma distro Linux / BSD mais "viva" / "incorporada" projetada mais com estabilidade / previsibilidade / segurança em mente, em vez de uma distro mais genérica

Como as coisas estão agora, é provável que eu use a opção 4 para instalar um sistema um pouco mais limitado do que a instalação completa do Debian que eu 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 recurso muito grande.

    

Answer 1

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

    

Answer 2

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

A resposta simples é desacelerar e prestar atenção ao que você está fazendo .

    

Answer 3

Nada impede que você se atire no pé. Você "pensou" que a partição raiz é um pen drive. Você pode facilmente confundir uma máquina importante com uma VM descartável (acontece com o melhor de nós)

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

Nesse caso, você pode ter duas versões do Linux instaladas em duas partições separadas. Você pode dizer ao seu irmão para iniciar o outro (apenas uma idéia)

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

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

Você também pode fornecer ao seu irmão um drive Linux USB para inicializar, com um servidor SSH e um conjunto de senhas. E defina seu PC para inicializar a partir do USB. Então, em caso de emergência, basta solicitar que ele insira o dispositivo USB e reinicie o computador.

    

Answer 4

Um pequeno, mas possivelmente muito útil passo nessa direção é instalar o molly-guard que impedirá você acidentalmente chamando reboot ou mesmo remote no host remoto. Ele detecta se você está logado do remoto e requer que você digite o nome do host para confirmar sua ação.

    

Answer 5

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

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

Você não disse qual FS estava no USB. Geralmente eles são VFAT. Você pode montá-los com opções para fazer com que todos os arquivos pareçam pertencer a um usuário específico. Então você nunca precisa executar chown -r ... e, assim, eliminar a possibilidade de erro.

Faça o prompt do seu shell de raiz de cor vermelha, para lembrá-lo de que você está executando com privilégios elevados.

Geralmente, dificulta as coisas para você fazer como root, com obstáculos como prompts de senha, etc.

Agora, após o reparo, você pode acessar outra máquina como esta e usar find para mostrar os programas SUID / SGID. Em seguida, faça o disco danificado corresponder àquele com o comando chmod .