Archives par mot-clé : Unix

Bien recevoir son serveur dédié (suite : c’est jamais fini)

Je reviens sur la sécurisation de mon petit serveur.Je dois avouer que depuis le changement de port SSH, je suis plutôt tranquille. Je vais tout de même aller plus loin en réduisant la liste des users autorisés à se connecter via SSH.

Et comme toujours, c’est relativement simple. On édite le fichier /etc/ssh/sshd_config et on ajoute une ligne du type :

AllowUsers moncompte

Bien recevoir son serveur dédié (suite part 2)

J’ai dans mon panier 2 solutions à mes problèmes d’attaque de force brute sur ma connexion SSH :

  • le démon denyhosts
  • et, plus simplement, changer le port par défaut d’écoute de SSH

denyhosts

denyhosts, c’est un processus daemon qui scrute votre fichier de log où se trouve toutes les traces de tentatives de connexions. Toutes les hosts qui génèrent trop d’erreur de connexion seront blacklisté.

L’installation prend 2 secondes sous Ubuntu :

sudo apt-get install denyhosts

Et voilà, c’est fait et c’est fonctionnel. Vous trouverez les fichiers listant les tentatives suspicieuses de connexion dans :

/var/lib/denyhosts

Il ne restera plus qu’à compléter le fichier de configuration avec un serveur d’envoi des mails pour recevoir une alerte à chaque fois qu’une adresse est ostracisée.

Changer de port

Par défaut, SSH écoute sur le port 22. Il est facilement modifiable dans le fichier :

/etc/ssh/sshd_config

Puis par un simple arrêt / relance du démon SSH :

/etc/init.d/sshd restart

Vous devriez voir le nombre de tentative se réduire drastiquement.

Toutefois, il faut être vigilant sur cette dernière astuce (et sur celle qui consiste à empêcher l’utilisateur root de se connecter). Je ne sais pas comment ça se passe pour les autres hébergeur mais chez OVH, lorsqu’ils livrent un serveur, ils installent une clef pour pouvoir se connecter en root lorsqu’une intervention est nécessaire. Interdire l’utilisateur root ou changer le numéro de port rendra toute intervention de l’hébergeur impossible. Renseignez-vous bien auprès de ce dernier ou, au moins, ayez conscience que vous serez à bord et que si vous n’avez plus accès à votre machine, il n’y aura plus d’autre choix que de la réinstaller (d’où l’importance d’avoir un plan de sauvegarde bien roder 🙂 ).

Bien recevoir son serveur dédié (suite)

Où est-ce que j’en étais ? Ha oui, on a créé l’utilisateur qui va nous servir d’administration avec les droit sudo qui vont bien. C’est bien beau mais on peut encore protéger notre utilisateur root un peu plus. Et pour cela, on peut simplement empêcher les connexions à distance avec le compte root. Editer le fichier /etc/ssh/sshd_config et remplacer avec la valeur ci-dessous :

PermitRootLogin No

Ce qui est marrant, c’est que sans n’avoir encore rien fait de concret avec ce serveur, on peut voir les attaques de force brut pour se connecter avec des utilisateurs courant. Voici un extrait de mon /var/log/auth.log :

Nov 30 07:40:39 XXXXXXXX sshd[27464]: Failed password for root from 91.121.166.49 port 51087 ssh2
Nov 30 07:40:39 XXXXXXXX sshd[27466]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:39 XXXXXXXX sshd[27466]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:42 XXXXXXXX sshd[27466]: Failed password for root from 91.121.166.49 port 51305 ssh2
Nov 30 07:40:42 XXXXXXXX sshd[27468]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:42 XXXXXXXX sshd[27468]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:44 XXXXXXXX sshd[27468]: Failed password for root from 91.121.166.49 port 51640 ssh2
Nov 30 07:40:44 XXXXXXXX sshd[27470]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:44 XXXXXXXX sshd[27470]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root
Nov 30 07:40:46 XXXXXXXX sshd[27470]: Failed password for root from 91.121.166.49 port 51833 ssh2
Nov 30 07:40:46 XXXXXXXX sshd[27472]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Nov 30 07:40:46 XXXXXXXX sshd[27472]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ks360976.kimsufi.com  user=root

Ici, ce sont plusieurs tentative de connexion avec l’utilisateur root (d’où ma soudaine prise de conscience d’interdire tout accès root à distance). Des logs de ce genre, on y voit des utilisateur oracle, irc, nagios, postgres ou encore trac.

De ces observation, je vais en retirer 3 conclusions :

  • tout mot de passe de ce serveur sera complexe et généré par un outil du type keepass
  • lorsque j’installerai ma suite logiciel, je choisirai soigneusement et personnellement des noms d’utilisateur totalement atypique
  • avoir un serveur, aussi petit soit-il, ça rend paranoïaque ; le prochain article de ce serveur dédié portera très certainement sur un firewall

 

La puissance du côté négatif de la force

Le côté négatif, c’est tout simplement le caractère ‘‘ et la force, chez nous aujourd’hui, est la shell Unix. Ce fameux caractère dash est un fabuleux outil à plusieurs facettes. Connaître ses possibilité est au moins aussi (si ce n’est plus) essentiel que de connaître quelques raccourcis claviers (comprendre que ça vous fera gagner du temps. Après si vous êtes pas pressés dans la vie, vous pouvez passer votre chemin).

