4.2.2.5 Обнаружение и защита от внедрения ложного dns-сервера

Обнаружение атак на DNS осуществляется при помощи анализа содержимого DNS трафика. Например при помощи программы dnstop. Эта утилита использующая libpcap для сниффинга DNS трафика и отображения кто и какие DNS запросы осуществляет в данный момент.

Логфайл программы:

Query Sources

Queries: 2 new, 57 total

Sources Count %

--------------- --------- ------

xx.172.220.163 3 5.3

xx.222.204.147 3 5.3

xxx.196.24.98 3 5.3

xx.60.124.201 3 5.3

xxx.77.99.18 2 3.5

xxx.2.181.6 2 3.5

xx.83.0.9 1 1.8

xx.231.32.10 1 1.8

xxx.71.10.161 1 1.8

xxx.204.183.61 1 1.8

xx.38.0.108 1 1.8

xx.160.37.3 1 1.8

xx.99.135.16 1 1.8

xxx.254.254.130 1 1.8

xxx.13.29.44 1 1.8

xx.25.5.150 1 1.8

xxx.207.78.69 1 1.8

xx.211.69.181 1 1.8

1st Level Query Names

Queries: 3 new, 440 total

Query Name Count %

------------ --------- ------

com 247 56.1

org 130 29.5

net 25 5.7

in-addr.arpa 19 4.3

us 19 4.3

2nd Level Query Names

Queries: 1 new, 509 total

Query Name Count %

----------------------- --------- ------

wpad.com 153 30.1

openresolvers.org 114 22.4

packet-pushers.com 103 20.2

measurement-factory.com 27 5.3

squid-cache.org 19 3.7

dont-contact.us 18 3.5

ircache.net 14 2.8

xx.in-addr.arpa 13 2.6

wpad.net 6 1.2

life-gone-hazy.com 4 0.8

wpad.org 4 0.8

web-polygraph.org 4 0.8

web-cache.com 4 0.8

wrec.org 4 0.8

wpad.us 3 0.6

nlanr.net 3 0.6

xx.in-addr.arpa 2 0.4

iwcw.org 2 0.4

Query Source and 2nd Level Domain

Queries: 2 new, 738 total

Source Query Name Count %

-------------- ----------------------- --------- ------

xx.160.37.4 measurement-factory.com 31 4.2

xxx.88.64.49 wpad.com 28 3.8

xxx.88.64.50 packet-pushers.com 14 1.9

xx.160.37.4 12.in-addr.arpa 12 1.6

xxx.88.64.50 wpad.com 7 0.9

xx.83.0.9 wpad.com 7 0.9

xx.160.37.4 life-gone-hazy.com 6 0.8

xxx.190.163.10 packet-pushers.com 4 0.5

xxx.155.0.15 packet-pushers.com 4 0.5

xx.18.192.242 wpad.com 4 0.5

xxx.69.16.18 packet-pushers.com 3 0.4

xx.140.11.85 packet-pushers.com 3 0.4

xxx.44.212.65 openresolvers.org 3 0.4

xx.160.37.4 74.in-addr.arpa 3 0.4

xx.18.251.250 wpad.com 3 0.4

xxx.104.96.79 wpad.com 3 0.4

xxx.126.96.162 ircache.net 3 0.4

xxx.137.171.10 wpad.com 3 0.4

Query Types

Queries: 3 new, 854 total

Query Type Count %

---------- --------- ------

A? 489 57.3

AAAA? 142 16.6

MX? 107 12.5

A6? 45 5.3

SOA? 45 5.3

PTR? 26 3.0

Таким образом, если через анализатор трафика идет информационный поток, представляющий собой UDP-пакеты DNS-ответов, которые отличаются друг от друга только полями «ID» и «Номер порта», то можно утверждать, что на один из компьютеров в локальной сети осуществляется атака типа «Ложный DNS-сервер».

