Вопрос: Частный IP-адрес в общедоступном DNS


У нас есть только почтовый сервер SMTP, расположенный за брандмауэром, который будет иметь общедоступную запись о почте.,  Единственный способ получить доступ к этому почтовому серверу - с другого сервера за тем же брандмауэром. Мы не запускаем собственный собственный DNS-сервер.

Является ли хорошей идеей использовать частный IP-адрес в качестве записи A на общедоступном DNS-сервере - или лучше хранить эти записи сервера в каждом файле локальных хостов серверов?


50
2018-05-05 02:21


Источник




Ответы:


Некоторые люди скажут, что никакие общедоступные записи DNS никогда не должны раскрывать частные IP-адреса ... с учетом того, что вы даете потенциальным злоумышленникам ногу на какую-то информацию, которая может потребоваться для использования частных систем.

Лично я считаю, что обфускация - это плохая форма безопасности, особенно когда мы говорим об IP-адресах, потому что вообще их легко угадать, так что я не вижу в этом реалистичного компрометации безопасности.

Больше внимания здесь делается для того, чтобы ваши публичные пользователи не записывали эту запись DNS как часть обычных общедоступных служб вашего размещенного приложения. т. е. внешние DNS-запросы каким-то образом начинают разрешать адрес, к которому они не могут добраться.

Помимо этого, я не вижу основополагающей причины, по которой помещать записи частного адреса A в публичное пространство является проблемой ... особенно если у вас нет альтернативного DNS-сервера для их размещения.

Если вы решите поместить эту запись в общедоступное пространство DNS, вы можете подумать о создании отдельной зоны на том же сервере для хранения всех «частных» записей. Это позволит уточнить, что они предназначены для частных ... однако для одной записи A я, вероятно, не стал бы беспокоиться.


49
2018-05-05 02:37



+1, см. Комментарий к ответу womble по причине :) - Mihai Limbăşan
Это хороший пример проблемы с этой идеей: merit.edu/mail.archives/nanog/2006-09/msg00364.html - sucuri
Этот совет по-прежнему применяется, если у вас есть чувствительные серверы с общедоступными IP-адресами, но за брандмауэром, ограничивающим доступ? Если публичный DNS для общедоступных IP-адресов дает дорожную карту инфраструктуры, разве это не используется злоумышленником? Идентификация узла? - Kenny
@Kenny Да, теоретически это имеет какое-то значение, но это не так сложно получить, потому что диапазон общедоступных IP-адресов легко обнаруживается. Я как-то обратился к этому в ответ и добавив к этому понятию, что могу утверждать, что если вы зависите от сокрытия IP-адресов или имен хостов как любой материальной линии защиты, у вас уже гораздо больше проблем. - Tall Jeff
@Kenny. К вашему моменту, конечно же, желательно свести к минимуму количество информации, которая является общедоступной, и вы не захотите раскрывать то, что вам не нужно, или, по крайней мере, не имели какой-то хорошей схемы затрат / чтобы рассмотреть его. Нет аргументов. Кроме того, суть моего пункта (и, я думаю, мы согласны) заключалась в простом том, что обфускация является плохой формой безопасности и что нет абсолютного хорошего / плохого, но только континуум компромиссов между затратами и выгодами рассматриваются в каждом конкретном случае в зависимости от вашей толерантности к риску и т. д. - Tall Jeff


Некоторое время назад я долго обсуждал эту тему в списке NANOG. Хотя я всегда думал, что это плохая идея, получается, что на практике это не такая плохая идея. Трудности в основном возникают из запросов rDNS (которые для частных адресов Just Do not Work во внешнем мире), и когда вы предоставляете доступ к адресам через VPN или аналогично, важно обеспечить, чтобы VPN-клиенты были должным образом защищены от «утечка» трафика при отключении VPN.

Я говорю, иди за ним. Если злоумышленник может получить что-либо значимое, чтобы иметь возможность разрешать имена для внутренних адресов, у вас возникают проблемы с безопасностью.


27
2018-05-05 02:30



