Текст книги "Атака на Internet"

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

Рис. 4.9. Таблица маршрутизации хоста

В каждой строке этой таблицы содержится описание соответствующего маршрута, которое включает IP-адрес конечной точки пути (сетевой адрес), IP-адрес соответствующего ближайшего маршрутизатора (адрес маршрутизатора), а также ряд других параметров, характеризующих этот путь. Обычно в системе существует так называемый маршрут по умолчанию (поле «сетевой адрес» содержит значение 0.0.0.0, заданное по умолчанию, а поле «адрес маршрутизатора» – IP-адрес маршрутизатора): все пакеты, посылаемые на IP-адрес вне пределов данной подсети, будут направляться по этому пути, то есть на маршрутизатор. IP-адресация, как адресация на сетевом уровне, была задумана именно для межсегментной передачи данных из одной точки глобальной сети в другую. Для обращения на канальном уровне используются аппаратные адреса сетевых карт. Если бы Сеть представляла собой всего один сегмент, то дополнительной IP-адресации не потребовалось бы, так как аппаратных адресов сетевых адаптеров было бы вполне достаточно для непосредственной пересылки пакетов. Сегодня Internet представляет собой совокупность сегментов, соединенных через маршрутизаторы, и в Сети мы вынуждены использовать систему двойной адресации (по аппаратным и сетевым адресам). Поэтому, когда пакет направляется в другой сегмент Сети, в заголовке сетевого уровня указывается IP-адрес назначения, а в заголовке канального уровня – Ethernet-адрес ближайшего маршрутизатора.

Как известно, в сети Internet существует управляющий протокол ICMP (Internet Control Message Protocol), одной из функций которого является удаленное управление таблицей маршрутизации на хостах внутри сегмента Сети. Динамическое удаленное управление маршрутизацией изначально задумывалось для предотвращения возможной передачи сообщений по неоптимальному маршруту, а также для повышения отказоустойчивости Сети в целом. Предполагалось, что сетевой сегмент может быть подключен к Internet не через один (как это обычно происходит), а через несколько маршрутизаторов. В этом случае адресоваться во внешнюю сеть можно через любой из ближайших узлов. Это довольно удобно как с точки зрения оптимальности маршрута (например, к хосту www.example.one кратчайший маршрут проходит через первый маршрутизатор, а к хосту www.example.two – через второй маршрутизатор), так и с точки зрения повышения надежности работы Сети: при выходе из строя одного из маршрутизаторов связь с внешним миром возможна через другой маршрутизатор. В обоих случаях – как при изменении оптимального маршрута, так и при выходе из строя маршрутизатора – необходимо изменение таблицы маршрутизации в памяти сетевой операционной системы. Одно из назначений протокола ICMP состоит именно в динамическом изменении таблицы маршрутизации оконечных сетевых систем.

Итак, в Internet удаленное управление маршрутизацией реализовано в виде передачи с маршрутизатора на хост управляющего ICMP-сообщения Redirect Message (Перенаправить сообщение). Заголовок сообщения представлен на рис. 4.10.

Рис. 4.10. Заголовок сообщения ICMP Redirect Message

Поля сообщения принимают следующие значения: поле Type – 5, поле Code – 0 = Redirect datagrams for the Network, 1 = Redirect datagrams for the Host, 2 = Redirect datagrams for the Type of Service and Network или 3 = Redirect datagrams for the Type of Service and Host.

Как следует из спецификации протокола ICMP, сообщение Redirect бывает двух видов. Первый вид сообщения (code 0) носит название Redirect Datagrams for the Network (Таблица данных перенаправления в сетях) и уведомляет хост о необходимости смены адреса маршрутизатора, заданного по умолчанию, или о смене маршрута к определенной подсети. Второй вид (code 1) – Redirect Datagrams for the Host (Таблица данных перенаправления для хоста) – информирует хост о том, что следует создать новый маршрут к отмеченному в сообщении объекту и внести его в таблицу маршрутизации, указывая IP-адрес хоста, для которого нужна смена маршрута (адрес будет занесен в поле Destination (Назначение) в пристыкованном IP-заголовке), и новый IP-адрес маршрутизатора, куда необходимо направлять пакеты для данного хоста (этот адрес заносится в поле Gateway). В результате исследования реакции различных сетевых систем на данное ICMP-сообщение выяснилось важное ограничение, накладываемое на IP-адрес нового маршрутизатора, – он должен быть в пределах адресов данной подсети.

