it-swarm.com.de

Private IP-Adresse im öffentlichen DNS

Wir haben einen Nur-SMTP-Mailserver hinter einer Firewall, der eine öffentliche A-Mail-Aufzeichnung hat .. Der einzige Weg, auf diesen Mailserver zuzugreifen, ist von einem anderen Server hinter derselben Firewall. Wir betreiben keinen eigenen privaten DNS-Server.

Ist es eine gute Idee, die private IP-Adresse als A-Eintrag in einem öffentlichen DNS-Server zu verwenden - oder ist es am besten, diese Servereinträge in der lokalen Hosts-Datei jedes Servers zu speichern?

62
Geoff Dalgas

Einige Leute werden sagen, dass keine öffentlichen DNS-Einträge jemals private IP-Adressen offenlegen sollten. Der Gedanke ist, dass Sie potenziellen Angreifern einige Informationen zur Verfügung stellen, die möglicherweise zur Ausnutzung privater Systeme erforderlich sind.

Persönlich denke ich, dass Verschleierung eine schlechte Form der Sicherheit ist, insbesondere wenn es sich um IP-Adressen handelt, da diese im Allgemeinen ohnehin leicht zu erraten sind. Daher sehe ich dies nicht als realistischen Sicherheitskompromiss an.

Die größere Überlegung hierbei ist, sicherzustellen, dass Ihre öffentlichen Benutzer diesen DNS-Eintrag nicht als Teil der normalen öffentlichen Dienste Ihrer gehosteten Anwendung abrufen. dh: Externe DNS-Lookups werden irgendwie in eine Adresse aufgelöst, die sie nicht erreichen können.

Abgesehen davon sehe ich keinen grundsätzlichen Grund, warum das Einfügen von Einträgen der privaten Adresse A in den öffentlichen Raum ein Problem darstellt. Dies gilt insbesondere dann, wenn Sie keinen alternativen DNS-Server haben, auf dem Sie sie hosten können.

Wenn Sie diesen Eintrag in den öffentlichen DNS-Bereich einfügen möchten, können Sie eine separate Zone auf demselben Server erstellen, in der alle "privaten" Einträge gespeichert sind. Dies wird klarer machen, dass sie privat sein sollen ... aber für nur eine A-Platte würde ich mich wahrscheinlich nicht darum kümmern.

63
Tall Jeff

Ich hatte vor einiger Zeit eine lange Diskussion zu diesem Thema auf der NANOG-Liste. Obwohl ich immer gedacht hatte, dass es eine schlechte Idee ist, stellt sich heraus, dass es in der Praxis keine so schlechte Idee ist. Die Schwierigkeiten ergeben sich hauptsächlich aus rDNS-Suchvorgängen (die für private Adressen in der Außenwelt einfach nicht funktionieren). Wenn Sie über ein VPN oder ähnliches auf die Adressen zugreifen, ist es wichtig, sicherzustellen, dass die VPN-Clients ordnungsgemäß geschützt sind "leckender" Verkehr, wenn das VPN ausgefallen ist.

Ich sage, mach mit. Wenn ein Angreifer etwas Sinnvolles daraus ziehen kann, Namen in interne Adressen aufzulösen, haben Sie größere Sicherheitsprobleme.

36
womble

Im Allgemeinen führt die Einführung von RFC1918-Adressen in öffentliches DNS zu einem späteren Zeitpunkt zu Verwirrung, wenn nicht sogar zu einem echten Problem. Verwenden Sie IPs, Hosteinträge oder eine private DNS-Ansicht Ihrer Zone, um die RFC1918-Adressen hinter Ihrer Firewall zu verwenden, sie jedoch nicht in die öffentliche Ansicht aufzunehmen.

