TUTO - Securiser serveur linux

bru38 · Le 04/01/2015, à 03:43

Hello !
Ayant rencontrés beaucoup de personnes qui mettent en ligne des serveurs mais qui ne savent pas les securiser, j'ai voulu créer un tuto expliquant quelques règles de bases.

Je vous laisse le découvrir et me donner vos avis...
N'hésitez pas à laisser des commentaires !

Le lien : http://www.bidouilleit.com/2015/01/04/s … eur-linux/

Et n'hésitez pas à balancer des nouvelles idées que je pourrais rajouter dans le tuto !

A+

bruno · Le 04/01/2015, à 08:28

Bonjour,

Je vais sans doute paraître un peu abrupt mais ton « tuto » n'apporte aucun élément de sécurité valable et certaines manipulations sont plus que contestables (changement de droits sur certains outils ou désactivation de l'ipv6 par exemple).
Un serveur ne se sécurise pas en appliquant des « tutos » surtout lorsque ceux-ci ne sont que des compilations de « recettes » glanées ici et là sans aucune explication. La sécurité est un travail permanent qui se réalise en lisant les documentations officielles, les pages de man, en faisant de la veille technologique (sur les failles logicielles notamment), etc.

tiramiseb · Le 04/01/2015, à 10:09

Salut,

Mon avis va un peu dans le même sens que celui de bruno : ton tuto est une compilation de plein de trucs plus ou moins utiles, bien souvent sans explication, voire avec une explication erronée.

Mon but n'est pas de descendre ton billet, il y a des trucs qui se tiennent et je sais que c'est un gros boulot de réunir toutes ces infos, mais je vais donner mon avis sur quelques points, ceux qui me semblent les plus "sensibles" (il y aurait probablement plein d'autres commentaires à faire, mais c'est un gros boulot)...

II. Sécurisation du SSH

L'interdiction de connexion en root n'a aucun intérêt : que ce soit en root ou en utilisateur, il faut bien se connecter. Psychologiquement, l'administrateur va se dire qu'il est en sécurité car il ne se connecte pas directement en root, il va alors être plus détendu et moins vigilant de manière générale. Ensuite, deux possibilités :
- soit on utilise sudo et ça ne change rien en terme de sécurité : on a le mot de passe, on peut devenir admin
- soit on n'utilise pas sudo et il faut retenir deux mots de passe, qui seront peut-être moins complexes qu'un seul mot de passe.

Les autres réglages, comme l'autorisation de ne se connecter qu'avec cet utilisateur, sont inutiles quand on a un simple serveur dédié et qu'on est le seul utilisateur : personne d'autre ne pourrait se connecter de toute façon.

Non, le plus sécurisé est d'interdire totalement les authentifications par mot de passe et de n'utiliser que des clés SSH. Et une connexion directe en root, ça ne pose aucun problème.

IV. Autorisations diverses

De manière générale, il ne faut pas toucher aux fichiers système, qui seront de toute façon rétablis à leur situation précédente lors de la prochaine mise à jour des paquets concernés. Et puis de toute manière, sur un système bien sécurisé il n'y aura personne pour tenter d'exécuter ces commandes : une fois que quelqu'un a pénétré le système, c'est trop tard, il faut réinstaller. Il faut alors sécuriser en amont, pour que personne n'entre.

V.1) Mises à jour système

On n'automatise pas les mises à jour. S'il y a un problème lors de la mise à jour, aucun administrateur ne serait présent pour prendre les mesures correctrices adaptées. Il faut mieux installer quelque chose comme cron-apt, sans installation mais avec uniquement information par e-mail de la disponibilité de mises à jour (et téléchargement des paquets sans installation, tant qu'à faire), ensuite il ne reste qu'à se connecter à la machine pour appliquer les mises à jour.

(pour ma part je ne fais pas d'alerte par e-mail, j'intègre ça dans mon serveur de supervision)

VI.1) Paramètres système

Les infos que tu donnes sont bien trop concises et induisent parfois en erreur.

Je prendrai juste deux exemples :

- « Protection contre l’usurpation d’adresse IP » : non, rp_filter n'est pas une solution anti-spoofing, ça effectue un simple filtrage de certaines situations, qui permet de se prémunir d'une petite partie des possibilités de spoofing dans certains cas précis ;
- « Autoriser le routage IP (requis pour faire de la NAT) » : tu proposes de l'activer mais ne dis pas pourquoi, un néophyte prendra cette info pour argent comptant et appliquera ça sur son serveur dédié, alors qu'il n'en avait pas besoin.

