it-swarm-ru.tech

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

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

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

62
Geoff Dalgas

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

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

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

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

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

63
Tall Jeff

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

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

36
womble

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

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

8
jj33

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

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

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

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

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

Например:

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

5
Alnitak

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

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

3
Zoredache

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

3
Dave Cheney

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

2
Nikola Toshev

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

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

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

1
Avery Payne

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

1
sh-beta

Я приехал сюда, когда искал подобную информацию, и был удивлен, что многие говорят, что это нормально - утечка ваших личных 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 _ и используя ваши IP-адреса DNS в опции nameserver. Что-то вроде этого:

iface eth0 inet static
    ...
    nameserver 10.0.0.1 10.0.0.103 ...

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

0
Alexis Wilke