Um meine Antwort anhand der anderen eingereichten Antwort zu verdeutlichen, halte ich die Einführung von RFC1918-Adressen in öffentliches DNS für einen Fauxpas und nicht für ein Sicherheitsproblem. Wenn mich jemand anruft, um ein Problem zu beheben, und ich in seinem DNS auf RFC1918-Adressen stoße, spreche ich sehr langsam und frage ihn, ob er kürzlich neu gestartet wurde. Vielleicht ist das Snobismus meinerseits, ich weiß es nicht. Aber wie gesagt, es ist keine notwendige Sache und es kann irgendwann zu Verwirrung und Missverständnissen (Mensch, nicht Computer) führen. Warum es riskieren?

8
jj33

Nein, geben Sie Ihre privaten IP-Adressen nicht in das öffentliche DNS ein.

Erstens werden Informationen verloren, obwohl dies ein relativ kleines Problem ist.

Das schlimmste Problem, wenn Ihre MX-Datensätze auf diesen bestimmten Host-Eintrag verweisen, besteht darin, dass jeder, der versucht, E-Mails an ihn zu senden, bestenfalls Zeitüberschreitungen bei der E-Mail-Zustellung erhält.

Abhängig von der Mail-Software des Absenders können sie Bounces erhalten.

Schlimmer noch, wenn Sie den RFC1918-Adressraum verwenden (den Sie in Ihrem Netzwerk verwenden sollten) und der Absender auch, besteht jede Möglichkeit, dass er versucht, die E-Mails stattdessen an sein eigenes Netzwerk zuzustellen.

Zum Beispiel:

  • das Netzwerk verfügt über einen internen Mailserver, jedoch keinen geteilten DNS
  • der Administrator fügt daher sowohl öffentliche als auch interne IP-Adressen in das DNS ein
  • und MX-Datensätze verweisen auf beide:

 $Origin example.com
 @        IN   MX    mail.example.com
 mail     IN   A     192.168.1.2
          IN   A     some_public_IP

  • jemand, der dies sieht könnte versuchen, eine Verbindung zu 192.168.1.2 herzustellen
  • im besten Fall springt es, weil sie keine Route haben
  • wenn sie jedoch auch einen Server mit 192.168.1.2 haben, wird die E-Mail an den falschen Ort gesendet

Ja, es ist eine kaputte Konfiguration, aber ich habe gesehen, dass dies (und noch schlimmer) passiert ist.

Nein, es ist nicht die Schuld von DNS, es tut nur das, was ihm gesagt wurde.

5
Alnitak

Obwohl die Möglichkeit gering ist, denke ich, dass Sie sich auf einige MITM-Angriffe einstellen.

Mein Anliegen wäre dies. Nehmen wir an, einer Ihrer Benutzer mit einem E-Mail-Client, der so konfiguriert ist, dass er auf diesen Mailserver zeigt, bringt seinen Laptop in ein anderes Netzwerk. Was passiert, wenn in diesem anderen Netzwerk auch derselbe RFC1918 verwendet wird? Dieser Laptop versucht möglicherweise, sich beim SMTP-Server anzumelden und die Anmeldeinformationen des Benutzers einem Server anzubieten, der diese nicht haben sollte. Dies gilt insbesondere, da Sie SMTP gesagt und nicht erwähnt haben, dass Sie SSL benötigen.

3
Zoredache

Ihre beiden Optionen sind/etc/hosts und das Einfügen einer privaten IP-Adresse in Ihre öffentliche Zone. Ersteres würde ich empfehlen. Wenn dies eine große Anzahl von Hosts darstellt, sollten Sie in Betracht ziehen, Ihren eigenen Resolver intern auszuführen. Es ist nicht so schwer.

3
Dave Cheney

Es kann subtile Probleme damit geben. Eine davon ist, dass gängige Lösungen für DNS-Rebind-Angriffe lokale DNS-Einträge filtern, die von öffentlichen DNS-Servern aufgelöst wurden. Sie öffnen sich also entweder, um Angriffe erneut zu binden, oder lokale Adressen funktionieren nicht oder erfordern eine komplexere Konfiguration (sofern Ihre Software/Ihr Router dies überhaupt zulässt).

2
Nikola Toshev