Методы противодействия DNS-spoofing’у. Ни административно, ни программно нельзя защититься от атаки на существующую версию службы DNS. Оптимальным с точки зрения безопасности решением будет вообще отказаться от использования службы DNS защищенном сегменте. Отказаться от использования имен при обращении к хостам для пользователей будет очень не удобно. Поэтому можно предложить следующее компромиссное решение: использовать имена, но отказаться от механизма удаленного DNS-поиска. Это фактически является возвращением к схеме, использовавшейся до появления службы DNS с выделенными DNS-серверами. Тогда на каждой машине в сети существовал hosts файл, в котором находилась информация о соответствующих именах и IP-адресах всех хостов в сети. Администратору можно внести в подобный файл информацию о лишь наиболее часто посещаемых пользователями данного сегмента серверах сети. Поэтому использование на практике данного решения чрезвычайно затруднено и, видимо, нереально.

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

Также очень распространенной является установка двух серверов DNS: внешнего и внутреннего. Внутренний сервер DNS предназначен исключительно для обслуживания внутренних клиентов сети. На нем хранится вся информация о хостах корпоративной сети. Благодаря использованию записей типа SECURE_ZONE этот сервер могут запрашивать только внутренние хосты. Более того, на брандмауэре устанавливается фильтр, который не пропускает IP-пакеты, направляемые в корпоративную сеть и предназначенные для порта 53 протоколов UDP и TCP внутреннего сервера DNS. Т. е. снаружи такой сервер DNS делается невидимым. Однако он сам может обращаться за информацией к серверам DNS сети Internet.

Внутренний сервер DNS обслуживает корпоративную сеть и не виден извне. Внешний сервер DNS предоставляет только часть информации о сети. Внешний сервер DNS предназначен для обслуживания запросов извне. На нем размещают информацию лишь о тех ресурсах корпоративной сети, которые будут доступны из Internet (серверы Web, ftp, почтовые шлюзы и т. п.). Серверы имен родительских доменов должны содержать информацию только о внешнем сервере DNS [3].

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

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

В основе действие протокола DNSSEC лежит метод цифровой подписи, который обеспечивает неприкосновенность данных в системе DNS.

В ответе с DNSSEC ответное сообщение содержит не только подписи и ключи, необходимые для проверки информации, но и сам исходный вопрос. Эта процедура называется «Аутентификацией транзакции и запроса»

Обычный DNS (рисунок 4.20):

Рисунок 4.20 - Запрос и ответ обычного DNS

Рисунок 4.21 - Запрос и ответ DNSSec

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

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

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

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

Криптографические подписи DNSSEC применяются к данным по зоне, динамическим обновлениям и транзакциям DNS. Кроме того, они используются для подтверждения отсутствия данных DNS. DNSSEC предусматривает три новые записи ресурсов - KEY RR, SIG RR и NXT RR.

KEY RR содержит открытый ключ, принадлежащий имени домена, указанному в KEY RR. Это не сертификат открытого ключа. Механизм обеспечения возможностей поиска сертификатов открытых ключей предусматривается DNSSEC WG, но не для целей защиты данных DNS. Он предоставляется в качестве дополнительного бонуса, благодаря которому DNS может применяться для запроса сертификатов открытых ключей на все, что может быть представлено с помощью имени домена. Эту возможность обеспечивает CERT RR.

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

Другим аспектом DNSSEC является подпись транзакции (Transaction Signature, TSIG). TSIG отличается от других подписей DNS тем, что она создается с использованием шифрования с секретными ключами.

Протокол DNSSEC как таковой не обеспечивает конфиденциальности данных или контроля доступа. Однако конкретные его реализации могут предусматривать те или иные механизмы обеспечения конфиденциальности и контроля доступа. Причина отсутствия такого стандартного механизма в DNS в том, что исходный протокол DNS предназначался для работы с общедоступными данными. Озабоченность утечкой информации относительно имен и местонахождения систем и возможность атак по типу "отказ в обслуживании" порождает спрос на механизмы обеспечения конфиденциальности и контроля доступа. Этот спрос отражается в реализациях DNS.

