Sécuriser un serveur debian
Fermé
fraigneau arnaud
-
4 avril 2016 à 17:20
mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 - 5 avril 2016 à 18:57
mamiemando Messages postés 33077 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 18 avril 2024 - 5 avril 2016 à 18:57
A voir également:
- Sécuriser un serveur debian
- Serveur pop - Guide
- Chaque fichier en ligne sur le web a un chemin d’accès sur un serveur. c’est le cas du fichier du logo présent sur la page de cette ville. quel est le chemin de ce fichier à partir de la racine du site ? - Forum Graphisme
- Impossible d'atteindre le serveur dhcp - Forum Réseau
- Serveur dhcp - Guide
- Le serveur de récupération n'a pas pu être contacté ✓ - Forum MacOS
1 réponse
mamiemando
Messages postés
33077
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
18 avril 2024
7 748
5 avril 2016 à 18:57
5 avril 2016 à 18:57
Bonjour,
1) Aspects réseaux
a) Pare-feu
Tu peux commencer par regarder comment configurer un pare-feu (typiquement cf
https://doc.ubuntu-fr.org/ufw
https://doc.ubuntu-fr.org/iptables
b) Ports ouverts
Il est important de regarder par exemple avec
Typiquement un serveur de base de données, s'il n'est requêté que par un serveur web installé sur la même machine, n'a aucune raison d'être bindé avec 0.0.0.0.
c) Détection d'intrusion
d) Limiter "l'adhérence" aux attaques
Certains outils consistent à brute-forcer un mot de passe. C'est en particulier gênant quand c'est le compte root en ssh qui se fait attaquer. C'est pourquoi les serveurs ssh récents (et bien configurés) n'autorisent pas les connexions ssh en root. Cependant ça n'empêchera pas un pirate de tenter d'attaquer des logins "classiques" (prénoms usuels, etc...) avec des mots de passes triviaux.
Plusieurs solutions contre ceci dans cet exemple :
- n'autoriser que les connexions par clé ssh (protégée par une passphrase, cela va de soi) :
http://prendreuncafe.com/blog/post/2005/08/29/262-installer-sa-cle-ssh-sur-un-serveur-distant
- bannir les clients qui tentent manifestement un peu trop leur chance, par exemple avec fail2ban :
https://doc.ubuntu-fr.org/fail2ban
2) Aspects logiciels
a) Un linux à jour, utilisant des sources sûres
Assure-toi que la distribution est à jour, en particulier tous les services sensibles (ssh, apache, mysql...) avec ton gestionnaire de paquets :
Debian ayant le bon goût de signer ces paquets, tant que tu t'en tiens à des dépôts standards, tu ne devrais pas avoir de mauvaises surprises (tant que tu n'installes pas des paquets qui proviennent de sources "non-sûres").
b) Des binaires sûrs
Il est important de pouvoir s'assurer qu'on a confiance dans le résultat d'une commande. Typiquement un pirate déployant sur ta machine un rootkit pourra masquer son intrusion en remplaçant certaines commandes essentielles (typiquement
Les outils
https://www.mistra.fr/tutoriel-linux-pirates-rootkit.html
3) Aspects utilisateurs
1) Des droits minimaux
Ceci revient à suivre quelques bonnes pratiques :
1) ne jamais changer les droits d'un fichier lié au système : relâcher des droits, c'est généralement ouvrir un trou de sécurité. Si un utilisateur n'a pas les droits d'accéder à un fichier c'est soit normal, soit qu'il faut le rajouter dans le groupe approprié.
2) éviter les scripts avec des bits suid
En effet il faut partir du principe que tu ne veux pas qu'un utilisateur local à ta machine puisse faire des bêtise. Et peu importe que root soit "bien protégé", si tu n'es pas prudent à ce niveau là et qu'un utilisateur se fait pirater, le reste peut tomber rapidement. En gros un pirate va généralement exploiter une petite faille, et petit à petit agrandir son pouvoir de nuisance sur la machine.
2) Des mots de passes sûrs !
Un mot de passe sûr n'est pas basé sur un mot du dictionnaire (ni ses variantes comme bonjour, BonJouR, B0Nj0uR) ou sur une suite de touche adjacentes (genre azerty).
Il met en jeu des lettres, minuscules et majuscules, des chiffres, des caractères spéciaux (genre @!#_) et fait un nombre de caractères raisonnablement grand (disons au moins 8 caractères).
Bonne chance
1) Aspects réseaux
a) Pare-feu
Tu peux commencer par regarder comment configurer un pare-feu (typiquement cf
iptablesou une surcouche comme
ufw). Je te mets les liens ubuntu car c'est construit sur debian, donc la distribution n'est pas significative.
https://doc.ubuntu-fr.org/ufw
https://doc.ubuntu-fr.org/iptables
b) Ports ouverts
Il est important de regarder par exemple avec
netstat -ntlps'il te paraît justifié que tes serveurs soient bindés avec 0.0.0.0 (écoute le trafic extérieur) ou 127.0.0.1 (trafic local).
Typiquement un serveur de base de données, s'il n'est requêté que par un serveur web installé sur la même machine, n'a aucune raison d'être bindé avec 0.0.0.0.
c) Détection d'intrusion
snortpermet de filtrer des motifs de paquets malicieux destinés à tirer parti d'une faille de sécurité. Il aura donc tendance (s'il est bien configuré) à jeter des séquences de paquets suspects.
d) Limiter "l'adhérence" aux attaques
Certains outils consistent à brute-forcer un mot de passe. C'est en particulier gênant quand c'est le compte root en ssh qui se fait attaquer. C'est pourquoi les serveurs ssh récents (et bien configurés) n'autorisent pas les connexions ssh en root. Cependant ça n'empêchera pas un pirate de tenter d'attaquer des logins "classiques" (prénoms usuels, etc...) avec des mots de passes triviaux.
Plusieurs solutions contre ceci dans cet exemple :
- n'autoriser que les connexions par clé ssh (protégée par une passphrase, cela va de soi) :
http://prendreuncafe.com/blog/post/2005/08/29/262-installer-sa-cle-ssh-sur-un-serveur-distant
- bannir les clients qui tentent manifestement un peu trop leur chance, par exemple avec fail2ban :
https://doc.ubuntu-fr.org/fail2ban
2) Aspects logiciels
a) Un linux à jour, utilisant des sources sûres
Assure-toi que la distribution est à jour, en particulier tous les services sensibles (ssh, apache, mysql...) avec ton gestionnaire de paquets :
apt-get update
apt-get upgrade
Debian ayant le bon goût de signer ces paquets, tant que tu t'en tiens à des dépôts standards, tu ne devrais pas avoir de mauvaises surprises (tant que tu n'installes pas des paquets qui proviennent de sources "non-sûres").
b) Des binaires sûrs
Il est important de pouvoir s'assurer qu'on a confiance dans le résultat d'une commande. Typiquement un pirate déployant sur ta machine un rootkit pourra masquer son intrusion en remplaçant certaines commandes essentielles (typiquement
ps,
netstat, ...) par des binaires qui renverront des résultats bidons.
Les outils
debsumset
rkhuntersont deux réponses possibles pour détecter ce genre choses. Pour plus de détails :
https://www.mistra.fr/tutoriel-linux-pirates-rootkit.html
3) Aspects utilisateurs
1) Des droits minimaux
Ceci revient à suivre quelques bonnes pratiques :
1) ne jamais changer les droits d'un fichier lié au système : relâcher des droits, c'est généralement ouvrir un trou de sécurité. Si un utilisateur n'a pas les droits d'accéder à un fichier c'est soit normal, soit qu'il faut le rajouter dans le groupe approprié.
2) éviter les scripts avec des bits suid
En effet il faut partir du principe que tu ne veux pas qu'un utilisateur local à ta machine puisse faire des bêtise. Et peu importe que root soit "bien protégé", si tu n'es pas prudent à ce niveau là et qu'un utilisateur se fait pirater, le reste peut tomber rapidement. En gros un pirate va généralement exploiter une petite faille, et petit à petit agrandir son pouvoir de nuisance sur la machine.
2) Des mots de passes sûrs !
Un mot de passe sûr n'est pas basé sur un mot du dictionnaire (ni ses variantes comme bonjour, BonJouR, B0Nj0uR) ou sur une suite de touche adjacentes (genre azerty).
Il met en jeu des lettres, minuscules et majuscules, des chiffres, des caractères spéciaux (genre @!#_) et fait un nombre de caractères raisonnablement grand (disons au moins 8 caractères).
Bonne chance