+1, благодарю вас за то, что вы являетесь голосом здравомыслия во всех ответах FUD на этот вопрос. «Риск безопасности» моих нижних дорзальных регионов, и, видя проблемы маршрутизации и проблемы с DNS, сложенные в одну коленную реакцию «не делай этого», просто заставляет задуматься о компетентности людей, работающих в сетях повсюду. - Mihai Limbăşan
Коррекция: сделайте так, чтобы «видеть проблемы маршрутизации и проблемы с DNS» а также проблемы с аутентификацией / идентичностью ". - Mihai Limbăşan


В общем, введение адресов RFC1918 в открытый DNS вызовет путаницу, если не настоящую проблему, в какой-то момент в будущем. Используйте IP-адреса, записи хостов или частные DNS-представления вашей зоны, чтобы использовать адреса RFC1918 позади вашего брандмауэра, но не включать их в общедоступный.

Чтобы прояснить мой ответ на основе другого представленного ответа, я думаю, что введение адресов RFC1918 в открытый DNS является ошибкой, а не проблемой безопасности. Если кто-то позвонит мне, чтобы решить проблему, и я натыкаюсь на адреса RFC1918 в своем DNS, я начинаю говорить очень медленно и спрашиваю, не перезагрузились ли они в последнее время. Может быть, это снобизм с моей стороны, я не знаю. Но, как я уже сказал, это не обязательно, и в какой-то момент это может привести к путанице и недопониманию (человеку, а не компьютеру). Зачем рисковать?


8
2018-05-05 02:29



Каковы реальные проблемы? Каким образом люди будут смущены? - womble♦
Так что ... вежливо ... не ставить 1918 адресов в общедоступный DNS? Я столкнулся с множеством проблем, которые вызвали «скрытые» и «разделенные горизонты» зоны DNS, но не так много, вызванные частным IP-адресом в общедоступном DNS. Я просто не вижу проблемы. - womble♦
@womble, компьютеры могут быть смущены, если по какой-то причине они попытаются подключиться к этому узлу за пределами вашей сети, и вместо того, чтобы получать SMTP-сервер, который они ожидали, они получили то, что живет на этом IP-адресе на LAN, где они сейчас подключены. Возможно, даже один из ваших сотрудников, использующий ноутбук на удаленном компьютере, может начать извергать имя пользователя и пароль в текстовом виде в чужой сети только потому, что у них также есть 192.168.1.1 - Zoredache
Проблема с вашим ответом заключается в том, что вы намекаете на проблемы, но не предоставляете никаких подробностей. Если есть причины не делать этого, я хочу знать о них, поэтому я могу сделать вполне обоснованное решение по этому вопросу. - womble♦
Я также хотел бы знать, что может возникнуть «путаница». Единственная «путаница», о которой я могу думать, - это RFC1918-адреса в публичных записях NS или MX, и это большая толстая ошибка, а не путаница. Проблема с безопасностью - это красная селедка, у 90% людей уже будет 192.168.1.0/24, и никто не захочет проверять DNS больше, и если вас беспокоит утечка внутренних сетей, вы проверили свои заголовки SMTP в последнее время? Так и думал. - Mihai Limbăşan


Нет, не ставьте личные IP-адреса в общедоступный DNS.

Во-первых, это утечка информации, хотя это относительно небольшая проблема.

Хуже проблема, если ваши записи MX указывают на то, что конкретная запись хоста заключается в том, что любой, кто пытается отправить ему почту, в лучшем случае получит тайм-ауты доставки почты.

В зависимости от почтового программного обеспечения отправителя они могут получить отскоки.

Хуже того, если вы используете адресное пространство RFC1918 (которое должно быть в вашей сети) и отправитель тоже, есть все шансы, что они попытаются доставить почту в свою собственную сеть.

Например:

  • сеть имеет внутренний почтовый сервер, но нет разделенного DNS
  • admin поэтому ставит как общедоступные, так и внутренние IP-адреса в DNS
  • и записи MX указывают на оба:

 $ORIGIN example.com
 @        IN   MX    mail.example.com
 mail     IN   A     192.168.1.2
          IN   A     some_public_IP

  • кто-то видел это мог бы попробуйте подключиться к 192.168.1.2
  • лучший случай, он отскакивает, потому что у них нет маршрута
  • но если у них также есть сервер, использующий 192.168.1.2, почта пойдет не туда

Да, это сломанная конфигурация, но я видел это (и еще хуже).