VI.3) Firewall

Je ne vais pas m'étendre là-dessus, le conseil systématique d'un pare-feu me donne des boutons, il faut proposer intelligemment et dire quand et pourquoi c'est utile. J'ai participé à assez de discussions à ce propos sur ce forum pour qu'on y trouve plein d'infos ; tu peux également lire mon article à ce propos dans le dernier numéro de Linux Pratique : De l'utilité d'un pare-feu.

Protection du FTP

Et le fait de déconseiller complètement l'utilisation du protocole FTP, tu as mis ça où ?

Exemple de script Iptables

Pourquoi ne pas conseiller plutôt UFW, tant qu'à faire ? Avec un script iptables on risque facilement de faire une erreur, ça fait des années que des solutions plus simples et solides existent.

-----

Enfin, je termine en disant que faire un bon tutoriel est très difficile. Le plus dur est de se rappeler que les gens qui vont le lire n'ont aucune compétence et vont aveuglément taper les commandes que l'on donne : il faut alors expliquer de manière détaillée chaque étape pour que la personne comprenne ce qu'elle fait, sinon le tutoriel n'apporte rien en terme d'apprentissage.
Même après plus de 12 ans d'écriture d'articles dont des tutoriels, une facilité personnelle en terme de pédagogie et de nombreuses formation, je sais que mes tutos et mes cours sont encore très perfectibles (je vois que tu es étudiant au CESi de Grenoble, je suis pour ma part prof de Linux pour le cycle GMSI au CESi de Strasbourg).

bruno · Le 04/01/2015, à 11:49

Bon tiramiseb est beaucoup plus diplomate que moi et a pris le temps de détailler sa réponse.;)

Je voudrais juste ajouter que chaque point que tu développes mériterait un « tuto » spécifique :

- la partie ssh pourrait être développée sur les « bons » choix en matière de clefs (RSA ou DSA, longueur, …) et d'algos de chiffrement : voir par exemple : https://bettercrypto.org/. Tu pourrais aussi y ajouter une partie montrant comment faire simplement du SFTP avec quelques directives de configuration, ce qui permet de se passer du FTP qui n'est pas sécurisé en soi.

- pour la partie IV, il est parfaitement inutile de modifier les droits d'exécution des outils apt-get/aptitude puisque les opérations ne peuvent être effectuées qu'avec les droits root. De plus, ta commande chmod sur /usr/bin/aptitude n'aura strictement aucun effet car il s'agit d'un lien symbolique. Il serait plus intéressant de discuter sur les droits à attribuer au fichiers accessibles sur le serveur (sites web, paratges réseaux, etc.) et/ou de mécanisme de sécurité comme apparmor ou SELinux.

- pour la partie pare-feu/autres défenses : attention de ne pas donner un faux sentiment de sécurité en utilisant ce type d'application. Je pense également qu'un pare-feu est relativement inutile sur un serveur dédié sauf à vouloir restreindre l'accès pour certains services à certains clients (et encore si on ne peut pas faire autrement). Le pare-feu, l'application de détection d'intrusion ou le scanner de vulnérabilité, ne vérifient pas tout et ne protègent pas de tout, il ne faut surtout pas se croire à l'abri parce qu'on les utilise ! Un des facteurs majeurs de compromission des serveurs web, par exemple, est la présence de failles dans le code d'une application web qui permet l'injection de code.

bru38 · Le 06/01/2015, à 01:03

Salut tout le monde !

Je prends note de vos remarques. Je vous remercie.

Je vais améliorer quelques points

A+

Brunod · Le 06/01/2015, à 06:42

http://www.bidouilleit.com/2015/01/04/s … eur-linux/ :
page non trouvée...
Faudrait revoir ton lien
Brunod

bru38 · Le 06/01/2015, à 16:41

Brunod a écrit :

http://www.bidouilleit.com/2015/01/04/s … eur-linux/ :
page non trouvée...
Faudrait revoir ton lien
Brunod

Bonjour,
C'est normal, je viens de passer l'article en mode hors ligne.
a+

