Какие параметры tcp соединения должны быть известны нарушителю для подмены участника
Какие параметры tcp соединения должны быть известны нарушителю для подмены участника
Это поле размером 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-соединения (рис 11).
Рис.11 Схема создания TCP-соединения
Это означает, что в передаваемом A сообщении установлен бит SYN (synchronize sequence number), а в поле Sequence Number установлено начальное 32-битное значение ISSa ( Initial Sequence Number ).
В этом пакете установлен бит ACK; поле Sequence Number содержит ISSa + 1; поле Acknowledgment Num-ber содержит значение ISSb + 1. Посылкой этого пакета на хост В заканчивается трехступенчатый handshake, и TCP-соединение между хостами А и В считается установленным.
Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-каналу:
Итак, для осуществления описанной выше атаки необходимым и достаточным условием является знание двух текущих 32-битных параметров ISSa и ISSb, идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения.
В том случае, когда атакующий находится в одном сегменте с целью атаки или через его сегмент проходит трафик предполагаемого объекта атаки, то задача получения значений ISSa и ISSb является тривиальной и решается путем анализа сетевого трафика. Следовательно, надо четко понимать, что протокол TCP позволяет, в принципе, защитить соединение только в случае невозможности перехвата атакующим сообщений, передаваемых по данному соединению, то есть в случае нахождения атакующего в других сегментах относительно абонентов TCP-соединения.
Поэтому наибольший интерес для нас представляют межсегментные атаки, когда атакующий и его цель находятся в разных сегментах сети. В этом случае задача получения значений ISSa и ISSb не является тривиальной. Далее предлагается следующее решение данной проблемы.
Математическое предсказание начального значения идентификатора TCP-соединения экстраполяцией его предыдущих значений
Таб.3 Таблица временных интревалов
|
Эта формула в общем случае позволяет нам по предыдущему значению ISN, зная функцию изменения ISN от времени, экстраполировать следующее значение ISN. Теперь атакующий может, получив в ответ на TCP-запрос текущее значение ISN для ОС в данный момент времени, математически предсказать следующее возможное значение ISN через некоторый промежуток времени.
Заметим, что атакующему вовсе не обязательно проводить подобные исследования с интересующим его удаленным хостом. Достаточно только узнать тип операционной системы на предполагаемой цели атаки и получить в свое распоряжение подобную систему для определения формулы изменения ISN в данной ОС.
Таблица изменения значения ISN для ОС Linux 1.2.8
|
Следующий график, построенный по значениям из данной таблицы и справедливый для ОС Linux 1.2.8, наглядно показывает линейный характер изменения значения начального идентификатора TCP-соединения ISN на данном временном промежутке (на самом деле зависимость изменения ISN для ОС Linux 1.2.8 носит кусочнолинейный характер):
 
