Sécuriser son serveur sous Linux – L’essentiel des mises à jour

Sécuriser son serveur sous Linux – L’essentiel des mises à jour

SI vous administrez un serveur pour votre utilisation personnelle ou bien pour des clients, l’aspect Sécurité est essentiel et il est important de respecter un certain nombre de règles afin de contrer ou bien limiter les intrusions, les destructions et autres attaques malveillantes.

La première étape réside dans la mise à jour et mise à niveau de son serveur et notamment des programmes sur le serveur, sur Debian, lancez régulièrement la commande :

# apt-get upgrade

et

# apt-get update

Par contre vérifiez bien vos distributions et les mises à jour disponibles en fonction de ces dernières.

Vérification de version Linux

Afin de vérifier votre distribution, entrez la commande suivante :

# cat /etc/debian_version

Logiquement sous Debian, vous devriez voir apparaître une des suivantes :

– Squeeze

– Wheezy

– Jessie

La première est stable mais ancienne, la seconde est stable et plus récente tandis que Jessie contient les paquets les plus récents mais présente des bugs.

Par exemple, si vous ne trouvez pas une version spécifique de php et que vous êtes certain qu’il y a un problème avec la version actuelle, alors il vous faudra trouver une autre liste pour faire la mise à niveau.

Faites bien la distinction sur Debian entre les distributions wheezy et squeeze ainsi que les paquets Test…

Vérifiez votre fichier de distributions pour y inclure des lignes telles que :

deb http://packages.dotdeb.org wheezy all
deb-src http://packages.dotdeb.org wheezy all

Posez vous la question entre une version Stable et une version en évolution constante.

En général la version Stable ne conviendra pas à moins de patcher les installations.

Mettre à jour constamment vers les dernières versions vous assurent des patchs automatiques couvrant les dernières failles découvertes.

Alors notre conseil : prenez tout ce qu’il y a de plus récent.

Mais faites bien vos sauvegardes avant toute mise à jour importante.

Voici un exemple qui implémente ces divers conseils :

Fichier /etc/apt/sources.list

deb http://mirror.ovh.net/debian/ wheezy main contrib
deb-src http://mirror.ovh.net/debian/ wheezy main contribdeb http://security.debian.org/ wheezy/updates main contrib
deb-src http://security.debian.org/ wheezy/updates main contribdeb http://packages.dotdeb.org wheezy all
deb-src http://packages.dotdeb.org wheezy all

deb http://ftp.us.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.us.debian.org/debian/ testing main contrib non-free

On voit bien ici testing main contrib non-free

testing inclue les paquets en test mais les plus récents.

Une fois votre liste à jour faites :

# apt-get update

et

# apt-get upgrade

Ou bien allez y par paquet si vous préférez.

# apt-get install apache2

En utilisant les commandes ci-dessus, vous êtes sûr d’utiliser la meilleure méthode pour mettre à jour vos paquets.

Aussi il peut être judicieux de nettoyer les restes des paquets antérieurs avec la commande :

# apt-get clean

et

# apt-get autoclean

Et voici une liste de sources incluant les pacquets en tests et qui sont instables :

# Unstable
deb http://ftp.debian.org/debian unstable main contrib non-free
deb-src http://ftp.debian.org/debian unstable main contrib non-free

# Testing
deb http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free

# Stable
deb http://ftp.debian.org/debian stable main contrib non-free
deb-src http://ftp.debian.org/debian stable main contrib non-free

# Security updates
deb http://security.debian.org/ stable/updates main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

Vous pouvez aussi utiliser cette liste mais sachez qu’il est préférable de s’y connaitre pour anticiper les problèmes et y remédier au cas où.

Pour davantage de profondeur, vous pouvez lancer la commande :

# apt-get dist-upgrade

Cette dernière mettra à niveau votre distribution. Ne la lancez pas sans raison.

Backports

Les sources « backports » sont d’autres sources qui permettent de télécharger et installer des paquets qui ne sont pas contenus dans les versions stables de Debian. Le problème réside dans certaines incompatibilités. On préfèrera ici les sources TEST qui listent des programmes encore plus récents.

Versions des logiciels

Il est primordial de connaître la version des logiciels installés sur une machine et les commandes suivantes ne sont qu’un aperçu :

Pour apache2 et openssl :

# apache2 -v

# openssl version

Et Openssh :

# sshd -v
# ssh -v

Les configurations

