Est-il possible de dire si deux adresses IP appartiennent au même serveur?

Compte tenu de deux adresses IP publiques et des connaissances qui se trouvent toutes deux sur le même réseau / 27, serait-il possible de déterminer à partir d'un emplacement distant (c'est-à-dire d'un pays différent) si elles appartiennent à un ou deux serveurs?

Non, ce n'est pas le cas dans le cas général.

Quelques ajouts, pour rendre nos invités de SO heureux:

• Il n'y a rien dans les protocoles TCP / IP de base (par exemple IP / TCP / UDP, ICMP) qui soit spécifiquement destiné à faire la distinction demandée dans la question.
• Il en va de même pour de nombreux protocoles de niveau supérieur, par exemple HTTP.
• Il est en effet possible d'utiliser des différences plus ou moins subtiles dans les schémas de réponse pour faire une supposition sur le système. Si vous avez deux systèmes très différents, par exemple un serveur Linux et un serveur Windows, cela peut suffire pour être sûr d'avoir deux hôtes.
• Cela deviendra plus difficile à mesure que les systèmes seront similaires. Il est probablement impossible de séparer deux nœuds d'un cluster Web HA avec un matériel et un système d'exploitation identiques. Je considère que c'est le cas général dans la plupart des scénarios aujourd'hui.
• Enfin: deux machines virtuelles sur le même boîtier physique ont-elles un ou deux serveurs? Selon la raison pour laquelle vous essayez de vous différencier en premier lieu, cela peut être important et il est complètement impossible de le dire au niveau du réseau.

Curieux de savoir "pourquoi". Les préoccupations concernant les machines à double hébergement sont généralement localisées comme des maux de tête de certains administrateurs système sans nom. Les détails sont censés être cachés par le modèle OSI.

Réponse centrée sur Linux à venir.

Il existe plusieurs façons de générer des empreintes digitales et de faire une supposition éducative.

1. nmap -o et nmap avec une analyse de port décente. Les serveurs ne se lient pas toujours aux deux cartes réseau. Mais souvent, ils le font.

2. Adresses MAC. Si vous aviez le moyen d'obtenir les adresses MAC, les fabricants aiment utiliser des adresses consécutives pour le matériel intégré. Deux adresses MAC presque identiques sont probablement la même carte mère. Bien sûr, cela ne s'applique pas aux cartes de rechange.

3. Salutations. Telnet, ftp, smtp et similaires offrent tous des informations d'identification. Vérifiez si ces services fonctionnent, offrez suffisamment d'informations distinctes. Les bannières sont probablement rares aujourd'hui mais valent toujours le coup.

4. Testez le comportement indépendant de la carte réseau. Par exemple, essayez de déclencher les hôtes refusés en fournissant une fausse authentification à ssh une douzaine de fois. Si le refus d'hôtes est déclenché, vous devriez trouver que le socket se ferme immédiatement lors du prochain essai. Vérifiez si cela se produit également pour l'autre IP.

A / 27 net c'est ... quoi, 29 hôtes? Je dirais que les chances d'identifier une machine à double domicile avec une confiance élevée sont très minces, peut-être 5%. Mais étant donné si peu d'hôtes, vous pourrez peut-être faire une supposition éclairée.

Question amusante pour une interview. Je peux le voler en fait.

Théoriquement, vous pouvez donner un niveau de confiance significatif dans la plupart des cas. Il y a cependant quelques mises en garde qui rendent la tâche beaucoup plus difficile dans la pratique.

Je vais chevaucher d'autres réponses, et j'ai probablement raté des trucs, mais c'est au moins un raisonnement détaillé pour expliquer pourquoi ces bits particuliers importent ou non.

Tout d'abord, oubliez toute pensée sur les adresses MAC. À moins d'avoir un accès direct au segment de réseau, vous ne pourrez pas les voir.

Ne faites pas non plus confiance aux analyses de port. Il est trivial de ne pare-feu les ports que pour certaines adresses IP, d'avoir un logiciel d'écoute uniquement sur certaines adresses IP ou d'avoir un système IDS / IPS qui applique le filtrage lorsqu'une analyse est détectée. Tout cela va brouiller vos tests.

