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 potentielle failles de sécurité d'Ubuntu, nous avons fait les mises à jour disponibles.

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

Connection en root par une personne malveillante

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

Pour ce faire nous avons modifier le fichier /etc/ssh/sshd_config. Dans ce fichier nous avons modifier la valeur la variable PermiRootLogin.

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 tentative qu'un attaquant peut faire. Le fonctionnement de Fail2Ban consiste a placer les adresse IP de machine ayant entré trop de fois un mauvais password dans des blacklist appelé des "jail". Une adresse IP mise dans la jail pourra retenter de faire une authentification ssh lorsque un délai, définis 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 a 10 minutes et de la fixer a un jours ce qui limitera les tentative de Brut Force

Nous avons ensuite activer Fail2Ban pour le service sshd et redémarrer le service Fail2ban afin de prendre en compte les modification.

2. Nous avons modifier le numéro de port utilisé par défaut pour les connexion SSH La majorité des tentative de connexion venant de bot utilise 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 prise en compte

Stockage des mots de passe sur GitHub

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

Fermeture de port non nécessaire au fonctionnement des services

Nous avons vérifier grâce à nmap que seul les port nécessaire a nos services était ouvert

• 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

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

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

Contre-mesures mises en place

Liste des contre-mesures réellement mises en place sur les VPS et leur configuration (Fail2Ban, Firewall etc.) + état des lieux de leur fonctionnement.