Sécurisation
- Utilisation de failles de sécurité du système
- Connection en root par une personne malveillante
- Utilisation de la méthode "Brute Force" avec le protocole SSH afin de trouver un mot de passe permettant une connexion au VPS
- Stockage des mots de passe sur GitHub
- Ouverture de port non nécessaire au fonctionnement des services
- Effectuer les mises à jours d'Ubuntu dès qu'elle sont disponible
- Désactivation de la connexion en root
- Modification du port de connexion en SSH
- Mise en place de Fail2Ban
- Suppression des mots de passes de GitHub
- Fermer les ports non utilisé ou ne nécessitant pas d'être accessible de l'extérieur du VPS
- Configuration d'un firewall
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
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
- 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.
- 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 variablePortdu fichier/etc/ssh/sshd_config. Ensuite nous avons redémarré le service afin que les modifications soit prises en compte
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.
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
Nous avons choisit de mettre en place le firewall "UFW" afin de limiter les connexion autorisées au ports nécessaires au services implémenté. Par défaut UFW bloque toutes les connexion entrantes n'ayant pas été précisées dans des règles, nous ne devrons donc que lui préciser quelles sont les connexion que nous voulons autoriser.
Nous avons dans un premier temps configurer UFW afin d'autoriser les connexion SSH via le nouveau port configuré (12322)
sudo ufw allow 12322 comment 'SSH'
Ensuite nous avons activé UFW sur chaque VPS
sudo ufw enable
Enfin, nous avons ajouté des règles en fonction des services actuellement implémenté sur les différents VPS via la même commande que celle utilisé pour le trafic SSH
- VPS de Vincent : DSN externe et Mail
- VPS de Aymar : Web (non terminé)
- VPS de Serge : Aucun
Nous avons mis en place la connexion par clé pour l'utilisateur vincent sur les 3 VPS en utilisant PuTTy et PuTTy key generator
- 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