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

У меня была долгая дискуссия на эту тему в списке NANOG некоторое время назад. Хотя я всегда думал, что это плохая идея, получается, что на практике это не такая плохая идея. Трудности в основном возникают из-за поиска по rDNS (который для частных адресов просто не работает во внешнем мире), и когда вы предоставляете доступ к адресам через VPN или подобное, важно обеспечить надлежащую защиту клиентов VPN от "утечка" трафика, когда VPN не работает.

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

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

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

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

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

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

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

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

Например:

• в сети есть внутренний почтовый сервер, но нет разделенного DNS
• Поэтому администратор помещает в DNS как публичные, так и внутренние IP-адреса.
• и записи 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, он просто делает то, что ему говорят.

Там могут быть тонкие проблемы с этим. Один из них заключается в том, что общие решения для атак повторного связывания DNS фильтруют локальные записи DNS, разрешенные с общедоступных DNS-серверов. Таким образом, вы либо открываете себя для повторной атаки, либо локальные адреса не работают, либо требуется более сложная конфигурация (если ваше программное обеспечение / маршрутизатор даже позволяет это).

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

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

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

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

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

РЕДАКТИРОВАТЬ: разъяснение намерения... (см. Комментарии ниже). Если это не имеет смысла, я проголосую, чтобы удалить свой пост.

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

Я приехал сюда, когда искал подобную информацию, и был удивлен, что многие говорят, что это нормально - утечка ваших личных IP-адресов. Я думаю, с точки зрения взлома, это не имеет большого значения, если вы находитесь в безопасной сети. Тем не менее, у DigitalOcean весь локальный сетевой трафик передавался по одним и тем же кабелям, и у всех действительно есть доступ ко всем остальным трафикам (возможно, это возможно при атаке "Человек посередине".) информация, безусловно, дает вам один шаг ближе к взлому моего трафика. (Теперь каждый клиент имеет свою собственную зарезервированную частную сеть, как и другие облачные сервисы, такие как AWS.)

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

Настройка требует две зоны. Выбор использует match-clients, Вот пример настройки с DNS-сервера Two-in-one с 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 ...

Теперь у вас должно быть все готово.

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

Я ищу подлинное обоснование, чтобы запретить политикой использование зарезервированных частных IP-адресов сегментов сети.

Я не вижу технических проблем с использованием общедоступных DNS-имен для разрешения IP-адреса для внутреннего использования. часто в этом редком сценарии использование разделенной зоны DNS может быть эквивалентным или меньшим объемом работы. (использование штрафа хостов логически эквивалентно отдельной зоне dnz, по моему мнению). Поэтому я думаю, что если вы рассматриваете частный адрес общедоступного DNS, подумайте, есть ли у вас более серьезная проблема с топологией, и убедитесь, что ваши изменения направлены на решение этой топологии.

Я вижу проблему тщеславия: будет бесчисленное множество других сетей, в которых рассматриваемое общедоступное имя будет случайно (в пользу злоумышленника) направлять к ресурсам, которые контролирует злоумышленник. Проблема тщеславия заключается в том, что мое DNS-имя может быть показано пользователю, пока связь идет на сервер, который я не контролирую. в этом случае могут произойти вещи, зависящие от протокола. В стране http использование hsts и сохранение секретного ключа tls должно обеспечить достаточную тщеславность, но до тех пор, пока браузеры не решат считать все веб-страницы, обслуживаемые из частных сетей, «небезопасными», в http будет оставаться вопрос тщеславия. другие протоколы, особенно там, где нет доказательства подлинности, например, общедоступные доверительные tls (например, https), частные доверительные tls (например, ssh) или взаимные tls (например, openvpn), использование общедоступных DNS, которые разрешаются в частные DNS, может привести к проблемам с тщеславием.

