За брандмауером є лише поштовий сервер SMTP, який матиме загальнодоступний запис пошти. . Єдиний спосіб отримати доступ до цього поштового сервера - це з іншого сервера за тим же брандмауером. Ми не запускаємо власний приватний DNS-сервер.
Чи корисно використовувати приватну IP-адресу як запис на загальнодоступному сервері 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 фільтрують локальні записи DNS, вирішені з загальнодоступних серверів DNS. Таким чином, ви або відкриваєтеся для відновлення атак, або локальні адреси не працюють, або потребуєте більш складної конфігурації (якщо ваше програмне забезпечення / маршрутизатор навіть це дозволяє).
Найкраще зберігати його у файлі хостів. Якщо будь-яка машина повинна коли-небудь підключитися до неї, що ви отримуєте, розміщуючи її в загальнодоступному DNS?
/etc/hostsфайл це не практично, тому що всі 2000 машин тоді повинні керувати цими парами IP / імен ...
Якщо під приватним ви маєте на увазі 10.0.0.0/8, 192.168.0.0/16 або 172.16.0.0/12, то не варто . Більшість маршрутизаторів Інтернету визнають його таким, яким він є - приватною адресою, яка ніколи не повинна прямим чином передаватися до публічного Інтернету , саме це сприяло популярності NAT. Кожен, хто намагається зв’язатися з вашим загальнодоступним сервером DNS, отримає приватну IP-адресу з DNS, лише щоб надіслати пакет .... нікуди. Оскільки їх підключення намагається перейти в Інтернет до вашої приватної адреси, якийсь (розумно налаштований) маршрутизатор по дорозі просто з'їсть пакет живим.
Якщо ви хочете отримати електронну пошту від "зовні", щоб надходити "всередину", в якийсь момент пакет повинен перетнути ваш брандмауер. Я б запропонував встановити DMZ-адресу для вирішення цього питання - єдиної загальнодоступної IP-адреси, яка жорстко контролюється будь-яким маршрутизатором / брандмауером, який у вас є. Наявна описана вами установка звучить так, що робить саме це.
EDIT: роз'яснення наміру ... (див. Коментарі нижче). Якщо це не має сенсу, я проголосую за видалення власної посади.
Я приїхав сюди, коли шукав подібну інформацію і був здивований, що багато хто каже, що добре просочити ваші приватні IP-адреси. Я думаю, що з точки зору зламу, це не має великого значення, якщо ви перебуваєте в безпечній мережі. Однак DigitalOcean мав увесь локальний мережевий трафік саме тими ж кабелями, коли всі дійсно мають доступ до трафіку всіх інших (можливо, це можливо зробити з атакою "Чоловік у середині"). Якщо ви просто отримаєте комп'ютер у тому ж центрі обробки даних, маючи це інформація, безумовно, дає вам на крок ближче до злому мого трафіку. (Тепер кожен клієнт має власну зарезервовану приватну мережу, як і для інших хмарних сервісів, таких як 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 ...
Тепер ви повинні бути все налаштовані.