[article] Sécuriser son serveur LAMP

Discussion dans 'Administration d'un site Web' créé par fandecine, 18 Août 2006.

  1. fandecine
    fandecine WRInaute passionné
    Inscrit:
    2 Avril 2005
    Messages:
    1 873
    J'aime reçus:
    0
    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:
    [email protected]# 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:
    [email protected]# /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:
    [email protected]# 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:
    [email protected]# 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:
    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:
    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:
    [email protected]# 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! :wink:

    Ressources :

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

    Voilà, en espérant que post (un peu long!) vous sera utile :wink:
     
  2. AW
    AW WRInaute passionné
    Inscrit:
    31 Mai 2005
    Messages:
    1 647
    J'aime reçus:
    1
    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 ;-)
     
  3. ltressens
    ltressens WRInaute occasionnel
    Inscrit:
    2 Avril 2004
    Messages:
    451
    J'aime reçus:
    0
    Bel article ! une reco !
     
  4. obi
    obi WRInaute discret
    Inscrit:
    26 Juillet 2006
    Messages:
    216
    J'aime reçus:
    0
    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 !
     
  5. Sumatrapointfr
    Sumatrapointfr WRInaute impliqué
    Inscrit:
    19 Avril 2005
    Messages:
    583
    J'aime reçus:
    0
    reco + une blague :

    Mettre un abat jour

    ...

    lamp ?

    ...


    ok :arrow: :arrow:
     
  6. samuel
    samuel WRInaute discret
    Inscrit:
    17 Octobre 2003
    Messages:
    130
    J'aime reçus:
    0
    super article ca, merci :)
     
  7. MirageDemonAsh
    MirageDemonAsh WRInaute occasionnel
    Inscrit:
    12 Février 2005
    Messages:
    336
    J'aime reçus:
    0
    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 + :D 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 :twisted:


    ___________


    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
     
  8. dmathieu
    dmathieu WRInaute accro
    Inscrit:
    9 Janvier 2004
    Messages:
    5 596
    J'aime reçus:
    0
    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 ;)
     
  9. rtb
    rtb WRInaute impliqué
    Inscrit:
    14 Novembre 2004
    Messages:
    870
    J'aime reçus:
    0
    Toujours un plaisir et un enrichissement de lire tes posts +1 reco
     
  10. cprail
    cprail WRInaute impliqué
    Inscrit:
    5 Mars 2006
    Messages:
    795
    J'aime reçus:
    0
    Effectivement, ça mérite largement une reco!
    (même si je n'utilise pas de serveur lamp ailleurs qu'en interne)
     
  11. yanhl
    yanhl WRInaute impliqué
    Inscrit:
    4 Décembre 2003
    Messages:
    655
    J'aime reçus:
    0
    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 !
     
  12. nza2k
    nza2k WRInaute impliqué
    Inscrit:
    16 Janvier 2004
    Messages:
    891
    J'aime reçus:
    2
    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...
     
  13. labrute
    labrute Nouveau WRInaute
    Inscrit:
    9 Octobre 2006
    Messages:
    20
    J'aime reçus:
    0
    Merci également pour cet article fort intéressant, notamment pour les débutants !
     
  14. thierry8
    thierry8 WRInaute accro
    Inscrit:
    11 Juillet 2005
    Messages:
    2 728
    J'aime reçus:
    0
    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 ?)
     
  15. billyboylindien
    billyboylindien WRInaute occasionnel
    Inscrit:
    28 Février 2005
    Messages:
    421
    J'aime reçus:
    0
    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 .. ?
     
  16. thierry8
    thierry8 WRInaute accro
    Inscrit:
    11 Juillet 2005
    Messages:
    2 728
    J'aime reçus:
    0
    edit: ok je suis c** :) (riez riez !!)
    c'est bon j'ai trouvé comment faire..

    Je "compile" donc les deux solutions, à savoir:

    - changer le port ssh
    - surveiller ce port, et n'autoriser que pour une plage d'adresse ip


    merci ;)
     
  17. billyboylindien
    billyboylindien WRInaute occasionnel
    Inscrit:
    28 Février 2005
    Messages:
    421
    J'aime reçus:
    0
    Par contre: chkconfig c'est du red hat ?

    Parce que sous debian : Nada ;)

    ++

    Il y a une equivalence:
    update-rc.d ?
     
  18. wullon
    wullon WRInaute accro
    Inscrit:
    18 Septembre 2004
    Messages:
    2 788
    J'aime reçus:
    0
    - changer le port
    - le filtrer éventellement (j'ai entendu parler de portknock aussi)
    - mais surtout, utiliser un système d'authentification par clés privées au lieu de rentrer son mot de passe au clavier ^^.
     
  19. thierry8
    thierry8 WRInaute accro
    Inscrit:
    11 Juillet 2005
    Messages:
    2 728
    J'aime reçus:
    0
    as tu un lien qui présente de manière bien construite la façon de générer une clé privée ? (sinon pas très grave je ferais une recherche..)

    mais il me semble que l'on peut associer un mot de passe aussi avec la clé privée...si on ce fait braquer la clé...oups...


    une question réelle : est-ce vraiment nécessaire tout ça ?

    admettons que l'accès ssh est blindé...je pense qu'il existe d'autres possibilités de pirater le serveur...ou est ce l'entrée ultime ?
     
  20. wullon
    wullon WRInaute accro
    Inscrit:
    18 Septembre 2004
    Messages:
    2 788
    J'aime reçus:
    0
    Je n'ai pas de tutorial, mais ce n'est pas très dur il me semble.

    Et j'avais lu que non, ce n'est pas très utile de blinder à mort le SSH parce qu'en général les failles sont plutôt du côté de scripts php ou comme ça.
     
  21. billyboylindien
    billyboylindien WRInaute occasionnel
    Inscrit:
    28 Février 2005
    Messages:
    421
    J'aime reçus:
    0
    Pas mal du coté de ssl aussi :/

    M'enfin c'est pas exploitable par le quidam si ca peut rassurer...

    La sécurité.. c'est pas mal subjectif :)
     
  22. fandecine
    fandecine WRInaute passionné
    Inscrit:
    2 Avril 2005
    Messages:
    1 873
    J'aime reçus:
    0
    Bonjour

    Tu as un outils avec la pack putty: http://www.chiark.greenend.org.uk/~sgta ... nload.html

    J'avais un pot qui mettait jamais l'antivol à son vélo... Jusqu'au jour où il se l'ai fait tiré! :wink:

    En matière de sécurité, rien n'est nécessaire mais rien n'est inutile.

    Bien sur qu'il y a de nombreuses failles potentielles mais si quelqu'un accéde à ton serveur en root ssh, il peut faire ce qu'il veut de ton serveur, même faire des choses dont tu ne te rendra jamais compte!

    edit: j'avais oublié le lien :oops:
     
  23. thierry8
    thierry8 WRInaute accro
    Inscrit:
    11 Juillet 2005
    Messages:
    2 728
    J'aime reçus:
    0
    merci fandecine

    oui c'est vrai question un peu bête de ma part. :roll:
     
Chargement...
Similar Threads - [article] Sécuriser serveur Forum Date
Google victime d'abus d'incompréhension dominante [Article] Droit du web (juridique, fiscalité...) 17 Septembre 2010
[Article] Automatisez le déploiement de vos sites Administration d'un site Web 13 Août 2009
[Article] Les journaux cherchent le moyen de faire payer leur contenu Monétisation d'un site web 24 Mars 2009
[article] Exploiter les stats Google Webmaster Tools Référencement Google 16 Octobre 2008
[article] backlinks: la mort de l' Ancre Référencement Google 30 Septembre 2008
[Article] Lighttpd et apache sur le même serveur II Administration d'un site Web 26 Juin 2008
[Article] [beta]Sauvegarder un dédié part II Administration d'un site Web 13 Juin 2008
[Article] Configurer lighttpd (lighty) avec php5 Administration d'un site Web 16 Janvier 2008
[Article] Exemple de script de sauvegarde pour un dédié Administration d'un site Web 13 Janvier 2008
[article] APACHE, comment ça marche ? Administration d'un site Web 28 Décembre 2007
[article] Faire évoluer son architecture serveur Administration d'un site Web 4 Novembre 2007
[article] illustration de la force ds liens internes Référencement Google 19 Août 2007
[article] Optimiser son serveur dedié part II Administration d'un site Web 12 Février 2007
[article] Bien configurer apache Administration d'un site Web 27 Novembre 2006
[article] Optimiser son serveur dédié Administration d'un site Web 8 Mai 2006
[Article] Link Spam Detection Based on Mass Estimation Techniques avancées de référencement 9 Novembre 2005
[article] Google, Yahoo et MSN unis contre le spam ? Techniques avancées de référencement 26 Janvier 2005
[Article] L'effet sandbox sur Google Référencement Google 29 Décembre 2004
[Article] Le poids des mots, le choc des URL :-) Référencement Google 8 Décembre 2004
[Article] La commande link:URL sur Google Netlinking, backlinks, liens et redirections 5 Décembre 2004