[article] Sécuriser son serveur LAMP

[fandecine]

De retour de vacances bien méritées, je me sens en pleine forme ! Pour compléter mon post sur l’optimisation des serveurs dédiés, je vous livre ici les recettes pour sécuriser (aussi bien que possible !) son serveur dédié (serveur LAMP uniquement, désolé mais je ne connais pas IIs et consorts !)

Tout d’abord, ne vous faite pas d’illusion, le serveur inviolable n’a pas (encore ?) été inventé. De plus, les spécialistes de la sécurité (quelque soit le système à protéger, informatique ou pas) vous diront que la mise en place d’une politique de sécurité est une question d’adéquation des moyens mis en œuvre. Vous viendrait il à l’idée d’acheter un coffre fort pour y enfermer la tire lire de vos enfants ? Non, bien sur.

Sachez également que rien n’étant définitif, il vous faudra surveiller votre serveur pour détecter toute tentative (réussie ou pas) d’intrusion sur votre serveur.

Entrons dans le vif du sujet (attention, je ne prétends en aucun cas donner une liste exhaustive de recette !)

1 - Supprimer tout ce qui est inutile !
2 - Pour vivre heureux, vivons cachés…
3 - Tester la sécurité de son serveur…
4 - Surveiller son serveur.


1 – Supprimer tout ce qui est inutile

Par défaut, votre serveur LINUX est installé avec un certain nombre d’outils et services qui, selon l’utilisation du serveur, vous seront inutiles. Supprimer tout ce qui est inutile !

A - Supprimer les services inutiles :

Dans le cas ou votre super-deamon est inetd :