Ok, donc la façon dont vous pouvez le dire est simple: la probabilité que deux cases soient exactement identiques est faible, sauf si elles sont liées de toute façon. Donc, ce que vous faites, c'est essayer de prouver qu'il s'agit de différentes boîtes, pas d'essayer de prouver qu'elles sont les mêmes.

1. Ping. Vous devez tester les deux en même temps et faire beaucoup de tests. Il s'avère que bien qu'il y ait une gigue dans les temps réseau, il s'agit d'un bruit pseudo-aléatoire de qualité assez élevée, si vous avez suffisamment d'échantillons dans un court laps de temps, le bruit est en moyenne assez élevé pour vous donner une comparaison précise.

   Chaque saut de couche 2 dans un réseau ajoute une petite quantité de latence, différents niveaux d'encombrement donneront différentes valeurs de latence. Si les deux adresses IP affichent une latence simultanée significativement différente, vous pouvez supposer qu'elles ne sont probablement pas la même case.

   Avertissement 1: Un serveur unique avec deux liaisons montantes (non liées) et configuré avec une IP différente sur chaque liaison montante pourrait avoir un déséquilibre de liaison montante suffisant pour éliminer cela.

2. Balayage de port. Les ports de destination peuvent être dans l'un des trois états suivants: écoute, fermé, filtré. Ils ne sont pas vraiment utiles comme indiqué ci-dessus, mais il reste des informations utiles à obtenir.

   1. Les boîtiers avec des ports ouverts sur plusieurs IP exécuteront très probablement le même logiciel sur toutes les IP. Il est possible d'exécuter, disons, nginx sur une IP et apache sur une autre, mais la plupart des gens ne s'en soucient pas. Empreinte digitale des services en cours d'exécution pour rechercher des similitudes. Recherchez le logiciel et la version dont il fait la publicité, les options qu'il prend en charge, le nom d'hôte (le cas échéant) annoncé, s'il y a des bizarreries dans le comportement du logiciel, des choses comme ça.

      Les services Web sont les moins utiles pour cela, beaucoup plus utiles sont des choses comme SMTP (difficile à mélanger et à faire correspondre en raison de la prise en charge de sendmail, fuite de nombreuses informations), SNMP (une mine d'or d'informations), SSH (qui exécute plusieurs démons SSH? ) et HTTPS (si vous avez de la chance et qu'ils exécutent le même logiciel, vous pouvez vérifier les différences de configuration SSL, une configuration identique mais inhabituelle est un bon indicateur). Le NTP était un bon test, mais il est maintenant verrouillé en raison de son utilisation intensive en tant qu'amplificateur DoS, le SNTP n'est pas vraiment assez précis pour un pistolet fumant de la même manière.

   2. Empreinte digitale de couche 3. Le principal moyen d'empreintes digitales d'un système d'exploitation à distance est de faire des excentricités dans son implémentation TCP / IP. Les détails exacts sont beaucoup trop longs pour entrer ici, mais essentiellement les métadonnées des paquets fuient beaucoup d'informations, tout comme la façon dont un port fermé ou filtré répond à une connexion et comment un hôte se comporte lorsqu'il reçoit des paquets mal formés. Bien que ces caractéristiques ne soient pas certaines pour dire ce qui fonctionne, elles sont raisonnablement garanties d'être presque identiques pour chaque IP liée à une pile TCP / IP particulière. Des systèmes sensiblement différents devraient avoir des caractéristiques sensiblement différentes.

   Mise en garde 2: deux boîtes exécutant exactement le même système d'exploitation et les correctifs du fournisseur sont susceptibles de se ressembler. Sous Windows, deux copies de la même version de Windows exécutant des mises à jour automatiques seront assez impossibles à distinguer, sauf si des pare-feu différents fonctionnent. Sous Linux, les différences sont probablement liées principalement à la version et aux options du noyau fournies. Ce test ne peut donner qu'une forte probabilité que deux IP ne soient pas sur le même système d'exploitation.

3. Rejouer les attaques. Avec la liste des ports ouverts sur les deux IP, effectuez des actions identiques sur chaque IP et recherchez les écarts de comportement. Des choses comme les délais d'attente, les messages d'erreur, les limites de nouvelle tentative, etc. Certains logiciels sont plus difficiles ou moins souvent configurés pour être différents en fonction de l'IP. Si vous savez qu'une IP accepte le courrier pour un domaine particulier, voyez si l'autre IP accepte également le courrier pour ce domaine.

   Mise en garde 3: Il s'agit de données de qualité inférieure à la partie d'empreintes digitales du service du test 2, car ces éléments sont plus faciles à configurer différemment sur différentes IP et il existe toutes sortes d'interactions en arrière-plan possibles. Le risque élevé de faux résultats ne donne guère confiance à ces résultats.

Donc, comme je l'ai dit, la théorie sous-jacente est que différents hôtes vont probablement avoir des configurations différentes et que des fuites d'informations.

Cela ne tient pas compte du fait qu'il est beaucoup plus difficile de dire si le même site fonctionnant sur deux adresses IP est le même serveur ou deux serveurs configurés pour la redondance. Il ne tient pas compte non plus des administrateurs système qui exécutent la gestion des configurations pour garder leurs systèmes très similaires. Il ne prend pas non plus en compte les hôtes qui effectuent le DNATage de plusieurs services exécutés sur différents hôtes vers une seule adresse IP.

La technologie de virtualisation jette quelques clés étranges dans les travaux. Les systèmes conteneurisés tels que Docker partagent suffisamment la pile pour que les conteneurs séparés soient plus similaires qu'ils ne le seraient en réalité. Les cartes réseau virtuelles reliées à un nic physique devraient être impossibles à distinguer du matériel physiquement séparé, mais ne le sont pas, provenant principalement du fait que le pont est un logiciel et que les paquets doivent donc passer par la pile IP hôte.

Il existe de nombreuses façons de confondre les personnes essayant de tester la répétabilité. Le mieux que vous puissiez espérer est un modèle qui a une faible marge de doute.

La morale de cela, pour les personnes qui exécutent des serveurs, est que vous devez configurer vos serveurs pour divulguer le moins d'informations possible:

1. Baissez autant que possible les informations sur les bannières. Moins une attaque connaît votre configuration, mieux c'est pour vous.

2. Les logiciels n'acceptent que les connexions sur l'IP sur laquelle ils sont censés être utilisés et uniquement lorsque cela est nécessaire. S'il n'a pas besoin d'être accessible de l'extérieur, faites-le uniquement sur localhost. Réduire la surface d'attaque est toujours bon.

3. Si vous devez absolument écouter quelque chose et que vous souhaitez éviter la corrélation entre deux adresses IP, essayez de limiter au minimum les options inhabituelles. Vous voulez qu'il se fondre.

4. Avoir un pare-feu en cours d'exécution avec une stratégie de suppression par défaut. Je pense qu'il peut y avoir de la valeur dans une configuration IDS qui répond aux attaquants avec des réponses aléatoires, le bruit rendrait plus difficile pour un attaquant de faire confiance à leurs résultats, mais cela vous fait vous démarquer.

5. Les modules de retard aléatoires sont sans valeur pour empêcher les attaques de synchronisation. Pas vraiment. Choisissez un nombre aléatoire, puis lancez un dé plusieurs fois, en notant le résultat plus le nombre que vous avez choisi au début. Vous vous retrouvez avec une plage avec un décalage fixe. Si le nombre aléatoire est substitué, la plage se déplace. Si la plage est modifiée, le décalage reste le même et il suffit de répéter le processus d'échantillonnage pour obtenir une nouvelle ligne de base.

6. Les normalisateurs de pile IP existent mais ont été une partie négligée de la recherche sur la sécurité la dernière fois que j'ai regardé. Ce serait probablement un bon marché pour investir dans un fournisseur de sécurité.