некоторые производители оборудования намеренно используют такие адреса, или, по крайней мере, я так думал, что раньше «routerlogin dot net» мог иметь, но не сейчас, по крайней мере, не там, где я нахожусь, или производитель может запарковать это как адрес черной дыры и положитесь на mitm для разрешения вашей маршрутизации или DNS (например, разделенного DNS), чтобы реализовать удобную для пользователя страницу настройки маршрутизатора.

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

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

Я думаю, что есть технические проблемы с использованием DNS разделенной зоны (он же частный DNS). особенно когда задействована какая-либо ОС или поставщик технологии более поздней версии 3 (например, VPN), потому что, в конце концов, программист сетевого стека ОС или оператор более поздней версии 3 имеют больший контроль над разрешением вашего голого DNS, чем вы. в частности, некоторые операционные системы используют многоадресную рассылку DNS, где самый быстрый ответ DNS считается авторитетным, и я готов поспорить, что ваш частный DNS-сервер через VPN будет медленнее, чем DNS-кеш или преобразователь isp'a, он просто ближе к концу пользователь в прыжках. это означает, что если у вас есть разрешение DNS-имени на общедоступный или частный IP-адрес - в зависимости от того, какая сеть - - теоретически - оно должно разрешать DNS через - я думаю, что у вас, вероятно, будет болезненная ситуация.

из-за этого я предпочитаю, чтобы ни одна запись DNS не имела более одного авторитетного ответа, независимо от топологии сети.

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

мне не нравится выборочный выбор маршрутизации через DNS. ip должен быть устойчивым к сбоям в сети, но это не так. что будет? чтобы быть более «ip», это было бы: иметь канонический IP-адрес (который, чтобы быть каноническим, не может быть адресом частной сети) и внедрить маршрут (/32) для этих адресов, который отправляет пакеты на маршрутизатор, которым я управляю. будет повторять этот процесс до тех пор, пока соединение не достигнет моего хоста через частную сеть, например VPN + локальную сеть, без маршрутизации через общедоступную сеть, если только VPN не отключен. --Для людей, которые считают управление несколькими файлами хостов слишком обременительным, я подозреваю, что управление такой таблицей маршрутов будет гораздо труднее. если только вы не используете ipv6 или не являетесь одним из старых гвардейцев, владеющих общедоступным IP-блоком класса A или класса B.

Примечание: я совершенно не согласен с использованием nat как де-факто «части защитной топологии сети». т. е. это используется там, где обычно есть несколько публичных адресов и много трансляций адресов портов (особенно в тяжелых системах Docker). случайно настроить брандмауэр на «отклонение по умолчанию» через деталь реализации интернет-провайдера, что случайно означает, что ваш интернет-провайдер в настоящее время не маршрутизирует какой-либо трафик, предназначенный для локальной сети брандмауэра — я думаю, все согласятся, что это очень плохая защита стратегия, однако я вижу ее повсюду по умолчанию. это настолько распространено, что в рамках кривой внедрения ipv6 сетевые операторы были сбиты с толку и потребовали технической поддержки для NAT на ipv6, где почти нет других регионов, кроме культивирования груза, которые могли бы это сделать, и если вы сделаете это неизбежно, есть хорошая Скорее всего, у вас буквально не хватает оперативной памяти для создания таблиц сетевых масок, необходимых для работы NAT, а это означает, что ipv6 nat имеет некоторые странные динамические характеристики, которые, я думаю, 20 лет назад считались бы совершенно безответственным и рискованным видом программного обеспечения. установить брандмауэр, где каждое утверждение должно быть правильным с первого раза и защищено от злоупотреблений.

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

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

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

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

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

У меня здесь нет диктаторского ответа, просто некоторые идеи, которых я не видел больше нигде в этой теме. «конечно, нет, если аудитория состоит из людей, люди будут совершать ошибки», «вероятно, нет, если у вас есть какие-либо другие реалистичные варианты», «если вам нужно, это нормально, будьте осторожны и будьте информированы, как и все, что мы делаем». делать онлайн».