SERE-L

Services Réseau Linux

Secure SHell

Bienvenue dans le premier cours SERE-L ! Qui veut, bien entendu, dire : Services Réseau Linux. Ce cours est basé sur le protocole SSH (Secure Shell) !

SSH permet donc, entre autres, à crypter les échanges ! Par exemple entre un client et un serveur. Il s’agit bien de la solution pour sécuriser les données envoyées sur le réseau !

Comment fait-il pour crypter les échanges ?

Il existe un nombre incalculable d’algorithmes de chiffrement, je ne peux pas tous les expliquer ici. Mais, dans tous ces algorithmes, il en existe deux catégories : Le chiffrement « symétrique » et le chiffrement « Asymétrique ». Le chiffrement symétrique consiste à envoyer une clef au destinataire qui lui permettra de décoder tous les messages qu’il recevra. Ce destinataire pourra ensuite vous répondre en utilisant cette même clef pour coder les messages qu’il vous enverra ! Et, bien entendu, vous pourrez décoder ses messages avec la clef.

« C’est super ! » me direz-vous ! Mais pour que tout ceci fonctionne il faut quand même envoyer la clef de codage / décodage en clair sur le réseau :/ Ce n’est pas cool ça ! Si un pirate la chope, il pourra décoder tous les messages transmis. Ce qui m’amène au cryptage Asymétrique !

Quand le cryptage symétrique n’utilise qu’une clef pour communiquer. Le cryptage asymétrique en utilise deux !

  • Une clef « publique » qui sert à chiffrer et qui peut être partagée (serrure)
  • Une clef « privée » qui sert à déchiffrer et doit rester secrète (clef)
Un pirate aura beau avoir la clef publique, s’il n’a pas de clef privée il ne pourra rien faire ! Et la clef privée doit obligatoirement rester secrète !

Le TP

Venons-en donc au TP. Le TP était donc divisé en 6 étapes. La première consistait à lancer la machine virtuelle fournie par le professeur, de la configurer pour les besoins de l’exercice, de créer un NAT pour lui permettre d’être joignable via SSH. Pour cela !

J’ai donc démarré la VM et me suis rendu compte qu’elle ne possédait pas d’adresse IP. Le problème venait en fait de Udev. Il s’agit d’un gestionnaire de périphériques qui, après le clonage d’une machine virtuelle, a du mal à remettre sa liste de matériels réseau au propre… On va donc l’aider en supprimant le fichier 70-persistant-net.rules comme cela :
sudo rm /etc/udev/rules.d/70-persistent-net.rules

Une fois supprimé, il ne nous reste plus qu’à redémarrer la machine pour que le fichier soit re-généré correctement. Une fois la machine redémarrée, l’interface Eth0 réapparait comme par magie lors de la commande « ifconfig » ! Nous avons donc notre adresse IP. Il faut désormais configurer un petit NAT pour pouvoir communiquer depuis notre PC physique jusque notre machine virtuelle !

Pour configurer un NAT, et comme le montre la photo ci-dessus, vous devez d’abord aller sur VirtualBox, faire « clic droit => configuration » sur votre machine virtuelle. Aller dans « Réseau » et choisir NAT en mode d’accès réseau. Ensuite cliquez sur « Avancé » puis sur « Redirection de ports ». Vous arriverez sur une petite interface ou il vous est possible de nommer une règle, de choisir le protocole de transport, l’IP de l’hôte avec son port puis l’IP de l’invité avec son port.

Ce qui vous permettra de vous connecter en SSH sur votre machine virtuelle depuis votre machine physique en tapant :

ssh lpasr@127.0.0.1 -p 2222

La seconde étape consistait à générer une paire de clefs. Je suis donc allé sur le terminal de ma machine physique et j’y ai tapé :

ssh-keygen
Le système propose ensuite l’endroit où je veux stocker mes clefs, ainsi que le nom des fichiers dans lesquels elles seront écrites. Je les ai laissés par défaut dans le /home de mon utilisateur (étudiant) et j’ai aussi gardé les noms de fichiers par défaut :

  • id_rsa (clef privée)
  • id_rsa.pub (clef publique)
Ensuite il nous est demandé d’écrire une « passphrase ». C’est comme un mot de passe mais… en phrase. C’est une phrase de passe ! Bref… Vous pouvez mettre qu’un mot si vous le voulez, hein. Une fois la paire de clefs créée, j’ai envoyé la clef publique (id_rsa.pub) sur le serveur, pour qu’il l’ait en sa possession. Le tout, avec la commande :
ssh-copy-id -i /home/etudiant/.ssh/id_rsa.pub lpasr@127.0.0.1 -p 2222

Et la clef publique a bien été envoyée sur le serveur :


Une fois que la paire de clefs est créée, que la clef publique a été envoyée sur le serveur, il ne reste plus qu’à charger la clef privée avec la commande :

