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…
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…