Accroître la sécurité et la disponibilité des Serveurs Web sur Internet grâce à l’utilisation des normes ouvertes

Source : Nomedia

INTRODUCTION

Pour qu’internet reste ouvert, connecté au niveau mondial, fiable et sûr, sa sécurité demeure un des critères principaux et c’est dans ce cadre que l’Internet Society a créé un projet dénommé « Open Standards Everywhere  »  qui est de déployer des normes ouvertes partout  afin  de savoir  les meilleures pratiques à adopter pour rendre disponible sur Internet nos serveurs web et accroître la sécurité sur  Internet.

Des normes Internet ouvertes sont la pierre angulaire du succès de l’Internet. Elles permettent son existence, facilitent son développement et fournissent une plate-forme qui soutient la créativité, ainsi que les opportunités commerciales et sociales pour ses milliards d’utilisateurs. Les standards ouverts sont mis en œuvre  dans le monde à travers toutes sortes de produits et services Internet. Elles permettent aux utilisateurs d‘Internet de pouvoir communiquer d’une partie à une autre partie du réseau en utilisant les mêmes normes et protocoles.

Pour accroître la sécurité des serveurs web,   il y a un processus à suivre qui se résume en quelques étapes dont la toute première à effectuer  avant toute manipulation est de tester ces serveurs  afin de déterminer les insuffisances puis de les corriger. Ce premier  test sera appelé Pré-test. Vous pouvez le faire avec l’outil https://internet.nl et l’outil http2.pro.

A – La Disponibilité 

Lorsqu’un site web ou un service web n’est pas disponible en ligne ou ne fonctionne pas assez bien pour que les utilisateurs terminent une tâche, le site est considéré comme étant indisponible.

Pour rendre disponible les sites et services web sur Internet, il est indispensable de disposer de normes et protocoles permettant d’accélérer les performances des serveurs web en réduisant la latence et  de répartir efficacement les charges découlant des requêtes des utilisateurs.

Pour que cela soit faisable, il devient nécessaire pour les serveurs web de disposer de :

 1 – IPv6

Les adresses IP (Internet Protocol) font partie des protocoles de communication sur Internet permettant à chaque machine, de l’ordinateur domestique au serveur hébergé dans un datacenter  (centre de données abritant plusieurs serveurs), d’avoir une adresse unique.

Nous utilisons au quotidien des adresses IP, dites IPv4, dont le nombre est désormais limité et dont les stocks sont presque épuisés. D’autant plus que les limites de IPv4 ont été largement éprouvées, les adresses IPv6 sont devenues importantes pour rendre les serveurs accessibles aux visiteurs à l’aide d’une adresse Internet. En cas d’impossibilité pour obtenir une adresse IPv6, il est recommandé d’aller vers un Réseau de Diffusion de Contenu (RDC) ou en anglais Content Delivery Network (CDN).

 

  • IPv6  – fournit par un Hébergeur Web ( Web Hosting Provider)

La mise à disposition pour les serveurs web d’adresse IPv6 est d’emblée fournit par la majorité des hébergeurs web disponibles sur le marché.

Mais dans le cas où votre serveur web n’en dispose pas ( faire le test sur internet.nl pour en être sûr) il faut contacter votre fournisseur de service pour lui demander d’en déployer sur votre infrastructure.

 

  • IPv6  ( sur un serveur Auto-hébergé avec Apache)

Dans ce cas de figure, Apache, serveur web, parmi les plus utilisés sur Internet, devrait être configuré par défaut pour écouter toutes les interfaces. Vous pouvez confirmer dans le fichier de configuration (généralement httpd.config apache.conf).

Référence : Configurer IPv6 sur un serveur Apache

 

  • IPv6   ( sur un serveur Auto-hébergé avec NGINX )

Tout comme Apache, NGINX est également un logiciel libre de serveur web, configurable, pour le rendre accessible au moyen d’une adresse  IPv6. Pour le configurer, inspirez vous des travaux référencés ici dans cette documentation : Configurer IPv6 sur un serveur NGINX

 

  • IPv6  et  DNS Auto hébergé

Vous disposez de serveur auto-hébergé ? Configurer votre adresse IPv6 en créant un enregistrement AAAA dans votre zone DNS. Suivez ce tutoriel en cliquant ici

 

  • IPv6  & RDC (Réseaux de Distribution de Contenu)

De nombreux RDCs  prennent en charge  IPv6 par  défaut. Les RDCs suivants  activent  IPv6 par  défaut.

2 – HTTP/2

