У нас есть только почтовый сервер SMTP, расположенный за брандмауэром, который будет иметь общедоступную запись о почте., Единственный способ получить доступ к этому почтовому серверу - с другого сервера за тем же брандмауэром. Мы не запускаем собственный собственный DNS-сервер.
Является ли хорошей идеей использовать частный IP-адрес в качестве записи A на общедоступном DNS-сервере - или лучше хранить эти записи сервера в каждом файле локальных хостов серверов?
Некоторые люди скажут, что никакие общедоступные записи DNS никогда не должны раскрывать частные IP-адреса ... с учетом того, что вы даете потенциальным злоумышленникам ногу на какую-то информацию, которая может потребоваться для использования частных систем.
Лично я считаю, что обфускация - это плохая форма безопасности, особенно когда мы говорим об IP-адресах, потому что вообще их легко угадать, так что я не вижу в этом реалистичного компрометации безопасности.
Больше внимания здесь делается для того, чтобы ваши публичные пользователи не записывали эту запись DNS как часть обычных общедоступных служб вашего размещенного приложения. т. е. внешние DNS-запросы каким-то образом начинают разрешать адрес, к которому они не могут добраться.
Помимо этого, я не вижу основополагающей причины, по которой помещать записи частного адреса A в публичное пространство является проблемой ... особенно если у вас нет альтернативного DNS-сервера для их размещения.
Если вы решите поместить эту запись в общедоступное пространство DNS, вы можете подумать о создании отдельной зоны на том же сервере для хранения всех «частных» записей. Это позволит уточнить, что они предназначены для частных ... однако для одной записи A я, вероятно, не стал бы беспокоиться.
Некоторое время назад я долго обсуждал эту тему в списке NANOG. Хотя я всегда думал, что это плохая идея, получается, что на практике это не такая плохая идея. Трудности в основном возникают из запросов rDNS (которые для частных адресов Just Do not Work во внешнем мире), и когда вы предоставляете доступ к адресам через 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, это просто то, что ему говорят.
Ваши две опции - / etc / hosts и размещение частного IP-адреса в вашей общественной зоне. Я бы порекомендовал первое. Если это представляет большое количество хостов, вы должны подумать о том, чтобы запустить собственный резольвер внутри, это не так сложно.
Хотя возможность отдаленная, я думаю, что вы можете настроить себя на некоторые атаки MITM.
Мое беспокойство было бы в этом. Допустим, что один из ваших пользователей с почтовым клиентом, настроенным на то, чтобы указать на этот почтовый сервер, переносит свой ноутбук в другую сеть. Что произойдет, если в этой другой сети также используется тот же RFC1918. Этот ноутбук может попытаться войти на сервер smtp и предоставить учетные данные пользователя серверу, который не должен иметь его. Это было бы особенно верно, так как вы сказали SMTP и не упоминали, что вы, где требуется SSL.
Лучше оставить его в файле hosts. Если в любом случае предполагается, что только одна машина подключается к ней, что вы получаете, поставив ее в публичный DNS?
Если по частному вы имеете в виду 10.0.0.0/8, 192.168.0.0/16 или 172.16.0.0/12, тогда не, Большинство интернет-маршрутизаторов признают это тем, что есть - частный адрес, который должен никогда направлять в общественный Интернет прямо, что и помогло популярности NAT. Любой, кто пытается связаться с вашим общедоступным DNS-сервером, получит частный IP-адрес из DNS, только для отправки пакета .... нигде. По мере того, как их соединение пытается пересечь интернет к вашему приватному адресу, некоторые (настроенные вручную) маршрутизаторы по пути просто съедят пакет в живых.
Если вы хотите получить электронную почту от «внешнего», чтобы войти «внутрь», в какой-то момент пакет должен пересечь ваш брандмауэр. Я бы предложил настроить адрес DMZ для обработки этого - единственный публичный IP-адрес, который жестко контролируется любым маршрутизатором / брандмауэром, который у вас есть. Существующая установка, которую вы описываете, звучит так, как будто она делает именно это.
EDIT: разъяснение намерения ... (см. Комментарии ниже). Если это не имеет смысла, я проголосую за удаление своего сообщения.