Linux: configurez la sysadmin distante
De temps en temps, je reçois la demande étrange de fournir un support à distance, un dépannage et/ou un réglage de performance sur les systèmes Linux.
Les grandes entreprises ont souvent déjà des procédures bien établies pour fournir un accès à distance aux fournisseurs/fournisseurs et il suffit de respecter les personnes. (Pour le meilleur ou pour le pire.)
D'autre part, les petites entreprises et les personnes se tournent invariablement vers moi pour leur instruire avec ce qu'ils doivent faire pour me préparer. Généralement, leurs serveurs sont directement liés à Internet et que les mesures de sécurité existantes sont constituées des valeurs par défaut de la répartition Linux.
Presque toujours, je vais avoir besoin d'un accès de niveau racine et quiconque mettra en place un accès pour moi n'est pas une sysadmin expert. Je ne veux pas que leur mot de passe root et je suis aussi assez sûr mes actions ne sera pas malveillant, mais quelles instructions raisonnablement simples dois-je donner à:
- mettre en place un compte et échanger en toute sécurité des informations d'identification
- configurer l'accès root (sudo)
- restreindre l'accès à mon compte
- fournir un sentier d'audit
(Et oui, je suis au courant et vous avertiez toujours ces clients qu'une fois que j'ai eu l'accès administrateur cacher des actions malveillantes est triviale, mais supposons que je n'ai rien à cacher et de participer activement à la création d'une piste d'audit.)
Qu'est-ce qui peut être amélioré sur les étapes ci-dessous?
Mon ensemble d'instructions actuelles:
mettre en place un compte et échanger en toute sécurité des informations d'identification
Je fournis un hash de mot de passe et demandez que mon compte est configuré avec ce mot de passe crypté. Nous n'aurons donc pas besoin de transmettre un mot de passe texte clair, je serai le seul à connaître le mot de passe et nous ne commençons pas avec un mot de passe faible prévisible.
Sudo useradd -p '$1$********' hbruijn
Je fournis une clé publique SSH (paire de clé spécifique par client) et demandez-leur de configurer mon compte avec cette clé:
Sudo su - hbruijn
mkdir -p ~/.ssh
chmod 0700 ~/.ssh
echo 'from="10.80.0.0/14,192.168.1.2" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault' >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys
configurer l'accès root (sudo)
Je demande au client de mettre en place sudo pour moi avec Sudo sudoedit ou en utilisant leur éditeur préféré et à ajouter à /etc/sudoers:
hbruijn ALL=(ALL) ALL
restreindre l'accès à mon compte
Généralement, le client autorise toujours les connexions basées sur le mot de passe et je leur demande d'ajouter les deux lignes suivantes à /etc/ssh/sshd_config Pour restreindre au moins mon compte aux clés SSH uniquement:
Match user hbruijn
PasswordAuthentication no
Selon le client, je vais parcourir tout mon accès SSH via un seul hôte de bastion pour toujours fournir une adresse IP statique unique (par exemple 192.168.1.2) et/ou fournir la plage d'adresses IP mon fournie par ISP (par exemple 10.80. 0,0/14). Le client peut avoir besoin d'ajouter celles à un whitelist de pare-feu si l'accès SSH est restreint (plus souvent que pas SSH n'est pas filtré).
Vous avez déjà vu ces adresses IP comme from= restriction dans le ~.ssh/authorized_keys Fichier qui limite les hôtes à partir desquels ma clé peut être utilisée pour accéder à leurs systèmes.
fournir un sentier d'audit
Jusqu'à présent, aucun client ne m'a demandé cela, et je n'ai rien fait spécifique au-delà des éléments suivants pour couvrir mon cul:
J'essaie d'utiliser systématiquement Sudo avec des commandes individuelles et essayez de prévenir d'utiliser Sudo -i ou Sudo su -. J'essaie de ne pas utiliser Sudo vim /path/to/file mais utilisez sudoedit à la place.
Par défaut, toutes les actions privilégiées seront ensuite connectées à Syslog (et /var/log/secure):
Sep 26 11:00:03 hostname Sudo: hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=jboss ; COMMAND=sudoedit /usr/share/jbossas/domain/configuration/domain.xml
Sep 26 11:00:34 hostname Sudo: hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=root ; COMMAND=/usr/bin/tail -n 5 /var/log/messages
J'ai principalement abandonné la personnalisation de mes environnements de travail, la seule chose que je fais vraiment est de définir ce qui suit dans mon ~/.bash_profile Augmenter l'historique des bash et inclure des timbres temporels:
export HISTSIZE=99999999999
export HISTFILESIZE=99999999999
export HISTIGNORE="w:ls:ls -lart:dmesg:history:fg"
export HISTTIMEFORMAT='%F %H:%M:%S '
shopt -s histappend
La seule chose qui vient à l'esprit serait d'ajouter --expiredate à l'appel adduser.
[.____] avec ce que le client sait que votre accès expirera automatiquement à une date fixe.
Il a encore besoin de vous faire confiance car vous avez un accès racine et pourriez toujours supprimer le drapeau de l'expiration.
Vous pouvez enregistrer vos sessions avec le script (1) utilitaire.
$ script session.log
Script started, file is session.log
$ ls
file1 session.log
exit
Script done, file is session.log
alors Tout est en session.log.
Puisque vous vous connectez déjà avec une clé publique SSH, elle serrerait un peu les choses si vous n'avez pas fourni de cas de mot de passe; au lieu de leur dire d'utiliser adduser --disabled-password (équivalent, useradd -p '!', Je pense), ce qui est effectivement équivalent à PasswordAuthentication no Pour ce compte, plus il n'y a aucune chance que quelqu'un snooping sur votre email puisse brut-forcer le hash de mot de passe et connecter comme vous.
Pourquoi fournir un mot de passe du tout, lorsque vous allez utiliser des clés publiques/privées.
Les clés publiques sont censées être partagées. Voici ce que vous devez utiliser pour échanger de manière sécurisée des identifiants, pas des mots de passe hachés.
Sudo useradd --disabled-password hbruijn
Lors de l'envoi de votre clé publique, vérifiez l'empreinte digitale sur une seconde chaîne, comme un appel téléphonique, vous savez donc que personne ne l'a modifié sur son chemin.
Puisque vous n'aurez pas de mot de passe maintenant pour utiliser sudo, vous devez également modifier votre ligne dans le fichier sudoers pour
hbruijn ALL=(ALL) NOPASSWD:ALL
Si vous n'êtes pas à l'aise avec aucun mot de passe pour sudo et que vous souhaitez vraiment un mot de passe, il n'est pas nécessaire que vous n'ayez pas besoin d'envoyer votre mot de passe haché, que le compte soit créé sans mot de passe, définissez votre clé publique et une fois votre compte. Configurer Vous pouvez vous connecter via SSH et exécuter passwd pour définir votre propre mot de passe.