[Tuto] Configurer et Sécuriser un accès SSH

[Tuto] Configurer et Sécuriser un accès SSH

Configurer et sécuriser un accès SSH, il n’y a rien compliqué mais cela est indispensable pour votre server. Aujourd’hui nous allons présenter une méthode de sécurisation simple, rapide et que je trouve relativement efficace. Le server sera sur Ubuntu server 10.04 LTS. Ce tutoriel est inspiré largement de celui disponible sur le site de Korben (http://korben.info/tuto-ssh-securiser.html).

Dans ce tutoriel, on partira du principe que le serveur est délocalisé et donc nous ne l’avons pas installé nous-même. Si toutefois vous avez installé votre propre serveur, vous devrez installer openssh  lors de votre première connexion par la commande : « sudo apt-get install openssh-server ». Le reste de la configuration est identique aux deux cas de figure.

On vous enverra par mail l’accès qui sera certainement avec le super utilisateur (root, noté #) et un mot de passe relativement court. En clair, si quelqu’un arrive à cracker votre mot de passe, il pourra faire ce que bon lui semble. Voilà toute l’utilité d’une configuration précise d’un accès ssh.

Une histoire de ports … et d’utilisateurs

Pour vous connecter en SSH à votre serveur, la procédure change selon le système d’exploitation de votre ordinateur. Si vous êtes sur Windows, vous devez télécharger le logiciel Putty. Une fois téléchargé, lancez l’exécutable. Dans la page « Session », entrez l’adresse ip de votre serveur dans « Host Name », ainsi que « 22 » dans l’espace port (c’est le port par défaut pour le SSH). On vous demandera par la suite le pseudo. Si vous êtes sous Unix, un simple ssh user@ipserver.  Puis indiquez votre mot de passe. Ne soyez pas surpris si rien ne s’affiche, un des avantages (ou désavantages) d’Unix est la sécurisation des accès.

Une fois identifiés, on met les paquets à jour :

Puis on va créer un nouvel utilisateur. Cet utilisateur sera celui (et le seul) qui utilisera le ssh, il lui faut donc un mot de passe compliqué. Ici on appellera notre utilisateur zedd.

Vous y remplirez les données qui vous seront demandées.

Nous allons maintenant vérifier que l’on peut se connecter en ssh.  Dans un premier temps on redémarre le ssh.

Puis on quitte notre session ssh.

On va maintenant se connecter avec l’utilisateur zedd. On remet notre ip server et cette fois, le pseudo utilisé sera zedd. On entre le mot de passe et comme par magie, nous voilà dans le /home de zedd. Cet utilisateur n’est pour l’instant qu’un simple utilisateur : il n’a presque pas de droits. Mais on peut repasser facilement en mode super utilisateur via la commande « su ».

Mettez le mot de passe super utilisateur, et vous voilà de retour en root.

On va maintenant éditer le fichier de config du ssh. Il s’appelle sshd_config. Pour cela on va utiliser l’éditeur de texte intégré ; VI. Pour écrire dans VI, il faut appuier sur « i ». On est alors en mode insertion. Pour en sortir, un simple « Echap » suffit. Pour sauvegarder et quitter, tapez « :wq » (pour write and quit). Pour sortir sans sauvegarder c’est « :q » (quit).

Là, nous aurons plusieurs parties à éditer.

1^er changement, le port par défaut. Une des attaques les plus dévastatrices est sans aucun doute le BRUTE FORCE. En clair, il s’agit une attaque sur le port par défaut. Le changer permettra de réduire considérablement les attaques visant votre serveur. Pour ma part j’opte pour un port à 5 chiffres.  Dans notre exemple, on prendra 1234.

2^ème changement, on interdit l’utilisateur root de se connecter en ssh. Cela bloquera toutes les tentatives d’accès en ssh avec le super utilisateur. Néanmoins, une fois loggé sous le pseudo zedd, vous pourrez y accéder via la commande « su » et le mot de passe super utilisateur.

On vérifie que la ligne PermitEmptyPasswords est bien sur « no ».

On vérifie également les lignes suivantes :

3^ème changement, les tentatives d’accès simultanés. Ce sont les valeurs de la ligne MaxStartups. Pour ma part j’aime bien mettre 3 à la première valeur. Dans mon cas, je fais donc un MaxStartups 3:15:20.

4^ème et dernier changement, le choix des utilisateurs qui auront accès au ssh. Il s’agit du dernier bloc d’informations du fichier et voilà ce que cela doit donner :

Dernière vérification, pour une future connexion en SFTP (secured FTP), vérifier que la ligne Subsystem sftp /usr/lib/openssh/sftp-server est bien dé-commentée. (pas de #)

On enregistre nos petits changements « :wq » et on fait un petit

Quelques logiciels pour finaliser la sécurisation

On va finir la sécurisation par l’installation de quelques logiciels de protection. Le premier est fail2ban. Comme son nom l’indique, si la tentative échoue, il y aura un ban. Attention en revanche à bien le paramétrer. On se connecte à son petit ssh sécurisé et puis on passe en mode super utilisateur.

On va maintenant configurer le logiciel. On se rend dans son répertoire :

Et on fait une copie du fichier jail.conf et on va l’appeler local (oui, notre server a beau être exporté, c’est lui en « local » qui va gérer les choses.

Puis on va éditer le fichier :

Puis on va aller aux premières configurations et voici ce qu’il faut y mettre :

En clair, l’utilisateur a le droit à trois tentatives pour se connecter, si ça ne fonctionne pas, il est banni pendant 3600 secondes.

Puis dans la section ssh [ssh] on reporte nos valeurs  pour l’activer (enabled = true, le port, le filtre etc…)

 Voilà une bonne chose de faite. Mais allons plus loin, et si on recevait un mail à chaque fois que quelqu’un essaie de se connecter et se prend un ban, intéressant non ?

Alors, on met une adresse mail à destemail, ce qui donne :

Puis on change la ligne :

Et l’on met :

On sauvegarde nos changements. et on redémarre le soft

Pour vérifier que tout fonctionne bien, il suffit d’appliquer en mode super utilisateur :

Une des lignes de retour sera :

 Dernier volet de sécurisation, les rootkits.  On va installer un petit logiciel très utile qui s’appelle RKhunter (rootkit hunter). Ce qu’il va faire ?  ll va effectuer des détections journalières anti-rootkits et enverra des notifications par e-mail.

Puis on configure notre adresse mail dans le fichier /etc/default/rkhunter.

Et on modifie et complète comme ce qui suit :

Et voilà. Vous avez sécurisé de manière simple, efficace et peu gourmande en ressource votre server. Attention toutefois, un vrai hacker trouvera toujours une faille. Cela permet uniquement d’empêcher les attaques classiques.