Этот метод служит логическим продолжением предыдущих двух методов, отличаясь от них усложнением задачи обнаружения сканирования. Суть его состоит в разбиении TCP SYN- или TCP FIN-зaпpoca на несколько маленьких IP-фрагментов (минимальный размер поля данных в IP-фрагменте 8 байт, следовательно, TCP SYN-запрос, имеющий минимальный размер 20 байт, можно разбить на три фрагмента). Однако у этого метода сканирования может быть незапланированный побочный эффект: некоторые некорректные реализации TCP/IP, получив подобные маленькие IP-фрагменты, вызывают сбой операционной системы.
Методы "невидимого" удаленного сканирования
Методом анонимного сканирования является метод, получивший название FTP Bounce Attack (скрытая атака по FTP). Протокол FTP имеет ряд недостаточно описанных функций, одна из которых – возможность создания так называемых "proxy" ftp-соединений с FTP-сервера. Если программная реализация FTP-сервера поддерживает режим proxy, то любой пользователь (и анонимный в том числе) может, подключившись к серверу, создать процесс DTP-server (Data Transfer Process – процесс передачи данных) для передачи файла с этого FTP-сервера на любой другой сервер в Internet. Функциональность данной возможности протокола FTP вызывает некоторое сомнение, так как в обычной ситуации ftp-клиент, подключающийся к серверу, передает и получает файлы либо непосредственно от себя, либо для себя.
Эта особенность протокола FTP позволяет предложить метод TCP-сканирования с использованием proxy ftp-сервера, состоящий в следующем: ftp-серверу после подключения выдается команда PORT с параметрами IP-адреса и TCP-порта объекта сканирования. Далее следует выполнить команду LIST, по которой FTP-сервер попытается прочитать текущий каталог на объекте, посылая на указанный в команде PORT порт назначения TCP SYN-запрос. Если порт на объекте открыт, то на сервер приходит ответ TCP SYN АСК и FTP-клиент получает ответы "150" и "226", если же порт закрыт, то ответ будет таким:
|
|
425. Can't Build Data Connection: Connection Refused (425. Невозможно установить соединение: в соединении отказано).
Далее в цикле FTP-серверу последовательно выдаются команды PORT и LIST и осуществляется сканирование разных портов.
Данный метод вплоть до конца 1998 года был единственным и поистине уникальным методом "невидимого" анонимного сканирования. Основная проблема взломщиков всегда состояла в невозможности скрыть источник сканирования, так как требовалось получать ответы на передаваемые запросы. Кроме того, в некоторых случаях межсетевой экран (МЭ) мог фильтровать запросы с неизвестных IP-адресов, поэтому данный метод совершил революцию в сканировании, так как, во-первых, позволял скрыть адрес злоумышленника и, во-вторых, давал возможность сканировать контролируемую МСЭ подсеть, используя внутренний расположенный за МСЭ ftp-сервер.
Сканирование с использованием "немого" хоста
Оригинальное название метода Dumb host scan переводится как "сканирование с использованием "немого" хоста". Основные положения, лежащие в основе метода (рис. 5.1), cостоят в следующем:
· с каждым переданным пакетом значение ID в заголовке IP-пакета обычно увеличивается на 1;
· хост отвечает на TCP SYN-3aпpoc TCP SYN ACK, если порт открыт; и TCP RST, если порт закрыт;
· существует возможность узнать количество пакетов, переданных хостом, но параметру ID в заголовке IP;
|
|
· хост отвечает TCP RST на TCP SYN ACK и ничего не отвечает на TCP RST.
Рис. 1. Сканирование методом Dumb host scan с открытым (слева) и закрытым (справа) портом X на хосте C
Рассмотрим, как работает данный метод.
Пусть X-Hacker - узел атакующего, откуда осуществляется сканирование, объект B – "тихий" узел (обычный узел, который не будет передавать пакеты, пока происходит сканирование узел C; таких узлов вполне достаточно в Internet), а узел C – объект сканирования. Узел X-Hacker при помощи, например, утилиты hping контролирует число исходящих от узла B пакетов по ID из заголовка IP,
ID увеличивается с каждым пакетом на 1, следовательно, узел B – именно тот "тихий" узел, который нужен взломщику.
X-Hacker посылает TCP SYN-запрос на порт Х узла C от имени B (автор метода предлагает для этого использовать утилиту hping с его сайта https://www.kyuzz.org/antirez, но можно применять и любые другие программные средства). Если порт X узла C открыт, то узел C пошлет узлу B ответ TCP SYN АСК (узел C не может знать, что этот пакет на самом деле пришел от X-Hacker). В этом случае объект B в ответ на TCP SYN АСК ответит на C пакетом TCP RST. Если атакующий пошлет на C определенное количество TCP SYN от имени узла B, то B, получив несколько TCP SYN АСК, ответит столькими же TCP RST, и на узле X-Hacker будет видно, что B посылает пакеты, следовательно, порт Х открыт.
Поле Identification (IP ID) в заголовке IPv4 показывает какой фрагмент содержит дейтаграмма при сборке фрагментов пакета. Спецификация IPv4 не задает порядок присвоения значений идентификатора, указывая лишь, что каждому пакету следует давать уникальное для пары отправитель-получатель и используемого протокола значение IP ID. Уникальность должна обеспечиваться в течение интервала времени, которое дейтаграмма (или любой из ее фрагментов) могут находиться в сети. Это означает, что присвоение значений IP ID может выполняться различными путями, которые мы будем делить на три класса:
|
|
Sequential jump — нарастание
Это наиболее распространенная политика присвоения идентификаторов в современных вариантах стека IP. Один счетчик IP ID используется для всех потоков пакетов. Когда отправитель работает с множеством потоков одновременно, значение IP ID между последовательными пакетами одного потока может увеличиваться более, чем на 1. Значения IP ID являются легко предсказуемыми, для их передачи требуется меньшее количество битов, а увеличение идентификатора от пакета к пакету (определяется числом активных потоков исходящих пакетов и частотой передачи) обычно бывает ограничено.
Random — случайные значения
Некоторые варианты стека IP используют в качестве IP ID псевдослучайные значения. В этом случае отсутствуют корреляции между значениями ID в последовательных пакетах. Следовательно, отсутствует возможность предсказать значение IP ID для следующей дейтаграммы. С точки зрения компрессии заголовков это означает, что поле IP ID нужно передавать без сжатия, что приводит к использованию двух лишних октетов в сжатом заголовке. Реализациям стека IP в терминалах сотовых сетей требуется эффективная компрессия, поэтому им не следует использовать данный вариант задания значений IP ID.
Sequential — равномерное увеличение
В этом варианте используется отдельный счетчик для каждого исходящего потока пакетов и значения IP ID будут увеличиваться на единицу для каждого следующего пакета (за исключением случаев достижения максимума и возврата к началу отсчета). Следовательно, изменение значения этого поля постоянно и заранее известно. Такой вариант присвоения идентификаторов наиболее подходит для сжатия заголовков. Однако его использование не столь широко, как следовало бы ожидать.
Во избежание нарушения требований спецификации RFC 791 [1], пакеты, использующие одну пару адресов «отправитель- получатель» и номер протокола IP, не могут иметь одинаковых значений IP ID. Следовательно, при выделении значений идентификатора по порядку нужно разделять значения идентификаторов для разных потоков одного протокола между одной парой конечных точек. Это можно сделать разными путями, каждый из которых использует случайные пропуски в порядке нумерации, что делает распределение идентификаторов не вполне последовательным. С точки зрения компрессии желательно реже использовать пропуски в значениях идентификаторов.
Отметим, что эти идентификаторы используются только в IPv4 и, следовательно, не рассматриваются в IPv6. Для IPv4 поля ID могут обрабатываться тремя разными способами. Во-первых, имеется малоэффективное, но надежное решение, в котором поле идентификации передается без изменений во всех пакетах, что ведет к увеличению сжатых заголовков на 2 октета. Этот способ является наилучшим вариантом обработки полей ID в иех случаях, когда отправитель использует случайные значения ID. Во-вторых, может использоваться более гибкий механизм, который обеспечит снижение числа битов для полей ID при нарастающей (sequential jump) нумерации. Такие механизмы могут в некоторых случаях увеличивать число требуемых битов при использовании отправителем случайных значений идентификаторов. Следовательно, информация об используемом отправителем механизме выделения идентификаторов полезна при выборе между двумя упомянутыми выше решениями. Наконец, даже для IPv4 могут быть созданы схемы компрессии, не включающие в сжатый заголовок никакой дополнительной информации о поле ID. Для использования таких схем нужно знать какой из механизмов выделения значений поля ID применяется отправителем. Получение такой информации возможно не во всех случаях, что ведет к весьма редкому применению таких механизмов. Однако разработчикам стеков IPv4 для терминалов сотовых сетей следует использовать политику выделения идентификаторов, близкую к последовательной.
В контексте компрессии TCP поведение поля IP ID остается таким же. Однако в RFC 3095 [31] значения IP ID в общем случае получаются из порядковых номеров RTP. Для случая TCP нет подходящего кандидата на роль «ведущего порядкового номера».
Очевидно, что наблюдаемое поведение загруженного сервера может быть достаточно изменчивым. В некоторых случаях возможность совместного использования контекста компрессии IP для множества потоков (между одной парой конечных точек) может давать некоторые преимущества. Однако реальное воздействие может наблюдаться лишь в случаях использования большого числа потоков между конкретной машиной и сервером. Если рассматривается совместное использование контекста, предпочтительным будет совместное использование связанной с IP части контекста.