Серьезной проблемой современности являются сетевые угрозы ИБ, то есть классы угроз, реализуемых с использованием протоколов межсетевого взаимодействия. Одним из таких протоколов является протокол системы доменных имен — DNS.

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

Отследить модификацию пакетов DNS-транзакций, при потенциально высокой опасности реализации в информационных системах атак довольно непросто, поэтому становятся возможными такие атаки как:

• анализ сетевого трафика;
• подмена доверенного объекта сети;
• навязывание ложного маршрута;
• внедрение ложного объекта сети.

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

Представим фрагмент глобальной сети Интернет от клиентского ПЭВМ до некоего удаленного веб-сервиса, а также другие элементы сети, имеющие отношение к системе доменных имен


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

1. Клиентская ПЭВМ (Клиент).
2. Интернет-провайдер (в составе: кэширующий DNS-сервер, шлюз).
3. Вспомогательный клиент.
4. Система доменных имен.
5. Точка мониторинга (межсетевой экран, фильтр, прокси-сервер).
6. Сервер информационной службы.

Для успешной реализации нашего замысла необходимо выполнение ряда условий:

1. Существует контролируемый DNS-сервер, отвечающий за какую-либо (любую) зону системы доменных имен.
2. Клиент обслуживается интернет-провайдером с кэширующим DNS-сервером либо известен иной DNS-сервер, услугами которого пользуется клиент, и данный сервер является кэширующим.
3. В момент получения DNS-ответа от контролируемого DNS-сервера в кэше DNS-сервера интернет-провайдера отсутствует запись с целевым DNS-именем узла информационной службы.
4. В точке мониторинга существует база IP адресов и доменных имен целевых информационных службы, в отношении которых ведется мониторинг и управление сетевым взаимодействием с клиентом.

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

Согласно рекомендациям RFC 1034, RFC 1035, устанавливающих порядок функционирования, спецификацию и применение системы доменных имен, при формировании DNS-ответа допускается добавление, так называемых полей «Additional». Данные поля необходимы для записи IP-адресов вспомогательных узлов различных типов, в том числе, для предотвращения повторного обращения к DNS-серверу, в случаях, когда по определенным причинам, основной узел, запись которого передается в поле «Answer», оказывается недоступным. В случае применения предлагаемого подхода, в поле «Additional» записывается IP-адрес, ставящийся в соответствие доменному имени целевой информационной службе, но реально принадлежащий точке мониторинга – межсетевому экрану.

Такую задачу (добавление нужного нам поля) можно возложить на скрипт, имитирующий работу легитимного DNS-сервера, отвечающего за какую-либо DNS-зону, причем не важно какого уровня…

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

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

При обращении клиента по полученному IP адресу к точке мониторинга, в которой на основании предопределенных параметров сетевой политики безопасности производится ряд управляющих воздействий. К этим действиям относится:

1. Разбор полученной от клиента транзакции.
2. Выработка и применение управляющих воздействий.
3. Аудит полученных транзакций и произведенных действий.
4. Формирование на основе данных полученной клиентской транзакции запроса к информационной службе.

В точке мониторинга – МСЭ осуществляется преобразование сетевых адресов (Network Address Translation – NAT), что позволяет обеспечить его «прозрачную» работу с точки зрения клиента и целевой информационной службой.

Проверка представленных изысканий производилась с использованием испытательного стенда в виде компьютерной сети со следующими элементами:

1. DNS-сервер на базе программного обеспечения BIND 9.4, отве-чающий за зону ".a", с доменным именем «ns.a».
2. DNS-сервер на базе программного обеспечения BIND 9.4, отве-чающий за зону ".b", с доменным именем «ns.b».
3. Клиентская ПЭВМ с IP адресом 10.0.33.13.
4. Точка мониторинга – межсетевой экран с IP адресом 10.0.33.13.

Между всеми объектами компьютерной сети настроено сетевое взаимодействие. Принцип работы компьютерной сети заключается в следующем.

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

На 1-м этапе на DNS сервере, отвечающем за зону ".b" запускается, скрипт «fakedns», реализующий работу DNS-коммутатора. В задачу скрипта входит обработка полученного DNS запроса на разрешение доменного имени из зоны ".b" и добавление в DNS ответ дополнительного поля «Additional» для заданного доменного имени (в примере – «victim.com»), соответствующим целевой информационной службе, для которой будет осуществляться мониторинг и управление безопасностью сетевого взаимодействия с клиентом, и с заданным IP адресом (в примере – «10.0.33.13»), соответствующим точке мониторинга – межсетевому экрану. Запуск скрипта «fakedns» с заданными параметрами, моделирующий работу DNS-коммутатора осуществляется **командой**


На 2-м этапе происходит формирование и передача DNS-запроса для доменного имени «test.b» от клиента в систему доменных имен, состоящему из DNS сервера «ns.a» и DNS сервера «ns.b». При этом первичным DNS сервером (DNS сервером интернет-провайдера) для клиента является DNS сервер «ns.a».

Структура запроса

На 3-м этапе формируется и передается DNS-ответ для доменного имени «test.b» с дополнительным полем «Additional» и заданным доменным именем «victim.com», соответствующий информационного службе, которому поставлен в соответствие заданный IP адрес «10.0.33.13», соответствующий точке мониторинга.

Структура пакета DNS ответа

На 4-м этапе осуществляется проверка наличия в кэш-памяти DNS сервера «ns.a» доменного имени «victim.com», соответствующего информационной службе, но с IP адресом, соответствующем точке мониторинга – «10.0.33.13».

Проверка осуществляется командой


На 5-м этапе принимается ответ о наличии в кэш-памяти DNS сервера «ns.a» доменного имени «victim.com».

Структура DNS-ответа

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

Проверка данного факта осуществляется командой


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