У нас есть почтовый сервер только SMTP за брандмауэром, который будет иметь общедоступную запись почты.. Единственный способ получить доступ к этому почтовому серверу - с другого сервера за тем же брандмауэром. У нас нет собственного частного 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-серверов. Таким образом, вы либо открываете себя для повторного связывания атак, либо локальные адреса не работают, либо вам требуется более сложная настройка (если ваше программное обеспечение / маршрутизатор даже позволяет это).
Лучше всего оставить его в файле hosts. Если в любом случае предполагается, что к нему будет подключаться только одна машина, что вы получите, разместив ее в общедоступном DNS?
Если под частным вы имеете в виду 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). Если бы вы просто поставили компьютер в том же центре обработки данных, имея это Информация, безусловно, на шаг приблизит вас к взлому моего трафика. (Теперь у каждого клиента есть собственная зарезервированная частная сеть, как и в случае с другими облачными сервисами, такими как 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 файл и используя ваши IP-адреса DNS в nameserver вариант. Что-то вроде этого:
iface eth0 inet static
...
nameserver 10.0.0.1 10.0.0.103 ...
Теперь все должно быть готово.