Атака и защита DNS

Пренебрежительное отношение к возможности вторжения с использованием ложных серверов DNS может обернуться катастрофой.

В сентябрьском номере LAN за этот год была опубликована статья Ильи Медведовского "DNS под прицелом". В статье описывались принципы атак с помощью ложных серверов DNS. Этот материал вызвал во многом скептические отклики специалистов, и прежде всего сомнению подвергались методы и форма реализации атак (подчеркивалась также надуманность примеров и неэффективность исполнения атак). Большинство приводимых доводов, в общем-то, небезосновательны (ниже мы поговорим о них более подробно), но в пылу критики все-таки не стоит забывать, что при определенных обстоятельствах атаки с использованием ложных серверов DNS могут оказаться очень опасными. Правда, Медведовский не представил методов борьбы с такими вторжениями. Более того, в переписке с редакцией он утверждает, что предотвратить атаки ложных серверов DNS практически невозможно.

На самом деле положение совсем не такое скверное. При грамотной политике безопасности вероятность вторжения можно значительно снизить. (Между прочим, критики статьи утверждают в противовес Медведовскому, что атаки на DNS легко обнаружить и обезвредить. Но это слишком большое упрощение ситуации.)

Целью данной публикации является обзор наиболее опасных видов атак на DNS, а также методов борьбы с ними.

НАСКОЛЬКО ОПАСНЫ АТАКИ НА DNS

Потенциальная возможность удаленных атак с использованием ложных серверов DNS известна давно. В литературе подобные атаки называют подменой DNS (DNS spoofing). Вместе с тем к их эффективности относятся весьма скептически. Так, в одном из самых авторитетных изданий по проблемам сетевой безопасности "Maximum Security. A Hacker's Guide to Protecting Your Internet Site and Network" издательства Sams.net Publishing, 1997 утверждается, что несмотря на опасность атаки типа подмены DNS реализовать ее крайне трудно. Кроме того, обнаружить и обезвредить атаку (а порой даже ее попытку) не так уж и сложно. К сожалению, это верно в общем случае, а в частностях все может быть совсем иначе.

Но давайте разберем примеры, приводимые Медведовским.

Наибольшие нарекания вызвало то обстоятельство, что клиент обращается к конфиденциальному серверу (обратите внимание на имя сервера - TOP.SECRET.COM) через Internet по обычным протоколам. Да, действительно весьма оригинально. Вот где хакерам развернуться-то. Даже подмену DNS использовать необязательно: есть ведь гораздо более простые и эффективные методы взлома.

Максимальную степень защиты может дать шифрование данных или применение протоколов с такими возможностями (к примеру, PPTP, SSL, S/MIME, SSH и т. д.), и именно их используют для обмена конфиденциальной информацией и для доступа к закрытым серверам как в локальных, так и в глобальных сетях (а совсем не протоколы telnet или ftp). Такие протоколы защищают не только от возможности подмены объектов, но даже от перлюстрации. Иногда применяют протоколы с подписью пакетов (например, протокол NCP в NetWare), но они, как правило, не предотвращают перлюстрацию, хотя и препятствуют несанкционированному доступу. При шифровании данных атаки типа подмены DNS или подмены IP-адресов будут практически безрезультатны.

Если же применять в глобальных сетях обычные протоколы (telnet, ftp, HTTP и т. п.), то об обмене конфиденциальной информацией или о доступе в удаленную систему с привилегированными полномочиями лучше забыть.

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

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

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

Иной тип атаки связан со "штормом" ложных ответов DNS. Особенность такой атаки в том, что ложный сервер DNS не располагается в цепочке клиент-настоящий сервер и не может перехватить запросы DNS. Поэтому он не знает ни адреса клиента, ни имени машины, адрес которой ищет клиент. Ложный сервер DNS не может даже предугадать время запроса. Вдобавок хакер имеет дело еще с целым рядом неизвестных, например с используемым протоколом, номером программного порта, с которого посылается запрос, и порядковым номером DNS-пакета при запросе.

