У нас есть только SMTP почтовый сервер за брандмауэром, который будет иметь публичную запись почты. , Единственный способ получить доступ к этому почтовому серверу - с другого сервера за тем же брандмауэром. У нас нет собственного частного DNS-сервера.
Является ли хорошей идеей использовать частный IP-адрес в качестве записи A на общедоступном DNS-сервере или лучше хранить эти записи сервера в файле локальных хостов каждого сервера?
Ответы:
Некоторые люди скажут, что никакие публичные записи DNS никогда не должны раскрывать частные IP-адреса .... с мыслью о том, что вы даете потенциальным злоумышленникам некоторую информацию, которая может потребоваться для использования частных систем.
Лично я считаю, что обфускация - плохая форма безопасности, особенно когда мы говорим об IP-адресах, потому что в общем случае их легко угадать, поэтому я не рассматриваю это как реальный компромисс безопасности.
Здесь больше внимания уделяется тому, чтобы ваши публичные пользователи не воспринимали эту запись DNS как часть обычных общедоступных сервисов вашего размещенного приложения. То есть: внешние DNS-запросы как-то начинают разрешаться по адресу, к которому они не могут добраться.
Кроме того, я не вижу фундаментальной причины, по которой размещение личных записей адреса А в публичном пространстве является проблемой ... особенно, если у вас нет альтернативного 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 фильтруют локальные записи DNS, разрешенные с общедоступных DNS-серверов. Таким образом, вы либо открываете себя для повторной атаки, либо локальные адреса не работают, либо требует более сложной конфигурации (если ваше программное обеспечение / маршрутизатор даже позволяет это).
Лучше всего хранить его в файле hosts. Если в любом случае предполагается, что к нему подключается только одна машина, что вы получите, разместив ее в общедоступном DNS?
/etc/hostsфайл нецелесообразно, потому что все 2000 машин должны управлять этими парами IP / имен ...
Если под частным вы подразумеваете 10.0.0.0/8, 192.168.0.0/16 или 172.16.0.0/12, то не делайте этого . Большинство интернет-маршрутизаторов признают его таким, какой он есть, - частным адресом, который никогда нельзя направлять в общедоступный Интернет прямым способом , что и способствовало популярности NAT. Любой, кто пытается связаться с вашим общедоступным DNS-сервером, извлекает частный IP-адрес из DNS, только чтобы отправить пакет в ... никуда. Поскольку их соединение пытается перебросить интернет на ваш частный адрес, некоторые (разумно настроенные) маршрутизаторы по пути просто сожрут пакет живым.
Если вы хотите получать электронную почту «извне» и «внутрь», в какой-то момент пакет должен пересечь ваш брандмауэр. Я бы посоветовал настроить адрес DMZ для этого - один публичный IP-адрес, который жестко контролируется любым имеющимся у вас маршрутизатором / брандмауэром. Существующая настройка, которую вы описываете, звучит так, как будто она делает именно это.
РЕДАКТИРОВАТЬ: разъяснение намерения ... (см. Комментарии ниже). Если это не имеет смысла, я проголосую, чтобы удалить свой пост.
Я приехал сюда, когда искал подобную информацию, и был удивлен, что многие говорят, что это нормально - утечка ваших личных 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 ...
Теперь у вас должно быть все готово.