Adresse IP privée dans le DNS public
Nous avons un serveur de messagerie SMTP uniquement derrière un pare-feu qui aura un enregistrement public de courrier .. La seule façon d'accéder à ce serveur de messagerie est à partir d'un autre serveur derrière le même pare-feu. Nous n'exécutons pas notre propre serveur DNS privé.
Est-ce une bonne idée d'utiliser l'adresse IP privée comme un enregistrement A dans un serveur DNS public - ou est-il préférable de conserver ces enregistrements de serveur dans chaque fichier d'hôtes locaux des serveurs?
Certaines personnes diront qu'aucun enregistrement DNS public ne doit jamais divulguer d'adresses IP privées ... en pensant que vous donnez aux attaquants potentiels un aperçu de certaines informations qui pourraient être nécessaires pour exploiter des systèmes privés.
Personnellement, je pense que l'obfuscation est une forme de sécurité médiocre, en particulier lorsque nous parlons d'adresses IP, car en général elles sont faciles à deviner de toute façon, donc je ne vois pas cela comme un compromis de sécurité réaliste.
La plus grande considération ici est de s'assurer que vos utilisateurs publics ne récupèrent pas cet enregistrement DNS dans le cadre des services publics normaux de votre application hébergée. ie: les recherches DNS externes commencent en quelque sorte à se résoudre à une adresse à laquelle elles ne peuvent pas accéder.
En dehors de cela, je ne vois aucune raison fondamentale pour laquelle mettre des enregistrements d'adresse privée A dans l'espace public est un problème ... surtout lorsque vous n'avez pas de serveur DNS alternatif pour les héberger.
Si vous décidez de placer cet enregistrement dans l'espace DNS public, vous pouvez envisager de créer une zone distincte sur le même serveur pour contenir tous les enregistrements "privés". Cela rendra plus clair qu'ils sont destinés à être privés ... mais pour un seul enregistrement A, je ne me dérangerais probablement pas.
J'ai eu une longue discussion sur ce sujet sur la liste NANOG il y a quelque temps. Bien que j'aie toujours pensé que c'était une mauvaise idée, il s'avère que ce n'est pas une si mauvaise idée dans la pratique. Les difficultés proviennent principalement des recherches rDNS (qui pour les adresses privées ne fonctionnent pas dans le monde extérieur), et lorsque vous fournissez l'accès aux adresses via un VPN ou similaire, il est important de s'assurer que les clients VPN sont correctement protégés contre "fuite" de trafic lorsque le VPN est en panne.
Je dis allez-y. Si un attaquant peut obtenir quelque chose de significatif en étant capable de résoudre des noms en adresses internes, vous avez de plus gros problèmes de sécurité.
En général, l'introduction d'adresses RFC1918 dans le DNS public causera de la confusion, sinon un problème réel, à un moment donné dans le futur. Utilisez des adresses IP, des enregistrements d'hôte ou une vue DNS privée de votre zone pour utiliser les adresses RFC1918 derrière votre pare-feu, mais ne les incluez pas dans la vue publique.
Pour clarifier ma réponse sur la base de l'autre réponse soumise, je pense que l'introduction d'adresses RFC1918 dans le DNS public est un faux pas, pas un problème de sécurité. Si quelqu'un m'appelle pour résoudre un problème et que je tombe sur des adresses RFC1918 dans leur DNS, je commence à parler très lentement et à leur demander s'ils ont redémarré récemment. C'est peut-être du snobisme de ma part, je ne sais pas. Mais comme je l'ai dit, ce n'est pas une chose nécessaire à faire et cela risque de causer de la confusion et des problèmes de communication (humains, pas informatiques) à un moment donné. Pourquoi le risquer?
Non, ne placez pas vos adresses IP privées dans le DNS public.
Premièrement, il fuit des informations, bien que ce soit un problème relativement mineur.
Le pire problème si vos enregistrements MX pointent vers cette entrée d'hôte particulière est que toute personne qui essaie de lui envoyer du courrier aura au mieux des délais de livraison.
Selon le logiciel de messagerie de l'expéditeur, ils peuvent recevoir des rebonds.
Pire encore, si vous utilisez l'espace d'adressage RFC1918 (ce que vous devriez faire à l'intérieur de votre réseau) et que l'expéditeur l'est également, il y a toutes les chances qu'il essaie de livrer le courrier à son propre réseau.
Par exemple:
- le réseau a un serveur de messagerie interne, mais pas de DNS partagé
- l'administrateur place donc les adresses IP publiques et internes dans le DNS
- et les enregistrements MX pointent à la fois:
$Origin example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
- quelqu'un voyant cela pourrait essayer de se connecter à 192.168.1.2
- dans le meilleur des cas, ça rebondit, car ils n'ont pas de route
- mais s'ils ont également un serveur utilisant 192.168.1.2, le courrier ira au mauvais endroit
Oui, c'est une configuration cassée, mais j'ai vu cela (et pire) se produire.
Non, ce n'est pas la faute de DNS, il fait juste ce qu'on lui dit.
Bien que la possibilité soit éloignée, je pense que vous vous préparez peut-être à certaines attaques MITM.
Ma préoccupation serait la suivante. Disons que l'un de vos utilisateurs avec un client de messagerie configuré pour pointer vers ce serveur de messagerie emmène son ordinateur portable vers un autre réseau. Que se passe-t-il si cet autre réseau utilise également le même RFC1918. Cet ordinateur portable peut tenter de se connecter au serveur smtp et offrir les informations d'identification de l'utilisateur à un serveur qui ne devrait pas l'avoir. Cela serait particulièrement vrai puisque vous avez dit SMTP et n'avez pas mentionné que vous nécessitiez SSL.
Vos deux options sont/etc/hosts et mettre une adresse IP privée dans votre zone publique. Je recommanderais l'ancien. Si cela représente un grand nombre d'hôtes, vous devriez envisager d'exécuter votre propre résolveur en interne, ce n'est pas si difficile.
Il peut y avoir des problèmes subtils avec cela. La première est que les solutions communes aux attaques DNS Rebind filtrent les entrées DNS locales résolues à partir de serveurs DNS publics. Donc, soit vous vous ouvrez pour relier les attaques, soit les adresses locales ne fonctionnent pas, ou vous avez besoin d'une configuration plus sophistiquée (si votre logiciel/routeur le permet même).
Si par privé vous entendez un 10.0.0.0/8, un 192.168.0.0/16 ou un 172.16.0.0/12, alors ne le faites pas . La plupart des routeurs Internet le reconnaissent pour ce qu'il est - ne adresse privée qui doit jamais être acheminée directement vers Internet public , ce qui a contribué à la popularité de NAT. Toute personne tentant de contacter votre serveur DNS public récupérera l'adresse IP privée du DNS, uniquement pour envoyer un paquet à .... nulle part. Alors que leur connexion tente de traverser Internet vers votre adresse privée, certains routeurs (correctement configurés) en cours de route mangeront simplement le paquet vivant.
Si vous voulez que les e-mails venant de "l'extérieur" viennent "à l'intérieur", à un moment donné, le paquet doit traverser votre pare-feu. Je suggérerais de configurer une adresse DMZ pour gérer cela - une adresse IP publique unique qui est étroitement contrôlée par n'importe quel routeur/pare-feu que vous avez en place. La configuration existante que vous décrivez sonne exactement comme elle le fait exactement cette.
EDIT: clarification de l'intention ... (voir commentaires ci-dessous). Si cela n'a pas de sens, je voterai pour supprimer mon propre message.
Il est préférable de le conserver dans le fichier hosts. Si une seule machine est censée s'y connecter de toute façon, que gagnez-vous à la mettre dans le DNS public?
Je suis arrivé ici car je cherchais des informations similaires et j'ai été surpris que beaucoup disent que c'est bien de divulguer vos adresses IP privées. Je suppose qu'en termes de piratage, cela ne fait pas une énorme différence si vous êtes sur un réseau sûr. Cependant, DigitalOcean a eu tout le trafic du réseau local sur les mêmes câbles, tout le monde ayant vraiment accès au trafic de tout le monde (probablement faisable avec une attaque Man in the Middle). l'information vous donne certainement un pas de plus vers le piratage de mon trafic. (Désormais, chaque client dispose de son propre réseau privé réservé, comme avec d'autres services cloud tels qu'AWS.)
Cela dit, avec votre propre service BIND9, vous pouvez facilement définir vos adresses IP publiques et privées. Cela se fait à l'aide de la fonction view, qui inclut un conditionnel. Cela vous permet d'interroger un DNS et d'obtenir une réponse sur les adresses IP internes uniquement si vous le demandez à partir de votre adresse IP interne.
La configuration nécessite deux zones. La sélection utilise le match-clients. Voici un exemple de configuration à partir de serveur DNS deux en un avec BIND9 :
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};
Voici la zone externe et nous pouvons voir que les adresses IP ne sont pas privées
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; We have our mail server somewhere else.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; We connect to client1 very often.
Quant à la zone interne, nous incluons d'abord la zone externe, c'est ainsi que cela fonctionne. Par exemple, si vous êtes un ordinateur interne, vous accédez uniquement à la zone interne, vous avez donc toujours besoin des définitions de zone externe, d'où le $include commande:
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103
Enfin, vous devez vous assurer que tous vos ordinateurs utilisent désormais ce DNS et ses esclaves. En supposant un réseau statique, cela signifierait éditer votre /etc/network/interfaces et en utilisant vos IP DNS dans l'option nameserver. Quelque chose comme ça:
iface eth0 inet static
...
nameserver 10.0.0.1 10.0.0.103 ...
Maintenant, vous devriez être prêt.