Подписи транзакций. Этот метод защиты называется TSIG, потому что он предполагает шифрование сообщения с помощью секретного ключа. Его отличие состоит в том, что один и тот же ключ используется как для генерации подписи, так и для ее проверки (т. е. вся процедура является закрытой) и что общий секретный ключ (также называемый "общим секретом") известен только хостам из одной локальной сети или (в крайнем случае) в одной территориальной сети. Использовать TSIG гораздо проще, чем полномасштабную защиту DNSSEC.

TSIG особенно полезен в случае транзакций DNS UPDATE. Большинство транзакций DNS представляет собой запросы относительно наличия данных. Транзакция DNS UPDATE вносит изменения в данные DNS на узле. Вследствие того, что обновление DNS осуществляется обычно по UDP, а запрос UDP легко подделывается, у сервера нет никаких способов установить, что запрос DNS UPDATE разрешен для данного узла. Если, с другой стороны, клиент UPDATE имеет общий секретный ключ с сервером DNS и использует его для генерации подписи под запросом, то сервер UPDATE может воспользоваться тем же самым ключом для проверки подписи и проверки наличия у запрашивающего надлежащих полномочий.

Недостатки DNSSec. Подписание и проверка данных DNS, очевидно, создают дополнительные накладные расходы, отрицательно сказывающиеся на производительности сети и серверов. Подписи занимают немало места, часто они намного превышают по объему данные, под которыми стоят. Это увеличивает нагрузку, которую DNS возлагает на магистраль Internet и многие немагистральные каналы. Генерация и проверка подписей отнимают значительное время ЦПУ. В некоторых случаях однопроцессорный сервер DNS придется даже заменить многопроцессорным сервером DNS. Подписи и ключи могут занимать на порядок больше места на диске и в оперативной памяти, чем собственно данные. Базы данных и системы управления придется наращивать, чтобы они могли справляться с возросшими объемами.

Кроме того, реализация DNSSEC сопровождается и другими, не столь очевидными затратами. Новое программное обеспечение больше по объему и сложнее, чем прежнее, а многие его компоненты являются совершенно новыми и нуждаются в обширном тестировании в реальных условиях. Пока широкомасштабных испытаний DNSSEC в Internet не проводилось, так что они могут принести множество сюрпризов.

Работа над некоторыми функциональными сторонами DNSSEC еще продолжается, например над тем, как именно администрация  будет подписывать открытые ключи. Соответствующий новый протокол может вскоре появиться. Кроме того, во время смены ключей может потребоваться поддерживать одновременно более одной пары открытых/личных ключей, но, как это будет реализовано, пока неясно. Если личный ключ окажется украден и, как следствие, должен будет изъят из обращения, то в настоящее время никаким способом нельзя известить о компрометации ключа тех, кто будет проверять с его помощью подпись.

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

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

4.3 Внедрение ложного объекта путем навязывания ложного маршрута

4.3.1 Навязывание хосту ложного маршрута с

использованием протокола ICMP

4.3.1.1 Протокол ICMP

ICMP (Internet Control Message Protocol - межсетевой протокол управляющих сообщений) - протокол, входящий в стек протоколов TCP/IP. ICMP используется для передачи сообщений об ошибках и других ситуациях, возникающих при передаче данных. Также на ICMP возлагаются некоторые сервисные функции.

Протокол ICMP не создан для того, чтобы обеспечивать абсолютную надежность передачи информации. Целью данных контрольных сообщений является обеспечение обратной связи, оповещение отправителя данных о проблемах, возникающих в коммуникационном оборудовании [3].

Формат сообщения (рисунок 4.22)

Рисунок 4.22 - Формат ICMP-сообщения

Поле типа может иметь следующие значения (таблица 4.7):

