Для чего используется создание ложного маршрутизатора
Навязывание хосту ложного маршрута с помощью протокола ICMP для создания в сети ложного маршрутизатора.
Маршрутизация в сети Internet играет важнейшую роль для обеспечения нормального функционирования сети. Маршрутизация в сети Internet осуществляется на сетевом уровне (IP-уровень). Для ее обеспечения в памяти сетевой ОС каждого хоста существуют таблицы маршрутизации, содержащие данные о возможных маршрутах. Каждый сегмент сети подключен к глобальной сети Internet через как минимум один маршрутизатор, а, следовательно, все ЭВМ в этом сегменте и маршрутизатор должны физически находится в одном сегменте. Поэтому, все пакеты, адресованные в другие сегменты сети, направляются на маршрутизатор, который, в свою очередь, перенаправляет их далее по указанному в пакете IP-адресу, выбирая при этом оптимальный маршрут. Напомним, что в сети Internet для выбора оптимального маршрута используются специальные протоколы маршрутизации: RIP, OSPF. Рассмотрим, что представляет из себя таблица маршрутизации хоста. В каждой строке этой таблицы содержится описание соответствующего маршрута. Это описание включает: IP-адрес конечной точки маршрута (Destination), IP-адрес соответствующего маршрутизатора (Gateway), а также ряд других параметров, характеризующих этот маршрут. Обычно в системе существует так называемый маршрут по умолчанию (поле Destination содержит значение 0.0.0.0, а поле Gateway — IP-адрес маршрутизатора). Этот маршрут означает, что все пакеты, адресуемые на IP-адрес вне пределов данной подсети, будут направляться по указанному по умолчанию маршруту, то есть, на маршрутизатор (это реализуется установкой в поле адреса назначения в Ethernet-пакете аппаратного адреса маршрутизатора).
Как говорилось ранее, в сети Internet существует управляющий протокол 1СМР, одной из функций которого является удаленное управление маршрутизацией на хостах внутри сегмента сети. Это необходимо для предотвращения возможной посылки пакетов по неоптимальному маршруту. В сети Internet удаленное управление маршрутизацией реализовано в виде передачи с маршрутизатора на хост управляющего IСМР-сообщения Redirect Message. Изучение протокола IСМР показало, что сообщение Redirect бывает двух типов. Первый тип сообщения носит название Redirect Net и уведомляет хост о необходимости смены адреса маршрутизатора, то есть, по умолчанию маршрута. Второй тип — Redirect Host информирует хост о необходимости создания нового маршрута к указанному в сообщении хосту и внесения его в таблицу маршрутизации. Для этого в этом сообщении указывается IP-адрес хоста, для которого необходима смена маршрута (адрес будет занесен в поле Destination), и IP-адрес маршрутизатора, на который необходимо направлять пакеты, адресованные данному хосту (этот адрес заносится в поле Gateway).
Анализ исходных текстов ОС Linux 1.2.8 показал, что, во-первых, IСМР-сообщение Redirect Net игнорируется данной ОС (это представляется логичным, следовательно, можно сделать вывод, что его игнорируют и другие сетевые ОС), а, во-вторых, единственный параметр, идентифицирующий сообщение IСМР Redirect Host — это IP-адрес отправителя, который должен совпадать с IP-адресом маршрутизатора, так как, это сообщение может передаваться только маршрутизатором.
Для осуществления этой удаленной атаки необходимо подготовить ложное ICMP-сообщение Redirect Host, в котором указать конечный IP-адрес маршрута (Destination) и IP-адрес ложного маршрутизатора. Далее, это сообщение посылается на атакуемый хост от имени маршрутизатора. Для этого в IP-заголовке в поле адреса отправителя указывается IP-адрес маршрутизатора. После этого весь трафик между атакуемым хостом и интересующим атакующего сервером оказывается под контролем на ложном маршрутизаторе и атака перейдет во вторую стадию, связанную с приемом, анализом и передачей пакетов, получаемых от обманутых хостов. Данная стадия атаки полностью совпадает со второй стадией типовой атаки ложный сервер. Рассмотрим схему осуществления второй стадии атаки, связанной с приемом и передачей пакетов на ложном маршрутизаторе:
— если пришел ARP-запрос от атакуемого хоста, то посылается ARP-ответ;
— если пришел пакет от атакуемого хоста, то он переправляется на настоящий маршрутизатор;
— если пришел пакет от маршрутизатора, то он переправляется на атакуемый хост;
— при приеме пакета возможно воздействие на информацию по схеме ложный сервер.
Данная удаленная атака была осуществлена на практике на примере ОС Linux 1.2.8 и ОС Windows 95 и показала своя работоспособность.
Атаки на уровне сетевого программного обеспечения
Сетевое программное обеспечение (СПО) является наиболее уязвимым,потому чтоканал связи, по которому передаются сообщения, чаще всего не защищен, и всякий, кто может иметь доступ к этому каналу, соответственно может перехватывать сообщения и отправлять свои собственные.
Поэтому на уровне СПО возможны следующие методы НСД:
— прослушивание сегмента локальной сети;
— перехват сообщений на маршрутизаторе;
— создание ложного маршрутизатора;
— навязывание сообщений (отправляя в сеть сообщения с ложным обратным сетевым адресом, злоумышленник переключает на свой компьютер уже установленные сетевые соединения и в результате получает права пользователей);
— отказ в обслуживании (при отправлении в сеть сообщения специального вида компьютерные системы, подключенные к сети, полностью или частично выходят из строя).
Для противодействия указанным методам НСД следует максимально защитить каналы связии тем самым затруднить обмен информацией по сети для тех, кто не является легальным пользователем.
Программные закладки
— общесистемные программные средства,
— и аппаратные средства информационных и телекоммуникационных систем.
Существуют три основные группы деструктивных действий, которые могут осуществляться программными закладками:
— копирование информации пользователя компьютерной системы (паролей, криптографических ключей, кодов доступа, конфиденциальных электронных документов), находящейся в оперативной или внешней памяти этой системы либо в памяти другой компьютерной системы, подключенной к ней через локальную или глобальную компьютерную сеть;
— изменение алгоритмов функционирования системных, прикладных и служебных’ программ;
— навязывание определенных режимов работы (например, блокирование записи на диск при удалении информации, при этом информация, которую требуется удалить, не уничтожается и может быть впоследствии скопирована).
Защищаем сеть L2 коммутаторами
Доброго времени суток. В данной статье рассказ пойдет о нескольких возможных атаках на сетевое оборудование, защититься от которых поможет правильная конфигурация коммутаторов.
Вся терминология и конфигурационные команды приведены в соответствии с документацией компании Cisco, как негласный отраслевой стандарт. В начале описания каждой атаки содержится краткий экскурс в механизм работы атакуемого протокола. Рассчитана статья скорее на новичков, чем на сетевиков-профессионалов.
• Rogue DHCP Server
• DHCP starvation
• CAM-table overflow
• VLAN hopping
• MAC-spoofing
За основу взят видеоурок CBT nuggets из цикла CCNA security.
Rogue DHCP Server
Описание
Приведем упрощенную схему работы протокола DHCP:
Discover: клиент, не имеющий IP-адреса, посылает широковещательный запрос на адрес 255.255.255.255, в котором просит откликнуться имеющиеся в сети DHCP-серверы.
Offer: DHCP-серверы присылают ответ, в котором предлагают параметры конфигурации (IP-адрес, DNS-серверы, default gateway). Ответ отсылается на MAC адрес клиента.
Request: Клиент выбирает, с каким сервером (при наличии нескольких) ему удобнее работать и отправляет запрос адреса. Данный запрос также отправляется широковещательно, но в качестве одной из опций уже указывается IP-адрес конкретного сервера.
Acknowledgment: На данном этапе запрос подтверждается сервером. После получения этого пакета клиент конфигурирует свои сетевые параметры и процесс получения адреса можно считать состоявшимся.
Цель данной атаки – подмена DHCP-сервера. При одновременном нахождении в сети двух DHCP-серверов, один из которых «вражеский», некоторая часть клиентов сконфигурирует у себя неправильные адреса и прочие сетевые реквизиты.
Вследствие подмены шлюза по умолчанию неавторизованный DHCP-сервер получит возможность прослушивать весь трафик клиентов, перенаправляя в дальнейшем пакеты по назначению. Таким образом мы имеем простейшую реализацию атаки типа MitM (Man in the Middle), которая может быть осуществлена в большинстве современных сетей.
Стоит отметить, что чаще всего атака с подменой DHCP-сервера не является атакой, как таковой. Распространены случаи, когда по незнанию в сеть подключается SOHO роутер с настроенным DHCP-сервером, причем подключается он LAN-портом. После этого у клиентов, успевших получить у него IP-адреса, наблюдаются как минимум существенные потери скорости, а чаще всего полная невозможность использования локальных и глобальных ресурсов.
Методы защиты
Простейший способ защиты от атак подобного рода – включение на всех коммутаторах функции DHCP snooping. Далее необходимо определить два типа портов:
• Доверенные – порты коммутатора, к которым подключается DHCP-сервер, либо другой коммутатор.
• Недоверенные – порты для клиентских подключений, за которыми DHCP-сервер находиться не может, зато вполне может находиться атакующее устройство.
В данном случае DHCP snooping необходим для того, чтобы указать коммутатору, что следует обращать внимание на пакеты DHCP offer и acknowledgment, проходящие сквозь него, и не допускать прохождения данных пакетов с недоверенных портов. Также широковещательные запросы от клиента (discover и request) теперь будут перенаправляться только на доверенные порты. Выглядеть топология должна примерно так:
Для конфигурирования функции DHCP snooping необходимо:
1) Включить ее на коммутаторе:
SW(config)#ip dhcp snooping
2) Указать для каких VLAN требуется отслеживать пакеты:
SW(config)#ip dhcp snooping vlan
3) Указать доверенные порты на коммутаторе (все остальные по умолчанию становятся недоверенными):
SW(config-if)#ip dhcp snooping trust
Спасти трафик от прослушки также может шифрование на стороне клиента, например туннелирование в транспортном режиме.
DHCP starvation
Описание
Еще одна атака, осуществляемая при помощи протокола DHCP. DHCP-пул, из которого клиенты получают IP-адреса, ограничен. Например, это может быть 253 адреса (при маске 255.255.255.0). Для нормальной работы сети этого должно хватить всем клиентам, но атака DHCP starvation стремится изменить данную ситуацию. Как происходит действие:
1) Атакующее устройство запрашивает себе IP-адрес у DHCP-сервера и получает его;
2) MAC-адрес атакующего устройства изменяется и оно запрашивает следующий, уже другой IP-адрес, маскируясь под нового клиента;
3) Такие действия повторяются до тех пор, пока весь пул IP-адресов на сервере не будет исчерпан.
Далее возможны два последствия, в зависимости от того, что является целью атаки:
• Отказ в обслуживании. IP-адреса исчерпаны, и новые хосты не могут получить их. Таким образом, их взаимодействие с сетью на этом закончится.
• Подмена DHCP-сервера. DHCP starvation отлично комбинируется с предыдущей атакой. Так как на основном DHCP-сервере свободных адресов не осталось, он выбывает из игры, и 100% клиентов достается вражескому атакующему DHCP-серверу.
Методы защиты
Самый простой способ защиты – ограничение числа MAC-адресов на порту коммутатора. Реализуется это с помощью функции port-security:
1) Переводим порт в access режим:
SW(config-if)#switchport mode access
2) Включаем port-security на интерфейсе:
SW(config-if)#switchport port-security
3) Ограничиваем число MAC-адресов на интерфейсе:
SW(config-if)switchport port-security maximum
4) Выбираем способ изучения MAC-адресов коммутатором (статический, sticky): Отличие статического адреса от sticky адреса состоит в том, что статические адреса необходимо прописывать руками, а sticky выучиваются автоматически и сохраняются в конфигурационный файл.
SW(config-if)#switchport port-security mac-address
5) Задаем тип реагирования на превышение числа разрешенных MAC-адресов:
protect – после переполнения все пакеты, отправленные с других MAC-адресов отбрасываются.
restrict – то же самое, но с уведомлением в syslog или по SNMP.
shutdown – порт выключается до автоматического или ручного его поднятия, также отправляются уведомления.
SW(config-if)#switchport port-security violation
Таким образом атакующее устройство просто не сможет исчерпать лимит IP-адресов DHCP-пула, так как коммутатор не позволит ему безнаказанно изменять свой MAC-адрес.
Также здесь может помочь все тот же DHCP snooping, а именно команда
SW(config-if)ip dhcp snooping limit rate
Данная команда ограничивает количество DHCP пакетов в секунду на порт (рекомендуется не более 100 pps), а при превышении данного ограничения переводит порт в состояние err-disable, то есть временно выключает его. Обычный клиент не превысит данный лимит, а вот атакующее устройство, генерирующее сотни MAC-адресов в секунду, будет обнаружено.
СAM-table overflow
Описание
Для того, чтобы понять, как работает данная атака, необходимо понимать принцип работы коммутатора.
Представим новый коммутатор SW, к которому подключены два хоста PC1 (MAC 0000.1111.1111) и PC2 (MAC 0000.2222.2222). На них уже настроены IP-адреса (10.0.0.1 и 10.0.0.2) и они хотят общаться друг с другом. Так как они располагаются в одной подсети, наличие маршрутизатора не требуется и весь обмен пакетами будет происходить с помощью коммутатора. Итак, какова последовательность установления их общения:
1) PC1 хочет обратиться к PC2 по IP-адресу. Тем не менее MAC-адрес PC2 ему неизвестен, поэтому PC1 использует протокол ARP. Отправляется широковещательный запрос: «Компьютер с IP-адресом 10.0.0.2, сообщите пожалуйста свой MAC-адрес компьютеру с адресом 10.0.0.1, чтобы я мог общаться с вами».
2) Коммутатор пересылает запрос на все свои порты, но записывает соответствие MAC-адреса отправителя (0000.1111.1111) и порта, теперь все кадры, адресованные данному получателю он будет пересылать непосредственно, а не наугад во все доступные интерфейсы.
3) PC2 получает адресованный ему пакет, понимает что должен ответить, и сообщает свой MAC-адрес PC1. Коммутатор при этом заносит в CAM-таблицу (таблицу MAC-адресов) запись вида: (интерфейс gig1/2 – MAC 0000.2222.2222). Теперь, когда компьютеры будут обмениваться информацией, задействоваться будут только два порта, за которыми они расположены. На другие информация пересылаться не будет.
Основной смысл в том, что если коммутатор видит адрес получателя в своей CAM-таблице, он пересылает кадр в конкретный порт. Если не видит – устраивает широковещательную рассылку, в надежде, что кадр все-таки найдет адресата.
На основании этого правила и работает рассматриваемая атака. Дело в том, что размер таблицы MAC-адресов у любого коммутатора ограничен. При переполнении новые адреса реальных клиентов уже не смогут пробиться в таблицу.
Таким образом необходимо всего лишь сгенерировать большое количество адресов и заставить коммутатор записать их в свою таблицу, чтобы реальные адреса реальных устройств постепенно вышли из нее. В таком случае коммутатор начнет, рассылать кадры, адресованные конкретному получателю на все порты, находящиеся в том же VLAN, следовательно у атакующего устройства появится возможность перехватить и прочитать их.
Следует заметить, что все коммутаторы, подключенные к атакованному также подхватят фальшивые MAC-адреса и начнут вести широковещательную рассылку всех кадров.
Методы защиты
1) Port-security на всех access-портах с лимитированием максимального количество MAC-адресов.
2) Шифрование трафика – в таком случае хоть все кадры и будут рассылаться широковещательно, а производительность сети сильно ухудшится, информация, попавшая в чужие руки, не будет прочитана.
VLAN hopping
Описание
Немного теории о том, чем access порт отличается от trunk порта:
Как известно, протокол 802.1Q повсеместно используется во всех современных сетях. Суть его состоит в том, что он слегка расширяет ethernet кадр, добавляя туда несколько полей (в частности поле VLAN Identifier, VID). На основании данного поля коммутатор способен определить, какой группе портов адресован тот или иной кадр.
Благодаря полю VID, к одному коммутатору можно подключить клиентов из нескольких разных подсетей, тем самым ограничив широковещательный домен. Также появляется возможность объединить клиентов, подключенных к разным коммутаторам в одну логическую сеть.
1) PC1 подключен к access-порту fa2/1 коммутатора SW1 в 10 VLAN’е. Это означает, что при попадании кадра на порт коммутатора, в него будет добавлен 802.1Q header с информацией о принадлежности к VLAN10.
2) SW1 пересылает тегированный кадр на SW2 через trunk-порт.
3) SW2 получает кадр, смотрит в свою CAM-таблицу и отправляет кадр в соответствующий access-порт, заголовок 802.1Q снимается.
При этом можно выделить следующие особенности:
• Клиенты ничего не знают о своей принадлежности к определенному VLAN и работают с нетегированными кадрами, заголовок 802.1Q появляется только при прохождении кадра через access-порт;
• Порт может быть нетегирован (access) только в одном VLAN (верно для коммутаторов Cisco);
• Через тегированный (trunk) порт можно передавать кадры, принадлежащие к разным VLAN.
• Существует так называемый native VLAN – при попадании на trunk-порт кадра без тега, он автоматически будет причислен к native VLAN. Как правило native VLAN’ом по умолчанию считается VLAN1 (изменяемо).
При этом кадры, принадлежащие native VLAN и попавшие в access-порт, передаваться через trunk-порт будут без тега.
Перейдем к самой атаке:
Как уже было сказано, VLAN hopping основан на том, что коммутаторы имеют возможность автоматически согласовывать тип порта. Используется для этого проприетарный протокол компании Cisco DTP (Dynamic Trunking Protocol). При его использовании (а он включен по умолчанию) возможны следующие состояния порта: dynamic auto, dynamic desirable, static access, static trunk. Предоставим сводную таблицу, как согласуются состояния двух портов, подключенных друг к другу:
Как мы видим, при определенных условиях, а именно в режимах dynamic auto и dynamic desirable порт коммутатора может согласовать свою работу в режиме trunk. Это значит, что если атакующее устройство будет вести себя как порт в режиме desirable оно согласует на себя trunk-порт и получит доступ к трафику всех VLAN’ов, которыми оперирует коммутатор.
Основная проблема заключается в том, что на коммутаторах Cisco все порты по умолчанию находятся в режиме auto. Поэтому даже если порт настроен в режиме access/auto при получении запроса на согласование его состояние может измениться на trunk/auto.
Методы защиты
Решение данной проблемы очень простое, но многие при конфигурировании коммутаторов забывают его использовать. Командой
SW(config-if)#switchport nonegotiate
мы просто отключаем возможность автоматического согласования и делаем атаку нереализуемой.
Описание
Еще один возможный вектор атаки VLAN hopping – использование native VLAN и добавление второго тега. Работает он только в том случае, если атакующее устройство находится в том VLAN, который является native VLAN для trunk-порта.
Исходя из определения native VLAN, кадр, пришедший на порт fa2/1, находящийся в VLAN1, будет передаваться через trunk-порт нетегированным, но, так как злоумышленник PC1 присвоил ему два заголовка, на выходе он окажется с тегом VLAN2 и дойдет до атакуемого клиента, чего при нормальной ситуации быть не должно.
Следует заметить, что такая атака является однонаправленной, так как невозможно по такой же схеме передать кадр обратно.
Методы защиты
Защититься можно следующим образом:
Назначаем на всех trunk-портах неиспользуемый VLAN в качестве native.
SW(config-if)# switchport trunk native vlan 999
Теперь атака неосуществима, так как VLAN 999 не относится ни к одному из access-портов.
MAC-Spoofing
Описание
Суть данной атаки заключается в подмене MAC-адреса на сетевой карте компьютера, что позволяет ему перехватывать пакеты, адресованные другому устройству, находящемуся в том же широковещательном домене.
В таблице MAC-адресов коммутатора запись с атакованным MAC-адресом будет соотнесена с интерфейсом, на котором в последний раз был идентифицирован кадр с данным source MAC. Таким образом, до поступления кадра с атакуемого устройства, все данные коммутатор, на основании своей CAM-таблицы, будет пересылать на атакующий компьютер.
Посмотрим атаку на практике. Использовать будем следующую топологию:
Добиться воспроизведения не удалось, т.к. коммутатор при включении порта на PC2 сразу перебивал MAC на интерфейс Eth0/1, и даже при пинге с PC1 на R в дебаге на SW наблюдалась такая картина:
Практически сразу после того, как пакет с MAC-адресом приходил с интерфейса Eth0/0 коммутатор вновь привязывал данный MAC к интерфейсу Eth0/1. Объяснение этому можно найти здесь:
SW# debug ethernet interface
Связано это, как я понимаю, с реализацией эмулятора IOU и является своеобразным аналогом keepalive сообщений. Как видно, обмен пакетами с интерфейсом Eth0/1 происходит позже, чем с интерфейсом Eth0/0, соответственно, в CAM-таблицу всегда попадает Eth0/1.
На реальных коммутаторах возможности опробовать атаку не появилось, но по сообщениям из достоверных источников она работает.
Методы защиты
Официально рекомендуемый метод – включение port-security на интерфейсе коммутатора:
SW(config-if)#switchport mode access
SW(config-if)#switchport port-security
SW(config-if)#switchport port-security mac-address 0000.1111.1111
Смотрим на таблицу:
И видим, что теперь MAC-адрес статически закреплен за интерфейсом Eth0/0. Теперь PC2, находящийся за портом Eth0/1 недоступен, и атаку можно считать отбитой.
Для чего используется создание ложного маршрутизатора
Как уже подчеркивалось в п. 3.2.3.1, маршрутизация в сети Internet играет важнейшую роль для обеспечения нормального функционирования сети. Маршрутизация в Internet осуществляется на сетевом уровне (IP-уровень). Для ее обеспечения в памяти сетевой ОС каждого хоста существуют таблицы маршрутизации, содержащие данные о возможных маршрутах. Каждый сегмент сети подключен к глобальной сети Internet как минимум через один маршрутизатор, а, следовательно, все хосты в этом сегменте и маршрутизатор должны физически располагаться в одном сегменте. Поэтому все сообщения, адресованные в другие сегменты сети, направляются на маршрутизатор, который, в свою очередь, перенаправляет их далее по указанному в пакете IP-адресу, выбирая при этом оптимальный маршрут. Напомним, что в сети Internet для выбора оптимального маршрута используются специальные протоколы маршрутизации: RIP, OSPF и т. д.
Анализ исходных текстов ОС Linux 1.2.8 показал, что ICMP-сообщение Redirect Net игнорируется данной ОС (это представляется логичным, так как динамическая смена маршрутизатора в процессе работы системы вряд ли необходима. Видимо, можно сделать вывод, что это сообщение игнорируют и другие сетевые ОС). Что касается управляющего сообщения ICMP Redirect Host, то единственным идентифицирующим его параметром является IP-адрес отправителя, который должен совпадать с IP-адресом маршрутизатора, так как это сообщение может передаваться только маршрутизатором. Особенность протокола ICMP состоит в том, что он не предусматривает никакой дополнительной аутентификации источников сообщений. Таким образом, ICMP-сообщения передаются на хост маршрутизатором однонаправлено, без создания виртуального соединения. Следовательно, ничто не мешает атакующему послать ложное ICMP-сообщение о смене маршрута от имени маршрутизатора.
Для осуществления этой удаленной атаки необходимо подготовить ложное ICMP Redirect Host сообщение, в котором указать конечный IP-адрес маршрута (адрес хоста, маршрут к которому будет изменен) и IP-адрес ложного маршрутизатора. Далее это сообщение передается на атакуемый хост от имени маршрутизатора. Для этого в IP-заголовке в поле адреса отправителя указывается IP-адрес маршрутизатора. В принципе, можно предложить два варианта данной удаленной атаки.
В первом случае атакующий находится в том же сегменте сети, что и цель атаки. Тогда, послав ложное ICMP-сообщение, он в качестве IP-адреса нового маршрутизатора может указать либо свой IP-адрес, либо любой из адресов данной подсети. Это даст атакующему возможность изменить маршрут передачи сообщений, направляемых атакованным хостом на определенный IP-адрес, и получить контроль над трафиком между атакуемым хостом и интересующим атакующего сервером. После этого атака перейдет во вторую стадию, связанную с приемом, анализом и передачей пакетов, получаемых от «обманутого» хоста. Рассмотрим функциональную схему осуществления этой удаленной атаки (рис 4.7):
Рис. 4.7. Внутрисегментное навязывание хосту ложного маршрута при использовании протокола ICMP. 
Рис. 4.7.1. Фаза передачи ложного ICMP Redirect сообщения от имени маршрутизатора. 
В случае осуществления второго варианта удаленной атаки атакующий находится в другом сегменте относительно цели атаки. Тогда, в случае передачи на атакуемый хост ложного ICMP Redirect сообщения, сам атакующий уже не сможет получить контроль над трафиком, так как адрес нового маршрутизатора должен находиться в пределах подсети атакуемого хоста (см. описанную выше в этом пункте реакцию сетевой ОС на ICMP Redirect сообщение), поэтому использование данного варианта этой удаленной атаки не позволит атакующему получить доступ к передаваемой по каналу связи информации. Однако, в этом случае атака достигает другой цели: нарушается работоспособность хоста. Атакующий с любого хоста в Internet может послать подобное сообщение на атакуемый хост и в случае, если сетевая ОС на данном хосте не проигнорирует данное сообщение, то связь между данным хостом и указанным в ложном ICMP-сообщении сервером будет нарушена. Это произойдет из-за того, что все пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора. Схема этой атаки приведена на рис. 4.8.
Рис. 4.8. Межсегментное навязывание хосту ложного маршрута при использовании протокола ICMP, приводящее к отказу в обслуживании. 
Рис. 4.8.1. Передача атакующим на хост 1 ложного ICMP Redirect сообщения от имени маршрутизатора 1. 
Рис. 4.8.2. Дезинформация хоста 1. Его таблица маршрутизации содержит информацию о ложном маршруте к хосту top.secret.com
Эксперимент показал, что оба варианта рассмотренной удаленной атаки удается осуществить (как межсегментно, так и внутрисегментно) на ОС Linux 1.2.8, ОС Windows ’95 и ОС Windows NT 4.0. Остальные сетевые ОС, исследованные нами (Linux 2.0.0 и защищенный по классу B1 UNIX), игнорировали данное ICMP Redirect сообщение (что, не правда ли, кажется вполне логичным с точки зрения обеспечения безопасности!).