sviluppo-web-qa.it

Indirizzo IP privato nel DNS pubblico

Abbiamo un server di posta SMTP solo dietro un firewall che avrà un record pubblico di posta A.. L'unico modo per accedere a questo server di posta è da un altro server dietro lo stesso firewall. Non eseguiamo il nostro server DNS privato.

È una buona idea utilizzare l'indirizzo IP privato come record A in un server DNS pubblico - oppure è meglio conservare questi record del server nel file degli host locali di ciascun server?

62
Geoff Dalgas

Alcuni diranno che nessun record DNS pubblico dovrebbe mai rivelare indirizzi IP privati ​​.... con l'idea che stai dando ai potenziali aggressori un vantaggio su alcune informazioni che potrebbero essere necessarie per sfruttare i sistemi privati.

Personalmente, penso che l'offuscamento sia una cattiva forma di sicurezza, specialmente quando parliamo di indirizzi IP perché in generale sono comunque facili da indovinare, quindi non lo vedo come un realistico compromesso di sicurezza.

La considerazione più importante qui è assicurarsi che gli utenti pubblici non raccolgano questo record DNS come parte dei normali servizi pubblici dell'applicazione ospitata. ovvero: le ricerche DNS esterne in qualche modo iniziano a risolversi in un indirizzo a cui non riescono.

A parte questo, non vedo alcun motivo fondamentale per cui inserire i record dell'indirizzo privato nello spazio pubblico sia un problema .... specialmente quando non si dispone di un server DNS alternativo su cui ospitarli.

Se decidi di inserire questo record nello spazio DNS pubblico, potresti prendere in considerazione la creazione di una zona separata sullo stesso server per contenere tutti i record "privati". Ciò renderà più chiaro che sono destinati a essere privati ​​.... tuttavia per un solo disco A, probabilmente non mi preoccuperei.

63
Tall Jeff

Ho avuto una lunga discussione su questo argomento nell'elenco NANOG qualche tempo fa. Anche se ho sempre pensato che fosse una cattiva idea, risulta che non è una cattiva idea in pratica. Le difficoltà derivano principalmente dalle ricerche rDNS (che per gli indirizzi privati ​​non funzionano nel mondo esterno) e quando si fornisce l'accesso agli indirizzi su una VPN o simili è importante assicurarsi che i client VPN siano adeguatamente protetti da "perdita" di traffico quando la VPN è inattiva.

Dico provaci. Se un utente malintenzionato può ottenere qualcosa di significativo dalla possibilità di risolvere i nomi in indirizzi interni, hai problemi di sicurezza più grandi.

36
womble

In generale, l'introduzione degli indirizzi RFC1918 nel DNS pubblico causerà confusione, se non un problema reale, in futuro. Utilizzare IP, record host o una vista DNS privata della propria zona per utilizzare gli indirizzi RFC1918 dietro il firewall ma non includerli nella vista pubblica.

Per chiarire la mia risposta in base all'altra risposta inviata, penso che introdurre indirizzi RFC1918 nel DNS pubblico sia un passo falso, non un problema di sicurezza. Se qualcuno mi chiama per risolvere un problema e mi imbatto in indirizzi RFC1918 nel suo DNS, inizio a parlare molto lentamente e chiedendo loro se si sono riavviati di recente. Forse è snobismo da parte mia, non lo so. Ma come ho detto, non è una cosa necessaria da fare ed è probabile che possa causare confusione e cattiva comunicazione (umana, non informatica) ad un certo punto. Perché rischiare?

8
jj33

No, non inserire i tuoi indirizzi IP privati ​​nel DNS pubblico.

In primo luogo, perde informazioni, sebbene si tratti di un problema relativamente minore.

Il problema peggiore se i tuoi record MX puntano a quella particolare voce dell'Host è che chiunque provi a inviarci posta otterrà al massimo i timeout di consegna della posta.

A seconda del software di posta del mittente, potrebbero ricevere rimbalzi.

