Abbiamo un server di posta SMTP solo dietro un firewall che avrà un record pubblico di posta. . 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?
Risposte:
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. vale a dire: le ricerche DNS esterne in qualche modo iniziano a risolversi in un indirizzo a cui non riescono.
A parte questo, non vedo alcuna ragione fondamentale per cui inserire i record dell'indirizzo privato nello spazio pubblico è 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.
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 capacità di risolvere i nomi in indirizzi interni, hai problemi di sicurezza maggiori.
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 sulla base dell'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?
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 tenti di inviarti 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:
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
Sì, è una configurazione non funzionante, ma ho visto succedere (e peggio).
No, non è colpa del DNS, sta solo facendo ciò che gli viene detto.
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.
Le tue due opzioni sono / etc / hosts e inserisci un indirizzo IP privato nella tua zona pubblica. Consiglierei il primo. Se questo rappresenta un gran numero di host, dovresti considerare di eseguire internamente il tuo resolver, non è poi così difficile.
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).
È meglio tenerlo nel file hosts. Se una sola macchina dovesse mai collegarsi ad essa, cosa guadagni inserendola nel DNS pubblico?
/etc/hostsfile perché tutte le 2000 macchine devono quindi gestire queste coppie IP / nome ...
Se per privato intendi un 10.0.0.0/8, un 192.168.0.0/16 o un 172.16.0.0/12, allora non farlo . La maggior parte dei router Internet lo riconosce per quello che è - un indirizzo privato che non deve mai essere indirizzato all'internet pubblico in modo diretto , il che è ciò che ha aiutato la popolarità del 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. Vorrei suggerire di impostare un indirizzo DMZ per gestirlo, un unico indirizzo IP pubblico strettamente controllato da qualsiasi router / firewall in atto. La configurazione esistente che descrivi suona esattamente come quella.
EDIT: chiarimento dell'intento ... (vedi commenti sotto). Se ciò non ha senso, voterò per rimuovere il mio post.
Sono arrivato qui mentre cercavo informazioni simili e sono rimasto sorpreso dal fatto che molti affermino 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 davvero accesso al traffico di tutti gli altri (probabilmente fattibile con un attacco Man in the Middle.) Se avessi un computer nello stesso data center, 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 viewfunzione, 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 dal 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 $includecomando:
$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 /etc/network/interfacesfile e utilizzare i propri IP DNS nameservernell'opzione. Qualcosa come questo:
iface eth0 inet static
...
nameserver 10.0.0.1 10.0.0.103 ...
Ora dovresti essere pronto.