Linux: rendre l'arrêt non exécutable pour des raisons de sécurité

Aujourd'hui, j'ai arrêté une machine de production par erreur parce que je pensais que j'étais sur ma machine locale. Je sais, novice :-(

Pour éviter que cela ne se reproduise, je pensais supprimer la permission d'exécution pour la commande d'arrêt car cette machine devrait toujours être allumée.

est-ce une bonne idée? Pouvez-vous voir un effet secondaire indésirable en faisant cela?

À la vôtre, Dan

Complètement une autre approche pour être averti que vous travaillez sur une machine de production est de marquer le terminal. Par exemple , le user@machine:~#texte pourrait être rouge sur des machines de production, vert au développement, etc. Voici beau tutoriel comment faire: Couleur Bash Prompt

Le meilleur conseil que je puisse vous donner est de ne pas vous connecter en tant que root, sauf si vous avez besoin d'un accès root, et assurez-vous d'avoir un mot de passe root / sudo différent sur chaque machine.

Rendre l'arrêt inaccessible est une option, mais ce n'est pas une bonne. Soit alias shutdownvers shutdown -aet touch /etc/shutdown.allowouchmod a-x /sbin/shutdown

Aussi, où cela se termine-t-il? Allez-vous également interdire l'arrêt, le redémarrage et l'initialisation?

Quelques points à considérer:

1. Que faisiez-vous en tant que root sur un système de production pendant le temps de production? Configurez vos systèmes de sorte que vous n'ayez pas à être root sur eux pour le travail quotidien. Vous ne devriez jamais être root sur un système de production sans une très bonne raison.
2. Apprenez la leçon importante. Lorsque vous êtes root, vous devez vérifier deux fois avant d'appuyer sur Entrée. SUDO n'est pas une protection si vous écrivez simplement votre mot de passe pour continuer, sans réfléchir. La coloration rapide, comme mentionné par mkudlacek, est un outil très utile pour vous assurer que vous n'êtes pas sur le mauvais système.
3. Ne jouez pas avec les outils intégrés. Il est probable qu'il interrompra les mises à jour et rendra les nouvelles recrues folles. Si vous voulez changer quelque chose, utilisez votre propre fichier d'alias.

Je ne pense pas que jouer avec les autorisations shutdownsoit le moyen de gérer la situation. Fondamentalement, vous venez d'apprendre une leçon. Tête haute.

J'ai fait le même genre de choses - obtenir de longues chaînes de sessions ssh, puis jouer avec les routes sur l'une des machines que j'ai traversées, en me coupant. J'ai bâclé une demande rsync, conduisant à une destruction systématique d'un système à l'autre bout du monde. J'ai couru rm -rf / pathsur un serveur de production. (Cette fois, j'ai appris comment les restaurations ont fonctionné.)

Donc, beaucoup plus vieux et, je l'espère, un peu plus sage, j'ai maintenant des règles strictes que je m'impose.

• Toutes les invites root se terminent par un #, quelles que soient les autres informations qu'elles contiennent.
• Chaque fois que je suis à une invite #, je m'assieds littéralement sur mes mains avant d'appuyer sur la touche Entrée.
• En cas de doute sur ce que je suis sur le point de faire, où je suis vraiment ou comment j'y suis arrivé, je l'annule et je le reconstruis à partir d'une condition de démarrage connue.
• Quand je fais une erreur (et je les fais toujours, bien qu'ils deviennent à la fois moins fréquents et plus obscurs au fil du temps), comprendre immédiatement ce que j'ai fait, qui j'ai eu un impact, et aller leur confesser mes péchés . Ensuite, laissez tomber tout le reste et défaites la damange aussi rapidement et du mieux que vous pouvez.

La nature de mon travail m'oblige à passer beaucoup de temps à de nombreuses invites racine variées, mais grâce à mes erreurs dans le passé, je conserve une bien meilleure conscience de la situation que lorsque j'ai commencé.

Si vous utilisez Ubuntu, essayez Molly-guard. Comme discuté dans cette question similaire .

Ça dépend vraiment. Vous pouvez essayer d'encapsuler la commande, mais cela signifie que si vous effectuez des mises à jour ou des mises à niveau qui affectent cet exécutable, vous pouvez l'oublier et lui faire foirer une mise à jour. Jouer avec les commandes d'arrêt du système peut être un PITA, surtout si vous avez de nouveaux employés ou un remplaçant qui finit par ne pas savoir que vous jouiez avec des binaires du système.

Personnellement, je regarderais envelopper la commande dans un script qui identifie le système par son nom et vous fait confirmer que c'est vraiment ce que vous voulez faire avant d'exécuter le binaire réel, ou que vous devez taper une certaine séquence de lettres pour confirmer l'arrêt avant d'exécuter le binaire. Cela devrait donner une pause.

Vous pouvez envisager de définir l'invite de commande pour inclure le nom de l'ordinateur, au moins sur les serveurs. Cela pourrait aider à empêcher l'exécution d'autres commandes sur la mauvaise machine à l'avenir. C'est plus efficace si les noms des machines sont colorés pour les faire ressortir et vous pouvez même colorer le code pour identifier les rôles de serveur.

Une façon consiste à ne pas utiliser suet / ou se connecter directement à root. Mieux vaut se connecter directement au compte ET avoir un mot de passe différent pour rootsur la machine locale et la clé ssh.

Bien sûr, cela s'ajoute à l'observation de l'invite rouge «#».

Oui, la suppression du bit d'exécution de la commande d'arrêt est le moyen le plus simple et le plus sûr d'empêcher les arrêts accidentels, surtout si vous avez un environnement de bureau comme KDE sur la machine et que vous souhaitez empêcher les arrêts accidentels lors de la déconnexion.

En ce qui concerne les nouvelles personnes confuses, je pense que la première chose qu'elles feront serait ls -l /sbin/shutdownde découvrir pourquoi cela ne fonctionne pas (surtout si elles ont la bonne habitude de compléter les noms d'exécutables par tabulation). De toute évidence, vous devez toutefois leur faire part des modifications que vous avez apportées.

Pour plus de sécurité, vous pouvez ajouter une ligne pour /etc/rc.localsupprimer le bit d'exécution de la commande d'arrêt afin de ne pas oublier de le réinitialiser après un redémarrage.

vous pouvez simplement supprimer / sbin / du chemin d'accès de root. de cette façon, vous devez taper le chemin complet pour l'exécuter, et il corrige généralement les accidents.