De temps en temps, je reçois une demande impaire de fournir une assistance, un dépannage et / ou un réglage des performances à distance sur les systèmes Linux.

Les grandes entreprises ont souvent déjà des procédures bien établies pour fournir un accès à distance aux vendeurs / fournisseurs et je n'ai qu'à me conformer à celles-ci. (Pour le meilleur ou pour le pire.)

D'autre part, les petites entreprises et les particuliers se tournent invariablement vers moi pour leur indiquer ce qu'ils doivent faire pour me mettre en place. Généralement, leurs serveurs sont directement connectés à Internet et les mesures de sécurité existantes consistent à utiliser les valeurs par défaut de leur distribution Linux.

Presque toujours, j'aurai besoin d'un accès de niveau racine et quiconque configurera l'accès pour moi n'est pas un administrateur système expert. Je ne veux pas de mot de passe root et je suis également convaincu que mes actions ne seront pas malveillantes, mais quelles instructions relativement simples devrais-je donner à:

• créer 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 une piste d'audit

(Et oui, je suis conscient et avertis toujours les clients qu’une fois que j’ai un accès administrateur, cacher toute action malveillante est trivial, mais supposons que je n’ai rien à cacher et que je participe activement à la création d’un journal d’audit.)

Que peut-on améliorer sur les étapes ci-dessous?

Mon jeu d'instructions actuel:

créer un compte et échanger en toute sécurité des informations d'identification

Je fournis un mot de passe et demande que mon compte soit configuré avec ce mot de passe crypté. Nous n'avons donc pas besoin de transmettre de mot de passe en texte clair. Je suis le seul à connaître le mot de passe et nous ne commençons pas par un mot de passe faible prévisible.

sudo useradd -p '$1$********' hbruijn

Je fournis une clé publique SSH (paire de clés spécifique par client) et leur demande 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 configurer sudo pour moi avec sudo sudoeditou en utilisant son éditeur préféré et ajoute à /etc/sudoers:

hbruijn ALL=(ALL) ALL

restreindre l'accès à mon compte

En règle générale, le client autorise toujours les connexions avec mot de passe et je leur demande d'ajouter les deux lignes suivantes pour /etc/ssh/sshd_configlimiter au moins mon compte aux clés SSH:

Match user hbruijn
PasswordAuthentication no

En fonction du client, je vais acheminer tous mes accès SSH via un seul hôte bastion afin de toujours fournir une adresse IP statique unique (par exemple 192.168.1.2) et / ou de fournir la plage d'adresses IP utilisée par mon fournisseur de services Internet (par exemple 10.80). 0,0 / 14). Le client peut avoir besoin d’ajouter celles-ci à une liste blanche de pare-feu si l’accès SSH est restreint (le plus souvent, SSH n’est pas filtré).

Vous avez déjà vu ces adresses IP comme la from=restriction dans le ~.ssh/authorized_keysfichier qui limite les hôtes à partir desquels ma clé peut être utilisée pour accéder à leurs systèmes.

fournir une piste d'audit

Jusqu'à présent, aucun client ne m'a demandé cela, et je n'ai rien fait de particulier à part les choses suivantes pour couvrir mes fesses:

J'essaie d'utiliser systématiquement sudoavec des commandes individuelles et essaie d'éviter d'utiliser sudo -iou sudo su -. J'essaie de ne pas utiliser sudo vim /path/to/file mais d'utiliser à la sudoeditplace.

Par défaut, toutes les actions privilégiées seront ensuite consignées dans 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

La plupart du temps, j'ai abandonné la personnalisation de mes environnements de travail. La seule chose que je fais réellement est de définir les éléments suivants dans mon ~/.bash_profilehistorique croissant de bash et d'inclure des horodatages:

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 me vienne à l’esprit serait d’ajouter --expiredateà l’ adduserappel.
Avec cela, le client sait que votre accès expirera automatiquement à une date fixe.

Il doit toujours vous faire confiance car vous disposez d'un accès root et pouvez toujours supprimer l'indicateur d'expiration.

Vous pouvez enregistrer vos sessions avec l' utilitaire de script (1) .

$ script session.log
Script started, file is session.log
$ ls
file1  session.log
exit
Script done, file is session.log

alors tout est dans session.log.

Étant donné que vous vous connectez déjà avec une clé publique SSH, il serait un peu plus serré si vous ne fournissiez pas de mot de passe haché; Au lieu de cela, dites-leur d'utiliser adduser --disabled-password(de manière équivalente, useradd -p '!'je pense), ce qui est en réalité équivalent à PasswordAuthentication noce compte, et il n'y a aucune chance que quelqu'un fouille dans votre courrier électronique puisse forcer brutalement le hachage du mot de passe et se connecter en tant que vous.

Pourquoi fournir un mot de passe quand vous allez utiliser des clés publiques / privées.

Les clés publiques sont destinées à être partagées. C'est donc ce que vous devez utiliser pour échanger des informations d'identification en toute sécurité, et non des mots de passe hachés.

sudo useradd --disabled-password hbruijn

Lorsque vous envoyez votre clé publique, vérifiez l’empreinte digitale sur un deuxième canal, comme un appel téléphonique, pour que vous sachiez que personne ne l’a modifiée en entrant.

Puisque vous n'avez pas de mot de passe pour utiliser sudo, vous devez également modifier votre ligne dans le fichier sudoers en

hbruijn ALL=(ALL) NOPASSWD:ALL

Si vous n'êtes pas à l'aise avec le fait de ne pas avoir de mot de passe pour sudo et que vous voulez vraiment un mot de passe, vous n'avez toujours pas besoin d'envoyer votre mot de passe haché, de laisser le compte être créé sans mot de passe, de définir votre clé publique et une fois votre compte créé. configurer, vous pouvez vous connecter sur ssh et exécuter passwdpour définir votre propre mot de passe.