Атака на Internet
Шрифт:
Конечно, условием успеха этой атаки будет получение объектом атаки ложного DNS-ответа ранее настоящего ответа от ближайшего DNS-сервера. Поэтому для повышения вероятности ее успеха желательно нарушить работоспособность ближайшего DNS-сервера (например, путем создания направленного шторма UDP-запросов на 53-й порт).
Рассмотрим функциональную схему предложенной удаленной атаки на службу DNS (рис. 4.6):
Рис. 4.6. Внедрение в Internet ложного сервера путем создания направленного шторма ложных DNS-ответов на атакуемый хост
1. Постоянная передача кракером ложных DNS-ответов на различные UDP-порты атакуемого хоста и, возможно, с различными ID от имени (с IP-адреса) настоящего DNS-сервера с указанием имени интересующего хоста и его ложного IP-адреса, которым будет являться IP-адрес ложного сервера – хоста атакующего.
2. В случае получения пакета от хоста – изменение в IP-заголовке пакета его IP-адреса на IP-адрес атакующего и передача пакета на сервер (то есть ложный сервер ведет работу с сервером от своего имени – со своего IP-адреса).
3. В случае получения пакета от сервера – изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного сервера и передача пакета на хост (для хоста ложный сервер и есть настоящий сервер).
Таким образом, реализация данной удаленной атаки, использующей пробелы в безопасности службы DNS, позволяет из любой точки сети Internet нарушить маршрутизацию между двумя заданными объектами (хостами). Такая атака осуществляется межсегментно по отношению к цели атаки и угрожает безопасности любого хоста Internet, использующего обычную службу DNS.
Перехват DNS-запроса или создание направленного шторма ложных DNS-ответов на DNS-сервер
Рассмотрим внедрение в сеть Internet ложного сервера путем перехвата DNS-запроса или создания направленного шторма ложных DNS-ответов на атакуемый DNS-сервер.
Из рассмотренной ранее схемы удаленного DNS-поиска следует, что если DNS-сервер не обнаружил указанное в запросе имя в своей базе имен, то такой запрос отсылается им на один из ответственных за домены верхних уровней DNS-серверов, адреса которых содержатся в файле настроек сервера root.cache.
Итак, если DNS-сервер не имеет сведений о запрашиваемом хосте, то он сам, пересылая запрос далее, является инициатором удаленного DNS-поиска. Поэтому ничто не мешает
При этом важно учитывать следующую особенность работы DNS-сервера. Для ускорения работы каждый DNS-сервер кэширует в области памяти свою DNS-таблицу соответствия имен и IP-адресов хостов. В том числе в кэш заносится динамически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера, то есть, если DNS-сервер, приняв запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает запрос на следующий сервер и, получив ответ, заносит найденные сведения в кэш-таблицу. Таким образом, при получении следующего запроса DNS-серверу уже не требуется вести удаленный поиск, так как необходимые сведения находятся у него в кэш-таблице.
Анализ подробно описанной здесь схемы удаленного DNS-поиска показывает, что если на запрос от DNS-сервера атакующий направит ложный DNS-ответ или (в случае шторма ложных ответов) будет вести их постоянную передачу, то в кэш-таблице сервера появится соответствующая запись с ложными сведениями, и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, а при адресации к хосту, маршрут к которому кракер решил изменить, связь с ним будет осуществляться через хост атакующего по схеме «ложный объект РВС». И, что хуже всего, с течением времени эта ложная информация, попавшая в кэш DNS-сервера, начнет распространяться на соседние DNS-серверы высших уровней, а следовательно, все больше хостов в Internet будут дезинформированы и атакованы.
Очевидно, что в том случае, когда взломщик не может перехватить DNS-запрос от DNS-сервера, для реализации атаки ему необходим шторм ложных DNS-ответов, направленный на DNS-сервер. При этом возникает следующая проблема, отличная от проблемы подбора портов в случае атаки на хост. Как уже отмечалось, DNS-сервер, посылая запрос на другой DNS-сервер, идентифицирует этот запрос двухбайтовым значением (ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Атакующему узнать текущее значение идентификатора DNS-запроса не представляется возможным. Поэтому предложить что-либо, кроме перебора 216 вероятных значений ID, сложно. Зато исчезает проблема перебора портов, так как все DNS-запросы передаются DNS-сервером на порт 53.
Еще одно условие осуществления атаки на DNS-сервер с использованием направленного шторма ложных DNS-ответов состоит в том, что она будет иметь успех только в случае, если DNS-сервер пошлет запрос на поиск имени, которое содержится в ложном DNS-ответе. DNS-сервер посылает этот столь необходимый и желанный для атакующего запрос лишь тогда, когда на него приходит DNS-запрос от какого-либо хоста на поиск данного имени и этого имени не оказывается в кэш-таблице DNS-сервера. Такой запрос может появиться когда угодно, и кракеру придется ждать результатов атаки неопределенное время. Однако ничто не мешает атакующему, никого не дожидаясь, самому послать на атакуемый DNS-сервер подобный DNS-запрос и спровоцировать DNS-сервер на поиск указанного в запросе имени. Тогда эта атака с большой вероятностью будет иметь успех практически сразу же после начала ее осуществления.
Вспомним, например, скандал, произошедший 28 октября 1996 года вокруг одного из московских провайдеров Internet – компании РОСНЕТ, когда пользователи данного провайдера при обращении к обычному информационному WWW-серверу попадали, как было сказано в телевизионном репортаже, «на WWW-сервер сомнительного содержания». Этот инцидент вполне укладывается в только что описанную схему удаленной атаки на DNS-сервер. С одним исключением: вместо адреса хоста атакующего в кэш-таблицу DNS-сервера был занесен IP-адрес другого, не принадлежащего взломщику, хоста (порносайта).
Уже затем нам довелось ознакомиться с интервью, которое якобы дал кракер, осуществивший этот взлом. Из интервью следовало, что атака использовала некую известную «дыру» в WWW-сервере РОСНЕТ, что и позволило атакующему подменить одну ссылку другой. Осуществление воздействий такого типа является, по сути, тривиальным и не требует от взломщика практически никакой квалификации, за исключением изрядной доли усидчивости и навыков в применении известных технологий (подчеркнем: именно осуществление, а не нахождение этой «дыры»). По нашему глубокому убеждению, тот, кто найдет уязвимость, и тот, кто осуществит на ее базе взлом, скорее всего, будут разными лицами, так как обычно специалист, обнаруживший «дыру», не интересуется вопросами практического применения полученных знаний. (Р. Т. Моррис не стал исключением, просто его червь из-за ошибки в коде вышел из-под контроля, и пользователям Сети был нанесен определенный ущерб.) В завершение хотелось бы снова вернуться к службе DNS и сказать, что, как следует из вышеизложенного, использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в безопасности этой, и так отнюдь не безопасной, глобальной сети. Как указывал С. М. Белловин (S. M. Bellovin) в ставшей почти классической работе [14]: «A combined attack on the domain system and the routing mechanisms can be catastrophic» («Комбинированная атака на доменную систему и механизмы маршрутизации может привести к катастрофическим последствиям»).
Навязывание хосту ложного маршрута с использованием протокола ICMP
Общеизвестно, что маршрутизация в Сети играет важнейшую роль для обеспечения ее нормального функционирования. Маршрутизация в Internet осуществляется на сетевом уровне (IP-уровень). На программном уровне для ее обеспечения в памяти сетевой операционной системы каждого хоста существуют специальные таблицы, содержащие данные о возможных маршрутах. На аппаратном уровне каждый сегмент Сети подключен к глобальной сети как минимум через один маршрутизатор, а следовательно, все хосты и маршрутизатор должны физически располагаться в одном сегменте. Поэтому все сообщения, адресованные в другие сегменты Сети, направляются на маршрутизатор, который, в свою очередь, перенаправляет их далее по указанному в пакете IP-адресу, выбирая при этом оптимальный маршрут. Рассмотрим, что представляет собой таблица маршрутизации хоста. Она состоит из пяти колонок: сетевой адрес, сетевая маска, адрес маршрутизатора, интерфейс и метрика (см. рис. 4.9).
Рис. 4.9. Таблица маршрутизации хоста
В каждой строке этой таблицы содержится описание соответствующего маршрута, которое включает IP-адрес конечной точки пути (сетевой адрес), IP-адрес соответствующего ближайшего маршрутизатора (адрес маршрутизатора), а также ряд других параметров, характеризующих этот путь. Обычно в системе существует так называемый маршрут по умолчанию (поле «сетевой адрес» содержит значение 0.0.0.0, заданное по умолчанию, а поле «адрес маршрутизатора» – IP-адрес маршрутизатора): все пакеты, посылаемые на IP-адрес вне пределов данной подсети, будут направляться по этому пути, то есть на маршрутизатор. IP-адресация, как адресация на сетевом уровне, была задумана именно для межсегментной передачи данных из одной точки глобальной сети в другую. Для обращения на канальном уровне используются аппаратные адреса сетевых карт. Если бы Сеть представляла собой всего один сегмент, то дополнительной IP-адресации не потребовалось бы, так как аппаратных адресов сетевых адаптеров было бы вполне достаточно для непосредственной пересылки пакетов. Сегодня Internet представляет собой совокупность сегментов, соединенных через маршрутизаторы, и в Сети мы вынуждены использовать систему двойной адресации (по аппаратным и сетевым адресам). Поэтому, когда пакет направляется в другой сегмент Сети, в заголовке сетевого уровня указывается IP-адрес назначения, а в заголовке канального уровня – Ethernet-адрес ближайшего маршрутизатора.
Немного о ICMP
Как известно, в сети Internet существует управляющий протокол ICMP (Internet Control Message Protocol), одной из функций которого является удаленное управление таблицей маршрутизации на хостах внутри сегмента Сети. Динамическое удаленное управление маршрутизацией изначально задумывалось для предотвращения возможной передачи сообщений по неоптимальному маршруту, а также для повышения отказоустойчивости Сети в целом. Предполагалось, что сетевой сегмент может быть подключен к Internet не через один (как это обычно происходит), а через несколько маршрутизаторов. В этом случае адресоваться во внешнюю сеть можно через любой из ближайших узлов. Это довольно удобно как с точки зрения оптимальности маршрута (например, к хосту www.example.one кратчайший маршрут проходит через первый маршрутизатор, а к хосту www.example.two – через второй маршрутизатор), так и с точки зрения повышения надежности работы Сети: при выходе из строя одного из маршрутизаторов связь с внешним миром возможна через другой маршрутизатор. В обоих случаях – как при изменении оптимального маршрута, так и при выходе из строя маршрутизатора – необходимо изменение таблицы маршрутизации в памяти сетевой операционной системы. Одно из назначений протокола ICMP состоит именно в динамическом изменении таблицы маршрутизации оконечных сетевых систем.
Итак, в Internet удаленное управление маршрутизацией реализовано в виде передачи с маршрутизатора на хост управляющего ICMP-сообщения Redirect Message (Перенаправить сообщение). Заголовок сообщения представлен на рис. 4.10.
Поля сообщения принимают следующие значения: поле 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 такое сообщение
Итак, мы подошли к основному вопросу: в чем же потенциальная опасность реакции сетевой ОС на 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):
1. Передача на атакуемый хост ложного ICMP-сообщения Redirect Datagrams for the Host.
2. Если пришел ARP-запрос от атакуемого хоста, то посылается ARP-ответ.
3. Если пришел пакет от атакуемого хоста, то он переправляется на настоящий маршрутизатор.
4. Если пришел пакет от маршрутизатора, то он переправляется на атакуемый хост.
5. При приеме пакета возможно воздействие на информацию по схеме «ложный объект РВС».
При осуществлении второго варианта удаленной атаки кракер находится в другом сегменте относительно цели атаки. Тогда в случае передачи на атакуемый хост ложного ICMP-сообщения Redirect сам взломщик уже не может получить контроль над трафиком, так как адрес нового маршрутизатора должен находиться в пределах подсети атакуемого хоста. То есть использование данного варианта атаки не позволит атакующему получить доступ к передаваемой по каналу связи информации; в этом случае атака достигает другой цели – нарушения работоспособности хоста (рис. 4.12). Кракер с любого хоста в Internet может послать подобное сообщение на объект атаки, и если сетевая ОС на этом хосте не проигнорирует данное сообщение, то связь между хостом и указанным в ложном ICMP-сообщении сервером нарушится. Это произойдет потому, что все пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора. Для того чтобы выполнить такую межсегментную атаку, атакующему необходимо, во-первых, знать внутренний IP-адрес маршрутизатора, к которому подключен хост, и, во-вторых, выбрать имя сервера, которому требуется изменить маршрутизацию.
Первая проблема – внутренний 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).
Подмена одного из субъектов TCP-соединения в сети Internet
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).
Предположим, что хосту А необходимо создать 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-соединения
Рассмотрим математическое предсказание начального значения идентификатора 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 вычисляется данной ОС в зависимости от текущего времени по следующему, отнюдь не случайному закону: