[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.

Putty

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

# sudo apt-get update
# sudo apt-get upgrade

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.

# sudo useradd 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.

# sudo /etc/init.d/ssh restart

Puis on quitte notre session ssh.

# exit

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 ».

$ 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).

# vi /etc/ssh/sshd_config

Là, nous aurons plusieurs parties à éditer.

1er 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.

PermitRootLogin no

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

On vérifie également les lignes suivantes :

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

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 :

UsePAM yes
AllowUsers zedd
GatewayPorts no
AllowTcpForwarding yes
KeepAlive yes

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

# sudo /etc/init.d/ssh restart
 
Une fois fait, vous quittez votre session ssh et tentez à nouveau de vous connecter via le super utilisateur et – ô magie – c’est impossible.  Seul l’utilisateur zedd le pourra.
 

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.

# sudo apt-get install fail2ban

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

# cd /etc/fail2ban

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.

# sudo cp jail.conf jail.local

Puis on va éditer le fichier :

# vi jail.local

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

[DEFAULT]
# « ignoreip » can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1
bantime  = 3600
maxretry = 3

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…)

[ssh]
enabled = true
port    = 1234
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 3

 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 :

destemail = your_email@domain.com

Puis on change la ligne :

action = %(action_)s

Et l’on met :

action = %(action_mw)s

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

# sudo /etc/init.d/fail2ban restart

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

# sudo iptables –L

Une des lignes de retour sera :

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-ssh  tcp  —  anywhere             anywhere            multiport dports 1234

 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.

 # apt-get install rkhunter

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

# vi /etc/default/rkhunter

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

REPORT_EMAIL= »youradressemail@totototo.com »
CRON_DAILY_RUN= »yes »

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.

    • Camille Latouche

      Le prochain tuto discutera de l’hébergement pour un site web de son server.

    • Thibaut

      Bon début, très clair. Go ahead !

      • BenDek

        Très bon tuto !