pires57 · Le 06/01/2015, à 21:05

L'interdiction de connexion en root n'a aucun intérêt

Je vais juste me permettre une petite remarque sur ce point tiramiseb. S'il est vrai qu'une authentification par clé règle ce soucis (je ne viendrait pas te contredire sur ce point) je déconseille fortement l'utilisation du compte root directement par SSH et je te le justifie par le fait que le pirate tentera une attaque sur root en premier (logique non? c'est un compte que tu retrouves partout).
Maintenant si l'un des autres comptes est compromis, alors ta sécurité l'est également, c'est juste une brique de plus ...

tiramiseb · Le 06/01/2015, à 21:12

Bah à partir du moment où le mot de passe est sûr, pourquoi déconseiller root ?

pires57 · Le 06/01/2015, à 21:32

Parce que tout le monde connaît le username.
Ce que je dit la est un peu tiré par les cheveux et ne s'applique pas a un serveur perso (pas d'intérêt et coût élevé) mais avec un grand nombre de ressources, du bruteforce avec non pas une machine isolé mais des fermes de serveur est tout a fait possible

robindesbois · Le 07/01/2015, à 14:00

pires57 a écrit :

Parce que tout le monde connaît le username.

C'est ce qui est conseillé sur les routeurs flashés avec DD-WRT, on enlève l'user que tout le monde connaît (admin) pour le remplacer par un alléatoire.

tiramiseb · Le 07/01/2015, à 14:19

Ça n'en reste pas moins de la sécurité par l'obscurité...

robindesbois · Le 07/01/2015, à 14:29

À l'inverse, cela fonctionne parfaitement, du coup...

tiramiseb · Le 07/01/2015, à 15:17

La sécurité par l'obscurité, ça ne fonctionne jamais "parfaitement", non...

pires57 · Le 07/01/2015, à 15:28

J'appellerai sécurité par l'obscurité de changer le port de ssh (22) par un port exotiques, ce qui aura pour effet de créer un sentiments de sécurité irréel. En revanche, interdire la connections ssh a un utilisateur connu de tous je le qualifie plutôt de sécurité élémentaire.
C'est plus dur de faire du brute-force si tu ne connais ni le username ni le mot de passe.

robindesbois · Le 07/01/2015, à 16:14

pires57 a écrit :

J'appellerai sécurité par l'obscurité de changer le port de ssh (22) par un port exotiques, ce qui aura pour effet de créer un sentiments de sécurité irréel. En revanche, interdire la connections ssh a un utilisateur connu de tous je le qualifie plutôt de sécurité élémentaire.
C'est plus dur de faire du brute-force si tu ne connais ni le username ni le mot de passe.

C'est dans ce sens que cela a été implémenté dans le logiciel DD-WRT...

tiramiseb · Le 07/01/2015, à 16:16

C'est là que nos points de vue divergent : pour moi, qu'on sache que l'utilisateur s'appelle "root" ne change rien, vu que la bonne pratique est de faire une authentification par clé SSH et désactiver le mot de passe...

pires57 · Le 07/01/2015, à 16:44

Relis le post #8. J'ai parlé de cette authentification en précisant qu'elle règle ce problème.

tiramiseb · Le 07/01/2015, à 16:49

Oui : on est à moitié d'accord.

Compte supprimé · Le 07/01/2015, à 18:13

pires57 a écrit :

L'interdiction de connexion en root n'a aucun intérêt
Je vais juste me permettre une petite remarque sur ce point tiramiseb. S'il est vrai qu'une authentification par clé règle ce soucis (je ne viendrait pas te contredire sur ce point) je déconseille fortement l'utilisation du compte root directement par SSH et je te le justifie par le fait que le pirate tentera une attaque sur root en premier (logique non? c'est un compte que tu retrouves partout).
Maintenant si l'un des autres comptes est compromis, alors ta sécurité l'est également, c'est juste une brique de plus ...

Salut

Je vais juste ajouter mon grain de sucre, l'option PermitRootLogin no dans le conf permet à quelqu'un s'il veut devenir superutilisateur par SSH, deux connexions sont nécessaires, ainsi le MDP du superutilisateur ne peut être attaqué par force brute par SSH.
Ceci dit, FAIL2BAN règle le problème.
Changer de port pour SSH n'est pas une sécurité totale, mais le pirate ne peut avoir la certitude de l'exécution d'un démon sshd...

