Chúng tôi có một máy chủ mail chỉ SMTP phía sau tường lửa sẽ có bản ghi thư công khai. . Cách duy nhất để truy cập máy chủ thư này là từ một máy chủ khác đằng sau cùng một tường lửa. Chúng tôi không chạy máy chủ DNS riêng của chúng tôi.
Có phải là một ý tưởng tốt khi sử dụng địa chỉ IP riêng làm bản ghi A trong máy chủ DNS công cộng - hay tốt nhất là giữ các bản ghi máy chủ này trong mỗi tệp máy chủ lưu trữ cục bộ?
Câu trả lời:
Một số người sẽ nói rằng không có bản ghi DNS công khai nào nên tiết lộ địa chỉ IP riêng .... với suy nghĩ rằng bạn đang cung cấp cho những kẻ tấn công tiềm năng một số thông tin có thể được yêu cầu để khai thác các hệ thống riêng tư.
Cá nhân, tôi nghĩ rằng obfuscation là một hình thức bảo mật kém, đặc biệt là khi chúng ta đang nói về địa chỉ IP bởi vì nói chung họ rất dễ đoán, vì vậy tôi không xem đây là một thỏa hiệp bảo mật thực tế.
Việc xem xét lớn hơn ở đây là đảm bảo người dùng công cộng của bạn không nhận bản ghi DNS này như một phần của các dịch vụ công cộng thông thường của ứng dụng được lưu trữ của bạn. tức là: Tra cứu DNS bên ngoài bằng cách nào đó bắt đầu giải quyết đến một địa chỉ mà họ không thể đến.
Ngoài ra, tôi không thấy lý do cơ bản nào khiến việc ghi địa chỉ riêng A vào không gian công cộng là một vấn đề .... đặc biệt là khi bạn không có máy chủ DNS thay thế để lưu trữ chúng.
Nếu bạn quyết định đưa bản ghi này vào không gian DNS công cộng, bạn có thể xem xét việc tạo một vùng riêng trên cùng một máy chủ để giữ tất cả các bản ghi "riêng tư". Điều này sẽ làm rõ hơn rằng họ dự định là riêng tư .... tuy nhiên đối với chỉ một bản ghi A, tôi có lẽ sẽ không bận tâm.
Tôi đã có một cuộc thảo luận dài về chủ đề này trong danh sách NANOG một thời gian trước đây. Mặc dù tôi luôn nghĩ rằng đó là một ý tưởng tồi, nhưng hóa ra đó không phải là một ý tưởng tồi trong thực tế. Những khó khăn chủ yếu đến từ việc tra cứu rDNS (đối với các địa chỉ riêng Chỉ không hoạt động ở thế giới bên ngoài) và khi bạn cung cấp quyền truy cập vào các địa chỉ qua VPN hoặc tương tự, điều quan trọng là đảm bảo rằng các máy khách VPN được bảo vệ đúng cách "rò rỉ" lưu lượng khi VPN ngừng hoạt động.
Tôi nói đi cho nó. Nếu kẻ tấn công có thể nhận được bất cứ điều gì có ý nghĩa từ việc có thể phân giải tên thành địa chỉ nội bộ, bạn đã gặp vấn đề bảo mật lớn hơn.
Nói chung, việc giới thiệu địa chỉ RFC1918 vào DNS công cộng sẽ gây nhầm lẫn, nếu không phải là vấn đề thực sự, tại một thời điểm nào đó trong tương lai. Sử dụng IP, bản ghi máy chủ hoặc chế độ xem DNS riêng của vùng của bạn để sử dụng các địa chỉ RFC1918 phía sau tường lửa của bạn nhưng không bao gồm chúng trong chế độ xem công khai.
Để làm rõ phản hồi của tôi dựa trên phản hồi đã gửi khác, tôi nghĩ việc giới thiệu các địa chỉ RFC1918 vào DNS công cộng là một giả mạo, không phải là vấn đề bảo mật. Nếu ai đó gọi tôi gặp rắc rối và xử lý sự cố và tôi tình cờ phát hiện ra các địa chỉ RFC1918 trong DNS của họ, tôi bắt đầu nói chuyện rất chậm và hỏi họ xem họ có khởi động lại gần đây không. Có lẽ đó là sự hợm hĩnh từ phía tôi, tôi không biết. Nhưng như tôi đã nói, đó không phải là điều cần thiết phải làm và nó có khả năng gây nhầm lẫn và thông tin sai lệch (con người, không phải máy tính) tại một số điểm. Tại sao phải mạo hiểm?
Không, đừng đặt địa chỉ IP riêng của bạn vào DNS công cộng.
Đầu tiên, nó rò rỉ thông tin, mặc dù đó là một vấn đề tương đối nhỏ.
Vấn đề tồi tệ hơn nếu các bản ghi MX của bạn trỏ đến mục lưu trữ cụ thể đó là bất kỳ ai cố gắng gửi thư đến đó đều sẽ nhận được thời gian gửi thư tốt nhất.
Tùy thuộc vào phần mềm thư của người gửi, họ có thể bị trả lại.
Thậm chí tệ hơn, nếu bạn đang sử dụng không gian địa chỉ RFC1918 (mà bạn nên, trong mạng của bạn) và người gửi cũng vậy, sẽ có mọi cơ hội họ sẽ thử và gửi thư đến mạng riêng của họ.
Ví dụ:
$ORIGIN example.com
@ IN MX mail.example.com
mail IN A 192.168.1.2
IN A some_public_IP
Vâng, đó là một cấu hình bị hỏng, nhưng tôi đã thấy điều này (và tệ hơn) xảy ra.
Không, đó không phải là lỗi của DNS, đó chỉ là những gì nó được nói với.
Mặc dù khả năng là xa nhưng tôi nghĩ bạn có thể tự mình thiết lập một số cuộc tấn công MITM.
Mối quan tâm của tôi sẽ là điều này. Hãy nói rằng một trong những người dùng của bạn có ứng dụng thư khách được định cấu hình để trỏ đến máy chủ thư đó sẽ đưa máy tính xách tay của họ đến một số mạng khác. Điều gì xảy ra nếu mạng khác cũng xảy ra có cùng RFC1918 được sử dụng. Máy tính xách tay đó có thể cố gắng đăng nhập vào máy chủ smtp và cung cấp thông tin đăng nhập của người dùng cho máy chủ không nên có. Điều này đặc biệt đúng vì bạn đã nói SMTP và không đề cập đến việc bạn yêu cầu SSL ở đâu.
Hai tùy chọn của bạn là / etc / hosts và đặt một địa chỉ IP riêng trong vùng công cộng của bạn. Tôi muốn giới thiệu trước đây. Nếu điều này đại diện cho một số lượng lớn máy chủ lưu trữ, bạn nên xem xét việc chạy bộ giải quyết riêng của mình trong nội bộ, điều đó không khó.
Có thể có những vấn đề tinh tế với nó. Một là các giải pháp phổ biến cho các cuộc tấn công DNS Rebind lọc các mục DNS cục bộ được giải quyết từ các máy chủ DNS công cộng. Vì vậy, bạn có thể tự mở các cuộc tấn công hoặc các địa chỉ cục bộ không hoạt động hoặc yêu cầu cấu hình phức tạp hơn (nếu phần mềm / bộ định tuyến của bạn thậm chí cho phép điều đó).
Tốt nhất là giữ nó trong tệp máy chủ. Nếu chỉ có một máy được cho là kết nối với nó bằng mọi giá, bạn sẽ đạt được gì khi đưa nó vào DNS công cộng?
/etc/hoststệp vì tất cả 2.000 máy sau đó cần phải quản lý các cặp IP / tên này ...
Nếu theo cách riêng tư, bạn có nghĩa là 10.0.0.0/8, 192.168.0.0/16 hoặc 172.16.0.0/12, thì không . Hầu hết các bộ định tuyến internet nhận ra nó là gì - một địa chỉ riêng không bao giờ được chuyển đến internet công cộng theo cách trực tiếp , đó là điều giúp NAT phổ biến. Bất cứ ai cố gắng liên hệ với máy chủ DNS công cộng của bạn sẽ lấy địa chỉ IP riêng từ DNS, chỉ để gửi một gói đến .... không nơi nào. Khi kết nối của họ cố gắng truy cập internet đến địa chỉ riêng của bạn, một số bộ định tuyến (được định cấu hình hoàn toàn) trên đường đi sẽ đơn giản ăn gói sống.
Nếu bạn muốn nhận email từ "bên ngoài" để đến "bên trong", tại một số điểm, gói phải vượt qua tường lửa của bạn. Tôi sẽ đề nghị thiết lập một địa chỉ DMZ để xử lý việc này - một địa chỉ IP công cộng duy nhất được kiểm soát chặt chẽ bởi bất kỳ bộ định tuyến / tường lửa nào bạn có. Các thiết lập hiện tại bạn mô tả âm thanh như nó làm chính xác điều đó.
EDIT: làm rõ ý định ... (xem bình luận bên dưới). Nếu điều này không có ý nghĩa, tôi sẽ bỏ phiếu để xóa bài đăng của riêng tôi.
Tôi đến đây khi tôi đang tìm kiếm thông tin tương tự và rất ngạc nhiên khi nhiều người nói rằng thật tốt khi rò rỉ địa chỉ IP riêng tư của bạn. Tôi đoán về việc bị hack, nó không tạo ra sự khác biệt lớn nếu bạn ở trong một mạng an toàn. Tuy nhiên, DigitalOcean đã có tất cả lưu lượng truy cập mạng cục bộ trên cùng một dây cáp với tất cả mọi người thực sự có quyền truy cập vào lưu lượng truy cập của mọi người khác (có thể thực hiện được với cuộc tấn công Man in the Middle.) Nếu bạn chỉ cần có một máy tính trong cùng một trung tâm dữ liệu, sẽ có điều đó thông tin chắc chắn cung cấp cho bạn một bước gần hơn để hack lưu lượng truy cập của tôi. (Bây giờ mỗi khách hàng có mạng riêng dành riêng như với các dịch vụ đám mây khác như AWS.)
Điều đó đang được nói, với dịch vụ BIND9 của riêng bạn, bạn có thể dễ dàng xác định IP công khai và riêng tư của mình. Điều này được thực hiện bằng cách sử dụng viewtính năng, bao gồm một điều kiện. Điều này cho phép bạn truy vấn một DNS và nhận được câu trả lời về IP nội bộ chỉ khi bạn hỏi từ một trong những địa chỉ IP nội bộ của riêng bạn.
Việc thiết lập đòi hỏi hai vùng. Các lựa chọn sử dụng match-clients. Dưới đây là ví dụ về thiết lập từ máy chủ DNS hai trong một với 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; };
};
};
Đây là khu vực bên ngoài và chúng ta có thể thấy IP không riêng tư
; 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.
Đối với khu vực nội bộ, trước tiên chúng tôi bao gồm khu vực bên ngoài, đó là cách nó hoạt động. tức là nếu bạn là một máy tính nội bộ, bạn chỉ truy cập vào vùng bên trong nên bạn vẫn cần các định nghĩa vùng bên ngoài, do đó $includelệnh:
$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
Cuối cùng, bạn phải đảm bảo rằng tất cả các máy tính của bạn hiện sử dụng DNS đó và nô lệ của nó. Giả sử một mạng tĩnh, điều đó có nghĩa là chỉnh sửa /etc/network/interfacestệp của bạn và sử dụng IP DNS của bạn trong nameservertùy chọn. Một cái gì đó như thế này:
iface eth0 inet static
...
nameserver 10.0.0.1 10.0.0.103 ...
Bây giờ bạn nên được thiết lập tất cả.