Astuces de sécurité en ligne de commande [fermé]

La ligne de commande et les scripts sont dangereux. Faites une petite faute de frappe avec rm -rf et vous vous retrouverez dans un monde de blessures. Confondez prod avec stage dans le nom de la base de données lors de l’exécution d’un script d’importation et vous êtes désossé (s’ils se trouvent sur le même serveur, ce qui n’est pas bon, mais cela arrive). Même chose pour avoir remarqué trop tard que le nom du serveur sur lequel vous avez sshed n’est pas ce que vous pensiez être après avoir exécuté certaines commandes. Vous devez respecter le Hole Hawg .

Avant d'exécuter des commandes risquées, j'ai quelques petits rituels, comme effectuer une triple prise du serveur sur lequel je suis. Voici un article intéressant sur la sécurité des entreprises .

Quels petits rituels, outils et astuces vous protègent en ligne de commande? Et je veux dire des choses objectives, comme "première exécution de ls foo *, regardez la sortie de cela, puis remplacez ls par rm -rf pour éviter de lancer rm -rf foo * ou quelque chose comme ça", pas "assurez-vous de savoir ce que la commande fera ".

Une solution qui fonctionne bien consiste à utiliser différentes couleurs d’arrière-plan sur votre shell pour les serveurs prod / staging / test.

Ayez un plan de retrait en tête avant de commencer.

• Zippez un fichier / répertoire au lieu de le supprimer immédiatement
• paramétrez le routeur (cisco) pour qu'il redémarre dans le nombre de minutes 'x' et ne le faites pas immédiatement
• assurez-vous que l'interface que vous modifiez n'est pas celle sur laquelle vous êtes entré dans le système. Il peut s’agir de l’interface du routeur à laquelle vous vous êtes connecté telnet ou du port Ethernet VNC.
• ne jamais se connecter en tant que 'root'
• faire une sauvegarde. vérifier que c'est bon. faire un autre.
• demandez à quelqu'un en qui vous avez confiance "Suis-je sur le point de faire une bêtise ici?"

J'ai une solution low-tech à certains d'entre eux.

J'ai développé une habitude innée de faire ce qui suit (lors de la planification de travailler en tant que root):

• Tout d’abord, vous connecter en tant qu’utilisateur normal, puis vous utilisez sudo su - rootle passage à la racine. Je le fais comme une préparation mentale, un rappel pour moi que je suis entré mentalement dans une zone très dangereuse et que je devrais être vigilant et sur mes gardes à tout moment. Aussi drôle que cela puisse paraître, ce petit rituel à lui seul m'a épargné une tonne de chagrin en renforçant simplement le fait que je ne peux pas être négligent .
• Chaque commande est tapée mais la touche [Retour] n'est jamais enfoncée. Jamais .
• Aucune commande n'est jamais exécutée sans comprendre exactement ce qu'elle fait. Si vous faites cela sans savoir ce que cela fait, vous jouez à la roulette russe avec votre système.
• Avant d' appuyer sur la touche [Retour], la commande déclenchée sur l'interface de ligne de commande est soigneusement examinée à l'œil. S'il y a une hésitation, un soupçon de problème potentiel, il est réexaminé. Si cette hésitation persiste, la commande est laissée sur la ligne et je modifie F2 sur une autre console pour consulter les pages de manuel, etc. Si, dans une session graphique, je lance un navigateur et effectue quelques recherches.
• Aucun utilisateur commun n'est jamais remis sudoà mes systèmes, non pas parce que je suis un BOFH , mais parce que sans préparation ni entraînement, cela revient à donner une arme chargée à un singe. C'est amusant et amusant au début, jusqu'à ce que le singe regarde le tonneau et le serre ...

Lors de l’utilisation de rm, j’ai toujours cdle premier répertoire, puis un préfixe de ./afin de s’assurer que le répertoire est correct, c’est-à-dire

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

ou je spécifie le chemin complet du fichier

rm /usr/some/directory/targetfile

qui est un PITA mais ... mieux vaut prévenir que guérir.

Celui-ci est spécifique à Windows Powershell.

