Genel bir A posta kaydına sahip olacak bir güvenlik duvarının arkasındaki bir SMTP yalnızca posta sunucumuz var. . Bu posta sunucusuna erişmenin tek yolu aynı güvenlik duvarının arkasındaki başka bir sunucudan geliyor. Kendi özel DNS sunucumuzu çalıştırmıyoruz.
Özel IP adresini genel bir DNS sunucusunda A kaydı olarak kullanmak iyi bir fikir midir - yoksa bu sunucu kayıtlarını her sunucuda yerel ana bilgisayar dosyasında tutmak en iyisi midir?
Yanıtlar:
Bazı insanlar hiçbir halka açık DNS kaydının hiçbir zaman özel IP adreslerini ifşa etmemesi gerektiğini söylerler.
Şahsen, gizliliğin zayıf bir güvenlik biçimi olduğunu düşünüyorum, özellikle de IP adreslerinden bahsederken genel olarak zaten tahmin etmek kolaydır, bu yüzden bunu gerçekçi bir güvenlik anlaşması olarak görmüyorum.
Buradaki en büyük husus, genel kullanıcılarınızın bu DNS kaydını barındırılan uygulamanızın normal kamu hizmetlerinin bir parçası olarak almadığından emin olmaktır. Örneğin: Dış DNS aramaları bir şekilde ulaşamadıkları adrese çözümlemeye başlar.
Bunun dışında, özel adres A kayıtlarını kamusal alana koymanın temel bir neden olmadığını anlıyorum .... özellikle onları barındıracak alternatif bir DNS sunucunuz olmadığı zaman.
Bu kaydı ortak DNS alanına koymaya karar verirseniz, tüm "özel" kayıtları tutmak için aynı sunucuda ayrı bir bölge oluşturmayı düşünebilirsiniz. Bu onların özel olmaları gerektiğini açıkça ortaya koyacak ... ancak sadece bir A kaydı için, muhtemelen rahatsız etmem.
Bir süre önce NANOG listesinde bu konuyla ilgili uzun bir tartışma yaptım. Her zaman kötü bir fikir olduğunu düşünmeme rağmen, pratikte bu kadar kötü bir fikir olmadığı ortaya çıktı. Zorluklar çoğunlukla rDNS aramalarından kaynaklanıyor (dış dünyadaki özel adresler için Just Don't Work) ve bir VPN veya benzeri adreslerden adreslere erişim sağlarken VPN istemcilerinin uygun şekilde korunmasını sağlamak önemlidir. VPN kapalı olduğunda trafiği "sızdırıyor".
Ben onun için git derim. Bir saldırgan, adlarını dahili adreslere çözümlemekten anlamlı bir şey alabilirse, daha büyük güvenlik sorunlarınız olur.
Genel olarak, RFC1918 adreslerini kamuya açık DNS’e sokmak, gerçek bir sorun olmasa da gelecekte bir noktada karışıklığa neden olacaktır. Güvenlik duvarınızın arkasındaki RFC1918 adreslerini kullanmak, ancak bunları genel görünüme dahil etmemek için IP'leri, ana bilgisayar kayıtlarını veya bölgenizin özel bir DNS görünümünü kullanın.
Gönderilen diğer cevaplara dayanarak cevabımı açıklığa kavuşturmak için, RFC1918 adreslerini kamuya açık bir DNS’e tanıtmak bir güvenlik meselesi değil, sahte bir işlemdir. Biri beni sorun çıkarmaya çağırırsa ve DNS'lerinde RFC1918 adreslerine rastlarım, yavaşça konuşmaya ve son zamanlarda yeniden başlatılıp başlatılmadıklarını sormaya başladım. Belki de bu benim kibirim, bilmiyorum. Ama dediğim gibi, yapılması gereken bir şey değil ve bir noktada karışıklığa ve yanlış iletişime (insan, bilgisayar değil) neden olabilir. Neden riske atıyorsun?
Hayır, özel IP adreslerinizi ortak DNS’e koymayın.
İlk olarak, göreceli olarak küçük bir problem olmasına rağmen bilgi sızdırıyor.
MX kayıtlarınız belirli bir ana bilgisayar girişine işaret ediyorsa, daha da kötüsü, kendisine posta göndermeye çalışan herkesin en iyi şekilde posta teslim zaman aşımına uğraması.
Gönderenin posta yazılımına bağlı olarak sıçramalar oluşabilir.
Daha da kötüsü, RFC1918 adres alanını kullanıyorsanız (bu, ağınızın içinde olmalıdır) ve gönderen de varsa, postayı kendi ağlarına teslim etme ve denemeleri için her ihtimal vardır.
Örneğin:
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
Evet, bozuk bir yapılandırma, ancak bunun (ve daha da kötüsü) olduğunu gördüm.
Hayır, bu DNS'nin hatası değil, sadece söyleneni yapıyor.
Olasılık uzak olsa da, bazı MITM saldırıları için kendinizi hazırladığınızı düşünüyorum.
Endişem bu olurdu. Diyelim ki, kullanıcılarınızdan birinin posta sunucusunu işaret edecek şekilde yapılandırılmış bir posta istemcisi ile dizüstü bilgisayarlarını başka bir ağa götürdüğünü söyleyelim. Diğer ağ aynı zamanda kullanımda aynı RFC1918'e sahipse gerçekleşir. Bu dizüstü bilgisayar, smtp sunucusunda oturum açmayı deneyebilir ve kullanıcının kimlik bilgilerini, sahip olmaması gereken bir sunucuya sunabilir. Bu özellikle SMTP’yi söylediğinizden ve SSL gerektiren yerlerde sizden bahsetmediğiniz için geçerlidir.
İki seçeneğiniz / etc / hosts dosyası ve ortak bölgenize özel bir IP adresi koymak. Eskiyi tavsiye ederim. Bu, çok sayıda ana bilgisayarı temsil ediyorsa, kendi çözümleyicinizi dahili olarak çalıştırmayı düşünmelisiniz, o kadar da zor değil.
Bununla ilgili ince problemler olabilir. Birincisi, DNS Rebind saldırıları için ortak çözümlerin, genel DNS sunucularından çözülen yerel DNS girişlerini filtrelemesidir. Yani, saldırıları yeniden bağlamak için kendinizi açıyorsunuz ya da yerel adresler çalışmıyor ya da daha karmaşık bir yapılandırma gerektiriyor (yazılımınız / yönlendiriciniz izin veriyorsa).
Hosts dosyasında tutmak en iyisidir. Yine de bir makinenin buna bağlanması gerekiyorsa, genel DNS’e koyarak ne kazanırsınız?
/etc/hostsDosyayı kullanmak pratik değil çünkü 2.000 makinenin tümü bu IP / isim çiftlerini yönetmeli ...
Özel olarak, 10.0.0.0/8, 192.168.0.0/16 veya 172.16.0.0/12 demek istiyorsan, yapma . - Çoğu internet yönlendiricileri Ne için onu tanımak gerekir özel adrese asla direkt bir tutumla kamu internete yönlendirilir NAT popülerliğini yardımcı budur. Genel DNS sunucunuzla bağlantı kurmaya çalışan herkes özel IP adresini DNS'den alır; yalnızca hiçbir yere bir paket göndermek için. Bağlantıları interneti özel adresinize yönlendirmeye çalıştığından, yol boyunca bazı (tamamen yapılandırılmış) bir yönlendirici basitçe paketi canlı olarak yer.
Eğer "içerden" gelmek için "dışardan" e-posta almak istiyorsanız, bir noktada paketin güvenlik duvarınızı geçmesi gerekir. Bunu işlemek için bir DMZ adresi kurmanızı tavsiye ederim - bulunduğunuz herhangi bir yönlendirici / güvenlik duvarı tarafından sıkı bir şekilde kontrol edilen tek bir genel IP adresi. Tanımladığınız mevcut kurulum tam olarak böyle sesler.
EDIT: niyetin açıklanması ... (aşağıdaki yorumlara bakınız). Bu mantıklı gelmezse, kendi gönderimi kaldırmak için oy kullanacağım.
Buraya benzer bilgiler aradığım için geldim ve birçoğunun özel IP adreslerinizi sızdırmanın iyi olduğunu söylediğine şaşırdım. Sanırım saldırıya uğramak açısından güvenli bir ağ kullanıyorsanız çok büyük bir fark yaratmıyor. Bununla birlikte, DigitalOcean tüm yerel ağ trafiğini tamamen aynı kablolarda, herkesin gerçekten herkesin trafiğine erişebilmesini sağladı (muhtemelen Ortadaki bir Adamla yapılabilir).) Aynı veri merkezinde bir bilgisayarı ele geçirirseniz bilgi kesinlikle size trafiğimi hacklemeye bir adım daha yaklaşıyor. (Artık her müşterinin AWS gibi diğer bulut hizmetlerinde olduğu gibi kendi özel ağına sahip.)
Bununla birlikte, kendi BIND9 servisinizle, kamu ve özel IP'lerinizi kolayca tanımlayabilirsiniz. Bu viewbir şartlı içeren özellik kullanılarak yapılır . Bu, bir DNS'yi sorgulamanıza ve yalnızca kendi dahili IP adresinizden birinden soruyorsanız dahili IP'ler hakkında bir cevap almanıza olanak sağlar.
Kurulum iki bölge gerektirir. Seçim, kullanır match-clients. İşte BIND9 ile Two-in-one DNS sunucusundan kurulum örneği :
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; };
};
};
İşte dış bölge ve IP’lerin özel olmadığını görebiliyoruz.
; 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.
İç bölgeye gelince, ilk önce dış bölgeyi ekledik, bu şekilde çalışıyor. yani eğer bir dahili bilgisayarsanız, sadece dahili bölgeye erişirsiniz, böylece yine de harici bölge tanımlarına ihtiyacınız vardır, bu nedenle $includekomut:
$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
Son olarak, tüm bilgisayarlarınızın artık bu DNS ve kölelerini kullandığından emin olmalısınız. Statik bir ağ varsayalım, bu, /etc/network/interfacesdosyanızı düzenlemek ve DNS IP'lerinizi nameserverseçeneğinde kullanmak anlamına gelir . Bunun gibi bir şey:
iface eth0 inet static
...
nameserver 10.0.0.1 10.0.0.103 ...
Şimdi hepiniz hazır olmalısınız.