Le caractère dash comme représentation du dernier répertoire

C’est un classique, taper la commande suivante pour revenir dans le répertoire précédent

cd -

Par exemple :

[user@host:/etc]$ cd /var/log
[user@host:/var/log] cd -
[user@host:/etc] cd -
[user@host:/var/log] cd -
[user@host:/etc]
...

On ne remonte pas l’historique des répertoires mais on est bien content quand on se trouve dans la situation où on lance une application, on regarde les logs, on change une configuration, on relance, on vérifie les logs, on change une configuration, on relance, on vérifie les logs, … Cette boucle vertueuse se révèle bien plus rapide, avec un ‘cd –‘ et une (ou 2) commande(s) dans le presse papier.

Le caractère dash comme redirection d’entrée/sortie

C’est dans ce chapitre que la force nécessite du contrôle. Bien caché dans une commande le caractère ‘‘ représente une redirection d’un fichier vers la sortie standard ou inversement  de l’entrée standard vers un fichier. Les exemples suivant devraient illustrer mon propos. Imaginons que je sois en pleine rédaction de scripts pour archiver des fichiers de log ou manipuler ces mêmes archives. Basiquement pour archiver, j’utiliserai les commandes suivantes :

tar cf archives_20111116.tar *.log
bzip2 archives_20111116.tar

un inconvénient qui (devrait) saute(r) au yeux est l’utilisation de ce fichier archives_20111116.tar à la durée de vie très limitée et au moins de taille égale aux fichiers de logs que je veux archiver. Heureusement la caractère ‘-‘ est là pour nous sauver, on recommence et on remplace par :

tar cf - *.log | bzip2 > archives_20111116.tar.bz

Ici, la commande tar écrit sur la sortie standard au lieu d’écrire dans un fichier, il n’y a donc plus de fichier temporaire, tout transite en mémoire au fur et à mesure que la compression avance.

C’est pas tout, mais j’aimerai bien les décompresser moi ces archives mais sans les altérer et sans utiliser de fichier temporaire (comme à l’archivage en somme). Et bien, la force reste avec vous jusqu’au bout :

bzip2 -d archives_20111116.tar.bz | tar xf -

La commande tar lit l’entrée standard au lieu de lire le contenu d’un fichier. Je ne pense pas que vous vous rendiez compte de la magie qui se cache derrière ces manipulations ; l’exemple ici est plutôt simple et basique mais en gardant constamment cette fonctionnalité à l’esprit, on obtient des commandes puissantes en une seule ligne. Mon dernier exemple en date : une comparaison de fichier local et distant :

ssh user@host "cat /etc/hosts" | diff -wb /etc/hosts -

Le caractère dash comme délimiteur d’option

Sur une commande, tous les mots qui commence par ‘-‘ sont des options. A priori, je vous apprends rien. Mais alors comment se dépêtrer des noms de fichier qui commencent par ce même caractère ? Ou comment s’assurer que l’utilisateur n’ajoutera une option insidieusement au sein d’un de vos shell ? La réponse : le double dash ‘–‘. Le double dash indique la fin des options. Ceci signifie que tout ce qui se suit sur la commande ne sera pas considéré comme une option. Un exemple valant mieux qu’un long discours, voici comment faire pour supprimer un fichier nommé ‘-filename‘ :

rm -f -- -filename

Malheureusement, tout les shell n’implémente pas ce séparateur d’options et, à ma connaissance, seul le Bash le propose.

Allez, maintenant, il est temps de renouveler ce classique shell d’archivage et de sans cesse l’améliorer (comme ce qu’on devrait faire dans tout ce qu’on entreprend).

Bien recevoir son serveur dédié

Cette nuit, j’ai reçu un petit serveur dédié provisionné par Kimsufi/OVH avec une pré-installation Ubuntu. Il devrait me servir à mettre en place ma propre plate-forme d’intégration continue en Java et autre Grails…mais, je n’y suis pas encore ; j’y reviendrai sûrement.

Si vous commandez un de ces serveurs, sachez que la disponibilité affiché d’1 heure ne correspond à rien car, vous passerez par des étapes de validation de vos moyens de paiements. Pour ma part, ça a prit environ 7 heures mais si vous n’avez pas de chance, vous aurez des papiers à renvoyer pour validation.

Le serveur reçu est fourni avec un compte root et si il y a bien une habitude à ne pas prendre, c’est celle de ne pas utiliser quotidiennement ce compte mais d’en passer par un autre. Donc, on créé son compte utilisateur tout de suite :

useradd -m -d /home/moncompte moncompte
passwd moncompte

Maintenant, pour ne plus jamais avoir à utiliser ce compte (comme dans les installations par défaut d’Ubuntu), il faut configurer ce nouveau compte pour l’autoriser à faire des sudo. Rien de plus simple, il suffit d’appartenir au groupe sudo :

adduser moncompte sudo

Reconnectez vous avec votre nouveau compte fraîchement créé et mettez à jour votre distrib :

sudo apt-get update
sudo apt-get upgrade

Voici le minimum vital que j’ai appliqué dès réception. Et je vous conseille d’en faire autant et de ne jamais utiliser de telnet et de ftp, vous pouvez tous faire avec SSH.