Quelques astuces pour sécuriser un serveur dédié.
Me revoilà pour un article un peu plus technique que d’habitude. Il paraitraît que certains en sont friands alors autant les régaler.
Sujet plutôt sérieux car il s’agit de sécurité informatique. Un domaine qui me plaît tout particulièrement. Il est très vaste, autant vous prévenir tout de suite. Cela va de l’accès physique de locauxà la formation du personnel pour leur apprendre à ne pas mettre “azerty” en mot de passe, en passant par les alimentations redondantes et la sécurité d’une application. Bien entendu pour maTiTine nous ne traiterons pas de tous ces différents points.
Je comprends déjà votre déception. Vous qui rêviez de découvrir, enfin, la sécurisation accrue de la boîte aux lettres de Raf ainsi que l’accès biométrique du lecteur mp3 de Kef, et bien c’est raté!
Je vais traiter ici des principes simples de sécurisation d’un serveur dédié. Sachez toutefois qu’une personne (ayant un peu de moyen) qui voudra accéder à votre serveur ou le faire tomber parviendra à ses fins. Le tout étant quand même de se protéger un minimum.
Voici quelques principes/astuces que vous pouvez mettre en place facilement
- Changer les ports usuels des applications. Je prend l’exemple de SSH. Commandez un serveur chez OVH, attendez 2-3 jours et regardez les logs de connexions… Vous y observerez de nombreuses tentatives de connexions, le plus souvent des attaques de type “dictionnaire”. L’attaquant va essayer de se connecter en SSH à votre machine avec des mots de passes potentiellement utilisés.
Modifiez maintenant le port d’écoute pour SSH (par défaut 22). Miracle, 98% des tentatives de connexions ont disparu. Faites de même si vous hébergez un serveur FTP etc. - Se protéger des plaisantins qui continuent à faire des tentatives de connexion. Installez Fail2Ban. Ce tools s’occupera de bannir (de manière non permanente) les IPs effectuant trop de tentatives.
Note: Si vous avez modifié les ports d’écoute des services comme indiqué au point précédent, n’oublier pas d’indiquer les nouveaux ports dans la config de Fail2Ban. - Ne pas donner d’indice. Cela peut paraître tout bête mais par défaut Apache, pour ne citer que lui, fournit un grand nombre d’informations à une personne mal intentionnée. Comment? Avez vous déjà observé une erreur 404 non personnalisée? Ex: Apache/2.0.55 (Debian) PHP/5.1.2-1+b1 mod_ssl/2.0.55 OpenSSL/0.9.8b.
Ca nous donne pas mal d’info tout ça. Vous pouvez très bien obtenir cette signature en tapant une adresse bidon, ou en faisant un Telnet (port 80) sur la machine. Enfin quand je dis obtenir, c’est surtout si le propriétaire de la machine a laissé la dite signature! Je vous conseil donc vivement de supprimer toute signature, ca ne sert pas a grand chose de toute façon.Vous pouvez aussi visiter http://www.netcraft.com/ et tester votre url
Vous saurez tout de suite si une signature est ou a été présente! - Modifier les urls de base de vos applis ou de votre backend. Oui car mettre mondomaine.com/admin comme partie d’administration, c’est pas ce qu’on a vu de mieux. Pareil pour PhpMyAdmin etc. C’est tout bête, mais ça ne coûte rien et ça peut vous éviter des surprises!
- Est-il nécessaire de faire un rappel sur les mots de passe? On va dire que non :D. Contentez vous de ne pas mettre votre date de naissance ou “azerty” et de diversifier le plus possible vos passwords.
- S’en suit de pleins d’autres mesures: faire attention aux droits des dossiers/fichiers, interdire toute connexion aux ports d’applications auxquels le “public” ne devrait pas avoir accès (IPTABLES vous aidera si vous êtes sous linux), monitorez votre équipement et surtout backupez le.
Je pense avoir fait à peu près le tour. Je finirai simplement par une note : adaptez la sécurité à la criticité de vos données / équipements. Votre machine pour tester une application vite fait, bon on s’en fiche un peu. Le serveur de prod ou dev, un peu moins. Il faut juste éviter de sortir le tank pour tuer la mouche à merde!