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

Из анализа механизмов адресации, описанных выше, становится ясно: так как поисковый ARP-запрос кроме атакующего получит и маршрутизатор, то в его таблице окажется соответствующая запись об IP-и Ethernet-адресе атакуемого хоста. Следовательно, когда на маршрутизатор придет пакет, направленный на IP-адрес атакуемого хоста, он будет передан не на ложный ARP-сервер, а непосредственно на хост. При этом схема передачи пакетов в этом случае будет следующая:

1. Атакованный хост передает пакеты на ложный ARP-сервер.

2. Ложный ARP-сервер посылает принятые от атакованного хоста пакеты на маршрутизатор.

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

В этом случае последняя фаза, связанная с приемом, анализом, воздействием на пакеты обмена и передачей их между атакованным хостом и, например, маршрутизатором (или любым другим хостом в том же сегменте) будет проходить уже не в режиме полного перехвата пакетов ложным сервером (мостовая схема), а в режиме «полуперехвата» (петлевая схема). Действительно, в режиме полного перехвата маршрут всех пакетов, отправляемых как в одну, так и в другую сторону, обязательно проходит через ложный сервер (мост); в режиме «полуперехвата» маршрут пакетов образует петлю (рис. 4.4). Петлевой маршрут может возникнуть и при рассмотренной ниже атаке на базе протоколов DNS и ICMP.

Рис. 4.4. Петлевая схема перехвата информации ложным АRP-сервером

Однако придумать несколько способов, позволяющих ложному ARP-серверу функционировать по мостовой схеме перехвата (полный перехват), довольно просто. Например, получив ARP-запрос, можно самому послать такое же сообщение и присвоить себе данный IP-адрес (правда, в этом случае ложному ARP-серверу не удастся остаться незамеченным: некоторые сетевые ОС, например Windows 95 и SunOS 5.3, перехватив такой запрос, выдадут предупреждение об использовании их IP-адреса). Другой, значительно более удобный способ – послать ARP-запрос, указав в качестве своего IP-адреса любой свободный в данном сегменте IP-адрес, и в дальнейшем вести работу с данного IP-адреса как с маршрутизатором, так и с «обманутыми» хостами (кстати, это типичная proxy-схема).

Заканчивая рассказ об уязвимостях протокола 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 – доменная система имен).

Читать дальше