Чего только не придумают!

Автор: Антошка | Рубрика: домены

На днях я начитался ужастиков про DNS. Domain name system – DNS – это такая мировая система по управлению доменными именами, а доменные имена – это те адреса, что вы используете при доступе к любым сайтам, например yandex.ru – доменное имя, и оно управляется NS Яндекса. А NS – name server – входят в состав DNS. Ну а дальше будет много непонятного, что наверное уже не будет так подробно расшифровано. Так что, внимание, далее научный контент!!

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

Случай первый. Безопасность почты. Давайте предположим, что у нас есть домен wikileaks.ltd, который добавлен на три DNS – два из них вторичные (slave) и один – первичный (master). slave-1 стоит в Москве, а slave-2 – в Чикаго. Внезапно master выходит из строя на долгий срок, нигде в мире на DNS не сохранился кэш, либо его срок действия уже истек, зону начинают обрабатывать только slave сервера. В этот же момент хакер проник на один из slave-серверов, допустим на тот, что в Чикаго (slave-2), и изменил зону домена, теперь MX записи у него стали не от Google Apps, а от Яндекс.Почты. Итак, получилась ситуация, что домен есть на двух вторичных NS, но на одном у нас MX Google (как и должно быть), а на другом – Яндекс (что неверно). Хакер запарковал домен в почту Яндекса и ждет двух важных и секретных писем – одно отправлят с сервера в Бразилии, а другое – с сервера в Казахстане. Получит ли хакер секретные письма? Оба, только одно или все-таки ни одного? Или почта раздвоится и будет отправлена и в Google, и в Яндекс?

По непроверенной информации, есть шанс, что Google настолько продвинут, что поддержит зону своим кэшем не один день. Но и Яндекс не лыком шит, думаю, что-то придумал. Но вот если MX записи у нас будут ни Google или Яндекс, а хостинг-1 и хостинг-2 с минималистическим кэшем, да и NS у такого хостинга почему-то по одному, проще говоря – пара VPS на разных континентах, где есть только один NS. Безусловно можно протестировать такую схему, но трудозатраты тут большие, но секретные письма из Бразилии и Казахстана этого могут стоить :)

Случай второй. Безопасность локальной сети. Это вариант для тех, у кого есть свои DNS, есть своя локальная сеть, компьютеры в ней и есть что из этой сети тащить. Здесь DNS нам тоже предлагает брешь, все дело в том, что при неправильной настройке сервера NS, с него можно стащить зонный файл и узнать записи домена, т.е. компьютеры, субдомены, IP. Далее я просто процитирую буквы из другой статьи, там все понятно:

Конфигурируя сервер, администраторы часто забывают правильно настроить службу DNS . После такой настройки служба DNS работает корректно: IP-адреса разрешаются в имена компьютеров, а символьные имена без проблем преобразуются в IP-адреса. На этом большинство администраторов и останавливаются: главное, чтобы работало. Работать-то оно работает, но неправильно настроенный сервер DNS может стать огромной дырой в системе безопасности компании. Одно дело, когда сервер DNS обслуживает локальную сеть без выхода в Интернет: даже, если кто-то и попытается “взломать” сервер, то вычислить “хакера” довольно просто. А вот, если сеть предприятия подключена к Интернет, то узнать, кто же пытался взломать (или взломал) вашу сеть довольно сложно. Ущерб от взлома может обойтись компании в кругленькую сумму.
Прежде, чем приступить к взлому сети или отдельной системы злоумышленник (или группа злоумышленников) пытается собрать как можно больше информации: имена компьютеров сети, имена пользователей, версии установленного программного обеспечения. Целой кладовой полезной для взломщика информации станет неправильно настроенная служба DNS (BIND). Рассмотрим небольшой пример: запустите программу nslookup и введите команду:
ls server.com
Если администратор забыл правильно настроить трансфер зоны, то кто угодно получит список компьютеров нашей сети:
[comp2.server.com]
server.com. 323.111.200.2
server.com. server = comp1.server.com
server.com. server = comp2.server.com
server.com. server = comp3.server.com
mail 323.111.200.17
gold 323.111.200.22
www.ie 323.111.200.11
jersild 323.111.200.25
comp1 323.111.200.1
comp3 323.111.200.3
parasit3 323.111.200.20
www.press 323.111.200.30
comp1 323.111.200.1
www 323.111.200.2

Примечание. Чтобы не было недоразумений, указаны несуществующие IP-адреса

Дабы не случилось непоправимого, разрешите передачу зону только одному компьютеру – вторичному серверу DNS вашей компании, если такой, конечно, имеется. В файле конфигурации сервиса named – /etc/named.conf – измените секцию options следующим образом:
options{
allow-transfer
{
192.168.1.2;
};
};
Вторичный сервер DNS , как правило, не передает никакой информации о зоне, поэтому обязательно укажите следующую строку в его файле конфигурации /etc/named.conf (в секции options):
allow-transfer { none; }
Если у вас нет вторичного сервера DNS , добавьте вышеуказанную строку в файл конфигурации основного сервера DNS .
Как любой хороший администратор, вы хотите, чтобы ваш сервер DNS быстро обслуживал запросы клиентов. Но к вашему серверу могут подключаться пользователи не из вашей сети, например, из сети конкурирующего провайдера. Тогда вас сервер будет обслуживать “чужих” клиентов. Непорядок! Опция allow-query позволяет указать адреса узлов и сетей, которым можно использовать наш сервер DNS:
allow-query { 192.168.1.0/24; localhost; };
В данном примере мы позволяем использовать наш сервер узлам из сети 192.168.1.0 и узлу localhost. Целесообразно разрешить рекурсивные запросы только из сети 192.168.1.0 и узлу localhost:
allow-recursion { 192.168.1.0/24; localhost; };
Обычно взлом любой сети начинается со сбора информации – о структуре сети, об установленном программном обеспечении и версиях этого ПО и т.д. Мы можем заставить сервер DNS сообщать не номер своей версии, а произвольное сообщение:
version “Made in USSR”;
Все вышеперечисленные опции должны быть указаны в секции options файла конфигурации named.conf:
options {
allow-query { 192.168.1.0/24; localhost; };
allow-recursion { 192.168.1.0/24; localhost; };
allow-transfer { 192.168.1.2; };
version “Made in USSR”;
}

Ну и на последок даю список бесплатных DNS хостингов. Для чего? Дабы, во-первых, парковать туда свои домены и быть он-лайн в своей почте, во-вторых, быстро (“на горячую”) менять A-запись для домена, а не ждать обновления NS у регистратора. (В 21-м веке “на горячую” смена происходит уже не только HDD-дисков, но и местоположения сайта.)

netbreeze.net/dns – максимум одна зона в бесплатном пакете, есть одномегабайтный хостинг (под визитку или редирект), суппорт может настроить трансфер зоны, три NS
pdd.yandex.ru/help/section9/ – два NS от Яндекса
ypdns.com – пять NS, 10 бесплатных зон
cloudns.net – три зоны, четыре NS, в бесплатном варианте много ограничений, но работать с этим вполне реально
freedns.ws
freedns.afraid.org – есть редактор
everydns.com
zoneedit.com – держит зону *.gov, нет редактора зоны, бесплатно 5 зон
editdns.net
xname.org
ns2.trifle.net – только вторичный NS