SysAdmin Tips

Aujourd’hui je vais vous exliquer comment transférer des répertoires de manière récursive, en conservant les permissions et les dates des fichiers, et le tout de manière cryptée.  De manière récursive, cela signifie que l’on prend tous les sous répertoires d’un répertoire donné, ainsi que leurs sous répertoires à eux et ainsi de suite.

Une commande sous linux permet de faire cela facilement : scp. Si vous réalisez régulièrement des transferts entre deux serveurs précis, je vous recommande de mettre en place une authentification par clé, afin de ne pas toujours devoir donner les mots de passes, en suivant la procédure expliquée ici.

La syntaxe de base est la suivante:

scp -rp user@serveurdistant.com:/home/user/repertoire .

Les switchs rp permettent respectivement de travailler de manière récursive et de conserver les temps d’accès, de modification ainsi que la valeur du chmod original. Ensuite, nous spécifions l’utilisateur distant utilisé (avant l’@), le nom ou l’ip de la machine distante. Après les deux points, c’est le répertoire de base sur la machine distante. Suit enfin, le répertoire de destination sur la machine locale. Le point indique « ici », mais vous pouvez bien entendu spécifier le répertoire de votre choix.

Comme précisé au début de l’article, le transfert est crypté, réalisé sur base du protocole SSH, à contrario de FTP où toutes les informations (données et mots de passe) circulent en clair sur le réseau, permettant à chacun de se servir allégrement.

Je vous invite à consulter la page de manuel de scp si vous désirez obtenir plus d’informations sur cet utilitaire très utile.

Dans un prochain article, nous verrons comment réaliser des sauvegarders incrémentales.

Système scp, ssh

Le but de cet article est d’arriver à établir une liaison SSH entre deux serveurs sans devoir entrer manuellement de mot de passe à la connexion. L’intérêt est double :

• lors de la réalisation d’un backup lancé en crontab, ou même de simple transfert de fichiers lancés par vous en console;
• lorsque vous passez d’une machine à l’autre régulièrement.

Dans le premier cas cité, il est impossible de rentrer manuellement le mot de passe, l’intérêt du crontab étant précisément de ne pas intervenir. Dans les deux autres, c’est simplement par pur confort.

Se connecter sans mot de passe, c’est bien, mais c’est la porte ouverte à des dérives. Il faut donc un autre moyen de s’identifier pour autoriser l’accès à des données parfois confidentielles. La réponse à se problème est l’utilisation d’un couple de clés, l’une privée et l’autre publique. Le but de l’article n’est pas de faire un cours sur le fonctionnement de la paire de clé, mais pour donner le background nécessaire, je dirai simplement que la clé publique est stockée sur le serveur distant et que vous utilisez la clé privée pour vous y connecter. Un contrôle supplémentaire sur l’adresse IP utilisée peut également facilement être mis en place pour éviter tout problème en cas de vol de votre clé privée.

Pour la suite de l’article, le scénario est le suivant : le serveur A se connecte au serveur B.

Sur le serveur A, connectez-vous au nom de l’utilisateur qui sera utilisé pour se connecter au serveur B. Tapez les commandes qui suivent sur l’invite de commande. Vous devrez répondre à quelques questions. Nous laissons le fichier par défaut pour le fichier dans lequel sauver la clé; nous ne mettons pas de passphrase.

ssh-keygen -t rsa -b 4096
cd ~/.ssh
cat idrsa.pub

S’affichera alors votre clé publique, que vous copiez dans votre presse-papier pour utilisation future.

Sur le serveur B, connectez-vous au nom d’utilisateur qui recevra la connexion du serveur A et tapez-y les commandes suivantes:

mkdir -p ~/.ssh
cd ~/.ssh

Editez ensuite le fichier authorized_keys2 (qui n’existe peut-être pas), et ajoutez-y la ligne suivante, où X représente la clé publique du serveur A se trouvant dans votre presse-papiers.

from="ip du serveur A" X

Vérifiez que la clé publique du serveur A ne contient pas de retours à la ligne. Ensuite, faites en console

chmod -R 600 ~./ssh

afin de donner les bonnes permissions au fichier créé ainsi qu’au répertoire le contenant.

Le serveur A peut maintenant se connecter au serveur B sans devoir entrer de mot de passe. Si vous devez également réaliser une connexion du serveur B vers le serveur A, il est nécessaire de reprendre cette procédure dès le début, en inversant A et B.

Système ssh

Dans un contexte de serveur d’hébergement offert à plusieurs utilisateurs, il est de coutume de leur donner un accès via FTP pour qu’ils puissent mettre en ligne leur site et de limiter leur accès à leur /home (via un chroot).

Si vous utilisez la liste des utilisateurs système pour le FTP, ces utilisateurs ont également par défaut un accès SSH et donc des droits en lecture sur pas mal de fichiers, ce qui est légitime de vouloir restreindre aux utilisateurs de confiance.

