Assomption avant de commencer : Bien entendu, vous êtes à jour des derniers correctifs de sécurité de l’ensemble de vos services…
En lisant un article faisant référence à un serveur mal sécurisé ; j’ai été pris de quelques doutes : et si mon serveur dédié était lui aussi mal sécurisé ?
Étant développeur et adepte de l’auto hébergement (oui je ne suis pas un grand fan des services hébergés chez les géants du net avec leurs clauses de confidentialité obscures…) je fais évoluer mon serveur dédié (services qui tournent dessus) au rythme de mes besoins… ce qui fait que la sécurité passe souvent au second plan…
Et rien de tel que de jeter un coup d’œil à la sécurisation de ces services de temps en temps…
Contents
Audit rapide et efficace
On commence avec nmap, avec les options qui vont bien :
|
1 |
sudo nmap -A mon.serveurdedie.fr |
On peut alors commencer à l’analyse du résultat, et à remédier aux problèmes.
DNS et Bind
Dans le rapport obtenu par nmap, si vous voyez :
|
1 |
| dns-zone-transfer: |
et ensuite la liste de vos sous domaines; méfiance, cela veut dire que quiconque peut lister vos sous domaines; pas forcément une bonne idée si certains d’entre eux sont là pour des tests ou pour des services non publics…
Les solutions
|
1 2 3 4 5 |
Rendez vous dans votre fichier de configuration de bind, /etc/bind/named.conf.options, et ajouter les options suivantes : allow-transfer { x.x.x.x; }; --> uniquement donner accès aux informations détaillées des zones à cette IP (votre dns secondaire) version "Ma version"; --> pourrait derouter certaines attaques en offuscant la version de Bind; mais comme disent certains, l'obfuscation est rarement une bonne méthode de sécurisation... fetch-glue no; --> défendre votre serveur dns aux attaques de type déni de service recursion no; --> défendre votre serveur dns aux attaques de type déni de service |
Ces informations sont issues d’un article de TechRepublic , et n’hésitez pas à vérifier votre configuration avec zonecheck
HTTP et Apache
Dans le rapport obtenu par nmap, si vous voyez :
|
1 |
80/tcp open http Apache httpd 2.2.9 ((Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny13 with Suhosin-Patch mod_wsgi/2.5 Python/2.5.2) |
Et bien cela signifie que votre serveur est très bavard…
La solution
Sur Ubuntu, dirigez vous vers /etc/apache2/conf.d/security et éditez :
|
1 |
ServerTokens Prod |
|
1 |
ServerSignature Off |
|
1 |
TraceEnable Off |
Si vous utilisez PHP, faites aussi un tour du côté de /etc/php5/apache2/php.ini
|
1 |
expose_php = Off |
Encore une fois, l’offuscation n’est pas une méthode de sécurisation en soit, mais moins les potentiels attaquants en savent, mieux c’est…
Ces informations sont issues de DebianAdmin
SSH et OpenSSH
Pour l’instant je ne peux que conseiller de lire cet article : http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
à suivre…
Sécurisé son serveur dédié n’est pas simple.Il ne faut surtout pas négliger la sécurité !
A l’heure d’aujourd’hui beaucoup de Web Agencies installent un bête Apache sur un serveur dédié et croient à tord avoir un hébergement dignes de ce nom.
On ne s’improvise pas administrateur système d’un jour à l’autre.
Je pense qu’il est bien mieux de faire infogérer son serveur dédié ou VPS par des professionnels.
A terme cela vous rapportera plus de clients, un très bon retour sur investissement, la garantie d’avoir vos données sécurisés, un contact en cas de problème et surtout un serveur en bonne santé, à jours, optimisé, surveillé, sauvegardé etc.
Pour compléter un peut votre article, pensez à désactiver IPv6 si vous ne l’utiliser pas…
Il y a aussi un module tres pratique avec Apache : mod_evasive qui permet de limiter les requetes (Exemple : IP bloque X secondes si plus de X requetes en X secondes).