; Рис.12 Зависимость изменения ISN от времени для Linux 1.2.8
В общем случае, определив вид функций для вычисления ISN в операционных системах на сервере и предполагаемом клиенте, атакующий начинает следить за ОС сервера, ожидая подключения предполагаемого клиента. В тот момент времени, когда подключение произошло, атакующий может подсчитать возможный диапазон значений ISN, которыми обменялись при создании TCP-канала данные хосты. Так как атакующий может вычислить значения ISN только приближенно, то ему не избежать подбора. Однако, если не проводить описанный выше анализ, то для перебора всех возможных значений ISSa и ISSb понадобилось бы послать 2 64 пакетов, что нереально. В случае использования описанного выше анализа в зависимости от полученной степени точности и удаления атакующего от хостов потребуется послать значительно меньшее число пакетов. Например, если удалось вычислить значения ISN на операционных системах с точностью до 100, то атакующему для подмены одного из абонентов TCP-соединения достаточно послать всего 10000 пакетов.
Далее мы рассмотрим ставшую уже классической удаленную атаку на r-службу, осуществление которой связано с описанными выше особенностями идентификации TCP-пакетов.
Сканирование отображения: атаки на TCP без возможности подмены трафика (часть I)
В данной статье рассматривается, каким образом поток траффика, взятый из общей очереди пакетов, может быть использован как сторонний канал, через который нарушитель может получить конфиденциальную информацию.
Краткое содержание
1. Введение
TCP-сессия защищена тремя неизвестными нарушителю числами: 16-битным номером порта (новый для каждой сессии) и двумя 32-битными последовательными числами (по одному с каждой стороны коммуникации). Прочие поля, такие как IP адреса конечных точек и порт сервера, легко определить в большинстве случаев. Каждый TCP сегмент, отправленный в рамках установленного подключения, использует все три секретных числа. Для того чтобы сегмент был корректно принят, он должен содержать корректный номер порта, его номер последовательности должен быть в рамках окна получателя, а также число принятия должен быть приемлемым. Согласно действующим рекомендациям, номер порта должен быть случайным числом в диапазоне 1025-65535, а число принятия является подходящим, только если оно равно следующему отправляемому октету или меньше максимального размера окна отправителя. Если данные рекомендации выполняются, нарушителю потребуется
попыток для генерации приемлемого сегмента. Если предположить, что оба окна содержат по 65 кБ, потребуется около 2 48 попыток. Если конечная точка строго следует правилам проверки RST, когда в RST сегменте номер последовательности должен быть равен следующему ожидаемому номеру последовательности, нарушителю потребуется 
попыток, чтобы вслепую переустановить соединение, что также подразумевает 2 48 вариантов. Используемые числа являются достаточно большими, чтобы в большинстве случаев провести атаку «вслепую» неэффективной. Для того чтобы подобрать только один сегмент, нарушителю потребуется 500 часов при скорости 100Гб в секунду. И даже если сегмент будет принят, вероятность того, что он совпадет с началом окна, равняется 
. Таким образом, успешная атака «вслепую» может скомпрометировать подключение, но шансов на успех достаточно мало.
Риск принятия поддельного TCP сегмента в качестве действительного имеет место, и его изучают. Выполняя определенные рекомендации можно не учитывать риск ответа на поддельные сегменты. Уровень TCP может либо сбросить данный сегмент, либо принять его (с ACK или RST). Данное действие различается в зависимости от реализации протокола. Впервые оно было упомянуто в разделе «обработка событий» RFC 793 [1], но используемые на сегодняшний день системы (а особенно межсетевые экраны) не следуют RFC полностью. Вместо этого в них реализуются функции фильтрации, как в примере, описанном в [2]. Эти новые правила созданы для того, чтобы сохранять совместимость между различными реализациями протокола.
В каждой конкретной реализации TCP перспектива ответа на отклоненный сегмент зависит от одного из закрытых значений сегмента. Если нарушитель узнает его и получит ответ на поддельный сегмент, TCP сессия может быть скомпрометирована. Нарушитель может определить, удовлетворяет ли закрытое значение определенным критериям (порт был выбран верно, число последовательности – в рамках окна, число принятия было подходящим). Неизвестные нарушителю значение могут быть найдены в несколько шагов, ни один из которых не требует больших ресурсов.
Перегрузка общей для нарушителя и целевого TCP потока очереди является, по сути, сторонним каналом, через который нарушитель может определить, был ли ответ на поддельный сегмент. Определение нагрузки, вызываемой одним пакетом, на практике может оказаться довольно сложной задачей, но нарушитель может отправить последовательность сегментов. Если будут получены ответы на все сегменты, будет зафиксировано резкое увеличение трафика (в худшем варианте – переполнение очереди). Данная методика представлена на рисунке 1.
2. Связанные работы
Атака, описанная в данной работе, имеет много общих моментов со всем известной техникой, эксплуатирующей слабости в реализации механизма генерации IP ID. Некоторые системы, для предотвращения данной атаки, увеличивают длину поля ID у каждого последующего IP пакета. Это создает сторонний канал, позволяющий определить, отправлен ли с хоста пакет в качестве ответа на входящий трафик. Этот канал может быть использован для сканирования портов или для выполнения атак на установленное TCP соединение [8]. В отличие от техники, описанной в данной работе, для эксплуатации IP ID канала нарушитель должен установить легитимный, двунаправленный канал коммуникации с атакуемым хостом. Современные межсетевые экраны, как правило, запрещают подобные подключения к клиентским машинам. Представленная вам работа сфокусирована на компрометации TCP сессий, но описанная техника может быть также использована для сканирования портов, аналог чего представлен в работе [7].
Рисунок 1. «Высокоуровневая схема атаки. Нарушитель посылает запрос жертве в форме последовательности поддельных сегментов. Если ответ на запрос положительный, жертва отвечает последовательностью сегментов, адресованных ее пиру. В то же время нарушитель пингует его, используя ту же очередь, что и сегменты жертвы. Увеличение времени ответа сигнализирует о позитивном ответе на запросы».
Авторы работы [9] показали, что перегрузка TCP может быть использована нарушителем для повышения эффективности его TCP-подключения за счет других. Применимость данной методики для проведения атаки «отказ в обслуживании» рассмотрена в работе [10]. При попытке проведения авторам удалось существенно снизить пропускную способность при TCP-соединении. В работе, посвященной оценке безопасности TCP [5], объясняется, что данная атака может быть проведена «вслепую» человеком, не имеющим возможность подменять траффик между хостами. Контроль перегрузки TCP поддерживается ACK сегментами, поэтому уровень TCP легко можно обойти с помощью генерации ACK поддельными сегментами с некорректными номерами последовательности.
3. Требования и применимость
На применимость атаки влияют различные факторы:
Определение практических ограничений исследуемой методики находятся за рамками данной работы. Результаты проведенных экспериментов могут служить ориентирами для анализа применимости атаки при различных сценариях. Подтверждение данной концепции может стать отправной точкой для дальнейших экспериментов. Для проведения рассматриваемой атаки необходимо не так много ресурсов, как для атак «вслепую», но, тем не менее, достаточно, чтобы сделать ее неприменимой во многих случаях.
4. Эксперименты
· Простаивающее TCP соединение с незначительным объемом трафика, проходящего через узкое место. Самый благоприятный сценарий, в ходе которого ответы за запросы занимали большую часть трафика, проходящего через узкое место.
Нарушитель отправляет ping на маршрутизатор, находящийся в одном хопе от граничного маршрутизатора. Это позволяет быть уверенным, что ping-пакеты и сегменты, отправляемые жертвой в ответ на поддельный трафик, используют одну очередь исходящих сообщений на граничном маршрутизаторе. Когда соединение с внешней сетью не использовалось, время на передачу и подтверждение (RTT) ping’а было порядка 20 мс, когда же соединение было нагружено, RTT возросло до 700 мс.
Был проведен анализ двух систем: Windows XP SP3 со включенным межсетевым экраном и Linux 3.0.0 с Netfilter, включенным следующей командой:
Это общепринятая конфигурация для клиентской машины. Весь входящий трафик, не предназначенный для подключений, инициированных данной машиной, отбрасывается.
На исследуемых системах использовались разные правила для обработки TCP-сегментов. Для определения того, как защищенный межсетевым экраном хост отвечает на входящие сегменты, необходимо проанализировать два шага. Первый – отбросит ли межсетевой экран подобный сегмент, и второй – как сегмент будет обработан на уровне TCP. Различия рассматриваемых систем видны уже на первом шаге: Netfilter использует более строгие правила фильтрации трафика [2]. Второй шаг в обеих системах одинаков (по крайней мере, правила обработки, на которые проводилась атака) и максимально соответствует RFC 793. Правила обработки, используемые при атаке, будут освещены далее.
Доказательство концепции, использованной для получения результатов экспериментов, можно найти в работе [16]. В работе не рассматриваются низкоуровневые детали реализации, заинтересованным читателям следует обратиться к документации.
Важно отметить, что атаки не выявили багов в реализации TCP.
5. Детали атаки
В итоге жертва должна сгенерировать ACK сегменты, содержащие около 80 байт (40 байт для заголовков второго уровня, 20 для IP- и 20 для TCP-заголовков). Согласно формуле, задержка при обработке 30 ACK сегментов должна равняться 0.06 секунды. Это в три раза больше, чем ping для простаивающего соединения, поэтому должно легко определяться. 100 ACK сегментов должны вызывать задержку в 2 секунды, что в три раза больше, чем ping при активно используемом соединении (700 мс). Это должно быть легко определяемым при проведении испытаний атаки.
5.1. Одноразовый номер порта.
TCP стеки в Windows и Linux построены с учетом рекомендаций RFC и отвечают ACK на любой сегмент с некорректным номером последовательности. Netfilter в Linux использует более строгие правила для проверки отброшенных сегментов, не принадлежащих ни одному из подключений:
Проверки числа принятия затрудняют поиск номера используемого порта с помощью сегментов с некорректным номером последовательности. Но есть один способ обхода:
На уровне TCP ACK-ответ на подобные сегменты происходит, если их номер последовательности находится вне окна. Это позволяет определить номер порта хоста, защищенного Netfilter. Единственным недостатком является тот факт, что, если номер последовательности SYN-ACK сегмента случайно окажется в рамках окна, Linux закроет соединение. Вероятность подобной ситуации равна (размер окна/2 32 ).
На рисунке 2 представлена динамика RTT при последовательности поддельных сегментов, направленных на верный порт. Скачок значения RTT происходит как и прогнозировалось, но зачастую он не является единственным. Далее повторяются все запросы, которые вызвали скачок, до тех пор, пока не останется только один. Данный алгоритм позволяет определить номер порта (максимальное значение среди успешных попыток)
а) соединение простаивает, 5 запросов ping на порт, 30 поддельных сегментов на порт
б) соединение используется (загрузка данных), 10 запросов ping на порт, 1000 поддельных сегментов на порт
Рисунок 2. Изменение динамики «потерянных» ping-запросов позволяет определить используемый порт (11235). Ping считается потерянным, если ответ не пришел три раза подряд с одного и того же порта.
Наименьшее время запроса равняется времени одного ping’а. Даже при минимальном времени в 20 мс сканирование 64 тысяч портов займет около 21 минуты. Если пропускная способность канала между нарушителем и жертвой является довольно большой, нарушителем может быть проверено большая часть портов в каждой последовательности поддельных сегментов. Данная последовательность может быть интерпретирована как запрос «при подключении используется порт в интервале [X;Y]?». Если часть последовательности отражается, то ответ «да», после чего можно продолжить поиск точного номера порта в данном интервале. Во время экспериментов данные запросы были довольно эффективны и позволяли снизить время поиска (см. рисунок 3). В таблице 1 приведены результаты попыток атаки. Результаты оказались схожими для обеих систем. Можно повысить эффективность, если при подключении будет использоваться порт из меньшего диапазона.
Рисунок 3. Сканирование при простаивающем соединении. Поддельные сегменты покрыли 200 множеств портов. 5 ping’ов и 6000 поддельных сегментов (30 на каждый порт) отправлены на каждое множество. Анализ RTT и «пиков» потерь ping’ов позволили определить, что номер используемого порта лежит на интервале 11200-11400.
Сканирование отображения: атаки на TCP без возможности подмены трафика (часть II)
В данной статье рассматривается, каким образом поток траффика, взятый из общей очереди пакетов, может быть использован как сторонний канал, через который нарушитель может получить конфиденциальную информацию.
Информация о Netfilter.
В комментарии к исходному коду netfilter сказано:
«Наше подключение может не быть синхронизировано, поэтому игнорируйте пакеты, которые могут сигнализировать о настоящем подключении между клиентов и сервером» (игнорировать, в данном случае, не значить отбрасывать)
Проблема заключается в том, что netfilter и TCP стек Linux являются разными, несвязанными элементами. Netfilter не имеет доступа к состоянию TCP подключению, но может воссоздавать его на основе сегментов, рассмотренных ранее. В данном случае не подразумевается, что защищаемая конечная точка находится на той же машине, и что принятые ей сегменты достигли цели.
5.2 Номера последовательности
Необходимые шаги для определения SND.NXT значительно различаются для двух проведенных экспериментов. В обоих случаях используются ACK-сегменты и одноразовый порт, определенные на предыдущем шаге. При установленном соединении (корректные IP-адреса и порты) межсетевой экран Windows никогда не отбрасывает ACK-сегменты, поэтому при анализе ответов Windows необходимо принимать во внимание только правила, установленные документом RFC 793. NetFilter применяет более строгие правила фильтрации. В следующем подразделе демонстрируется, что более строгие правила фильтрации значительно уменьшают количество ресурсов, необходимых для атаки.
Хост работает строго по правилам RFC 793
запросов, чтобы найти номер последовательности, содержащийся в окне. Риск случайно внести в сессию искажения пренебрежимо мал. Сессия будет искажена, только если нарушитель подтвердит получение данных, потерянных при передаче. В этом случае данные повторно передаваться не будут.
Из N запросов необходимо выделить единственный, который не вызывает положительного ответа. Ситуация противоположна сканированию портов, где, наоборот, производится поиск запроса, вызывающего положительный ответ. В действительности, поиск отрицательного ответа более сложен. Это вызвано следующими возможными проблемами:
Из рис. 4 видно, как уменьшается время RTT, когда номер последовательности находится внутри окна. В таблице 2 показано, что даже в случае простоя, для полного сканирования требуется значительное время. В экспериментальное среде PoC коду потребовалось примерно 36 часов, чтобы провести сканирование при закачивании данных.
Зная номер последовательности внутри окна, нарушитель может найти SND.NXT узла сети жертвы. Для этого нужно найти минимальный номер последовательности, который не генерирует ответ. Значение SND.NXT не превосходит размера окна, меньше номера последовательности, и может быть найдено с помощью бинарного поиска за логарифмическое относительно размера окна число запросов.
Кроме того, если требуется найти значение SND.NXT жертвы, то теперь это можно легко сделать. Для наибольшего номера подтверждения, который не генерирует ответа (если принимается), необходимо сделать 31 запрос в бинарном поиске. Полученное число равно значению SND.NXT жертвы.
Для защиты используется Netfilter
Благодаря этому можно найти подходящий номер подтверждения за 2 32 / max(66000, максимальный размер видимого окна отправителя) попыток. Если жертва отвечает на сегмент с неправильным номером последовательности, то это означает, что номер подтверждения был принят Netfilter’ом. Поиск подходящего номера подтверждения аналогичен поиску одноразового порта. Необходимо проверить по крайней мере 2 32 / 66000 = 65075 значений, и только одно из этих значений вызывает генерацию положительного ответа, поэтому также за один запрос можно проверять несколько значений. Для оценки необходимых ресурсов можно вновь обратиться к таблице 1.
Таблица 1. Поиск одноразового порта. Поиск осуществлялся на всем пространстве из 65К одноразовых портов.
Максимальное число проверенных портов за запрос
30 портов за запрос
1000 портов за запрос
1000 портов за запрос
Таблица 2. Поиск номера последовательности, находящегося внутри окна, в случае строгого следования RFC 793. Размер окна: 65 КБ.
Таблица 3. Поиск подходящего номера подтверждения. Нарушитель обманывает Netfilter, увеличивая окно отправителя до 8.3 МБ, это позволяет проверить всё возможное пространство номеров подтверждения за небольшое количество запросов.
Максимальное число проверенных номеров подтверждения за запрос
30 номеров подтверждения за запрос
1000 номеров подтверждения за запрос
1000 номеров подтверждения за запрос
результаты сканирования номера последовательности (нормализация: 0 внутри окна)
(а) бездействие, 5 пинг на каждый номер последовательности, 30 поддельных сегментов на каждый номер последовательности
результаты сканирования номера последовательности (нормализация: 0 внутри окна)
(а) закачка, 10 пинг на каждый номер последовательности, 1000 поддельных сегментов на каждый номер последовательности
Рисунок 4. Измерено наименьшее среднее время RTT и количество потерь, в случае, когда поддельный сегмент находится внутри окна. Время RTT и количество потерь для других замеров достаточно велико и поэтому, длительность сканирования увеличивается. Естественные скачки трафика могут маскировать минимумы. Пинг считается потерянным, если ответ не получен по прошествии двух интервалов RTT с момента последнего пинга для того же номера последовательности.
Существует уловка, которая позволяет улучшить эффективность поиска. Netfilter можно легко обмануть, установив максимально возможный размер окна отправителя. Точное значение максимума определяется во время установки сессии. Для того чтобы обойти фильтр потребуется отослать 65075 ACK-пакетов, покрывающих все пространство в 2 32 номеров подтверждения, причем значения номеров будут отличаться на 66000. Для всех таких ACK-сегментов устанавливается максимально возможный размер окна: 0xFFFF. Один из ACK-сегментов должен приниматься Netfiltr’ом и устанавливать максимальный размер видимого окна в 
(заметим, что это не повлияет на реальный размер окна, протокол TCP в конечной точке отбросит ACK-сегмент, поскольку он содержит неправильный номер последовательности). Во время эксперимента, отправитель устанавливал размер окна равным 114, а коэффициент масштабирования равным 7, следовательно, размер видимого окна устанавливается в 
. Последовательная отправка поддельных ACK-сегментов обманывает Netfilter и увеличивает размер видимого окна до 
. С помощью окна такого размера можно покрыть все пространство в 2 32 номеров подтверждения, задействовав всего 512 значений. Если бы целью атаки являлся хост, работающий строго по RFC 793, то нарушителю можно было бы обойтись без знания размера окна жертвы и масштабирующего множителя. Можно предположить, что размер окна максимальный (1 ГБ), и путем последовательного деления пополам найти номер подтверждения.
Сводная информация о необходимых для атаки ресурсах приведена в таблице 3.
Зная подходящий номер подтверждения, с помощью бинарного поиска легко находится номер последовательности следующего октета, отсылаемого жертвой. Для этого необходимо log(max(66000, максимальный размер видимого окна отправителя)) запросов.
У нарушителя есть несколько способов узнать значение SND.NXT сетевого узла жертвы:
5.3 Другие случаи
6. Улучшенные методы сканирования
Метод также подходит для обнаружения номера одноразового порта хоста, который не отфильтровывает сегменты, принадлежащие несуществующему соединению, а вместо этого отвечает RST-сегментом на каждый такой сегмент. Последовательность поддельных сегментов, направленная на некорректный номер порта вызывает генерацию последовательности RST-сегментов, отбрасываемых на другом конце соединения без каких-либо дополнительных действий. Последовательность поддельных сегментов, направленная на корректный номер порта вызывает генерацию последовательности ACK-сегментов, которая, в свою очередь, вынуждает другую сторону выслать полное окно данных. Если нарушитель заметит скачок трафика, причиной которого служит отправка полного окна данных, то он также сможет определить порт.
На практике такой метод не проверялся.
7. Защита
Если аутентификация основывается на номерах последовательности, то иногда бывает сложно убедиться в том, что протокол никогда не отвечает на отброшенные сегменты. Номера последовательности предназначены для решения двух задач. В первую очередь они нужны для обнаружения дубликатов, потерянных и поврежденных сегментов. Но в дополнение к этому номера последовательности стали выступать в качестве защитного механизма от атаки, и такая функция не упоминается даже в исходной документации. Если Netfilter отфильтрует SYN-ACK сегменты, направленные на установленное соединение, и отбросит ACK-сегменты c некорректными номерами последовательности, то атака на систему, защищенную Netfilter’ом, вероятнее всего, окажется неудачной. Но составлять более строгие правила фильтрации нужно с особой аккуратностью, так как в противном случае иногда такие правила могут привести к зависанию соединения.
Выборочный пропуск ответов на отброшенные сегменты не должен делать утечку информации возможной на практике. Метод выборочного пропуска ответов для ACK-сегментов, генерируемых в ответ на RST и SYN-ACK сегменты, находящихся внутри окна, был предложен в работе [3]. Этот механизм эффективен только тогда, когда ACK-сегменты будут выборочно пропускаться в ответ и на другие отброшенные сегменты.
Атака упрощается, если нарушитель находится по ту же сторону от пограничного маршрутизатора, что и жертва. Расстояние в несколько близлежащих хопов также идеально подходит для фильтрации подмененных IP пакетов. Сеть, сконфигурированная отбрасывать подобный трафик, защищена, по крайней мере, от внутренней атаки.
Политика постановки в очередь, позволяющая изолировать трафик, идущий от различных пользователей, также может усложнить реализацию атаки. В работе [15] изучается политика диспетчеризации и защиты конфиденциальности. Авторам удалось значительно снизить влияние видов трафика различных пользователей в очереди друг на друга, не налагая дополнительных ограничений на производительность. Разработанная политика снижает утечки информации в зависимости от конкретного вида трафика, но поток трафика по-прежнему остается высоким из-за увеличения времени обработки пакета. Для реализации атаки, описанной в настоящей статье достаточно обнаружить увеличение потока трафика, когда как знать конкретный вид трафика необязательно. В дальнейших исследованиях необходимо оценить влияние различных политик постановки в очередь на эффективность атаки.
8. Заключение
Автор не ставит перед собой цель определить в работе практические ограничения для атаки. Осталось еще множество проблем для дальнейшего исследования, например в контексте ситуаций более неблагоприятных для нарушителя (низкая полоса пропускания между нарушителем и жертвой, постоянно загруженное “бутылочное горлышко”, разделяемое несколькими пользователями, различные политики постановки в очередь). Проведенные эксперименты могут послужить в качестве отправной точки для дальнейших исследований. В работе также не делается попыток провести детальное изучение эффективности атаки по отношению к распространенным реализациям протокола TCP. И наконец, работа в центр внимания ставит компрометацию TCP сессий, хотя предложенная атака может быть использована и для других случаев.