Исследование публикаций, посвященных протоколу ICMP, показало, что сообщение Redirect Datagrams for the Network устарело и уже не используется современными сетевыми ОС. Это подтверждает и проведенный авторами анализ исходных текстов ОС Linux 1.2.8. Иначе дело обстоит с управляющим сообщением Redirect Datagrams for the Host: здесь нет такого единства в рядах разработчиков различных сетевых ОС. Наши исследования показали, что на практике многие из известных UNIX-систем игнорируют это сообщение. Например, если в версии Linux 1.2.8 еще была реакция на Redirect Datagrams for the Host, то уже в версии Linux 2.0.0 такое сообщение игнорировалось. Иначе обстоит дело с ОС фирмы Microsoft – Windows 95 и Windows NT. Опасность Redirect Datagrams for the Host не была принята во внимание, и обе системы реагируют на это сообщение, позволяя удаленно изменять таблицу маршрутизации на любом Windows-хосте.

Итак, мы подошли к основному вопросу: в чем же потенциальная опасность реакции сетевой ОС на ICMP-сообщение Redirect Datagrams for the Host? Ответ очевиден: существует возможность несанкционированного изменения маршрутизации на хосте. Что может помешать кракеру самому послать подобное сообщение и навязать системе ложный маршрут? К сожалению, ничего. Анализ механизма идентификации ICMP-сообщения Redirect показывает, что единственным параметром, идентифицирующем это сообщение, является IP-адрес отправителя, который должен совпадать с IP-адресом маршрутизатора, так как это сообщение может и должно передаваться только маршрутизатором. Особенность протокола ICMP состоит в том, что он не предусматривает никакой дополнительной аутентификации отправителей. То есть ICMP-сообщения передаются на хост маршрутизатором однонаправленно без создания виртуального соединения (в процессе создания такого соединения можно было бы динамически, например по схеме Диффи-Хелмана, выработать идентифицирующую информацию). А так как ни хост, ни маршрутизатор не имеют заранее определенной статической ключевой информации для идентификации ICMP-сообщения Redirect, то очевидно, что в данном случае у получателя такого сообщения нет возможности установить подлинность его отправителя. Следовательно, ничто не мешает атакующему самому послать ложное ICMP-сообщение Redirect о смене маршрута от имени ближайшего роутера.

Приведенные выше факты позволяют осуществить типовую удаленную атаку «внедрение в распределенную ВС ложного объекта путем навязывания ложного маршрута».

Для осуществления этой удаленной атаки необходимо подготовить ложное ICMP-сообщение Redirect Datagrams for the Host, где указать конечный IP-адрес маршрута (адрес хоста, маршрут к которому будет изменен) и IP-адрес ложного маршрутизатора. Затем такое сообщение передается на атакуемый хост от имени маршрутизатора, для чего в IP-заголовке в поле адреса отправителя указывается IP-адрес маршрутизатора. Можно предложить два варианта данной удаленной атаки.

В первом случае кракер находится в том же сегменте сети, что и объект атаки. Тогда, послав ложное ICMP-сообщение, он в качестве IP-адреса нового маршрутизатора может указать свой IP-адрес или любой из адресов данной подсети. Это даст атакующему возможность перемаршрутизировать сообщения, направляемые атакованным хостом на определенный IP-адрес, и получить контроль над трафиком между этим хостом и интересующим взломщика сервером. Далее атака перейдет во вторую стадию, связанную с приемом, анализом и передачей пакетов, получаемых от «обманутого» хоста. Рассмотрим функциональную схему осуществления этой атаки (рис. 4.11):

Рис. 4.11. Внутрисегментное навязывание хосту ложного маршрута при использовании протокола ICMP