Нет, это не ошибка DNS, это просто то, что ему говорят.


6
2018-05-05 09:35



Как доставка почты на неправильную машину является проблемой DNS? Вы должны аутентифицировать SMTP-сервер. Это проблема конфигурации SMTP, которая не имеет абсолютно никакого отношения к DNS. Вы даже не сравниваете яблоки с апельсинами здесь, вы сравниваете радиоактивный масляный тост с пятью миллиграммами лагранжианских производных на палочке. Если вы беспокоитесь о получении неправильного результата MX или A, вы должны использовать DNSSEC вместо того, чтобы держать DNS ответственным за то, что он не несет ответственности, и если вы ошибочно доставляете SMTP на неправильный номер RFC1918, вы неправильно сконфигурировали или неправильно настроили свою сеть. - Mihai Limbăşan
(пересмотренная оценка за разъяснение) - Mihai Limbăşan
Если кто-то из вашей сети «составил» IP-номер, IP-протокол функционирует точно так, как он был разработан, то есть без безопасности. То, о чем вы спрашиваете, «как я могу доверять, что я на самом деле разговариваю с тем, с кем я должен поговорить?» и ответ на него не может быть доставлен по IP и / или DNS, ответ на который предоставляется DNSSEC и / или SSL / TLS и / или механизм прикладного уровня. - Mihai Limbăşan
Просто прочитайте свой комментарий к сообщению Дейва - ваше сообщение имеет больше смысла сейчас :) Я по-прежнему не согласен с положением, но я не думаю, что это иррационально больше ... - Mihai Limbăşan
Нет, речь шла вовсе не об аутентификации, а о связях, заканчивающихся не в том месте. я видел много от того, когда Verisign решила подстановочный знак * .com в 2001 году. - Alnitak


Ваши две опции - / etc / hosts и размещение частного IP-адреса в вашей общественной зоне. Я бы порекомендовал первое. Если это представляет большое количество хостов, вы должны подумать о том, чтобы запустить собственный резольвер внутри, это не так сложно.


3
2018-05-05 04:32



Это, конечно, вариант, но почему? Что заставляет внутренний распознаватель или (намного умнее) использовать что-то вроде представлений BIND, вы получаете помимо административных накладных расходов и бремени обслуживания? Вот чего я не понимаю. - Mihai Limbăşan
Запуск собственного сервера имен - это не ракетостроение. Если ваша сеть имеет достаточный размер, который вы считаете использованием / etc / hosts в качестве взлома или трудоемким, вам необходимо настроить пару резольверов в вашей сети. В качестве побочного преимущества вы уменьшаете количество трафика DNS, выходящего из вашей сети, и ускоряете разрешение общих запросов. - Dave Cheney
Я знаю, что это не ракетостроение, но это накладные расходы на техническое обслуживание и потенциальный риск для безопасности. Разумеется, более высокий риск безопасности, чем утечка существования сети RFC1918. DNS-трафик абсолютно ничтожен - на моем DNS работает около 80 умеренно больших и загруженных файлов зон, а еженедельный трафик DNS составляет менее 2 минут Youtube. Упрощение разрешения запросов на самом деле является первым аргументом здравого смысла в отношении номеров RFC1918 в DNS, который я видел здесь :). Приобретенный за то, что он немного задумывался над обычным коленом «О, нос, это реакция безопасности» :) - Mihai Limbăşan
@Alnitak: Я понимаю, откуда вы пришли, но это все еще не проблема DNS, и я утверждаю, что попытка исправить проблемы, возникающие где-то в другом месте через DNS, не является хорошей идеей вообще. Проблемы должны быть исправлены в источнике, а не исправлены DNS-хаками - хаки делают сети хрупкими. - Mihai Limbăşan
хорошо, да, я согласен. И размещение информации вашего частного хоста в общедоступном DNS - это взломанное решение проблемы отсутствия внутреннего DNS-сервера ... :) Проблема в том, что более высокие уровни не знать что эта информация должна быть «частной». - Alnitak


Хотя возможность отдаленная, я думаю, что вы можете настроить себя на некоторые атаки MITM.

