Илья Медведовский - Атака на Internet Страница 18

Заканчивая рассказ об уязвимостях протокола ARP, покажем, как различные сетевые ОС используют этот протокол для изменения информации в своих ARP-таблицах.

Исследования различных сетевых ОС выявили, что в ОС Linux при адресации к хосту, находящемуся в одной подсети с данным хостом, ARP-запрос передается, если в ARP-таблице отсутствует соответствующая запись о Ethernet-адресе, и при последующих обращениях к данному хосту ARP-запрос не посылается. В SunOS 5.3 при каждом новом обращении к хосту (в том случае, если в течение некоторого времени обращения не было) происходит передача ARP-запроса, и, следовательно, ARP-таблица динамически обновляется. ОС Windows 95 при обращении к хостам, с точки зрения использования протокола ARP, ведет себя почти так же, как и ОС Linux, за исключением того, что периодически (каждую минуту) посылает ARP-запрос о Ethernet-адресе маршрутизатора; в результате в течение нескольких минут вся локальная сеть с Windows 95 без труда берется под контроль ложным ARP-сервером. ОС Windows NT 4.0 также использует динамически изменяемую ARP-таблицу, и ARP-запросы о Ethernet-адресе маршрутизатора передаются каждые 5 минут.

Особый интерес вызвал следующий вопрос: можно ли осуществить данную удаленную атаку на UNIX-совместимую ОС CX/LAN/SX, защищенную по классу B1 (мандатная и дискретная сетевая политики разграничения доступа плюс специальная схема функционирования SUID/SGID процессов), установленную на двухпроцессорной мини-ЭВМ? Эта система является одним из лучших в мире полнофункциональных межсетевых экранов (МЭ) CyberGuard 3.0 (мы тестировали этого «монстра» в 1996 году). В процессе анализа защищенности этого МЭ относительно удаленных воздействий, осуществляемых по каналам связи, выяснилось, что в случае базовой (после всех стандартных настроек) конфигурации ОС защищенная UNIX-система также поражается ложным ARP-сервером (что, в общем, было вполне ожидаемым).

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

Ложный DNS-сервер в сети Internet

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

На самом раннем этапе развития Internet именно для удобства пользователей было принято решение присвоить всем компьютерам в Сети имена. Использование имен помогает лучше ориентироваться в киберпространстве Internet: запомнить, например, имя www.ferrari.it пользователю куда проще, чем четырехразрядную цепочку IP-адреса. Употребление в Internet мнемонически удобных и понятных пользователям имен породило проблему преобразования имен в IP-адреса. Такое преобразование необходимо, так как на сетевом уровне адресация пакетов идет не по именам, а по IP-адресам, следовательно, для непосредственной адресации сообщений в Internet имена не годятся. Сначала, когда в сеть Internet было объединено небольшое количество компьютеров, NIC (Network Information Center) для решения проблемы преобразования имен в адреса создал специальный файл (hosts file), в который вносились имена и соответствующие им IP-адреса всех хостов в Сети. Этот файл регулярно обновлялся и распространялся по всей Сети. Но, по мере развития Internet, число объединенных в Сеть хостов увеличивалось и такая схема становилась все менее и менее работоспособной. На смену ей пришла новая система преобразования имен, позволяющая пользователю получить необходимые сведения о соответствии имен и IP-адресов от ближайшего информационно-поискового сервера (DNS-сервера). Этот способ решения проблемы получил название Domain Name System (DNS – доменная система имен).

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

Поясним основную задачу, решаемую службой DNS. В современной сети Internet хост (имеется в виду клиентская часть DNS, называемая resolver) при обращении к удаленному серверу обычно знает его имя, но не IP-адрес, который необходим для непосредственной адресации. Следовательно, перед хостом возникает стандартная задача удаленного поиска: по имени удаленного хоста найти его IP-адрес. Решением этой задачи и занимается служба DNS на базе протокола DNS.

Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети Internet.

...

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

1. Хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается при настройке сетевой ОС) DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти.

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

Анализируя уязвимость этой схемы удаленного поиска, можно прийти к выводу, что в сети, использующей протокол DNS, возможно осуществление типовой удаленной атаки «ложный объект РВС». Практические изыскания и критический анализ безопасности службы DNS позволяют предложить три возможных варианта удаленной атаки на эту службу.

Перехват DNS-запроса

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

Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и использование протокола TCP), что, естественно, делает ее менее защищенной, так как протокол UDP (в отличие от TCP) вообще не предусматривает средств идентификации сообщений. Для того чтобы перейти от UDP к TCP, администратору DNS-сервера придется очень серьезно изучить документацию (в стандартной документации на демон named в ОС Linux нет никакого упоминания о возможном выборе протокола, на котором будет работать DNS-сервер). Этот переход несколько замедлит систему, так как при использовании TCP требуется создание виртуального соединения, кроме того, конечная сетевая ОС вначале посылает DNS-запрос с использованием протокола UDP, и только в том случае, если придет специальный ответ от DNS-сервера, она пошлет следующий запрос с использованием TCP.

Во-вторых, начальное значение поля «порт отправителя» в UDP-пакете ≥ 1023 и увеличивается с каждым переданным DNS-запросом.

В-третьих, значение идентификатора (ID) DNS-запроса устанавливается следующим образом. В случае передачи DNS-запроса с хоста оно зависит от конкретного сетевого приложения, вырабатывающего DNS-запрос. Эксперименты показали, что если запрос посылается из оболочки командного интерпретатора (SHELL) операционных систем Linux и Windows 95 (например, ftp nic.funet.fi), то это значение всегда равняется единице. Если же DNS-запрос передается из Netscape Navigator или его посылает непосредственно DNS-сервер, то с каждым новым запросом сам браузер или сервер увеличивает значение идентификатора на единицу. Все эти тонкости имеют значение в случае атаки без перехвата DNS-запроса.