Sécurisation

Analyse de sécurité

Identification des risques

1. Utilisation de failles de sécurité du système
2. Connection en root par une personne malveillante
3. Utilisation de la méthode "Brute Force" avec le protocole SSH afin de trouver un mot de passe permettant une connexion au VPS
4. Stockage des mots de passe sur GitHub
5. Ouverture de port non nécessaire au fonctionnement des services

Contre-mesures contrant les risques identifiés

1. Effectuer les mises à jours d'Ubuntu dès qu'elle sont disponible
2. Désactivation de la connexion en root
3. Modification du port de connexion en SSH
4. Mise en place de Fail2Ban
5. Suppression des mots de passes de GitHub
6. Fermer les ports non utilisé ou ne nécessitant pas d'être accessible de l'extérieur du VPS
7. Configuration d'un firewall

Choix des contre-mesures mises en place et justification.

Utilisation de failles de sécurité du système

Afin de limiter les risque d'utilisation des potentielles failles de sécurité d'Ubuntu, nous avons fait les mises à jour disponibles.

Commandes utilisées : apt-get update et apt-get upgrade

Connexion en root par une personne malveillante

Nous avons désactivé la connexion en SSH à l'utilisateur root de nos VPS.

Pour ce faire nous avons modifié le fichier /etc/ssh/sshd_config. Dans ce fichier, nous avons modifié la valeur de la variable PermiRootLogin.

Cependant le mot de passe est toujours demandé lorsque quelqu'un tente de se connecter en root. Ne disposant pas du mot de passe root nous ne pouvons pas déterminer si la connexion en root est bien refusée.

Utilisation de la méthode "Brute Force" avec le protocole SSH afin de trouver un mot de passe permettant une connexion au VPS

1. Nous avons mis en place Fail2Ban afin de limiter le nombre de tentatives qu'un attaquant peut faire. Le fonctionnement de Fail2Ban consiste à placer les adresses IP de machine ayant entré trop de fois un mauvais password dans des blacklists appelées des "jails". Une adresse IP mise dans la jail pourra retenter de faire une authentification ssh lorsque un délai, défini dans la configuration de Fail2Ban, sera arrivé à son terme.

Nous avons décidé de modifier la valeur bantime qui était fixée par défaut à 10 minutes et de la fixer à un jour, ce qui limitera les tentatives de Brut Force

Nous avons ensuite activé Fail2Ban pour le service sshd et redémarré le service Fail2ban afin de prendre en compte les modifications.

2. Nous avons modifié le numéro de port utilisé par défaut pour les connexions SSH La majorité des tentatives de connexion venant de bot utilisent le port 22 qui est le port par défaut. Nous avons donc modifié le port utilisé par SSH en
   modifiant la variable Port du fichier /etc/ssh/sshd_config. Ensuite nous avons redémarré le service afin que les modifications soit prises en compte

Stockage des mots de passe sur GitHub

Nous avons supprimé tous les mots de passe présents dans les fichiers commités sur GitHub. Ils ont tous été remplacés par la valeur [password]. Il faudra à présent directement demander à l'administrateur du service pour connaitre un mot de passe ou alors consulter les fichier sur le serveur.

Fermeture de port non nécessaire au fonctionnement des services

Nous avons vérifié grâce à nmap que seuls les ports nécessaires à nos services étaient ouverts.

• Sur 176.96.231.164 il y a le DNS externe (53) et le serveur mail (25, 143, 587, 993)
• Sur 176.96.231.163 il y a le service web(80) dont l'implémentation n'est pas finie
• Sur 176.96.231.162 il n'y a aucun service

Configuration d'un firewall

A faire

Identification des risques résiduels (non-couverts par des contre-mesures)

• Les attaques de Brute Force ne peuvent pas être évitées mais nous en avons grandement réduit le nombre.
• L'utilisateur root est toujours accessible par une personne étant connectée en ssh au serveur par un autre utilisateur
• De nouvelles failles de sécurités peuvent être découvertes à tout moment, il faudra donc faire attention à faire régulièrement les mises à jour