Wenn mit privat ein 10.0.0.0/8, ein 192.168.0.0/16 oder ein 172.16.0.0/12 gemeint ist, dann nicht . Die meisten Internet-Router erkennen es als das, was es ist - eine private Adresse, die nie direkt an das öffentliche Internet weitergeleitet werden muss , was zur Popularität von beigetragen hat NAT. Jeder, der versucht, Ihren öffentlichen DNS-Server zu kontaktieren, ruft die private IP-Adresse von DNS ab, um ein Paket an ... nirgendwo zu senden. Während ihre Verbindung versucht, das Internet zu Ihrer privaten Adresse zu durchqueren, frisst ein (ordnungsgemäß konfigurierter) Router auf dem Weg das Paket einfach lebendig.

Wenn Sie E-Mails von "außen" erhalten möchten, um "innen" zu kommen, muss das Paket irgendwann Ihre Firewall überqueren. Ich würde vorschlagen, eine DMZ -Adresse einzurichten, um dies zu handhaben - eine einzelne öffentliche IP-Adresse, die von jedem vorhandenen Router/jeder vorhandenen Firewall streng kontrolliert wird. Das vorhandene Setup, das Sie beschreiben, klingt genau so Das.

EDIT: Klarstellung der Absicht ... (siehe Kommentare unten). Wenn dies keinen Sinn ergibt, stimme ich dafür, meinen eigenen Beitrag zu entfernen.

1
Avery Payne

Es ist am besten, es in der Hosts-Datei zu behalten. Wenn nur ein Computer jemals eine Verbindung herstellen soll, was bringt es Ihnen, wenn Sie ihn in öffentliches DNS stellen?

1
sh-beta

Ich kam hier an, als ich nach ähnlichen Informationen suchte, und war überrascht, dass viele sagen, es sei in Ordnung, Ihre privaten IP-Adressen zu verlieren. Ich denke, in Bezug auf das Hacken macht es keinen großen Unterschied, ob Sie sich in einem sicheren Netzwerk befinden. DigitalOcean hat jedoch den gesamten lokalen Netzwerkverkehr auf genau den gleichen Kabeln, wobei jeder wirklich Zugriff auf den Verkehr aller anderen hat (wahrscheinlich mit einem Man-in-the-Middle-Angriff möglich). Wenn Sie nur einen Computer im selben Rechenzentrum haben würden, dann haben Sie diesen Informationen geben Ihnen sicherlich einen Schritt näher an das Hacken meines Verkehrs. (Jetzt hat jeder Client sein eigenes reserviertes privates Netzwerk wie bei anderen Cloud-Diensten wie AWS.)

Mit Ihrem eigenen BIND9-Dienst können Sie jedoch problemlos Ihre öffentlichen und privaten IP-Adressen definieren. Dies erfolgt mit der Funktion view, die eine Bedingung enthält. Auf diese Weise können Sie nur dann einen DNS abfragen und eine Antwort zu internen IPs erhalten, wenn Sie von Ihrer eigenen internen IP-Adresse eine Anfrage stellen.

Das Setup erfordert zwei Zonen. Die Auswahl verwendet den match-clients. Hier ist ein Beispiel für die Einrichtung von Zwei-in-Eins-DNS-Server mit 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; };
    };
};

Hier ist die externe Zone und wir können sehen, dass IPs nicht privat sind

; 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.

Was die interne Zone betrifft, schließen wir zuerst die externe Zone ein, so funktioniert es. Wenn Sie ein interner Computer sind, greifen Sie nur auf die interne Zone zu, sodass Sie weiterhin die Definitionen der externen Zone benötigen, daher der Befehl $include:

$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

Schließlich müssen Sie sicherstellen, dass alle Ihre Computer jetzt diesen DNS und seine Slaves verwenden. Unter der Annahme eines statischen Netzwerks würde dies bedeuten, dass Sie Ihre /etc/network/interfaces - Datei bearbeiten und Ihre DNS-IPs in der Option nameserver verwenden. Etwas wie das:

iface eth0 inet static
    ...
    nameserver 10.0.0.1 10.0.0.103 ...

Jetzt sollten Sie fertig sein.

0
Alexis Wilke