เรามีเซิร์ฟเวอร์อีเมล SMTP เดียวที่อยู่หลังไฟร์วอลล์ซึ่งจะมีบันทึก A ของสาธารณะ . วิธีเดียวในการเข้าถึงเซิร์ฟเวอร์จดหมายนี้มาจากเซิร์ฟเวอร์อื่นที่อยู่หลังไฟร์วอลล์เดียวกัน เราไม่เรียกใช้เซิร์ฟเวอร์ DNS ส่วนตัวของเราเอง
เป็นความคิดที่ดีหรือไม่ที่จะใช้ที่อยู่ IP ส่วนตัวเป็นระเบียน A ในเซิร์ฟเวอร์ DNS สาธารณะ - หรือเป็นการดีที่สุดที่จะเก็บระเบียนเซิร์ฟเวอร์เหล่านี้ไว้ในไฟล์โฮสต์เซิร์ฟเวอร์ภายในแต่ละเครื่อง
คำตอบ:
บางคนจะบอกว่าไม่มีระเบียน DNS สาธารณะที่ควรเปิดเผยที่อยู่ IP ส่วนตัว .... ด้วยความคิดที่ว่าคุณกำลังให้ข้อมูลที่อาจจำเป็นต้องใช้ในการโจมตีช่องโหว่ของระบบส่วนตัว
โดยส่วนตัวแล้วฉันคิดว่าการทำให้งงงวยเป็นรูปแบบการรักษาความปลอดภัยที่แย่โดยเฉพาะอย่างยิ่งเมื่อเรากำลังพูดถึงที่อยู่ IP เพราะโดยทั่วไปแล้วพวกเขาจะเดาได้ง่ายดังนั้นฉันจึงไม่เห็นว่านี่เป็นการรักษาความปลอดภัยที่สมจริง
ข้อพิจารณาที่ใหญ่กว่าที่นี่คือการทำให้แน่ใจว่าผู้ใช้สาธารณะของคุณไม่รับข้อมูล DNS นี้เป็นส่วนหนึ่งของบริการสาธารณะทั่วไปของแอปพลิเคชันที่โฮสต์ของคุณ เช่นการค้นหา DNS ภายนอกการเริ่มต้นแก้ไขที่อยู่ที่ไม่สามารถเข้าถึงได้
นอกเหนือจากนั้นฉันไม่เห็นเหตุผลพื้นฐานว่าทำไมการใส่ที่อยู่ส่วนตัว A ลงในพื้นที่สาธารณะเป็นปัญหา .... โดยเฉพาะอย่างยิ่งเมื่อคุณไม่มีเซิร์ฟเวอร์ DNS สำรองเพื่อโฮสต์พวกเขา
หากคุณตัดสินใจที่จะใส่บันทึกนี้ลงในพื้นที่ DNS สาธารณะคุณอาจพิจารณาสร้างโซนแยกต่างหากบนเซิร์ฟเวอร์เดียวกันเพื่อเก็บบันทึก "ส่วนตัว" ทั้งหมด สิ่งนี้จะทำให้ชัดเจนว่าพวกเขาตั้งใจที่จะเป็นส่วนตัว .... แต่สำหรับหนึ่งระเบียน A ฉันอาจจะไม่รำคาญ
ฉันมีการอภิปรายที่ยาวนานในหัวข้อนี้ในรายการ NANOG นานมาแล้ว แม้ว่าฉันจะคิดเสมอว่ามันเป็นความคิดที่ไม่ดี แต่กลับกลายเป็นว่ามันไม่ใช่ความคิดที่เลวร้ายในทางปฏิบัติ ปัญหาส่วนใหญ่มาจากการค้นหา rDNS (ซึ่งสำหรับที่อยู่ส่วนตัวไม่ทำงานในโลกภายนอก) และเมื่อคุณให้การเข้าถึงที่อยู่ผ่าน VPN หรือสิ่งที่คล้ายคลึงกันสิ่งสำคัญคือต้องแน่ใจว่าไคลเอนต์ VPN ได้รับการปกป้องอย่างถูกต้องจาก "รั่ว" ทราฟฟิกเมื่อ VPN หยุดทำงาน
ฉันว่าไปเลย หากผู้โจมตีสามารถรับสิ่งที่มีความหมายจากความสามารถในการแก้ไขชื่อไปยังที่อยู่ภายในแสดงว่าคุณมีปัญหาด้านความปลอดภัยที่ใหญ่กว่า
โดยทั่วไปการแนะนำที่อยู่ RFC1918 ใน DNS สาธารณะจะทำให้เกิดความสับสนหากไม่ใช่ปัญหาจริงในอนาคต ใช้ IP ระเบียนโฮสต์หรือมุมมอง DNS ส่วนตัวของโซนของคุณเพื่อใช้ที่อยู่ RFC1918 หลังไฟร์วอลล์ของคุณ แต่ไม่รวมอยู่ในมุมมองสาธารณะ
เพื่อชี้แจงการตอบสนองของฉันตามการตอบสนองอื่น ๆ ที่ส่งมาฉันคิดว่าการแนะนำที่อยู่ RFC1918 ใน DNS สาธารณะนั้นเป็นมารยาทไม่ใช่ปัญหาด้านความปลอดภัย หากมีคนโทรหาฉันเพื่อแก้ไขปัญหาและฉันพบที่อยู่ RFC1918 ใน DNS ของพวกเขาฉันจะเริ่มพูดช้าและถามพวกเขาว่าพวกเขาได้รีบูตเครื่องเมื่อเร็ว ๆ นี้หรือไม่ บางทีฉันก็หัวเสียฉันก็ไม่รู้ แต่อย่างที่ฉันบอกว่ามันไม่จำเป็นต้องทำและมีแนวโน้มที่จะทำให้เกิดความสับสนและการสื่อสารผิดพลาด (มนุษย์ไม่ใช่คอมพิวเตอร์) ในบางจุด ทำไมต้องเสี่ยง?
ไม่ไม่ต้องใส่ที่อยู่ IP ส่วนตัวของคุณใน DNS สาธารณะ
ประการแรกมันรั่วข้อมูลแม้ว่ามันจะเป็นปัญหาเล็กน้อย
ปัญหาที่เลวร้ายยิ่งขึ้นถ้าระเบียน MX ของคุณชี้ไปที่รายการโฮสต์นั้นคือทุกคนที่พยายามส่งอีเมลไปจะได้รับเวลาการส่งอีเมลที่ดีที่สุด
ขึ้นอยู่กับซอฟต์แวร์อีเมลของผู้ส่งพวกเขาอาจได้รับการตีกลับ
ยิ่งแย่ไปกว่านั้นถ้าคุณใช้พื้นที่ที่อยู่ RFC1918 (ซึ่งคุณควรอยู่ในเครือข่ายของคุณ) และผู้ส่งก็มีโอกาสที่พวกเขาจะลองและส่งจดหมายไปยังเครือข่ายของตนเองแทน
ตัวอย่างเช่น:
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
ใช่มันเป็นการกำหนดค่าที่ใช้งานไม่ได้ แต่ฉันเห็นสิ่งนี้เกิดขึ้น
ไม่มันไม่ใช่ความผิดของ DNS แต่ทำตามที่บอก
แม้ว่าความเป็นไปได้นั้นจะอยู่ในระยะไกล แต่ฉันคิดว่าคุณอาจตั้งค่าตัวเองสำหรับการโจมตีของ MITM
ความกังวลของฉันจะเป็นเช่นนี้ ช่วยบอกผู้ใช้ของคุณด้วยไคลเอ็นต์เมลที่กำหนดค่าให้ชี้ไปที่เมลเซิร์ฟเวอร์นั้นนำแล็ปท็อปไปยังเครือข่ายอื่น จะเกิดอะไรขึ้นหากเครือข่ายอื่นมีการใช้ RFC1918 เหมือนกัน แล็ปท็อปนั้นอาจพยายามลงชื่อเข้าใช้เซิร์ฟเวอร์ smtp และเสนอข้อมูลรับรองของผู้ใช้ไปยังเซิร์ฟเวอร์ที่ไม่ควรมี นี่จะเป็นจริงโดยเฉพาะอย่างยิ่งเมื่อคุณพูดถึง SMTP และไม่ได้พูดถึงว่าคุณต้องการ SSL
สองตัวเลือกของคุณคือ / etc / hosts และใส่ที่อยู่ IP ส่วนตัวในพื้นที่สาธารณะของคุณ ฉันขอแนะนำให้อดีต หากนี่แสดงถึงโฮสต์จำนวนมากคุณควรลองใช้โปรแกรมแก้ไขของคุณเองภายในไม่ใช่เรื่องยาก
อาจมีปัญหาเล็กน้อยกับมัน หนึ่งคือโซลูชันทั่วไปสำหรับการโจมตี DNS Rebind กรองรายการ DNS ภายในที่แก้ไขจากเซิร์ฟเวอร์ DNS สาธารณะ ดังนั้นคุณจึงเปิดตัวเองเพื่อต่อต้านการโจมตีหรือที่อยู่ในพื้นที่ไม่ทำงานหรือต้องการการกำหนดค่าที่ซับซ้อนยิ่งขึ้น (หากซอฟต์แวร์ / เราเตอร์ของคุณอนุญาตให้ทำได้)
เป็นการดีที่สุดที่จะเก็บไว้ในไฟล์โฮสต์ หากมีเพียงเครื่องเดียวเท่านั้นที่ควรเชื่อมต่อกับมันคุณจะได้อะไรจากการใส่ลงใน DNS สาธารณะ
/etc/hostsไฟล์เพราะทุก 2,000 เครื่องแล้วจะต้องจัดการทรัพย์สินทางปัญญาเหล่านี้ / คู่ชื่อ ...
ถ้าโดยส่วนตัวคุณหมายถึง 10.0.0.0/8, 192.168.0.0/16 หรือ 172.16.0.0/12 ก็ไม่ควร เราเตอร์อินเทอร์เน็ตส่วนใหญ่รับรู้ว่าเป็นอะไร - ที่อยู่ส่วนตัวที่ต้องไม่ถูกส่งไปยังอินเทอร์เน็ตสาธารณะในรูปแบบตรงซึ่งเป็นสิ่งที่ช่วยให้ NAT เป็นที่นิยม ทุกคนที่พยายามติดต่อเซิร์ฟเวอร์ DNS สาธารณะของคุณจะดึงข้อมูลที่อยู่ IP ส่วนตัวจาก DNS เพียงเพื่อส่งแพ็คเก็ตไปยัง .... ไม่มีที่ไหนเลย เมื่อการเชื่อมต่อของพวกเขาพยายามที่จะท่องอินเทอร์เน็ตไปยังที่อยู่ส่วนตัวของคุณเราเตอร์ (กำหนดค่าอย่างถูกต้อง) บางคนที่อยู่ระหว่างทางก็จะกินแพ็คเก็ตที่ยังมีชีวิตอยู่
หากคุณต้องการรับอีเมลจาก "นอก" เพื่อมา "ข้างใน" ในบางจุดแพ็กเก็ตจะต้องข้ามไฟร์วอลล์ของคุณ ฉันขอแนะนำให้ตั้งค่าที่อยู่ DMZ เพื่อจัดการสิ่งนี้ - ที่อยู่ IP สาธารณะเดียวที่ควบคุมโดยเราเตอร์ / ไฟร์วอลล์ที่คุณมี การตั้งค่าที่มีอยู่คุณอธิบายเสียงเหมือนว่ามันทำอย่างนั้น
แก้ไข: การชี้แจงเจตนา ... (ดูความคิดเห็นด้านล่าง) หากนี่ไม่สมเหตุสมผลฉันจะลงคะแนนเพื่อลบโพสต์ของตัวเอง
ฉันมาถึงที่นี่เพราะฉันกำลังมองหาข้อมูลที่คล้ายกันและรู้สึกประหลาดใจที่หลายคนบอกว่าไม่ควรเปิดเผยที่อยู่ IP ส่วนตัวของคุณ ฉันเดาว่าในแง่ของการถูกแฮ็กมันไม่ได้สร้างความแตกต่างอะไรมากถ้าคุณอยู่ในเครือข่ายที่ปลอดภัย อย่างไรก็ตาม DigitalOcean มีการรับส่งข้อมูลเครือข่ายท้องถิ่นทั้งหมดบนสายเคเบิลเดียวกันกับทุกคนที่มีการเข้าถึงการรับส่งข้อมูลคนอื่น ๆ (อาจทำได้กับ Man in the Middle Attack) หากคุณเพิ่งจะได้รับเครื่องคอมพิวเตอร์ในศูนย์ข้อมูลเดียวกัน ข้อมูลจะช่วยให้คุณเข้าใกล้การแฮ็คข้อมูลของฉันได้ในขั้นตอนเดียว (ตอนนี้ลูกค้าแต่ละรายมีเครือข่ายส่วนตัวที่สงวนไว้เช่นเดียวกับบริการคลาวด์อื่น ๆ เช่น AWS)
ดังที่กล่าวไว้ด้วยบริการ BIND9 ของคุณเองคุณสามารถกำหนด IP สาธารณะและส่วนตัวของคุณได้อย่างง่ายดาย สิ่งนี้จะทำโดยใช้viewคุณสมบัติซึ่งรวมถึงเงื่อนไข วิธีนี้ช่วยให้คุณสามารถสืบค้น DNS หนึ่งตัวและรับคำตอบเกี่ยวกับ IP ภายในเฉพาะเมื่อคุณขอจากที่อยู่ IP ภายในของคุณ
การตั้งค่าต้องใช้สองโซน match-clientsการเลือกใช้ นี่คือตัวอย่างของการตั้งค่าจากเซิร์ฟเวอร์ DNS สองในหนึ่งเดียวที่มี 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; };
};
};
นี่คือโซนภายนอกและเราสามารถเห็น IP ไม่ได้เป็นส่วนตัว
; 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.
สำหรับโซนภายในเราก่อนจะรวมโซนภายนอกซึ่งเป็นวิธีการทำงาน เช่นถ้าคุณเป็นคอมพิวเตอร์ภายในคุณจะเข้าถึงเฉพาะโซนภายในเท่านั้นดังนั้นคุณยังต้องใช้คำจำกัดความของโซนภายนอกดังนั้น$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
ในที่สุดคุณต้องตรวจสอบให้แน่ใจว่าคอมพิวเตอร์ทั้งหมดของคุณใช้ DNS และทาสนั้น สมมติว่าเครือข่ายคงที่นั้นจะหมายถึงการแก้ไข/etc/network/interfacesไฟล์ของคุณและใช้ DNS IP ของคุณในnameserverตัวเลือก บางสิ่งเช่นนี้
iface eth0 inet static
...
nameserver 10.0.0.1 10.0.0.103 ...
ตอนนี้คุณควรจะตั้งค่าทั้งหมด