En tant que stratégie, nous ajoutons les éléments suivants à la machine profile.ps1 sur chaque serveur. Cela garantit que les éléments suivants sont vrais:

1. Les fenêtres de la console Admin PowerShell ont une couleur de fond rouge foncé
2. L'administrateur est ajouté au titre
3. Le message "Avertissement: Powershell s'exécute en tant qu'administrateur". est écrit au démarrage
4. La barre de titre est préfixée avec "Administrateur:"
5. Les utilitaires standard (tels que les scripts d'entreprise, vim et infozip) se trouvent dans le chemin.

$ currentPrincipal = New-Object Security.Principal.WindowsPrincipal ([Security.Principal.WindowsIdentity] :: GetCurrent ())
& {
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        (get-host) .UI.RawUI.Backgroundcolor = "DarkRed"
        clear-host
        write-host "Avertissement: PowerShell s'exécute en tant qu'administrateur.` "
    }

    $ utilities = $ null
    if ([IntPtr] :: size * 8 -eq 64)
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x64)" 
        $ utilities = "$ {env: programfiles (x86)} \ Utilities"
    }
    autre
    {
        $ host.UI.RawUI.WindowTitle = "Windows PowerShell (x86)"
        $ utilities = "$ {env: programfiles} \ Utilities"
    }
    if ((Test-Path $ utilities) -et! ($ env: path -match $ utilities.Replace ("\", "\\")))
    {
        $ env: path = "$ utilities; $ {env: path}"
    }
}

fonction invite
{
    if ($ currentPrincipal.IsInRole ([Security.Principal.WindowsBuiltInRole] :: Administrator))
    {
        if (! $ host.UI.RawUI.WindowTitle.StartsWith ("Administrateur:"))
        {$ Host.UI.RawUI.WindowTitle = "Administrateur:" + $ host.UI.RawUI.WindowTitle}
    }
    'PS' + $ (if ($ nestedpromptlevel -ge 1) {'>>'}) + '>'
}

Je suis d’accord avec toutes les réponses ci-dessus, mais je tiens à souligner ce conseil très important:

Savoir quand éviter le multitâche.

Je m'assure que le nom d'hôte du système sur lequel je me trouve est dans l'invite bash (ou autre shell). Si je suis chrooté, je m'assure que ça le fait aussi.

J'étais une fois en train d'installer un système Gentoo depuis une autre distribution Linux en direct et d'exécuter accidentellement une commande plutôt destructive (je ne me souviens plus de ce que c'était l'ATM - une variante de rm) dans le mauvais shell, ce qui a provoqué l'apparition de tout un tas de choses sur le système live. supprimé, plutôt que des choses à l'intérieur du chroot. A partir de là, j'ai toujours fait

export PS1="(chroot) $PS1"

chaque fois que je travaillais dans un chroot.

Il y a peu de choses importantes à prendre en compte avant d'effectuer un changement de serveur:

• Assurez-vous que je suis sur le bon serveur

• Soyez conscient de ** combien de personnes seront touchées par cette action * (si vous faites une erreur ou non)

• Avant de taper la touche 'Entrée', soyez conscient de la possibilité d'annuler

• Demandez-vous si cette commande a le potentiel de déconnecter votre session (règle fw, arrêt incorrect, etc.). Assurez-vous qu'il y ait un basculement (notamment si vous êtes hors site)

Si vous ne l'avez pas déjà fait, alias rm à rm -i

Règle 1 - faire des sauvegardes

Règle 2 - N'ajoutez JAMAIS de wrapper "molly guard" aux commandes standard, créez votre propre version, bien sûr, mais ne reprenez pas le nom, cela ne vous fera que vous mordre lorsque vous êtes sur un système que vous n'avez pas configuré.

Des astuces rapides telles qu'une couleur différente pour la racine et une arborescence de répertoires (partielle) sont d'excellents auxiliaires, mais encore une fois, assurez-vous de pouvoir travailler sans elles.

Cela peut sembler contre-intuitif et moins ardent, mais mon meilleur conseil de sécurité en ligne de commande est le suivant: Si une alternative en mode graphique est disponible et pratique, utilisez USE IT .

Pourquoi? Assez facile. Le mode GUI a généralement un filet de sécurité intégré, sous la forme d'un "avertissement - vous êtes sur le point de cogner le freeblefrop, êtes-vous sûr de vouloir faire cela?" Même si ce n'est pas le cas, cela vous ralentit et vous donne plus de temps pour réfléchir. Il vous permet de vérifier plus facilement les options avant de les valider. Vous pouvez effectuer une capture d'écran avant et après les états, il vous protège des fautes de frappe. toutes bonnes choses utiles et utiles.

Dans le cas classique de la redoutable "rm -rf", pensez-vous qu'il est plus facile de le publier accidentellement à partir d'une interface graphique ou d'une interface de ligne de commande?

En fin de compte, il n’ya pas de honte à avoir recours à une interface graphique. Cela n'empêchera pas infailliblement les catastrophes majeures; il est tout aussi possible d'être satisfait d'une gâchette dans une interface graphique que dans une interface de ligne de commande; mais si cela vous sauve une fois, cela prouvera qu'il en vaut la peine.

Faites preuve de bon sens et n'exécutez pas de commandes que vous ne comprenez pas. C'est tout un bon conseil. Si vous avez envie de peiner en écrivant le chemin absolu de tout ce que vous passez, ou en exécutant quoi que ce soit par le biais de sudo, n'hésitez pas. Je préférerais alors -c. Au moins, il ne cache pas le mot de passe. Je ne me sentirais pas à l'aise avec un utilisateur ordinaire autorisé à exécuter des tâches avec des privilèges root sans vérification du mot de passe.

Il y a quelques choses que vous pouvez mettre dans votre ~ / .bashrc pour rendre les choses un peu plus sûres, telles que:

alias srm='rm -i'

Vous permettant d'avoir une alternative sûre à la rm, ...

Mais à la fin, vous pouvez et vous foirez toujours. L'autre jour, un script de configuration obsolète a écrasé tout mon dossier / usr / bin, cassant plusieurs choses. Oui, une simple «installation» de tout type de logiciel contenant un bogue peut endommager votre système. Vous n'êtes jamais en sécurité, quoi que vous fassiez. Ce à quoi je veux en venir est la chose la plus importante:

Gardez des sauvegardes régulières.

Au lieu d'aliaser rm à rm -i, ne serait-il pas préférable d'alias de supprimer ou de supprimer plus sûrement (et de les utiliser comme outil de suppression de votre choix). Ensuite, lorsque vous utilisez une boîte qui n’a pas été configurée, aucun dommage n’est causé.

Assurez-vous de ne jamais exécuter de commande que vous trouvez en ligne, à moins que vous ne compreniez bien ce qu’ils font.

Votre système peut être différent de celui de l'affiche et cela pourrait causer un monde de blessures.

Un bon exemple pour la sécurité en ligne de commande d’un point de vue Unix / Linux est l’utilisation appropriée du compte root.
Un rm -rf en tant que root est généralement plus dangereux qu'en tant qu'utilisateur, et il est essentiel d'utiliser des éléments intégrés tels que sudo plutôt que de vous connecter en tant que root. Un simple whoami simple aidera généralement à combattre la schizophrénie ou de multiples personnalités.

Cela et le préfixe font écho à toutes les commandes filechanging, surtout si vous voulez vous assurer que vous avez le bon résultat pour un glob ou une regex.

Avoir une connexion secondaire à la machine sur laquelle vous travaillez peut être pratique si vous interrompez votre session principale ou si vous faites quelque chose de stupide qui la bloque ... un traitement lourd, etc.

De cette façon, vous avez toujours accès à la machine et pouvez tuer votre session principale.

La plupart des commentaires ci-dessus font référence à rm, mais j'ai aussi fait des choses stupides avec d'autres commandes ...

ifconfig pour démonter le réseau - ouch, cela nécessite une présence physique pour y remédier.

En ce qui concerne les scripts, je travaille généralement dans deux fenêtres. Le premier que j'utilise pour écrire le script, le second pour tester chaque ligne au fur et à mesure que je l'écris. En procédant lentement et avec précaution, je peux m'assurer que chaque ligne fonctionne comme prévu lorsque j'écris le code, en prenant soin de conserver les mêmes variables, etc.

Personnellement, je ne trouve pas les invites supplémentaires pour des choses comme rm -i vraiment utiles. Je fais la plupart de mes erreurs quand je suis fatigué, stressé, etc., ce sont des moments où je ne fais que taper du pied et ignorer l'invite de toute façon. Mauvaise pratique peut-être.

Si vous utilisez bash, essayez ceci:

TMOUT=600

dans votre /root/.bashrcou similaire. Il vous déconnecte automatiquement au bout de 10 minutes, ce qui réduit le risque de basculement vers un terminal root que vous avez accidentellement laissé ouvert et de taper quelque chose de stupide.

Oui, je sais que vous devriez utiliser sudo pour exécuter les commandes root - il s’agit simplement d’un filet de sécurité supplémentaire au cas où vous décideriez de jouer à risque un jour.

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

Un alias hautement recommandé à avoir si vous utilisez la CLI mysql.

Au lieu de ls, j'utilise echo pour que je puisse voir la commande complète une fois que le shell a tout développé. Aussi, doublez toujours les variables de guillemets qui représentent des fichiers afin que votre travail fonctionne avec des noms de fichiers pouvant comporter des tabulations ou des espaces.

J'évite le *glob comme argument personnel chaque fois que possible. Même si je veux vraiment dire "supprimer tout ce qui se trouve dans ce répertoire", j'essaie d'être plus précis, c'est-à-dire. rm *.php. Il s'agit d'un contrôle préventif des dommages au cas où j'exécuterais accidentellement la même commande en dehors de l'historique dans un autre répertoire.

Une excellente façon de vous faire penser à ce que vous faites est d’ajouter quelque chose comme ceci à la commande bashrc de root (cshrc, peu importe):

unset PATH

De cette façon, vous devez faire / bin / rm au lieu de "rm". Ces caractères supplémentaires pourraient vous faire réfléchir.

Pour les expressions rationnelles complexes, les commandes 'find', en particulier, placent l'écho devant et les capturent dans un fichier. Ensuite, vous pouvez vérifier que vous supprimez / déplacez / etc exactement ce que vous pensez être avant d'exécuter le fichier avec 'source'.

C'est également pratique pour ajouter manuellement ces cas marginaux que la regex n'a pas détectés.

Un peu de méta à l’égard des autres publications: j’utilise d’abord les étapes habituelles echo / ls suggérées pour vérifier que la commande sélectionne l’ensemble de fichiers que je veux ou que le shell l’interprète comme prévu.

Mais ensuite, j'utilise les fonctionnalités d'édition de l'historique des commandes du shell afin de récupérer la commande précédente et de ne modifier que les parties devant varier.

Cela n'aide pas du tout de taper chacune de ces commandes indépendamment ...

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

... parce que j'ai accidentellement tapé un espace dans la dernière ligne et supprimé tous les fichiers. Je voudrais toujours récupérer la ligne précédente et simplement supprimer le "écho".

utilisateur root:
Ne soyez pas root à moins que vous n'ayez à le faire.
Si le fournisseur dit qu'il doit être exécuté en tant que root, dites-lui que vous êtes le client et que vous souhaitez l'exécuter en tant que non-root.
Combien de logiciels disponibles sur le marché veulent la racine «simplement parce que c'est plus facile»?

habitude:
ne jamais utiliser '*' avec remove sans l'examiner trois fois Il est préférable de prendre l'habitude d'utiliser ls -l TargetPattern , puis d'utiliser 'rm! $'. La plus grande menace n'est pas d'être là où vous pensez être. Je tape presque 'hostname' aussi souvent que 'ls'!

béquilles:
une invite norme aide beaucoup, tout comme les alias comme « alias rm = « rm -i » », mais souvent je n'ai pas le contrôle total sur les machines que je suis sur donc j'utiliser un attendre simplement pour définir le script wrapper votre chemin , prompt et alias avec '-i'

trouver des problèmes:
utiliser un chemin complet aide, mais dans les cas où cela n'est pas possible, insérez cd dans un emplacement plus sûr et utilisez également '&&' pour vous assurer que le 'cd' réussit avant de trouver, supprimer, tar, untar, etc. etc:
exemple: l' cd /filesystema && tar cf - | ( cd /filesystemb && tar vxf -)
utilisation de '&&' peut empêcher un fichier tar d'être extrait sur lui-même dans ce cas (bien que dans ce cas, 'rsync' serait mieux)

supprime:
ne supprime jamais récursivement si vous pouvez l'aider, en particulier dans un script. rechercher et supprimer avec -type f et -name 'pattern' Je vis encore dans la crainte de ne rien nourrir avec xargs ... tar et untar pour déplacer des éléments (utilisez plutôt rsync)

Si vous utilisez plusieurs variantes d'un système d'exploitation, soyez très conscient des différences de syntaxe. ce qui est raisonnablement sûr sur une variante unix est extrêmement dangereux sur une autre.

Exemple: killall

Linux / FreeBSD / OSX - supprime tous les processus correspondant au paramètre transmis. Exemple: "killall apache" tue tous les apaches, laissant tous les autres processus seuls.

Solaris - tue tous les processus. Pas vraiment. Depuis la page de manuel : killall est utilisé par shutdown (1M) pour tuer tous les processus actifs non directement liés à la procédure d'arrêt.

Au lieu de

rm foo*

utilisation

rm -i foo*

C'est pratique avec une poignée de fichiers, mais pas avec une archive complète, par exemple. C'est pourquoi l'aliasing rmvous gênera.

Exécuter la commande avec echo en premier est une bonne idée, mais il reste sujet aux fautes de frappe.

Essayez de l'utiliser avec une extension telle que! $.

echo foo*
rm -rf !$

Le! $ Se développe jusqu'au dernier mot de la dernière commande, il est donc équivalent à

echo foo*
rm -rf foo*

Il existe également! *, Qui s'étend à tous les arguments de la dernière commande.

En effet, vous pouvez le faire de cette façon si vous préférez

echo rm -rf foo*
!*

(Si vous utilisez ksh, pas bash, vous pouvez taper Echap + point pour insérer le dernier mot.)

Dans le cas de quelque chose comme:

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

Vous pouvez utiliser l'opérateur de substitution, comme ceci:
$ ls * .php
<dir listing>

$ ^ ls ^ echo rm (ceci remplace ls dans la commande précédente par echo rm, en gardant le reste de la ligne de commande identique)

$ ^ echo rm ^ rm (remplace echo rm par just, ce qui évite de retaper * .php et de placer un espace au mauvais moment)

^ = shift-6, pour ceux qui ne le connaissent pas.

Utilisez bash et définissez PS1 = '\ u @ \ h: \ w>'. Cela se développe en nom_utilisateur @ nom_hôte: / full / working / directory / path> Comme indiqué dans d'autres réponses, vous pouvez utiliser expect pour configurer l'environnement chaque fois que vous vous connectez si vous ne pouvez pas mettre à jour les fichiers .profile ou .bash_profile. Changer les couleurs de fond est bien la meilleure réponse :-)

Ah oui. Cette astuce ancestrale consistant à envoyer à quelqu'un un fichier via IRC nommé "-rf" afin qu'il se retrouve dans leur répertoire ~. Un petit "rm -rf" plus tard (au lieu de "rm - -rf") et beaucoup de rire s'ensuivirent alors qu'ils apprenaient une dure leçon sur le fait de ne pas exécuter IRC en tant que racine.

Au lieu d'utiliser rm -rf <dir>mettre la -rffin comme ceci: rm <dir> -rf. Pensez-y comme si vous supprimiez la sécurité après avoir visé et avant de tirer. De cette façon, vous êtes protégé si vous avez un bout de la touche Entrée lorsque vous tapez le nom du répertoire (ou utilisez la complétion par tabulation) et que vous avez des répertoires portant le même nom.