В качестве объекта атаки обычно выбирается активный клиент сети. Ставка делается на то, что клиент будет пытаться связаться с каким-либо широко известным сервером, к примеру www.altavista.digital.com. Правда, даже если атака удастся, то в лучшем (для хакера) случае он сможет только изменить заставку сервера AltaVista на какую-нибудь скабрезную картинку. Методом простого перебора UDP-портов клиента и идентификаторов DNS-запросов ложный сервер DNS донимает потенциальную жертву "штормом" ложных ответов. Поскольку ложный сервер DNS в общем случае не знает, когда клиент обратится с DNS-запросом по конкретному узлу (в нашем примере www.altavista.digital.com), "шторм" ложных ответов должен продолжаться достаточно долго, чтобы атака была результативной. Кроме того, следует помнить, что корпоративная сеть всегда имеет несколько серверов DNS, причем приоритет их для клиента хакеру заранее не известен. Поэтому если цель атаки - проникновение внутрь корпоративной сети, то ложный сервер DNS должен генерировать ответы от имени всех серверов DNS сети, что приведет к резкому снижению производительности соединения локальная сеть-Internet на длительный промежуток времени. Администраторы могут достаточно быстро выявить попытку атаки посредством анализа трафика между локальной сетью и Internet.

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

Таким образом, если атакуется сервер DNS, то "подложная" информация будет распространяться среди его клиентов. К тому же путем несложных манипуляций можно определить, как долго та или иная информация (полученная с серверов имен других доменов) будет находиться в кэше сервера. Благодаря этому хакерам гораздо проще проводить атаки. В момент истечения времени кэширования информации хакер запускает на несколько секунд направленный "шторм" ложных ответов DNS на адрес атакуемого сервера DNS от имени сервера имен корневого домена. Опять же хакер обычно не знает, с какими узлами Internet работают станции корпоративной сети, и поэтому может ориентироваться лишь на распространенные серверы типа www.microsoft.com. Одновременно хакер посылает запрос к атакуемому серверу DNS с просьбой сообщить информацию по подменяемому объекту (www.microsoft.com), провоцируя сервер DNS обратиться к серверам корневого домена.

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

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

ЛОВЛЯ НА ЖИВЦА

Речь идет о приложениях, устанавливающих доверительные отношения на основе доменных имен хостов, а не паролей пользователей. К ним относятся NFS, NIS, SMTP, X, rsh, rlogin, rcp и отчасти ftp и rexec (когда задействованы конфигурационные файлы типа $HOME/.netrc). Если использовать упомянутые приложения даже исключительно внутри сети предприятия и не задействовать хорошо продуманную систему безопасности, то хакерам посредством атаки с подменой DNS достаточно просто получить доступ к сети извне.

Рассмотрим сеть, где отсутствуют средства безопасности и где используется сетевая файловая система NFS (Network File System) версии 2 (см. Рисунок 1). Эта версия широко распространена в мире UNIX-систем.

Когда на сервере NFS некая файловая система делается доступной для совместного использования в сети, то говорят, что она экспортируется. Чтобы обеспечить доступ к сетевой файловой системе, клиент NFS должен ее смонтировать (импортировать).

Сервер NFS при запросе на монтирование проверяет, имеет ли клиент необходимые полномочия, при этом сервер ориентируется на доменное имя клиента. Если клиент наделен необходимыми полномочиями, то ему сообщается некий ключ, который в дальнейшем используется при обращении к файловой системе. Ключ действителен до перезагрузки сервера NFS. Задача хакера - получить ключ. В случае, когда файловая система экспортируется с правами записи, и особенно с правами доступа привилегированного пользователя (root), хакер может натворить в ней немало бед.

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

1. Для атаки необходимо выбрать сеть, в которой используются UNIX-системы (NFS применяется чаще всего в UNIX). В качестве примера возьмем сеть company.COM.

2. С помощью программы nslookup, входящей во все серьезные ОС, на сервере имен зоны COM можно узнать доменные имена и IP-адреса серверов имен зоны company.COM.

3. Используя все ту же программу nslookup, необходимо переписать информацию по зоне company.COM с одного из серверов имен этой зоны. Таким образом хакер получит информацию по всем хостам данной зоны. Кроме того, он узнает значение поля записи SOA, которое так же, как значение поля у записей хостов, характеризует время кэширования данных DNS на клиентских машинах.

4. Поскольку есть вероятность, что в сети находятся скрытые серверы имен, о которых не знает сервер DNS зоны COM и которые не отражены в информации по зоне, следует опросить хосты на наличие демона named (порт 53 протоколов UDP и TCP). Все выявленные хосты являются серверами имен.

5. Теперь необходимо выявить серверы NFS, что делается путем опроса порта 2049 протокола UDP на хосте.

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

7. Для осуществления атаки необходимо написать программу, реализующую передачу ответа сервера DNS. Такая программа должна позволять менять адрес отправителя в IP-пакете.

