Pourquoi certains serveurs Web fournissent-ils toujours des informations sur le fournisseur et la version dans les en-têtes de réponse HTTP
Je pense que dans le domaine de la sécurité, c'est un fait bien connu que ce n'est pas une bonne idée de laisser le fournisseur du serveur Web (par exemple Apache) et la version être visible à l'extérieur car cela peut être utilisé pour lancer des attaques ciblées contre un serveur spécifique la mise en oeuvre.
J'ai lancé un conteneur Docker Apache 2.4 pour voir si c'est toujours le cas - et oui, c'est le cas.
J'y ai réfléchi un peu. Ne serait-il pas formidable d'avoir une norme que les serveurs Web peuvent implémenter par rapport à laquelle définit un ensemble de fonctionnalités standard qui est versionné à l'aide de la version sémantique?
De cette façon, les applications peuvent toujours gérer différentes versions de serveur (ce qui semble être la seule raison pour laquelle je voudrais voir la version de l'extérieur) - mais au moins le fournisseur du serveur Web pourrait être caché. Ce serait au moins un obstacle supplémentaire auquel un attaquant doit faire face.
Qu'est-ce que tu penses?
Oui, en théorie, le fournisseur de publicité et la version de la bannière facilitent le travail d'un attaquant, mais comme un tout petit peu.
Même si vous n'en faites pas la publicité, cela peut être déterminé à partir du comportement de l'application. Prenons par exemple l'outil d'analyse de réseau nmap:
Nmap fournit un certain nombre de fonctionnalités pour sonder les réseaux informatiques, y compris la détection d'hôte et la détection de service et de système d'exploitation. Ces fonctionnalités sont extensibles par des scripts qui fournissent une détection de service plus avancée, une détection de vulnérabilité et d'autres fonctionnalités.
Source: wikipedia
Une fois que TCP et/ou UDP ont été découverts à l'aide de l'une des autres méthodes d'analyse, la détection de version interroge ces ports pour déterminer ce qui est réellement en cours d'exécution. La base de données nmap-service-sondes contient des sondes pour interroger divers services et faire correspondre des expressions pour reconnaître et analyser les réponses.
Source: documentation nmap .
Fondamentalement, nmap commencera par essayer de décider s'il s'agit d'Apache/nginx/IIS, etc., ce qu'il fera en envoyant un paquet spécifique auquel il sait que les différents serveurs Web répondront différemment. Ensuite, une fois qu'il sait qu'il s'agit d'Apache, il enverra des paquets qui ciblent les comportements qui ont changé entre une version et une autre, peut-être à cause d'un bug corrigé ou à cause d'une nouvelle fonctionnalité.
Comme indiqué par @ paj28 dans les commentaires, nmap est assez bon pour détecter le fournisseur, mais avec et avec la version, lorsque nmap affiche des informations détaillées sur la version, c'est probablement parce qu'il y avait une bannière. Bien sûr, si vous essayez de pirater, pourquoi vous embêter à essayer de trouver la version du tout; une fois que vous savez que c'est Apache, pourquoi ne pas simplement exécuter tous les scripts d'exploitation Apache de metasploit et voir si certains d'entre eux restent?
Donc oui, en théorie, il est possible d'écrire une spécification pour "Voici comment tous les serveurs Web DOIVENT se comporter", mais cela signifie que vous n'autorisez jamais les serveurs Web à innover ou à corriger des bogues. De plus, les serveurs Web voudront se différencier avec des fonctionnalités que les autres serveurs n'ont pas.
Comme l'a souligné @TripeHound, les bannières de version peuvent être considérées comme une victoire pour la sécurité car elles permettent aux administrateurs système de répertorier facilement leurs systèmes et de les maintenir à jour.
TL; DR: Bannière ou non, vous pouvez déterminer à quel serveur Web et système d'exploitation vous parlez.
Exemple Nmap
Depuis que ce post est devenu populaire, je vais ajouter et quelques exemples:
Apache httpd place les informations de version directement dans un en-tête HTTP:
HTTP/1.1 200 OK
Date: Thu, 17 Oct 2019 14:26:10 GMT
Server: Apache/2.4.6 (CentOS)
et sans surprise, nmap reprend ceci:
~ nmap 192.168.56.107 -p 80 -A --version-all
Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-17 07:58 EDT
Nmap scan report for 192.168.56.107
Host is up (0.0020s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.6 ((CentOS))
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Apache/2.4.6 (CentOS)
|_http-title: Apache HTTP Server Test Page powered by CentOS
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 Host up) scanned in 14.23 seconds
Si nous essayons quelque chose d'un peu plus délicat, Apache Tomcat ne donne pas de bannière évidente:
HTTP/1.1 200
Accept-Ranges: bytes
ETag: W/"1896-1527518937672"
Last-Modified: Mon, 28 May 2018 14:48:57 GMT
Content-Type: text/html
Content-Length: 1896
Date: Thu, 17 Oct 2019 14:35:05 GMT
Connection: close
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Apache Tomcat</title>
</head>
...
nous voyons que nmap obtient le bon vendeur, mais n'a pas de supposition sur la version:
~ nmap -A -p 8080 192.168.56.1
Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-17 10:34 EDT
Nmap scan report for 192.168.56.1
Host is up (0.0013s latency).
PORT STATE SERVICE VERSION
8080/tcp open http Apache Tomcat
| http-methods:
|_ Potentially risky methods: PUT DELETE
|_http-open-proxy: Proxy might be redirecting requests
|_http-title: Apache Tomcat
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 Host up) scanned in 21.71 seconds
Les attaquants s'en moquent. Lorsque vous avez un site Web populaire, vous trouvez des robots qui sondent chaque version (vulnérable) de phpmyadmin sur tous les chemins imaginables, même lorsque votre site n'utilise pas du tout de base de données. De la même manière, ils recherchent probablement des failles de sécurité dans chaque version, par exemple, Apache. Être allongé ou omis de l'en-tête Server ne vous apporte pas beaucoup de sécurité ici.
Mais lorsque vous êtes l'administrateur, vous pouvez utiliser l'en-tête Server pour identifier rapidement, si le serveur n'est toujours pas corrigé, ce qui peut vous empêcher d'oublier que vous n'avez pas encore mis à jour.
Bien sûr, vos préoccupations sont valables, par exemple, lorsque quelqu'un recueille des informations et peut trier manuellement les exploits, cela fonctionnerait lorsqu'il connaît la bonne version, mais dans la plupart des cas, il s'agit uniquement de sécurité par obscurité. Le point important est que vous devez vous assurer de maintenir le logiciel à jour, vous n'avez donc pas à vous soucier d'un attaquant sachant que vous exécutez la dernière version.
Historiquement, de nombreux serveurs ont renvoyé des en-têtes comme celui-ci:
Serveur: Apache/2.4.1 (Unix) mod_php/1.2 mod_ssl/0.9
Cela donne un peu plus d'informations que vous ne le souhaitez, donc la plupart des serveurs utilisent désormais par défaut des en-têtes comme celui-ci:
Serveur: Apache
En fait, la plupart des serveurs Web rendent difficile la désactivation de cet en-tête. La raison? Commercialisation. Ils veulent apparaître dans les enquêtes sur les serveurs Web les plus courants.
En ce qui concerne les empreintes digitales, un certain nombre d'outils peuvent déterminer de manière assez fiable Apache vs NGINX vs IIS, etc.
Comme dit, ce n'est pas un problème de sécurité de le laisser, et c'est une information utile pour certains programmes clients. Prenez curl par exemple: il utilise la valeur d'en-tête Server pour vérifier si le pipelining HTTP peut être activé:
Tiré de https://serverfault.com/a/596560/34761
[curl affiche ce message lorsqu'il est exécuté en mode verbeux
-v]:
* Server Apache/... is not blacklistedIl s'agit d'un message interne de curl. Semble faire partie d'une fonction de bouclage liée au pipelining.
Voir aussi https://daniel.haxx.se/blog/2013/03/26/better-pipelining-in-libcurl-7-30-0/
une liste noire de serveurs [note: "basée sur l'en-tête du serveur"] qui permet à l'application de spécifier une liste de serveurs pour lesquels le pipelining HTTP ne doit pas être tenté - des tests réels ont prouvé que certains serveurs sont trop cassés pour être autorisés à jouer le Jeu
C'est pourquoi il est toujours activé par défaut et est totalement inoffensif (il suffit de garder votre serveur à jour). C'est en quelque sorte la version du serveur de User-Agent entête.
Parce que masquer les informations de version est une mesure de sécurité faible et une forme de sécurité par l'obscurité . Le niveau de sécurité qu'il ajoute est discutable, étant donné que a) les attaquants peuvent toujours prendre leurs empreintes digitales et déterminer probablement votre serveur, votre version et vos mods dans une marge d'erreur étroite et b) les attaquants peuvent simplement vous lancer leur bibliothèque entière d'exploits de toute façon.
Dans la plupart des scénarios, tout ce que vous faites est d'ajouter un peu de temps et d'efforts à l'attaquant. Le seul scénario où vous gagnez réellement quelque chose est si un attaquant prépare une grande attaque en analysant des réseaux entiers pour concentrer sa dernière attaque uniquement sur les serveurs trouvés vulnérables (c'est-à-dire qu'il veut compromettre autant de sites que possible en aussi peu de temps que possible) - et il n'utilise pas les empreintes digitales ou cela ne fonctionne pas de manière fiable sur votre site.
C'est pourquoi désactiver les informations de version en production est l'un de ces fruits bas que nous faisons ou conseillons habituellement simplement parce que cela ne fait pas de mal et pourrait faire un peu de bien, alors pourquoi pas?
Pendant le développement, ne pas pouvoir vérifier la version de l'extérieur peut entraîner un travail supplémentaire (se connecter au système, y vérifier avec des outils de ligne de commande), ou peut-être même pas possible car les développeurs ne peuvent pas accéder directement au serveur, donc dans la version de développement les numéros ne sont généralement pas désactivés.
Votre image Docker ne sait pas si elle sera utilisée pour la production ou le développement. C'est pourquoi il conserve les numéros de version - cela ferait plus de mal dans un cadre que dans l'autre.