Таблица 4.7. Значения поля типа

Значение	Тип сообщения
0	Эхо-ответ (Echo Replay)
3	Узел назначения недостижим (Destination Unreachable)
4	Подавление источника (Source Quench)
5	Перенаправление маршрута (Redirect)
8	Эхо-запрос (Echo Request)
11	Истечение времени дейтаграммы (Time Exceeded for a Datagram)
12	Проблема с параметром пакета (Parameter Problem on a Datagram)
13	Запрос отметки времени (Timestamp Request)
14	Ответ отметки времени (Timestamp Replay)
17	Запрос маски (Address Mask Request)
18	Ответ маски (Address Mask Replay)

Как видно из используемых типов сообщений, протокол ICMP представляет собой некоторое объединение протоколов, решающих свои узкие задачи.

Эхо-протокол. Протокол ICMP предоставляет сетевым администраторам средства для тестирования достижимости узлов сети. Эти средства представляют собой очень простой эхо-протокол, включающий обмен двумя типами сообщений: эхо-запрос и эхо-ответ. Компьютер или маршрутизатор посылают по интерсети эхо-запрос, в котором указывают IP-адрес узла, достижимость которого нужно проверить. Узел, который получает эхо-запрос, формирует и отправляет эхо-ответ и возвращает сообщение узлу - отправителю запроса. В запросе могут содержаться некоторые данные, которые должны быть возвращены в ответе. Так как эхо-запрос и эхо-ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы интерсети.

Во многих операционных системах используется утилита ping, которая предназначена для тестирования достижимости узлов. Эта утилита обычно посылает серию эхо-запросов к тестируемому узлу и предоставляет пользователю статистику об утерянных эхо-ответах и среднем времени реакции сети на запросы.

Сообщения о недостижимости узла назначения. Когда маршрутизатор не может передать или доставить IP-пакет, он отсылает узлу, отправившему этот пакет, сообщение «Узел назначения недостижим» (тип сообщения - 3). Это сообщение содержит в поле кода значение, уточняющее причину, по которой пакет не был доставлен. Причина кодируется следующим образом (таблица 4.8):

Таблица 4.8. Значение поля кода

Код	Причина
0	Сеть недостижима
1	Узел недостижим
2	Протокол недостижим
3	Порт недостижим
4	Требуется фрагментация, а бит DF установлен
5	Ошибка в маршруте, заданном источником
6	Сеть назначения неизвестна
7	Узел назначения неизвестен
8	Узел-источник изолирован
9	Взаимодействие с сетью назначения административно запрещено
10	Взаимодействие с узлом назначения административно запрещено
11	Сеть недостижима для заданного класса сервиса
12	Узел недостижим для заданного класса сервиса

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

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

Недостижимость протокола и порта означают отсутствие реализации какого-либо протокола прикладного уровня в узле назначения или же отсутствие открытого порта протоколов UDP или TCP в узле назначения.

Ошибка фрагментации возникает тогда, когда отправитель послал в сеть пакет с признаком DF, запрещающим фрагментацию, а маршрутизатор столкнулся с необходимостью передачи этого пакета в сеть со значением MTU меньшим, чем размер пакета.

Перенаправление маршрута. С течением времени при изменении топологии сети маршрутные таблицы компьютеров могут устаревать. Кроме того, эти таблицы обычно содержат минимум информации, например, только адреса нескольких маршрутизаторов.

Для корректировки поведения компьютеров маршрутизатор может использовать сообщение протокола ICMP, называемое «Перенаправление маршрута» (Redirect).

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

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

В сообщении «Перенаправление маршрута» маршрутизатор помещает IP-адрес маршрутизатора, которым нужно пользоваться в дальнейшем, и заголовок исходного пакета с первыми 64 битами его поля данных. Из заголовка пакета узел узнает, для какой сети необходимо пользоваться указанным маршрутизатором. На изменении маршрута и основана атака ICMP-spoofing [41].