La solution est de créer un groupe d’utilisateurs, que nous nommerons par exemple sshallow dans le quel il suffit de placer les utilisateurs qui disposeront d’un droit d’accès à SSH. La création d’un groupe se fait via la commande addgroup sshallow.

Nous ajoutons alors les utilisateurs désirés dans le groupe adduser nom sshallow. N’oubliez pas d’y ajouter l’utilisateur avec lequel vous administrez la machine!!!

Ensuite, nous informons le serveur SSH de l’existence du groupe en éditant le fichier /etc/ssh/sshd_config et en y rajoutant la directive AllowGroups sshallow.

Il ne reste plus qu’à redémarrer le serveur ssh. Avant de fermer la fenêtre, je vous recommande de tester une nouvelle connexion avec l’utilisateur que vous utilisez habituellement pour administrer la machine afin de s’assurer qu’il n’y a aucun blocage.

Système ftp, ssh

Vous avez sûrement déjà constaté qu’une connexion SSH laissée ouverte trop longtemps sans activité fini par se couper au bout d’un certain temps. La raison vient du fait que votre FAI coupe les connexions inactives au bout d’un certain temps.

Pour éviter celà et ne pas devoir vous reconnecter intempestivement, il suffit d’éditer le fichier /etc/ssh/sshd_config, et d’y rajouter la directive ClientAliveInterval 60, sans oublier de redémarrer le serveur SSH.

Avec cette directive, le serveur SSH enverra à votre client un paquet « keep-alive » toutes les 60 secondes pour éviter que la connexion soit déclarée inactive et donc coupée

Système ssh

Fail2ban est un démon qui lit les fichiers de logs au fur et à mesure de leur écriture afin de bloquer les ip indésirables pendant un temps donné. Le but est simplement d’éviter de surcharger votre serveur avec des dizaines de requêtes par seconde dont le seul but est d’essayer de trouver un couple utilisateur/mot de passe valide afin de tenter de hacker votre machine ou de s’en servir comme relais pour l’envoi de courrier électronique indésirable.

Fail2ban intègre par défaut le contrôle des scans SSH, en lisant votre fichier /var/log/auth.log. Il n’y a donc pas de configuration particulière à faire pour ssh.

Il est possible de le configurer pour qu’il lise aussi votre /var/log/mail.log afin de bloquer les adresses ip qui floodent votre serveur de courrier avec des couples login/mots de passe invalides. L’espoir des hackeurs est de tomber sur un serveur qui pratique le pop-before-smtp, c’est à dire la technique qui consiste à d’abord lire son courrier puis d’utiliser le serveur smtp. Le fait de s’authentifier avec succès sur le serveur pop implique que votre adresse ip est autorisée à envoyer du courrier pendant un certain temps, vers toutes les destinations. Les hackeurs peuvent alors se servir de votre serveur pour envoyer leur spam à la terre entière.

La première étape est de demander à dovecot de transcrire dans les logs les tentatives de connexion échouées. Cela se fait en éditant son fichier de configuration /etc/dovecot/dovecot.conf et en positionnant la directive auth_verbose à true.

Ensuite, il faut éditer le fichier /etc/fail2ban/jail.local et y rajouter

[dovecot-auth]
enabled  = true
port     = imap,imaps,pop3,pop3
sfilter   = dovecot-auth
logpath  = /var/log/mail.log

Vous pouvez rajouter d’autres directives: maxretry (nombre de tentatives après blacklistage), ignoreip (liste d’ip qui ne seront pas blacklistées séparées par des espaces) et bantime (temps de blacklistage en secondes). Attention, ne pas oublier de mettre 127.0.0.1 dans la liste des ip à ignorer, sans quoi des tentatives infructueuses via un webmail conduiraient à un auto-blacklistage, ce qui aurait un impact sur toutes les applications (postfix ne saurait plus se connecter à MySQL, par exemple). En haut du fichier, ces 3 directives sont présentes de manière globale, le fait de les repréciser dans une règle leur fait prendre le dessus pour la règle en cours.

Ensuite, créer un fichier /etc/fail2ban/filter.d/dovecot-auth.conf et y mettre

[Definition]
failregex = auth-worker(.*): sql(.*,<HOST>): unknown user

Il est évident qu’il peut être nécessaire d’adapter la regexp à votre situtation, l’ip à blacklister étant représentée par <HOST>. Dans ce cas-ci, on ne bloquera que les utilisateurs inexistants, la regexp peut par exemple être adaptée pour prendre en compte les vrais utilisateurs qui se trompent de mot de passe.

Redémarrer fail2ban et dovecot pour les faire prendre en compte leur nouvelle configuration.

Fail2ban consigne ses actions dans le fichier /var/log/fail2ban.log.

Système dovecot, hacker, imap, pop, scan, spam, ssh