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.
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 :
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).
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.
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
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
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
De nombreux RDCs prennent en charge IPv6 par défaut. Les RDCs suivants activent IPv6 par défaut.
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 :
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.
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
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
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.
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.
Référence :
https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-1-3-apache.md
Référence : https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-1-3-nginx.md
Référence :
https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-versions-cdns.md
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
Référence :
https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-cipher-order-apache.md
Référence:
https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-tls-1-3-nginx.md
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».
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 :
Référence:
https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-hsts-apache.md
Réference: https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-hsts-nginx.md
Référence : https://github.com/InternetSociety/ose-documentation/blob/master/ose-web-hsts-cdns.md
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 :
Référence :
Référence:
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.
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:
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 :
