Risques d'utiliser des adresses IP non privées en interne?


20

Mon entreprise a reçu une grande machine industrielle avec de nombreux appareils en réseau. Malheureusement, l'ingénieur en charge a utilisé une plage d'adresses IP publiques sur la machine. Je suis en Europe. La plage d'adresses choisie appartient à une entreprise américaine. Disons que c'est 143.166.0.0 (qui appartient en fait à Dell).

Supposons que je ne connecte pas la machine au réseau local de notre entreprise (pour l'instant), mais que j'y connecte mon ordinateur portable pour programmer un périphérique - disons 143.166.0.1. Disons également que mon adaptateur réseau sans fil pour ordinateur portable est connecté au réseau local de l'entreprise et donc à Internet. Maintenant, j'ai deux itinéraires possibles vers deux appareils qui partagent une adresse. L'adresse locale que je veux et l'adresse Dell.

Ma question est: "A quel point devrais-je m'inquiéter?" Que devrait-il et se passerait-il dans ce cas? Je suppose que la machine locale répondrait en premier et que je pourrais m'en tirer mais que finalement je serais mordu. Par ailleurs, j'ai également vu des adresses IP publiques sur d'autres machines. Il semble que les ingénieurs ne comprennent pas l'adressage privé ou ne s'attendent pas à ce que leur machine soit connectée au reste du monde.

Des idées / commentaires? (cela n'implique pas de violence envers l'ingénieur machine)?

Épilogue

Nous avons trouvé un problème intéressant qui nous a obligés à changer les adresses IP en privées.

  • L'un des périphériques de la machine est programmé via Internet Explorer à l'aide d'un composant ActiveX. Cet appareil essaiera de pousser les données vers l'écouteur ActiveX (plutôt que le mode navigateur habituel de demande de données à un serveur distant).
  • Notre configuration Active Directory télécharge les politiques de sécurité sur nos ordinateurs lors de la connexion. La politique contient la liste des sites de confiance. Ceux-ci inclus:
    • Adresses d'entreprises agréées.
    • Diverses adresses externes telles que notre banque.
    • Adresses privées 192.168.0.0/16, 172.16.0.0/20 et 10.0.0.0/24.
    • Tout le reste est bloqué.
  • En raison de la politique de sécurité, le composant ActiveX n'a ​​jamais reçu de données car le trafic entrant est bloqué par la politique de sécurité!

Cela m'a obligé à demander au fournisseur de modifier les adresses à 172.16.0.0. Je dormirai plus facilement.

Merci pour tout l'intérêt porté.

Réponses:


21

Réponse courte: Dupliquer les adresses publiques allouées est une mauvaise idée.

Réponse légèrement plus longue: en laissant de côté les problèmes de routage pour le moment, il n'est pas sûr de supposer que vous n'aurez jamais besoin d'accéder à cette machine depuis un endroit autre qu'un câble directement connecté, ou que les allocations d'adresses publiques ou privées sont statiques et ne changeront jamais .

Les problèmes d'accès à distance sont évidents: l'Internet mondial pense que 143.166 / 16 est à un endroit, et vous voulez qu'il soit à un autre. Les routeurs n'iront pas vers votre machine.

Et la propriété pourrait changer. Même si cette adresse n'était pas attribuée à Dell, elle pourrait lui être attribuée à l'avenir. Dell a cette adresse aujourd'hui, mais quelqu'un d'autre pourrait le faire demain, avec un itinéraire différent. Qui sait? Votre organisation pourrait même acheter ce bloc d'adresses, avec encore plus d'aventures de routage.

Conclusion: ne présumez pas que les adresses IP en double peuvent être bloquées en toute sécurité pour toujours.

Quant au routage, votre interface filaire préférerait l'adresse locale à Dell. Votre interface filaire enverrait une demande ARP pour cette adresse et l'obtiendrait directement de la machine industrielle, aucune passerelle requise. Par la suite, les paquets destinés à cette adresse utiliseraient l'adresse MAC de destination de la machine industrielle.

Cela fonctionnera bien car vous n'utilisez qu'un câble pour l'accès, et tant que vous n'avez jamais besoin d'atteindre cette machine depuis un autre endroit, et tant que la table de routage globale reste statique.

Ça fait beaucoup de si. Il vaut mieux éviter le problème en utilisant soit une adresse publique unique, soit quelque chose en dehors du pool d'adresses privées.


Vous avez raison - je suis désolé, je n'ai pas compris que c'était l'espace de quelqu'un d'autre. Merci.
Pseudocyber

12

Le seul problème sera une incapacité à parler aux vraies machines (Internet) avec ces adresses. Bien sûr, vous pouvez mettre un pare-feu ("nat box") entre votre réseau et cette chose pour le faire ressembler à des adresses privées de votre réseau.

Ce genre de chose a surgi partout depuis de nombreuses années parce que les gens sont paresseux et utilisent des adresses "non attribuées" à leurs propres fins; maintenant qu'ils sont assignés, cela pose un petit problème.

[Edit: pour mémoire, je n'ai jamais renuméroté mon réseau domestique. mais je n'aurai probablement jamais besoin de parler aux gens qui ont maintenant cet espace d'adressage. 15 ans et plus ...]


5
+1, j'ajouterais que la taille du problème dépend de la mesure dans laquelle vous laissez ces adresses pénétrer dans votre IGP et du nombre de ces adresses qui fuient vers le reste de votre entreprise. Malheureusement, quelqu'un a ajouté de gros blocs de blocs de classe A d'AT & T partout dans notre IGP avant mon arrivée.
Mike Pennington

8

Ma question est: "A quel point devrais-je m'inquiéter?" Que devrait-il et se passerait-il dans ce cas? Je suppose que la machine locale répondrait en premier et que je pourrais m'en tirer mais que finalement je serais mordu.

En remarque, il ne s'agit pas de savoir qui répond en premier. Si vous donnez à votre ordinateur une adresse dans le même sous-réseau, le trafic ira directement à la machine, sans routeurs impliqués.

Même si vous utilisiez le routage, en entrant un itinéraire vers 143.166.0.0/16 sur certains routeurs internes de votre réseau, ils préféreront cet itinéraire à leur itinéraire (par défaut?) Vers Internet. Cela se produit parce que la «correspondance de préfixe la plus longue» est préférée, c'est-à-dire. l'itinéraire le plus spécifique est choisi.

Vous avez raison sur le résultat net, la partie 143.166.0.0/16 d'Internet sera inaccessible pour vous ou votre réseau si vous installez la route dans vos routeurs internes. / 16 semble un peu volumineux pour ce problème, plus le sous-réseau vers lequel vous routez est petit, plus les chances de se faire mordre sont faibles.


0

Ci-dessous, ma réponse modifiée - qui à l'origine ne comprenait pas qu'il ne s'agissait pas d'un espace IP "appartenant", mais plutôt de l'espace de quelqu'un d'autre.

Tant que c'est votre espace, cela n'a pas d'importance. Une adresse IP est une adresse IP. Vos applications ne savent pas ce qui est privé et ce qui est public. Si vous avez de l'espace, vous pouvez même avoir des sous-réseaux qui sont "internes" et d'autres qui sont "externes" accessibles - contrôlables avec les contrôles de routage habituels, les pare-feu, etc.

Tout l'espace public à l'intérieur signifie que vous n'avez pas à vous soucier du NAT pour entrer ou sortir de votre réseau.

Si ce n'est PAS votre propre espace IP, mais celui de quelqu'un d'autre, cela peut techniquement fonctionner. Cependant, vous ne pourrez jamais atteindre leur espace sans beaucoup d'efforts supplémentaires et de configuration - tels que la tunnellisation, le NAT ou le double NAT, ou un routage plus spécifique. Il serait préférable de suggérer de réadresser votre réseau, par écrit, et de détailler comment le faire, comment il peut être géré, etc. ".

Les votes négatifs ci-dessous sont issus de ma réponse originale, dans laquelle j'ai mal lu la question.

Merci tout le monde.


Je suis désolé mais je dois voter contre cela, même si vous pouvez utiliser l'espace d'adressage de quelqu'un d'autre, ce n'est pas aussi facile que vous le dites.
Mike Pennington du

Un vote négatif de ma part pour "cela n'a pas d'importance. Ce n'est peut-être pas important maintenant, mais il finira par mordre quelqu'un au moment le moins attendu.
generalnetworkerror
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.