1. Передача на атакуемый хост ложного ICMP-сообщения Redirect Datagrams for the Host.

2. Если пришел ARP-запрос от атакуемого хоста, то посылается ARP-ответ.

3. Если пришел пакет от атакуемого хоста, то он переправляется на настоящий маршрутизатор.

4. Если пришел пакет от маршрутизатора, то он переправляется на атакуемый хост.

5. При приеме пакета возможно воздействие на информацию по схеме «ложный объект РВС».

При осуществлении второго варианта удаленной атаки кракер находится в другом сегменте относительно цели атаки. Тогда в случае передачи на атакуемый хост ложного ICMP-сообщения Redirect сам взломщик уже не может получить контроль над трафиком, так как адрес нового маршрутизатора должен находиться в пределах подсети атакуемого хоста. То есть использование данного варианта атаки не позволит атакующему получить доступ к передаваемой по каналу связи информации; в этом случае атака достигает другой цели – нарушения работоспособности хоста (рис. 4.12). Кракер с любого хоста в Internet может послать подобное сообщение на объект атаки, и если сетевая ОС на этом хосте не проигнорирует данное сообщение, то связь между хостом и указанным в ложном ICMP-сообщении сервером нарушится. Это произойдет потому, что все пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора. Для того чтобы выполнить такую межсегментную атаку, атакующему необходимо, во-первых, знать внутренний IP-адрес маршрутизатора, к которому подключен хост, и, во-вторых, выбрать имя сервера, которому требуется изменить маршрутизацию.

Рис. 4.12. Межсегментное навязывание хосту ложного маршрута при использовании протокола ICMP, приводящее к отказу в обслуживании

Первая проблема – внутренний IP-адрес маршрутизатора – решается только простым перебором, так как узнать этот адрес из внешней сети не представляется возможным (например, утилита traceroute даст только IP-адрес маршрутизатора во внешней сети). Так как большинство хостов в сети находится в подсетях класса C, то для осуществления этой атаки достаточно будет послать 256 ICMP-сообщений Redirect с различными IP-адресами отправителя. Например, IP-адрес хоста 194.85.96.197. Предположим, что этот хост находится в подсети класса С, тогда IP-адрес маршрутизатора, к которому он подключен, будет иметь те же первые три байта: 194.85.96.*, и взломщику достаточно будет перебрать только последний байт (послать 256 пакетов).

Вторая проблема для кракера – выбор имени (или IP-адреса) сервера, к которому будет изменена маршрутизация. Очевидно, что узнать, к какому серверу наиболее часто обращается пользователь данного хоста, для атакующего не представляется возможным. Однако взломщик может, посылая неограниченное число ICMP-сообщений Redirect, последовательно изменять маршрутизацию к наиболее известным или часто используемым серверам Internet (поисковые серверы, серверы известных фирм и т. д.). Дело сильно упростится в том случае, если кракер обладает некоторой информацией об атакуемом объекте (например, он является бывшим сотрудником данной фирмы).

Эксперимент показал, что оба варианта рассмотренной удаленной атаки удается осуществить как межсегментно, так и внутрисегментно на ОС Linux 1.2.8, ОС Windows 95 и ОС Windows NT 4.0. Остальные сетевые ОС, исследованные нами (Linux версии выше 2.0.0 и CX/LAN/SX, защищенная по классу B1 UNIX), игнорировали ICMP-сообщение Redirect, что кажется вполне логичным с точки зрения обеспечения безопасности.

Защититься от этого воздействия можно фильтрацией проходящих ICMP-сообщений Redirect при помощи систем Firewall. Другой способ защиты заключается в изменении исходных текстов сетевого ядра операционных систем с дальнейшей его перекомпиляцией, чтобы запретить реакцию на ICMP-сообщение Redirect. Однако это возможно только в случае свободного распространения исходных текстов ОС (как в случае с ОС Linux или ОС FreeBSD).