tiramiseb a écrit :

La sécurité par l'obscurité, ça ne fonctionne jamais "parfaitement", non...

On n'est bien d'accord, mais ces deux règles appliquées conjointement améliorent la sécurité.

Ceci étant, je vous rejoins avec l'authentification par clé, ça reste plus sécurisé

Dernière modification par ignus (Le 07/01/2015, à 18:15)

tiramiseb · Le 07/01/2015, à 20:52

Changer de port pour SSH n'est pas une sécurité totale, mais le pirate ne peut avoir la certitude de l'exécution d'un démon sshd...

Un petit scan de ports et voilà on sait où est SSH...

Compte supprimé · Le 07/01/2015, à 21:50

Oui, c'est sur, mais parfois, des vilains pas bô lancent un scan sur «des ranges d'IP complètes», donc à la recherche d'une machine sur Internet présentant le service pour lequel ils «règlent» leur scanner, donc par exemple sur le port 22, ou 21 ou que sais-je.

Ceci dit, si tu cibles une machine précise, il est bien évidant que le service sera détecté puisque le scan de port sera élargie!

SangokuSS · Le 11/01/2015, à 17:05

tiramiseb a écrit :

Changer de port pour SSH n'est pas une sécurité totale, mais le pirate ne peut avoir la certitude de l'exécution d'un démon sshd...
Un petit scan de ports et voilà on sait où est SSH...

Sauf si le paquet Portsentry est installé et bien configuré. La protection est assez radical : un simple scan via Nmap suffit à être bannit.

Je recommande vivement le couple Fail2ban (contre les attaques de mots de passe) / Portsentry (contre les scans de ports).

YSF.ma · Le 19/01/2015, à 21:04

le lien du tuto ne marche plus. !

tiramiseb · Le 19/01/2015, à 21:21

YSF.ma: si tu avais lu la discussion tu aurais vu qu'on l'a déjà dit...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 04/01/2015, à 03:43

TUTO - Securiser serveur linux

#2 Le 04/01/2015, à 08:28

Re : TUTO - Securiser serveur linux

#3 Le 04/01/2015, à 10:09

Re : TUTO - Securiser serveur linux

#4 Le 04/01/2015, à 11:49

Re : TUTO - Securiser serveur linux

#5 Le 06/01/2015, à 01:03

Re : TUTO - Securiser serveur linux

#6 Le 06/01/2015, à 06:42

Re : TUTO - Securiser serveur linux

#7 Le 06/01/2015, à 16:41

Re : TUTO - Securiser serveur linux

#8 Le 06/01/2015, à 21:05

Re : TUTO - Securiser serveur linux

#9 Le 06/01/2015, à 21:12

Re : TUTO - Securiser serveur linux

#10 Le 06/01/2015, à 21:32

Re : TUTO - Securiser serveur linux

#11 Le 07/01/2015, à 14:00

Re : TUTO - Securiser serveur linux

#12 Le 07/01/2015, à 14:19

Re : TUTO - Securiser serveur linux

#13 Le 07/01/2015, à 14:29

Re : TUTO - Securiser serveur linux

#14 Le 07/01/2015, à 15:17

Re : TUTO - Securiser serveur linux

#15 Le 07/01/2015, à 15:28

Re : TUTO - Securiser serveur linux

#16 Le 07/01/2015, à 16:14

Re : TUTO - Securiser serveur linux

#17 Le 07/01/2015, à 16:16

Re : TUTO - Securiser serveur linux

#18 Le 07/01/2015, à 16:44

Re : TUTO - Securiser serveur linux

#19 Le 07/01/2015, à 16:49

Re : TUTO - Securiser serveur linux

#20 Le 07/01/2015, à 18:13

Re : TUTO - Securiser serveur linux

#21 Le 07/01/2015, à 20:52

Re : TUTO - Securiser serveur linux

#22 Le 07/01/2015, à 21:50

Re : TUTO - Securiser serveur linux

#23 Le 11/01/2015, à 17:05

Re : TUTO - Securiser serveur linux

#24 Le 19/01/2015, à 21:04

Re : TUTO - Securiser serveur linux

#25 Le 19/01/2015, à 21:21

Re : TUTO - Securiser serveur linux

Pied de page des forums