Par défaut les configurations de certains programmes sont un peu léger en terme de sécurité, un brin de modification permet d’améliorer la robustesse :
Par exemple Php affiche sa version ouvertement à tout public, une simple modification dans /etc/php5/apache2/php.ini :
expose_php=Off
Aussi Apache2 si on ne s’en occupe pas, laisse l’opportunité aux visiteurs d’un site internet de lister les éléments d’un répertoire. Pour palier à cela, il faut ajouter la commande suivante au sein de vos fichiers pour chaque site, dans apache2 :

Ajoutez la ligne :

Options -Indexes

au sein d’un fichier /etc/apache2/site-available/nomdedomaine.com.conf

par exemple :

<Directory /home/nomdedomaine.com/html>
#on retire le listing des directory
Options -Indexes
IndexIgnore *
# On autorise tous le monde a voir le site
Require all granted
</Directory>

Lors des mises à jour de Apache ou autre, méfiez vous des modifications que cela implique, par exemple entre une version 2.2 et 2.4 de apache2, il y a des surprises.
Dans apache2, on peut ne pas afficher la version du serveur aussi :
Au sein de conf.d/security :
ServerSignature Off

Quelques vulnérabilités

Pour une liste de vulnérabilités à jour, rendez vous sur :

http://www.kb.cert.org/vuls/

  • Forward Secrecy – Clé de sécurité non compromise

Vous avez un site avec connexion sécurisée en ssl, alors il vous faut contrer les failles de certains navigateurs en renforçant les protocoles utilisés par votre serveur Apache.

On bloque certains protocoles, tout type de compression non requise et on définit un ordre pour les navigateurs.

Pour ce faire, modifiez le fichier ssl.conf utilisé par Apache pour ajouter ces lignes :

SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA
Faites une analyse de votre serveur (outils listés plus bas) pour vous assurer que la ligne suivante montre bien :
Forward Secrecy Yes (with most browsers)   ROBUST
  • Vulnérabilité Etag

Dans les fichiers des virtualhost sites-available/host.conf

on ajoute la directive :

FileETag None

Cette directive permet de sécuriser le protocole http de votre serveur pour ne pas ajouter au cache des éléments qui peuvent être utilisés par les hackers. Notamment pour les connexions sécurisés, on ne veut pas « cacher » des informations confidentielles !

Toujours à propos de Cache,

Activez le module headers avant tout :

# sudo a2enmod headers

Pour votre site sécurisé, assurez d’avoir ces lignes dans les headers de vos pages :

Header set Expires "Thu, 19 Nov 1981 08:52:00 GM"
Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0,private"
Header set Pragma "no-cache"

Cela permet d’éviter la sauvegarde des pages de la part des proxy et navigateurs.

Sessions et Cookies

Concernant les cookies et sessions stockées, la directive : HTTPOnly

fait en sorte que les cookiers des navigateurs sont illisibles pour les scripts javascripts de ce fait les attaques XSS sont considérablement réduites.

Afin d’activer cette directive, cela se passe au niveau de vos scripts Php :

ini_set(« session.cookie_httponly », 1);
ini_set(« session.cookie_secure », 1);
//cookies valides 10 minutes  :

session_set_cookie_params(‘600’,);

session_start();

Ces lignes vous assurent un bonne utilisation des cookies.

Outils de détection

Une fois que votre serveur est prêt, faites lui une batterie d’analyses avec les outils appropriés.

Voici une liste de quelques outils bien utiles :

  • ZAP ou Zed Attack Proxy Project

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Un logiciel proxy simple à télécharger, il vous permet de lister les failles d’un serveur en particulier.

Et des outils en ligne généralement utilisés :

Vous êtes fin prêt à passer le scan pour obtenir le certificat pci compliance

Et vous n’avez que faire de la menace Heart Bleed Bug

En espérant que cet article vous mettra sur la bonne voie, le principal étant de régulièrement faire les mises à jour.

Et de s’informer sur les différentes configurations de vos serveurs vous aidera à comprendre telle ou telle fonction et surtout de savoir si elles sont utiles ou tendent à ouvrir de nouvelles portes aux attaques.

Pour d’autres notions sur la sécurité de votre serveur, parcourez l’article Sécurité de votre serveur Linux.

Sources :

http://www.dotdeb.org

http://backports.debian.org

http://www.mayin.org/ajayshah/COMPUTING/debian-principles.html

http://heartbleed.com/

http://debian-handbook.info/browse/wheezy/apt.html

Copyrights © 2016: RHM - Optimisation et développement informatique pour Entreprises et Associations