Ancora peggio, se stai utilizzando lo spazio degli indirizzi RFC1918 (che dovresti, all'interno della tua rete) e lo è anche il mittente, ci sono tutte le possibilità che proveranno a consegnare la posta alla propria rete.

Per esempio:

  • la rete ha un server di posta interno, ma nessun DNS diviso
  • admin quindi inserisce sia gli indirizzi IP pubblici che quelli interni nel DNS
  • e i record MX indicano entrambi:

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

  • qualcuno che vede questo potrebbe prova a connettersi a 192.168.1.2
  • nel migliore dei casi, rimbalza, perché non hanno percorso
  • ma se hanno anche un server che utilizza 192.168.1.2, la posta andrà nel posto sbagliato

Sì, è una configurazione non funzionante, ma ho visto succedere (e peggio).

No, non è colpa del DNS, sta solo facendo ciò che gli viene detto.

5
Alnitak

Anche se la possibilità è remota, penso che potresti essere pronto per alcuni attacchi MITM.

La mia preoccupazione sarebbe questa. Diciamo che uno dei tuoi utenti con un client di posta configurato per puntare a quel server di posta porta il proprio laptop verso un'altra rete. Cosa succede se anche l'altra rete ha la stessa RFC1918 in uso. Quel laptop può tentare di accedere al server smtp e offrire le credenziali dell'utente a un server che non dovrebbe averlo. Ciò sarebbe particolarmente vero dal momento che hai detto SMTP e non hai detto che dovevi richiedere SSL.

3
Zoredache

Le tue due opzioni sono/etc/hosts e inserisci un indirizzo IP privato nella tua area pubblica. Consiglierei il primo. Se questo rappresenta un gran numero di host, dovresti considerare di eseguire internamente il tuo resolver, non è poi così difficile.

3
Dave Cheney

Potrebbero esserci problemi sottili. Una è che le soluzioni comuni agli attacchi DNS Rebind filtrano le voci DNS locali risolte dai server DNS pubblici. Quindi ti apri per respingere gli attacchi, o gli indirizzi locali non funzionano, o richiedi una configurazione più sofisticata (se il tuo software/router lo consente).

2
Nikola Toshev

Se per privato intendi un 10.0.0.0/8, un 192.168.0.0/16 o un 172.16.0.0/12, allora no . La maggior parte dei router Internet lo riconosce per quello che è - n indirizzo privato che deve mai essere indirizzato a Internet pubblico in modo diretto , che è ciò che ha aiutato la popolarità di NAT. Chiunque tenti di contattare il proprio server DNS pubblico recupererà l'indirizzo IP privato dal DNS, solo per inviare un pacchetto a ... da nessuna parte. Mentre la loro connessione tenta di attraversare Internet al tuo indirizzo privato, alcuni router (configurati in modo corretto) lungo la strada mangeranno semplicemente il pacchetto vivo.

Se vuoi ricevere email dall'esterno per arrivare "dentro", ad un certo punto, il pacchetto deve attraversare il tuo firewall. Suggerirei di impostare un DMZ indirizzo per gestire questo - un unico indirizzo IP pubblico strettamente controllato da qualsiasi router/firewall che hai installato. L'impostazione esistente che descrivi suona come se fosse esattamente quello.

EDIT: chiarimento dell'intento ... (vedi commenti sotto). Se ciò non ha senso, voterò per rimuovere il mio post.

1
Avery Payne

È meglio tenerlo nel file hosts. Se una sola macchina dovesse mai collegarsi ad essa, cosa guadagni mettendola nel DNS pubblico?

1
sh-beta

Sono arrivato qui mentre cercavo informazioni simili e sono rimasto sorpreso dal fatto che molti dicano che va bene perdere i tuoi indirizzi IP privati. Immagino in termini di essere hackerato, non fa una grande differenza se sei su una rete sicura. Tuttavia, DigitalOcean ha avuto tutto il traffico di rete locale sugli stessi cavi con tutti gli utenti che hanno realmente accesso al traffico di tutti gli altri (probabilmente fattibile con un attacco Man in the Middle.) Se avessi un computer nello stesso data center, avendolo le informazioni certamente ti avvicinano di più all'hacking del mio traffico. (Ora ogni client ha una propria rete privata riservata come con altri servizi cloud come AWS.)

Detto questo, con il tuo servizio BIND9, potresti facilmente definire i tuoi IP pubblici e privati. Questo viene fatto usando la funzione view, che include un condizionale. Ciò consente di interrogare un DNS e ottenere una risposta sugli IP interni solo se si richiede dal proprio indirizzo IP interno.

L'installazione richiede due zone. La selezione utilizza il match-clients. Ecco un esempio di installazione da server DNS due in uno con 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; };
    };
};

Ecco la zona esterna e possiamo vedere che gli IP non sono privati

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

Per quanto riguarda la zona interna, includiamo prima la zona esterna, che è come funziona. cioè se sei un computer interno, accedi solo alla zona interna, quindi hai ancora bisogno delle definizioni di zona esterna, quindi il $include comando:

$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

Infine, devi assicurarti che tutti i tuoi computer ora facciano uso di quel DNS e dei suoi slave. Supponendo una rete statica, significherebbe modificare il tuo /etc/network/interfaces e usando i tuoi IP DNS nell'opzione nameserver. Qualcosa come questo:

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

Ora dovresti essere pronto.

0
Alexis Wilke