Transmission Control Protocol (протокол TCP) является одним из базовых протоколов транспортного уровня сети Internet. Он позволяет исправлять ошибки, которые могут возникнуть в процессе передачи пакетов, устанавливая логическое соединение – виртуальный канал. По этому каналу передаются и принимаются пакеты с регистрацией их последовательности, осуществляется управление информационным потоком, организовывается повторная передача искаженных пакетов, а в конце сеанса канал разрывается. При этом протокол TCP является единственным базовым протоколом из семейства TCP/IP, имеющим дополнительную систему идентификации сообщений и соединения. Именно поэтому протоколы прикладного уровня FTP и TELNET, предоставляющие пользователям удаленный доступ на хосты Internet, реализованы на базе протокола TCP.

Для идентификации TCP-пакета в TCP-заголовке существуют два 32-разрядных идентификатора – Sequence Number (Номер последовательности) и Acknowledgment Number (Номер подтверждения), которые также играют роль счетчиков пакетов. Поле Control Bits (Контрольная сумма) размером 6 бит может содержать следующие командные биты (слева направо): URG – Urgent Pointer Field Significant (Значение поля безотлагательного указателя), ACK – Acknowledgment Field significant (Значение поля подтверждения), PSH – Push Function, RST – Reset the Connection (Восстановить соединение), SYN – Synchronize Sequence Numbers (Синхронизировать числа последовательности), FIN – No More Data from Sender (Конец передачи данных от отправителя).

Рассмотрим схему создания TCP-соединения (рис. 4.13).

Рис. 4.13. Схема создания TCP-соединения

Предположим, что хосту А необходимо создать TCP-соединение с хостом В. Тогда А посылает на В следующее сообщение: SYN, ISSa.

Это означает, что в передаваемом A сообщении установлен бит SYN (Synchronize Sequence Number), а в поле Sequence Number установлено начальное 32-битное значение ISSa (Initial Sequence Number).

Хост В отвечает: SYN, ACK, ISSb, ACK(ISSa+1).

В ответ на полученный от А запрос В посылает сообщение, в котором установлены бит SYN и бит ACK; в поле Sequence Number хостом В задается свое начальное значение счетчика – ISSb; поле Acknowledgment Number содержит значение ISSa, полученное в первом пакете от хоста А и увеличенное на единицу.

Хост А, завершая рукопожатие (handshake), посылает: ACK, ISSa+1, ACK(ISSb+1).

В этом пакете установлен бит ACK; поле Sequence Number содержит значение ISSa+1; поле Acknowledgment Number содержит значение ISSb+1. Посылкой этого пакета на хост В заканчивается трехступенчатый handshake, и TCP-соединение между хостами А и В считается установленным.

Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-каналу; передается следующая информация: ACK, ISSa+1, ACK(ISSb+1); DATA.

Из рассмотренной схемы создания TCP-соединения видно, что единственными идентификаторами, помимо IP-адреса инициатора соединения, TCP-абонентов и TCP-соединения, являются два 32-битных параметра Sequence Number и Acknowledgment Number. Следовательно, для формирования ложного TCP-пакета атакующему необходимо знать текущие идентификаторы для данного соединения – ISSa и ISSb. Это означает, что кракеру достаточно, подобрав соответствующие текущие значения идентификаторов TCP-пакета для данного TCP-соединения (например, данное соединение может представлять собой FTP– или TELNET-подключение), послать пакет с любого хоста в сети Internet от имени одного из участников данного соединения (например, от имени клиента), указывая в заголовке IP-пакета его IP-адрес, и данный пакет будет воспринят как верный.

Итак, для осуществления описанной выше атаки необходимым и достаточным условием является знание двух текущих 32-битных параметров ISSa и ISSb, идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения.

Если взломщик находится в одном сегменте с объектом атаки или через сегмент кракера проходит трафик такого хоста, то задача получения значений ISSa и ISSb является тривиальной и решается путем сетевого анализа. Следовательно, нельзя забывать что протокол TCP позволяет защитить соединение только в случае невозможности перехвата атакующим сообщений, передаваемых по данному соединению, то есть тогда, когда кракер находится в других сегментах относительно абонентов TCP-соединения. Поэтому наибольший интерес для нас представляют межсегментные атаки, когда атакующий и его цель находятся в разных сегментах Сети. В этом случае задача получения значений ISSa и ISSb не является тривиальной. Далее предлагается следующее решение обозначенной проблемы.