Développé par le groupe de travail httpbis de l’IETF, HTTP/2 est une version majeure du protocole réseau HTTP utilisé sur le World Wide Web. Il est issu du protocole expérimental SPDY de Google.

HTTP/2  de son nom Hypertext Transfer Protocol version 2 accélère les performances du serveur web et réduit la latence en :

  • Permettant  plusieurs  échanges  de données  sur une seule  connexion
  • effectuant la Compression des en-têtes
  • Permettant  aux serveurs  Web de « pusher »  les  données  vers les  navigateurs  Web

 

  • HTTP/2  & Fournisseur d’hébergement

Si vous  utilisez  un fournisseur  d’hébergement,  HTTP  / 2 est probablement  activé  par  défaut.  Vous pouvez le vérifier  en utilisant  votre test internet.nl ou sur http2.pro. Dans le cas ou votre serveur n’en disposerait pas, réclamez cette option auprès de votre fournisseur de services d’hébergement de services web.

 

  • HTTP/2  Self Hosted- Apache & Nginx (Debian)

Vous disposez d’un serveur que vous administrez vous même ? Utilisez HTTP/2 et configurer le sur votre serveur web Apache,  en vous référant sur :

Référence: Configurer http2 sur un serveur apche et sur Nginx en suivant ce tutoriel : configurer http2 sur un serveur Nginx

 

  • HTTP/2  RDC

Certains RDCs prennent en charge  HTTP  / 2 par  défaut. Par défaut des Fournisseurs de Contenus comme Akamai et Cloudfare activent IPv6. Nous continuons à développer  la liste  dans  la  documentation à  mesure que nous découvrirons  d’autres RDCs prenant  en charge  HTTP  / 2.

Référence : https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-http2-cdns.md

 

B-  La Sécurité

source : pixabay

La sécurité informatique est importante, principalement pour protéger vos informations. Il est également important pour la santé globale de votre ordinateur, en aidant à prévenir les virus et les logiciels malveillants et en aidant les programmes à fonctionner plus facilement.

 

1 – TLS

Standardisée dans le RFC 8446 -août  2018, le Transport Layer Security, anciennement connu sous le nom de  «Secure  Sockets  Layer»  ou «SSL»  chiffre  la  connexion entre le client  Web et le serveur sur lequel sont hébergés vos services et sites web. TLS  est devenue un des meilleurs moyens pour sécuriser les  activités.

La session chiffrée est utilisée pour empêcher un tiers d’intercepter des données sensibles transitant par le réseau : numéro de carte lors d’un paiement par carte bancaire, mot de passe lorsque l’utilisateur s’identifie sur un site…

Aujourd’hui TLS en est à sa version 1.3 et il est naturel pour les serveurs web de disposer de cette version plus récente ou tout au moins de la version 1.2 qu’en lieu et place des celles antérieures. Différentes autorités de certification proposent de nos jours des certificats TLS gratuits et sécurisés.

Avec Let’sEncrypt, vous pouvez installer un TLS sur vos serveurs web afin de sécuriser vos utilisateurs et vos services et sites qui y sont déployés.

Pour déployer et protéger les serveurs, différentes configurations de TLS sont utilisées et dépendent du type de service sur le serveur web.

source : pixabay

  • TLS – Self hosted –Apache

Référence :

https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-1-3-apache.md

 

  • TLS – Self hosted –NGINX 

Référence : https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-1-3-nginx.md

 

  • TLS Versions RDC

Référence :

https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-versions-cdns.md

 

  • TLS – Cipher Order

TLS  utilise  plusieurs  formes de chiffrements  cryptographiques. La meilleure  pratique  consiste à configurer  votre serveur  Web pour  qu’il  préfère  les chiffrements  les  plus sécurisés

 

  • TSL Cipher Order- Self hosted Apache

Référence :

https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-cipher-order-apache.md

 

  • TSL Cipher Order- Self hosted NGINX

Référence:

https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-1-3-nginx.md

 

  • TSL Cipher Order- CDNs

De nos recherches jusqu’à présent, la plupart des CDN ne permettent pas de modifier l’ordre de chiffrement à moins que vous ne soyez un client payant avec un plan «premium» ou «entreprise».

Voir: https://community.akamai.com/customers/s/article/WebPerformanceSSLTLSCipherProfilesforAkamaiSecureCDN20180522162530?language=en_US

 

2 – HSTS

HSTS est le HTTP Strict Transport Security – standardisé par le RFC 6787 de 2012. Il fait partie des HTTP security headers.