ssh-add

4ème étape : Une fois les clefs mises en place, et que l’on peut se connecter au serveur sans avoir besoin de mot de passe (puisqu’on utilise la clef pour se connecter), pourquoi devrait-on les garder ? Autant les retirer ! Ça empêchera un éventuel pirate qui voudrait faire un brute force pour entrer de pouvoir le faire ! Pour cela, rien de plus simple. Nous devons aller dans le fichier :

vi /etc/ssh/sshd_config

Afin de trouver la ligne « #PasswordAuthentification yes », la dé-commenter et changer « yes » en « no » comme ci-dessous.

Sans oublier de redémarrer le service SSH après ça !

sudo /etc/init.d/ssh restart

Et dorénavant, quand quelqu’un essayera de se connecter en SSH en voulant utiliser un mot de passe, le serveur refusera et répondra :


Maintenant, pour la 5ème étape, on nous a demandé de remettre la possibilité de se connecter par mot de passe (de la même manière que pour désactiver) et d’installer Fail2Ban qui bannira les adresses essayant de se connecter trop de fois (en échouant) dans un trop court laps de temps. Pour cela, il allait falloir télécharger Fail2Ban mais aucune connexion n’était possible depuis ma machine virtuelle… Il manquait le PROXY de l’IUT !

Pour configurer un PROXY, il suffit de suivre ces commandes :

cd /etc/apt/apt.conf.d/
Vi 90Proxy

Cela ira créer le fichier 90Proxy dans le répertoire apt.conf.d et il vous faudra remplir ce fichier avec la ligne :

Acquire::http::Proxy "http://proxy.web.lan:3128";

Puis il vous suffira de faire un :

apt-get update

Afin de prendre le PROXY en compte. Maintenant qu’on a un accès aux serveurs Debian, il nous est possible d’installer Fail2Ban.

apt-get install fail2ban

Maintenant que Fail2Ban est installé, il faut aller dans le fichier de configuration de fail2ban comme cela :

vi /etc/fail2ban/jail.conf

Afin de configurer les bannissements SSH. La surveillance du protocole SSH est automatiquement activée dans Fail2Ban. Il faut juste configurer le temps de bannissement, le nombre maximum d’essais et le temps dans lequel il ne doit pas y avoir plus de tant d’échecs.

    bantime
  • La durée, en secondes, de bannissement après un nombre donné d’échecs dans un temps donné.

  • maxretry
  • Le nombre d’échecs autorisés.

  • findtime
  • Le temps dans lequel les échecs sont comptés.

Une fois Fail2Ban configuré, je redémarre, bien entendu, le service.

/etc/init.d/fail2ban restart

Je tente de me connecter en utilisant le mot de passe et de faire exprès d’échouer en chaîne. Et une fois que j’ai été banni et que le bannissement est terminé. Je suis allé voir dans les logs ou j’ai pu voir :

Ce qui prouve que mon IP a bien été bannie et dé-bannie. Fail2Ban fonctionne.


La dernière étape consistait à créer un tunnel via SSH sur le service 80 de ma machine virtuelle afin d’avoir accès à la page « It Works ! » d’apache 2. Pour cela, rien de plus simple, il suffit d’ouvrir une connexion grâce à la commande :

ssh -L 8080:localhost:80 lpasr@127.0.0.1 -p 2222
Cette commande veut donc dire : Je me connecte au serveur WEB (localhost) via le serveur SSH (127.0.0.1 sur le port 2222). (le serveur WEB et le serveur SSH étant un seul et même serveur, je vais vous l’expliquer une seconde fois ensuite pour effacer toute ambiguïté… parce que oui, localhost et 127.0.0.1 c’est le même endroit !) Et je vais ouvrir une connexion entre le port 80 du serveur web (le port 80 de localhost) pour le rediriger vers mon port 8080 à moi ! Le tout en passant par lpasr@127.0.0.1 sur le port 2222 !

Si la commande avait été :
ssh -L 8080:ip-srv-web:80 user@ip-srv-ssh -p 2222
On aurait utilisé la communication avec le serveur ssh sur le port 2222 (donc la communication avec ip-srv-ssh avec l’utilisateur « user ») pour faire communiquer mon port 8080 avec le port 80 de ip-srv-web. Ainsi, dans l’URL de mon navigateur, j’aurais pu taper « ip-srv-web:8080 » et arriver à communiquer avec une adresse LAN depuis l’extérieur !

Donc, quand je vais sur mon navigateur et que je tape : « 127.0.0.1 :8080 » dans la barre d’URL, j’arrive bien sur la page « It Works ! » venant de ma machine virtuelle ! Et si vous voulez fermer cette connexion, il vous suffit de la quitter avec la commande « exit » !

Création du lien

Fermeture du lien