Рассмотрим математическое предсказание начального значения идентификатора TCP-соединения экстраполяцией его предыдущих значений.

Первый вопрос, который возникает в данном случае: как сетевая операционная система формирует начальное значение ISSa или так называемый ISN – Initial Sequence Number (Начальный номер последовательности)? Очевидно, что наилучшим с точки зрения безопасности решением будет генерация значения ISN по случайному закону с использованием программного (а лучше аппаратного) генератора псевдослучайных чиселс достаточно большим периодом, тогда каждое новое значение ISN не будет зависеть от его предыдущего, и, следовательно, у атакующего не будет даже теоретической возможности нахождения функционального закона получения ISN.

На практике, однако, оказывается, что подобные правила случайной генерации ISN как для составителей описания протокола TCP (RFC 793), так и для разработчиков сетевого ядра различных ОС далеко не очевидны. Об этом говорят следующие факты. В описании протокола TCP в RFC 793 рекомендуется увеличивать значение этого 32-битного счетчика на 1 каждые 4 микросекунды. В ранних Berkeley-совместимых ядрах ОС UNIX, например, значение этого счетчика увеличивалось на 128 каждую секунду и на 64 для каждого нового соединения. Анализ исходных текстов ядра ОС Linux 1.2.8 показал, что значение ISN вычисляется данной ОС в зависимости от текущего времени по следующему, отнюдь не случайному закону:

ISN = mcsec + 1 000 000 sec, (1)

где mcsec – время в микросекундах;

sec – текущее время в секундах; отсчет его идет от 1970 года.

В ОС Windows NT 4.0 значение ISN увеличивается на 10 примерно каждую миллисекунду, то есть для Windows NT справедлива следующая формула:

ISN ≈ 10 msec, (2)

где msec – текущее время в миллисекундах.

Однако больше всего нас удивила защищенная по классу B1 операционная система CX/LAN/SX, установленная на многопроцессорной мини-ЭВМ – полнофункциональном межсетевом экране CyberGuard. Эта наиболее защищенная из всех, что встречалась авторам, сетевая ОС также имеет простой времязависимый алгоритм генерации начального значения идентификатора TCP-соединения. Как говорится, комментарии излишни. Мало того, что в единственном базовом «защищенном» протоколе Internet – протоколе TCP – применяется простейший способ идентификации соединения, который не может гарантировать надежную защиту от подмены одного из абонентов при нахождении атакующего в том же сегменте, так еще сами разработчики сетевых ОС разрушают и без того хрупкую безопасность этого протокола, используя простые времязависимые алгоритмы генерации ISN.

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

ISN = F (mсsec, msec, sec), (3)

где mcsec – время в микросекундах; (обычно минимальной единицей измерения машинного времени является микросекунда); циклически изменяется за одну секунду от 0 до 10⁶ – 1;

msec – текущее время в миллисекундах; этот параметр циклически изменяется за секунду от 0 до 999;

sec – текущее время в секундах.

На малом промежутке времени (меньше одной секунды) для удобства аппроксимации можно утверждать, что

ISN = F (mсsec). (4)

Итак, мы будем считать, что значение ISN зависит только от времени в микросекундах. Данная функция в силу особенностей изменения своих аргументов в сетевых ОС обычно является или кусочнолинейной, или ступенчатой. Например, зависимость (1), описывающая закон получения ISN в ОС Linux, в случае приведения ее к виду (4) является кусочнолинейной, а функциональная зависимость (2), справедливая для Windows NT, – ступенчатой.

На данном этапе мы вплотную подошли к проблеме определения вида функциональной зависимости ISN от времени (mcsec) для конкретной сетевой ОС. Первый способ получения этой зависимости – анализ исходных текстов ядра операционной системы. Использование данного способа на практике обычно оказывается невозможным из-за отсутствия исходных текстов большинства ОС. Исключение составляют ОС Linux и FreeBSD, поставляемые с исходными текстами ядра.