Le fichier de configuration est /etc/inetd.conf . Editez le et commentez (#) toutes les lignes contenant les services à désactiver. Enregistrez le fichier et redémarrer le super-deamon par :

Code: Tout sélectionner

root@votreserveur# kill -HUP num_pid_inetd

Dans le cas ou votre super-deamon est xinetd :

Rendez vous dans le répertoire /etc/xinetd.d . Editez le fichier correspondant au service choisi et à la ligne disable = no remplacer no par yes . Enregistrez le fichier et redémarrer le super-deamon par :

Code: Tout sélectionner

root@votreserveur# /etc/rc.d/init.d/xinetd restart

B – Connaître les services lancés au démarrage ?

Pour connaître les services lancés au démarrage, en mode console sous root, taper :

Code: Tout sélectionner

root@votreserveur# chkconfig –list

Vous obtenez la listes des services démarrés pour chacun des niveaux de démarrage de votre machine linux (niveaux 0 à 6)

Pour supprimer un service de la liste des services à démarrer, en mode console sous root, taper :

Code: Tout sélectionner

root@votreserveur# chkconfig --level 0123456 nomduservice off

Mais à quoi correspondent les niveau de démarrage0 à 6 ?

Niveau 0 : niveau permettant d'arrêter le système,
Niveau 1 : niveau dit mono-utilisateur (single-user)
Niveau 2 : niveau dit multi-utilisateur (multi-user), c'est le mode par défaut de démarrage de Linux,
Niveau 3/4 : ce sont les mêmes niveaux que le précédent avec la possibilité de faire des opérations supplémentaires
Niveau 5 : niveau dit "station de travail" ou terminal X, car il permet de démarrer directement sous l'interface graphique.
Niveau 6 : niveau permettant de rebooter le système.

Dans le cas d’un serveur WEB, le niveau de démarrage est généralement le 3. Pour changer de niveau il suffit de taper la commande init num_du_niveau (par exemple la commande « niveau 0 » correspond à la commande « shutdown »)

C - Supprimer les Modules apache inutiles :

Les fonctionnalités de votre serveur apache sont obtenues par l’ajout de modules (par exemple, l’url rewriting est gérée par un module apache). Pour limiter les failles de sécurité, supprimez les modules inutiles. La liste des modules à recharger est donnée dans le fichier /etc/httpd/conf/httpd.conf par exemple :

Code: Tout sélectionner

LoadModule rewrite_module modules/mod_rewrite.so pour le module de rewriting.

Par exemple, si vous n’utilisez pas la mise en cache des fichier avec apache 2, commentez la ligne :

Code: Tout sélectionner

LoadModule file_cache_module modules/mod_file_cache.so

Seul les modules mod_dir, mod_mime et mod_log_config sont nécessaire au fonctionnement d’apache (et encore !).

D – Supprimer les utilisateurs inutiles :

Les hackers at autres spamer testent en priorité les noms d’utilisateurs standards. Seul les users suivants sont nécessaire au système :

root, bin, daemon, adm, nobody

Les users suivants sont utiles si :

lp (si vous avez un système d'impression, rare pour un serveur Web !)
mail (si serveur mail)
news (si serveur de news)
uucp (si vous utilisez UUCP)
ftp (si serveur FTP anonyme)

Les users suivants peuvent êtres supprimés :

games, gopher, halt, sync, shutdown, operator, lists, xfs

2 – Pour vivre heureux, vivons cachés !

A – De nombreux services sont associés à un port (22 pour le ssh, 80 pour httpd). Lorsque c’est possible, changez le port par défaut. Par exemple, rien ne vous empêche de mettre le ssh sur le port 24356 ! (il suffit que les utilisateurs ssh le sache) cela réduira sensiblement les tentatives de pénétration de votre serveur. Vous pouvez faire de même pour le ftp (port 21) si vous êtes le seul à l’utiliser.

Pour changer le port de votre accès ssh.

1 - Connectez vous en ssh a votre serveur (user root)
2 – éditez le fichier /etc/ssh/sshd.config
3 – Changez le numéro de port (remplacez 22 par XXXX, choisir un port libre bien sur et une valeur élevée.)
4 – enregistrez le fichier et relancez ssh par /etc/rc.d/init.d/sshd restart
5 – ouvrez une autre console ssh en root (sans quitter celle-ci) pour tester que le nouveau port est bien pris en compte.

Si vous êtes paranos vous pouvez changer le mot de passe root régulièrement :

1 - Connectez vous en ssh a votre serveur (user root)
2 – en mode console taper passwd nouveaumdp
3 – ouvrez une autre console ssh en root (sans quitter celle-ci) pour tester que le nouveau mot de passe est bien pris en compte.

B – Evitez les bavardages de votre serveur.

Pour cette partie, reportez-vous à ce post ou j’explique comment rendre son serveur apache moins bavard. Moins vous donnerez d’infos aux utilisateurs malveillant, moins ils seront armés pour vous nuire.

C – Sécurisez vos mots de passe

Au delà des règles de bon sens (mots de passe de 8 caractères minimum, mélange de chiffres, majuscules et minuscules, mot de passe différent du login, pas de mots contenus dans un dictionnaire), sécurisez vos mots de passe. La première chose que fait un Hacker est d’essayer de lire le fichier /etc/passwd (fichier en lecture seule pour tout le monde, en écriture pour le root). Utilisez le shadowing, cela aura pour effet de déplacer les mots de passes dans un fichier généralement appelé /etc/shadow (fichier illisible sauf pour le root !)
Pour activer le shadowing des mots de passe, connectez vous en mode console sous root et tapez :

Code: Tout sélectionner

root@votreserveur# pwconv

Edit: Ajout du 18/08/2006 16:00 --------------------
Oooops! j'ai oublié ceci !

D - Changer les repertoire d'installation

Les outils tel PhpMyADmin s'installent par defaut dans des répertoires connus de tous (pour phpMyAdmin c'est généralement :
-http://monserveur/admin/phpMyAdmin/ mais vous pouvez l'installer ou vous voulez!

Fin Edit -------------------------------------------------

3 - Tester la sécurité de son serveur…

Voici quelques outils pour tester la sécurité de votre serveur :

http://tatumweb.com/iptools.htm une batterie impressionnante d’outils en ligne (par exemple pour tester les ports ouverts, si votre serveur autorise le relaying…)

http://www.dnsbl.au.sorbs.net/lookup.shtml? Pour savoir si votre serveur est répertorié comme relayeur de spam

http://www.mail-abuse.com/cgi-bin/lookup idem que le précédant

http://www-arc.com/sara/ , http://www.nessus.org/ des outils pour tester les vulnérabilités

Utilisez un scanneur de port pour tester les ports ouverts de votre serveur (une recherche sur google vous en proposera plusieurs, à vous de choisir !)

4 - Surveiller son serveur.

Il existe une solution simple pour être informé de ce qui se passe sur le serveur : logwatch

Logwatch est un système d’analyse des logs de votre serveur capable de vous envoyer un mail tous les matins pour vous informer de ce qui c’est passé durant les dernières 24 H.

Logwatch est généralement présent et installé. Si ce n’est pas le cas, vous le trouverez ici http://www2.logwatch.org:8080/tabs/download/.
Pour paramétrer Logwatch, vous trouverez les instructions ici http://www2.logwatch.org:8080/tabs/docs ... Watch.html

Ensuite, un petit outils bien pratique pour détecter virus et autres spywares : rkhunter

Vous trouverez toutes les informations ici http://www.rootkit.nl/projects/rootkit_hunter.html

Rkhunter analyse votre système à la recherche de toutes les salop….es qui pourraient s’y trouver et vous envoie un rapport complet par mail tous les jours.

il existe également des outils temps réel de monitoring orientés sécurité, mais je vous laisse chercher un peu!

Ressources :

Si vous lisez l’anglais, le must : http://www.linuxsecurity.com/

Voilà, en espérant que post (un peu long!) vous sera utile

[AW]

Yes merci Fandecine, encore une recommandation pour toi!

Je rajoute un petit lien sur apache et le gestion de vhost qui peut etre trés utile, meme si cela n'a rien a voir avec la securité d'un serveur LAMP : http://www.apachefrance.com/Forums/inde ... topic=1166

Et je precise pour les utilisateurs de webmin, il suffit d'autoriser seulement votre ip ou un dns dynamique si besoin. C'est radical et tellement simple

[ltressens]

Bel article ! une reco !

[obi]

Superbe ! Une reco pour toi.
J'ajouterai, même si ce n'est pas tant sur la configuration que sur le déployement effectif de sites en php:

Mettez toutes les pages php qui ne sont jamais accédées directement par l'utilisateur dans une zones privée du site (i.e. non servies par apache). On peut avoir des surprises avec ça !

[Sumatrapointfr]

reco + une blague :

Mettre un abat jour

...

lamp ?

...


ok

[samuel]

super article ca, merci

[MirageDemonAsh]

LAMP = Linux Apache Mysql PHP Edit : J'viens de comprendre la blague... En même temps je suis debout depuis hier 17h.

Et une Reco en + Merci Fandecine

Un peu de paranos en plus :

Pour SSH : Interdire l'accès en tant que root depuis l'exterieure et créer un compte utilisateur avec très peu de droit et un bon mot de passe à la 34MkLeRv56gh78jkG Cela permettra de se connecter dans un 1er temps avec un compte utilisateur et ensuite, avec la commande su, de devenir root (root ayant egalement un mot de passe béton et différent) :

Pour cela créez un compte utilisateur, ensuite :

Editez le fichier /etc/ssh/sshd_config

Cherchez PermitRootLogin yes et remplacez par PermitRootLogin no

Et ajoutez AllowUsers Le-nom-de-lutilisateur-autorisé

Enregistrez le fichier et relancez ssh

Il n'y aura qu'un seul utilisateur autorisé à se connecter via ssh depuis l'exterieure. Avec le changement de port d'ecoute et ça


___________


Un autre pour le dossier phpmyadmin ou (Pareil pour Awstats) :

Je change le nom de dossier. Exemple khdksqq9839 à la place de phpmyadmin et je place aussi une seconde protection par mot de passe avec .htaccess et .htpasswd

[dmathieu]

J'avais pas vu ce post, mais il est effectivement très bien construit, et très intéréssant
merci fandecine, une reco pour toi de ma part aussi

[rtb]

Toujours un plaisir et un enrichissement de lire tes posts +1 reco

[cprail]

Effectivement, ça mérite largement une reco!
(même si je n'utilise pas de serveur lamp ailleurs qu'en interne)

[yanhl]

Si vous avez un formulaire de contact, je vous conseille cet article que je ne sais plus qui avait recommandé ici même: http://www.phpsecure.info/v2/article/Ma ... Inject.php

Ca doit être l'une des failles classées au top ten des plus répandues et utilisées par les spammeurs.
Je vous assure que ça n'est pas du luxe, je bloque chaque jour l'envoi de centaines de spams via mes formulaires !

[nza2k]

Salut et merci Fandeciné !

Je suis débutant en PHP MySQL... et j'y connais absolument rien en administration serveur.
A la lecture de tes mises en garde, j'ai un peu peur de passer d'un hébergement mutualisé à un hébergement dédié...
En fait, très clairement, si j'ai mon serveur dédié, je me sens incapable de réaliser correctement tout ce que tu conseilles...

...Quand on prend une offre de base pour un serveur dédié chez un hébergeur type Sivit, OVH... on a tout ça à faire ou pas ? Est-ce généralement une option payante ? Si c'est le cas, vous connaissez un hébergeur qui propoe une telle option pour pas cher, avec efficacité, réactivité et compréhensivité (qui ne se contentera pas de dire "c'est pas possible", si les règles de sécurité entrent en conflit avec certains besoins, comme désactiver le safemode pour installer Image Gallery 2 et ce genre de trucs...) ?

Avec mon hébergement mutualisé, y a pas mal de choses que je n'arrive pas à faire car il y a des modifs à faire dans la configuration serveur que me refuse l'hébergeur... Je pense de plus en plus à prendre un dédié mais justement, j'y connais rien en serveur et je crains de me retrouver seul et désarmé ds la jungle des hackers/spammers/rigolos du net...

Bien entendu, les hébergeurs sont tous rassurants là-dessus, mais bon, je ne suis pas dupe, c'est dans leur intérêt de faire passer leurs clients mutu en dédié... C'est pour ça que je préfère avoir l'avis objectif de webmasters sur la question...

[labrute]

Merci également pour cet article fort intéressant, notamment pour les débutants !

[thierry8]

une question par rapport à la modification du port de connexion ssh.

vaut-il mieux :

- modifier le port ssh

- ne pas modifier le port ssh et autoriser une plage d'adresse ip à la connexion ssh

- ne pas modifier le port ssh et n'autoriser aucune connexion au port ssh
(sachant que l'on peut l'activer via http)


je crain un peu avec la dernière solution, si un plantage quelconque, et que l'accès ssh est complètement out...

la deuxième permet de restreindre l'accès..

la première permet d'être cachée..(pour un temps je pense ?)

[billyboylindien]

une question par rapport à la modification du port de connexion ssh.

vaut-il mieux :

- modifier le port ssh

- ne pas modifier le port ssh et autoriser une plage d'adresse ip à la connexion ssh

- ne pas modifier le port ssh et n'autoriser aucune connexion au port ssh
(sachant que l'on peut l'activer via http)


)

Le premier te permet d'etre a l'abri de 99% des scann deja mais pourquoi ne pas combiner 1 et 2 ?

Le 3 d'avance non merci, si apache tombe en rade .. ?