Мое беспокойство было бы в этом. Допустим, что один из ваших пользователей с почтовым клиентом, настроенным на то, чтобы указать на этот почтовый сервер, переносит свой ноутбук в другую сеть. Что произойдет, если в этой другой сети также используется тот же RFC1918. Этот ноутбук может попытаться войти на сервер smtp и предоставить учетные данные пользователя серверу, который не должен иметь его. Это было бы особенно верно, так как вы сказали SMTP и не упоминали, что вы, где требуется SSL.


2
2018-05-05 02:56



Если у пользователя есть ноутбук, который они используют в вашем офисе, а также в другом месте, скорее всего, они сконфигурировали бы свой файл hosts, чтобы указать на внутренний IP-адрес MTA, или использовали IP-адрес непосредственно в своей конфигурации MUA. Тот же конечный результат. Принесите IPv6 и смерть RFC1918, это единственный способ быть уверенным ... - womble♦
Отличная точка Zoredache. Это интересный вектор атаки. В зависимости от MUA он может представить обычное «что-то раздражающее, пожалуйста, нажмите на меня, чтобы сделать то, что вы хотели, чтобы я сделал в первую очередь» диалоговое окно, или он может выйти из строя, если сертификат ssl не соответствует. - Dave Cheney


Лучше оставить его в файле hosts. Если в любом случае предполагается, что только одна машина подключается к ней, что вы получаете, поставив ее в публичный DNS?


1
2018-05-05 15:13





Если по частному вы имеете в виду 10.0.0.0/8, 192.168.0.0/16 или 172.16.0.0/12, тогда не, Большинство интернет-маршрутизаторов признают это тем, что есть - частный адрес, который должен никогда направлять в общественный Интернет прямо, что и помогло популярности NAT. Любой, кто пытается связаться с вашим общедоступным DNS-сервером, получит частный IP-адрес из DNS, только для отправки пакета .... нигде. По мере того, как их соединение пытается пересечь интернет к вашему приватному адресу, некоторые (настроенные вручную) маршрутизаторы по пути просто съедят пакет в живых.

Если вы хотите получить электронную почту от «внешнего», чтобы войти «внутрь», в какой-то момент пакет должен пересечь ваш брандмауэр. Я бы предложил настроить адрес DMZ для обработки этого - единственный публичный IP-адрес, который жестко контролируется любым маршрутизатором / брандмауэром, который у вас есть. Существующая установка, которую вы описываете, звучит так, как будто она делает именно это.

EDIT: разъяснение намерения ... (см. Комментарии ниже). Если это не имеет смысла, я проголосую за удаление своего сообщения.


1
2018-05-05 13:39



Это все хорошо и правда, но вы не дали реальной причины, почему нельзя публиковать RFC1918-адреса в DNS. Вы только что описали адреса RFC1918 и что у них нет пути к некоторым из них. Чем это отличается от любого другого IP-номера? Возможно, нет пути к 198.41.0.4 - значит ли это, что неправильно публиковать 198.41.0.4 в DNS? DNS - это система разрешения имен, Это не имеет никакого отношения к маршрутизации, они ортогональны. Вы скупаете две категории проблем, которые в основном составляют FUD. - Mihai Limbăşan
Контекстом обсуждения стало использование частных IP-адресов в общественности DNS-сервер. Пункт сообщения состоял в том, чтобы указать, что по умолчанию маршрутизаторы не маршрутизируют частные IP-адреса. Я не пытался указать, что вы не может используйте частные IP-адреса на DNS-сервере, только чтобы вы не предоставляли эти IP-адреса «снаружи». Если это будет недостаточно ясно, я с радостью выведу пост. В противном случае я не согласен с тем, что сообщение является 100% -ным пятном - чистый эффект для этого человека заключается в том, что у них будут проблемы / если они это сделают. - Avery Payne
поклоны Ваш комментарий по почте от Alnitak очистил его :) Спасибо. - Mihai Limbăşan
«Любой, кто пытается связаться с вашим общедоступным DNS-сервером, получит частный IP-адрес из DNS, только для отправки пакета ... нигде», - Нет, на самом деле вы только что описали DNS-восстановление и работают над некоторыми из наиболее безопасных маршрутизаторов, включая мой PepWave Surf SOHO: rebind.network/rebind - Ohad Schneider