8. Клиентов NFS гораздо сложнее обнаружить. Часто помогает внимательное изучение информации по зоне, в особенности записей HINFO. Если никакой дополнительной информации нет, можно выбрать хост наугад. Пусть это будет host.company.COM.

9. Периодически проверяя доступность выбранного клиента (host.company.COM) с помощью программы ping, можно определить график его работы. Лучше подобрать клиента, который отключается на выходные.

10. Атаку следует проводить с учетом значения времени кэширования данных на клиентских местах DNS (DNS, а не NFS!). Например, если время кэширования равно одним суткам, а клиент NFS отключился вечером в пятницу, то начиная с вечера субботы в кэш-памяти DNS сервера NFS отсутствует информация по данному клиенту NFS. При новом обращении к серверу NFS со стороны клиента NFS, первый для получения информации по клиенту NFS должен будет вновь обратиться к серверу DNS. Из этого следует, что чем меньше время кэширования, тем проще организовать атаку.

11. Теперь все готово для проведения атаки. Используя ложный клиент NFS (он выполняет роль приманки), следует дать команду на импортирование файловой системы с сервера NFS. Одновременно на несколько секунд необходимо организовать "шторм" ответов DNS со стороны ложного сервера DNS. Ложные ответы должны направляться на сервер NFS и содержать преобразование IP-адреса ложного клиента NFS в доменное имя истинного клиента NFS. Ложные ответы DNS упаковываются в IP-пакеты, у которых в качестве обратных адресов стоят IP-адреса серверов имен домена company.COM. Подбор UDP-портов и порядковых номеров DNS-пакетов с ответами можно выполнять по методике Медведовского.

12. Сервер NFS, получив запрос на монтирование сетевой файловой системы со стороны мнимого host.company.COM, посылает в свою очередь запрос серверу DNS, чтобы определить, что это за хост. Именно на основании этой информации сервер NFS оценивает полномочия хоста. Существует достаточно высокая вероятность того, что сервер NFS получит раньше не истинный, а ложный ответ DNS. Если хост host.company.COM не имеет права импортировать файловую систему, то следует выбрать другой хост и повторить все начиная с п. 8.

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

ЗАЩИТА ОТ АТАК НА DNS

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

Из-за открытости Internet ситуация там значительно сложнее. Поэтому применять ftp или telnet не стоит, даже когда просто осуществляется доступ к обычным ресурсам, но с привилегированными полномочиями (например, с правами на запись).

Если в корпоративной сети, подключенной к Internet, используются приложения и протоколы NFS, NIS, rcp, rlogin, rsh, то необходимо отрезать доступ по этим протоколам извне, что делается с помощью фильтра IP-пакетов на пограничном маршрутизаторе или брандмауэре. Вдобавок следует в обязательном порядке запретить применение тех приложений X и ftp, которые осуществляют аутентификацию только по доменному имени машины или имени пользователя. Желательно также ограничить одной-двумя машинами доступ извне корпоративной сети по протоколу SMTP. В отношении этих машин нужно предпринять повышенные меры безопасности.

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

Вот, так сказать, малый джентльменский набор рекомендаций. В полной мере против атак с подменой DNS он не спасает, как не спасает и установка самых мощных и дорогих брандмауэров.

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

Начиная с версии 4.9.3 в спецификацию BIND было внесено несколько директив и типов записей DNS, которые призваны несколько улучшить защиту серверов имен. Директива xfrnets файла начальной загрузки (/etc/named.boot) позволяет указать список IP-адресов сетей и серверов имен, на которые данный сервер имеет право пересылать информацию по зоне (операция зонной пересылки). Второе важное новшество - введение особого типа записи ресурсов TXT под названием SECURE_ZONE. Такая запись управляет перечнем машин и сетей (по IP-адресам), которым разрешено запрашивать данный сервер имен. Но несмотря на эти нововведения для отражения атак с подменой DNS требуется принять еще ряд мер.

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

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

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

В настоящее время на стадии утверждения в качестве стандарта Internet находится документ RFC 2065 "Domain Name System Security Extensions", в котором введены новые расширения DNS, такие как использование криптографической цифровой подписи. Планируется, что в следующем году спецификация DNS BIND v.8 будет включать поддержку RFC 2065 (реализации BIND для различных ОС свободно распространяются и доступны на сервере http://www.vix.com). Таким образом, отпадут практически все проблемы, связанные с безопасностью DNS.