Ce header, à la différence des autres en-têtes dont nous parlerons plus bas, s’assure que les communications entre le navigateur web et le serveur seront bien en HTTPS. En bref, une fois que le navigateur a reçu ce header de la part du serveur, celui-ci n’enverra plus de requêtes HTTP au serveur, mais restera sur HTTPS. Si un lien ou un contenu utilise HTTP, il sera automatiquement converti vers HTTPS. HSTS permet de protéger contre des cyberattaques comme les attaques de l’homme du milieu (MiTM).

REMARQUE: si vous désactivez TLS, les navigateurs Web qui ont déjà visité votre site ne pourront pas se connecter via HTTP non sécurisé jusqu’à l’expiration de HSTS.

Pour déployer et protéger les serveurs, différentes configurations de TLS sont utilisées et dépendent du type de service sur le serveur web :

 

  • HSTS – Self-hosted – Apache  

Référence:

https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-hsts-apache.md

 

  • HSTS – Self-hosted – NGINX

Réference: https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-hsts-nginx.md

 

  • HSTS – avec les Content Delivery Networks

Référence : https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-hsts-cdns.md

 

3 – HTTP Security Headers

La sécurité des sites et serveurs web peut impliquer de lourds investissements en termes de développement web. Mais certains petits ajustements peuvent aussi vous permettre une avancée significative en matière de sécurité. Ces modifications sont minimes en termes de code et de configuration, mais elles requièrent une bonne analyse et une validation avant d’être implémentées.

Il s’agit des headers HTTP. Il faut savoir que ces headers ont un impact sur les navigateurs web. Ils donnent des directives aux navigateurs pour leurs comportements (s’ils implémentent les fonctionnalités correspondantes). Ils ne modifient pas le comportement du serveur web, mais accroît sa sécurité.

Les différentes configurations observées au niveau des serveurs web peuvent facilement se prêter pour l’implémentation des en-têtes HTTP :

 

  • HTTP Security Headers – Self-hosted – Apache  

Référence :

https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-http-security-headers-apache.md

 

  • HTTP Security Headers – Self-hosted – NGINX

Référence:

https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-http-security-headers-nginx.md

 

  • HTTP Security Headers – CDNs

Les quatre en-têtes de sécurité que nous recommandons d’ajouter «passeront tous» le CDN s’ils sont configurés sur le serveur d’origine.

Certains CDN autorisent la configuration de ces en-têtes si le serveur d’origine ne les prend pas en charge.origin server ne les prend pas en charge.

4 – DNSSEC

Les extensions de sécurité DNS, «DNSSEC», permettent de s’assurer que vous obtenez des informations précises du DNS

Resources : https://www.internetsociety.org/deploy360/dnssec/

 DNSSEC doit être configuré avec vos serveurs DNS. Les étapes comprennent généralement:

Les serveurs DNS qui hébergent votre domaine doivent « signer » le domaine. Ces serveurs DNS peuvent être ceux que vous exploitez directement. Ils peuvent être chez un fournisseur d’hébergement DNS. Ils peuvent être chez votre registraire de nom de domaine.

Les informations du serveur DNS sur les signatures (un « enregistrement DS ») doivent être fournies à votre bureau d’enregistrement de noms de domaine.

Le registraire du nom de domaine enverra cet enregistrement DS au « registre » du domaine de premier niveau pour votre domaine (ex. .COM, .ORG, .NL, .MX)

Une fois cela terminé, votre domaine sera signé.

Référence:

https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-http-security-headers-apache.md

En ce qui concerne le DNSSEC pour les serveurs contenus dans un CDN, il faut noter que la plupart de ces fournisseurs de services demandent des modifications minimales pour que le trafic DNSSEC passe. Certains CDN fournissent des services d’hébergement DNS et signer automatiquement avec DNSSEC.

 

CONCLUSION

Le plus du projet Open Standard Everywhere est d’essayer quelque chose de différent.

Notre objectif est de pouvoir mettre à la disposition de la communauté et des administrateurs systèmes, des DevOps et des développeurs d’applications un livre blanc pour leur permettre de configurer les Normes Ouvertes Partout sur les infrastructures dont ils ont la charge.

 

Par Harold ADJAHO & Elie EHOUMI, membres d'Internet Society Benin

 

Ressources :

  1. https://www.internetsociety.org/resources/deploy360/2013/making-content-available-over-ipv6/
  2. https://www.internetsociety.org/tutorials/introduction-to-ipv6
  3. https://github.com/InternetSociety/ose-documentation/