В связи с этим предлагается другой метод получения закона изменения ISN во времени. Сетевая ОС рассматривается исследователем как «черный ящик», к которому применяется метод тестирования «запрос – ответ»: на исследуемую ОС передается серия обычных запросов на созданиеТСР-соединения и принимается соответствующее количество ответов с текущими значениями ISN операционной системы в каждый момент времени. При этом замеряются временные интервалы в микросекундах между запросом и ответом на него и время, прошедшее между запросами. В результате у исследователя будет следующая таблица дискретных отсчетов ISN и соответствующих им моментов времени в mcsec:

где ISN_n – значение ISN, полученное за время t_n от начала эксперимента (время начала эксперимента принимается за 0).

Аппроксимируя данную таблицу дискретных значений непрерывной функции одним из известных математических методов (например, методом наименьших квадратов), получим непрерывную функцию, приближенно описывающую изменение ISN на данном временном промежутке (от 0 до t_n), при этом чем выше точность исходных данных, тем точнее приближение:

ISN(t) ≅ F(t). (5)

С помощью этой формулы мы можем, зная функцию изменения ISN от времени, экстраполировать следующее значение ISN по предыдущему. Теперь атакующий, получив в ответ на TCP-запрос текущее значение ISN для ОС в данный момент времени, способен математически предсказать следующее возможное значение ISN через некоторый промежуток времени.

Хотелось бы обратить внимание на следующий важный момент: чем ближе в сети находятся исследователь и тестируемая ОС, тем выше точность получения аппроксимирующей функции. В противном случае время, за которое запрос дойдет до системы и будет выработан ISN, может существенно отличаться от времени передачи ответа из-за задержек в канале связи; при этом погрешность исходных данных будет увеличиваться, а точность экстраполяции падать.

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

Применение описанной выше методики получения формулы ISN(t) на примере ОС Linux 1.2.8 и Windows NT 4.0 в случае нахождения в одном сегменте с данными ОС позволило определить это 32-битное значение (от 0 до 2³² -1) по его предыдущему значению для ОС Windows NT с точностью до 10, а для ОС Linux 1.2.8 – с точностью примерно до 100. В табл. 4.1 приведены снятые в процессе эксперимента с ОС Linux 1.2.8 значения изменения ISN за соответствующие промежутки времени (а не абсолютные значения).

Таблица 4.1. Изменение значения ISN для ОС Linux 1.2.8

График на рис. 4.14, построенный на основе данных из этой таблицы и справедливый для ОС Linux 1.2.8, наглядно показывает линейный характер изменения значения начального идентификатора TCP-соединения ISN на данном временном промежутке (на самом деле зависимость изменения ISN для ОС Linux 1.2.8 носит кусочнолинейный характер).

Рис. 4.14. Зависимость изменения ISN от времени для Linux 1.2.8

Как правило, определив вид функций для вычисления ISN в операционных системах на сервере и предполагаемом клиенте, атакующий начинает следить за ОС сервера, ожидая подключения предполагаемого клиента. В тот момент, когда подключение произошло, кракер может подсчитать возможный диапазон значений ISN, которыми обменялись при создании TCP-канала данные хосты. Так как атакующий может вычислить значения ISN только приближенно, то ему не избежать подбора. Однако без помощи описанного выше метода для перебора всех возможных значений ISSa и ISSb понадобилось бы послать 2⁶⁴ пакета, что нереально. В противном случае, например, если удалось вычислить значения ISN на операционных системах с точностью до 100, для подмены одного из абонентов TCP-соединения взломщику достаточно послать всего 10 000 пакетов. Вообще говоря, осуществить атаку, связанную с подменой TCP-абонентов, путем предсказания ISSa и ISSb без перехвата трафика практически невозможно (за исключением случая, когда оба абонента используют ОС Windows NT). Поэтому более реальным выглядит воздействие, связанное с подменой только одного из абонентов TCP-соединения и предсказанием одного значения ISSa.

Рассмотрим ставшую уже классической подобную удаленную атаку на r-службу. Осуществление такого взлома связано с описанными выше особенностями идентификации TCP-пакетов.