Доменная система имен

Из анализа описанной схемы удаленного DNS-поиска становится очевидно, что в том случае если в ответ на запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае "шторма" ложных ответов будет вести их постоянную передачу), то в кэш-таблице сервера появится соответствующая запись с ложными сведениями, и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, и при обращении к хосту, маршрут к которому атакующий решил изменить, связь с ним будет осуществляться через хост атакующего по схеме "Ложный объект РВС". И с течением времени эта ложная информация, попавшая в кэш DNS-сервера, будет распространяться на соседние DNS-серверы высших уровней. Межсегментная удаленная атака на DNS-сервер Значительно более общим случаем является межсегментная атака, не требующая для своей реализации столь жестких условий, когда атакующий и целевой DNS-сервер разделяют общую физическую среду передачи [3]. Рис. 7. Межсегментная удаленная атака Межсегментная атака на DNS-сервер выглядит следующим образом. Предположим для определенности, что целью атаки является "подмена" IP-адреса web-сервера www.coolsite.com на IP-адрес сервера www.badsite.com для пользователей некоторой подсети, которую обслуживает DNS-сервер ns.victim.com. В первой фазе атаки ns.victim.com провоцируется на поиск информации о IP-адресе www.coolsite.com путем посылки ему соответствующего рекурсивного запроса. Во второй фазе атакующий посылает серверу ns.victim.com ложный ответ от имени ns.coolsite.com, который является ответственным за домен coolsite.com. В ложном ответе вместо реального IP-адреса www.coolsite.com указывается IP-адрес www.badsite.com. Сервер ns.victim.com кэширует полученную информацию, в результате чего в течении определенного промежутка времени (величина этого промежутка указывается в поле TTL ложного ответа и может произвольно выбираться атакующим) ничего не подозревающие пользователи вместо сервера www.coolsite.com попадают на www.badsite.com (рис. 7). Для того, чтобы ложный ответ был воспринят сервером ns.victim.com как истинный, достаточно выполнения четырех условий: ·IP адрес отправителя ответа должен соответствовать IP-адресу запрашиваемого сервера (в данном случае ns.coolsite.com); ·UDP-порт, на который направляется ответ, должен совпадать с портом, с которого был послан запрос; ·идентификатор ответа должен совпадать с идентификатором запроса; ·ответ должен содержать запрашиваемую информацию (в данном случае IP-адрес web-сервера www.coolsite.com). Очевидно, что выполнение первого и четвертого условий не представляет для атакующего особых трудностей. Со вторым и третьим условиями ситуация намного сложнее, поскольку в случае межсегментной атаки у атакующего нет возможности перехватить исходный запрос и "подсмотреть" необходимые параметры. Ошибочные действия администратора DNS-сервера Ошибочные действия администратора DNS-сервера, т.е. неправильное указанию соответствия IP-адреса хоста и его имени, могут привести к распространению ошибки на другие DNS-сервера. Следовательно при обращении к DNS-серверу, он будет выдавать неправильный IP-адрес искомого хоста. Как видно из раздела – в сети существует достаточно проблем связанных с корректностью функционирования DNS-службы, и это довольно серьезные проблемы, которые могут сильно осложнить работу пользователей и сетевых администраторов. В следующем разделе будут рассмотрены некоторые современные решения и советы для избежания этих проблем. Некоторые решения проблем функционирования DNS-службы Оптимальным с точки зрения безопасности решением будет вообще отказаться от использования службы DNS в защищаемом сегменте. Конечно, совсем отказаться от использования имен при обращении к хостам для пользователей будет очень не удобно. Поэтому можно предложить следующее компромиссное решение: использовать имена, но отказаться от механизма удаленного DNS-поиска, использовавшегося до появления службы DNS с выделенными DNS-серверами. Тогда на каждой машине в сети существовал hosts файл, в котором находилась информация о соответствующих именах и IP-адресах всех хостов в сети. Очевидно, что на сегодняшний день администратору можно внести в подобный файл информацию о лишь наиболее часто посещаемых пользователями данного сегмента серверах сети. Рис 8. Внутренний сервер DNS обслуживает корпоративную сеть и не виден извне. Внешний сервер DNS предоставляет только часть информации о сети. Для затруднения осуществления удаленной атаки можно предложить администраторам использовать для службы DNS вместо протокола UDP, который устанавливается по умолчанию, протокол TCP (хотя из документации далеко не очевидно, как его сменить). Это существенно затруднит для атакующего передачу на хост ложного DNS-ответа без приема DNS-запроса. Так же можно предложить использовать комплект приложений BIND (Berkley Internet Name Daemon) – берклевский демон имен Internet. Начиная с версии 4.9.3 в спецификацию BIND было внесено несколько директив и типов записей DNS, которые призваны несколько улучшить защиту серверов имен. Директива xfrnets файла начальной загрузки (/etc/named.boot) позволяет указать список IP-адресов сетей и серверов имен, на которые данный сервер имеет право пересылать информацию по зоне (операция зонной пересылки). Второе важное новшество - введение особого типа записи ресурсов TXT под названием SECURE_ZONE. Такая запись управляет перечнем машин и сетей (по IP-адресам), которым разрешено запрашивать данный сервер имен. Но несмотря на эти нововведения для отражения атак с подменой DNS требуется принять еще ряд мер. Среди них наиболее распространенной является установка двух серверов DNS: внешнего и внутреннего (см. Рис. 8). Внутренний сервер DNS предназначен исключительно для обслуживания внутренних клиентов сети. На нем хранится вся информация о хостах корпоративной сети. Благодаря использованию записей типа SECURE_ZONE этот сервер могут запрашивать только внутренние хосты. Более того, на брандмауэре устанавливается фильтр, который не пропускает IP-пакеты, направляемые в корпоративную сеть и предназначенные для порта 53 протоколов UDP и TCP внутреннего сервера DNS. Т. е. снаружи такой сервер DNS делается невидимым. Однако он сам может обращаться за информацией к серверам DNS сети Internet Последняя версия BIND 8.2.2. включает в себя поддержку (RFC 2065) криптографической цифровой подписи, т.е. это уже не стандартный DNS –протокол, а расширенный, в котором в тело DNS-запроса будет включаться цифровая подпись. Это решение практически полностью обезопасит работу с DNS-службой. К сожалению, желаемый результат может дать только широкомасштабное внедрение новых протоколов, которое сопряжено со значительными организационными трудностями и не может быть проведено за короткое время.

Отправить комментарий

Проверка
Антиспам проверка
Image CAPTCHA
...