5. Синтаксис файла с описанием пакетов

Программа
пользователя
AnetTest.
Руководство
Содержание
1. Общее описание ...................................................................................................... 1
2. Термины и определения .......................................................................................... 2
3. Инсталляция ........................................................................................................... 2
3.1. Инсталляция для Windows XP .............................................................................. 2
3.2. Инсталляция для UNIX ........................................................................................ 3
4. Режимы работы ....................................................................................................... 3
4.1. Генератор пакетов.............................................................................................. 3
4.2. Отслеживание пакетов ....................................................................................... 4
4.3. Тест пакетного фильтра ...................................................................................... 5
4.4. Расширенный режим ........................................................................................... 7
4.5. Чередование посылки и приема пакетов .............................................................. 7
4.6. Режим сниффера ................................................................................................ 7
4.7. Автоматизация тестов ......................................................................................... 8
4.8. Изменение trace файлов ..................................................................................... 8
4.9. Имитация работы приложений............................................................................. 8
5. Синтаксис файла с описанием пакетов ................................................................... 14
5.1. Типы значений полей ....................................................................................... 15
5.2. Автоматические значения ................................................................................. 17
5.3. Создание своих заголовков ............................................................................... 17
5.4. Сборка заголовков ........................................................................................... 18
5.5. Размер генерируемого пакета ........................................................................... 19
5.6. Маска пакета ................................................................................................... 19
5.7. Команды скрипта ............................................................................................. 21
Таблица 1. Опции и режимы работы программы .................................................................. 11
1. Общее описание
Программа может использоваться как генератор пакетов. Генерировать можно
любые пакеты на канальном уровне (только для сетей Ethernet), некоторые типы пакетов
на сетевом (протокол IP) и на прикладном (посылка нужных данных в рамках TCP сессий).
Описания пакетов можно хранить в текстовых файлах или передавать
непосредственно в командной строке. Синтаксис описания достаточно прост (имя поля значение).
Программа позволяет определять свои заголовки. Описания заголовков можно
хранить в отдельных заголовочных файлах, включая их в свои описания пакетов. Кроме
числовых типов данных предлагаются строковые типы, IP адрес, MAC адреса.
Генерацию одних пакетов можно чередовать с ожиданием других. В случае
ожидания пакетов задается маска пакета аналогично тому, как это делается для
снифферов.
Можно использовать программу как сниффер. Если описать в файле набор
пакетов, то программа может быть сканером сети на предмет наличия указанных пакетов.
Через заданные интервалы времени будут выводится отчеты об общем количестве и
интенсивности пакетов каждого типа.
Можно использовать программу для построения автоматизированных тестов
различных сетевых устройств и приложений. Это достигается тем, что при описании
1
пакетов можно указывать требования к каждому из них, в соответствии с которыми эти
пакеты будут искаться в переданных программе trace-файлах, или же в реальном времени
будет сканироваться сеть. В общем случае можно будет генерировать наборы пакетов,
ожидая реакцию различных устройств и сетевых приложений на эти пакеты и получать в
качестве результата либо сообщение “Successful test ”, либо список несоответствий.
Программа позволяет изменять trace файлы, путем использования специальных
команд.
2. Термины и определения
Главный интерфейс – по умолчанию первый интерфейс, указанный с помощью
опции –d. С этого интерфейса будет происходить генерация пакетов. Для некоторых
специальных команд именно на этом интерфейсе пакеты будут ожидаться (команда
WAIT). Его можно менять с помощью команды MI.
Маска пакета – часть описания пакета, которая будет использована при сравнении
данного пакета с каким-либо другим принятым на физическом интерфейсе или из traceфайла. В самом простом случае маска состоит из тех полей, для которых были указаны
значения при описании пакета. Только значения этих полей будут учитываться при
сравнении пакета с другим. Подробнее о маске пакета.
Приемные интерфейсы – сетевые интерфейсы компьютера или trace – файлы, т.е.
пакеты могут отслеживаться в реальном времени, или браться из trace–файлов,
переданных программе. Логика работы программы при этом не меняется. Требования к
пакету будут относиться к приемным интерфейсам. В большинстве режимов работы
приемные интерфейсы – открытые физические интерфейсы (идут в том же порядке, в
каком они переданы через опцию -d). При online-тесте первый открытый физический
интерфейс становится главным, остальные будут приемными.
Требования к пакету – список требований вроде «принят» (accept, >>), «не
принят» (drop, <<), «не имеет значения» (any). Может быть указан для любого пакета.
Каждое требование соответствует одному приемному интерфейсу. Первое в списке –
для первого приемного интерфейса, второе – для второго и т.д. Указываются как
параметры в командах SEND и WAIT. Подробнее можно почитать здесь.
Синтаксис списка:
<требование> ::= “<<” | “>>” | “DROP” | “ACCEPT” | “ANY”
<список требований> ::= {<требование>}
При работе в расширенном режиме список требований другой.
Пользовательский номер интерфейса – номер, который является именем
интерфейса и используется при выводе различной информации. О том, как его можно
указать написано в описании опций –d и –c.
3. Инсталляция
3.1.
Инсталляция для Windows XP
Необходимо наличие дистрибутива anettest_win32.
Перед работой с программой потребуется сначала установить библиотеку WinPcap
(версия 3.1 и выше).
Для инсталляции требуется разархивировать архив дистрибутива в постоянную
папку, где будет находиться программа. После этого можно сразу начать работу с
anettest.exe. Для удобства работы можно использовать файл registry.reg, который
находится в дистрибутиве. В нем можно прописать путь поиска заголовочных файлов
(путь к папке, в которой находится исполняемый файл anettest.exe, папки headers и
samples), тип сетевого устройства, используемого по умолчанию, а также само имя
интерфейса (IP адрес). После изменения файла его нужно применить, кликнув по нему и
ответив утвердительно на вопрос системы о подтверждении добавления информации в
реестр. После такой «инсталляции» можно будет не указывать при каждом запуске
программы путь поиска заголовочных файлов и имя интерфейса. Если при запуске
программы не будет указано ни одного интерфейса, то автоматически будет открыт
выбранный по умолчанию.
2
Далее можно запустить программу из командной строки (находясь в папке с
программой)
anettest icmp srcip 1.1.1.1
anettest tcp dstport 80 dstip host_name
Если
возникают
какие-то
проблемы,
значит,
инсталлирована, и придется прочитать об опциях -d, -I.
3.2.
программа
некорректно
Инсталляция для UNIX
Необходимо наличие дистрибутива anettest_unix.
В папке дистрибутива найдите исполняемый файл INSTALL, который произведет
инсталляцию.
При работе с программой можно использовать системный сценарий ant.
В системных сценариях ant0, ant1, ant2 автоматически открывается один из
сетевых адаптеров (eth0, eth1, eth2).
После инсталляции попробуйте запустить программу
ant -d eth0 icmp srcip 1.1.1.1
Во всех примерах далее вместо anettest можно использовать ant.
4. Режимы работы
Все опции и режимы работы описаны в таблице 1.
Далее приведен обзор основных режимов с примерами.
4.1.
Генератор пакетов
Для генерации пакетов можно запустить программу одним из следующих способов:
anettest –d eth0 –f packets.fws
anettest –d 10.0.0.1 –f packets.fws
anettest –d eth0 tcp dstip 1.1.1.1 dstport 80
Через опцию –d указывается имя сетевого адаптера для работы на канальном
уровне (например eth0). Можно в начале работы посмотреть список доступных адаптеров,
запустив anettest с единственной опцией –i. Вместо имени адаптера можно указать
присвоенный ему IP-адрес (показано во втором варианте). Присвоенные адаптерам IPадреса можно также посмотреть, используя опцию –i.
Описание пакетов можно хранить в текстовом файле, указывая его программе
через опцию –f (показано в первых двух вариантах).
Файл packets.fws может быть таким:
include tcp.fws
srcip lpc10
dstip 1.1.1.1
dstport 80
SEND
Перед описание своего пакета желательно включить один из заголовочных файлов
с помощью команды include. Вместо include tcp.fws можно бы было написать просто tcp, и
программа попыталась бы найти похожий заголовочный файл. Заголовочный файл tcp.fws
включает в себя и другие заголовочные файлы так, что значения всех полей каждого
сетевого заголовка (Ethernet, IP, TCP) заполняется корректными значениями по
умолчанию, иначе бы эти значения были просто равны 0. В показанном примере после
включения заголовочного файла значения трех полей (с именами srcip, dstip, dstport)
изменяются так, как нужно для конкретного пакета. Команда SEND генерирует описанный
перед ней пакет. После команды SEND можно бы было продолжить описание пакета, т.е.
изменить значения некоторых полей, а потом опять использовать команду SEND, чтобы
послать второй пакет, немного отличающийся от первого. Подробнее о синтаксисе
сценария с описанием пакетов читайте в соответствующем разделе.
3
В дистрибутиве программы должна находиться папка HEADERS с заголовками
сетевых протоколов. Имена полей сетевых заголовков можно посмотреть в заголовочных
файлах или использовать опцию -k. Просмотрев эти файлы, можно будет уже попробовать
сгенерировать свои пакеты, основываясь на примере, который приведен выше.
Описание пакета можно передать непосредственно в командной строке, как
показано в третьем варианте запуска. Единственная особенность: к концу описания
пакета автоматически добавляется команда послать пакет (SEND) для того, чтобы не
приходилось каждый раз ее писать. В третьем варианте запуска “tcp” означает включение
заголовочного файла (воспринимается как часть описания пакета в командной строке).
Далее задаются значения двух полей IP и TCP заголовка. Таким образом, то, что не
похоже на опцию программа принимает за описание пакета.
В папке SAMPLES можно найти файлы-примеры, начинающиеся со слова generate
(generate_udp_packet.fws, generate_sequence_packets.fws).
Подробнее о генерации пакетов: опции -T (работа на уровне TCP сессий), -p
(работа на сетевом уровне).
4.2.
Отслеживание пакетов
Программа реализует одну из стандартных функции снифферов – отслеживание
пакетов и запись их в файл. Программа не выводит описание пакетов, а только
записывает их содержимое в файл (формат файла libpcap). Адаптер указывается через
опцию –d. Имя файла для записи задается через опцию –t. Содержимое пакета
записывается целиком.
Пример запуска:
anettest –d eth0 –t trace.pcap
Внимание: если интенсивности пакетов будет слишком высока в течение
достаточно большого промежутка времени, то некоторые пакеты могут быть не
зарегистрированы (не записаны в файл). Тем не менее, общее число пакетов, принятых
на главном интерфейсе, которое будет выведено в конце работы программы, покажет
действительное число принятых пакетов.
Total number of packets recieved on first interface = 1
4
4.3.
Тест пакетного фильтра
Это режим для проведения автоматизированных тестов, когда последовательности
различных пакетов нужно не только генерировать, но и отслеживать эти пакеты в
нескольких сегментах сети, причем не хочется каждый раз визуально просматривать
вывод программ-снифферов и делать выводы об успешности теста. Предполагается, что
будут ожидаться те же пакеты, что и генерируются, т.е. проверяется, проходят ли они с
одного физического интерфейса на другой. Этот режим специально предназначен для
более удобного тестирования пакетных фильтров.
Если все интересующие сегменты (физические интерфейсы), где необходимо
отслеживать пакеты, можно подключить к одному компьютеру, то возможно выполнение
быстрого теста, когда параллельно с генерацией пакетов происходит их отслеживание, и
сразу после генерации всех пакетов можно получить результат теста (online-тест). Если
сегменты сети подключены к разным хостам, то во время генерации пакетов с одного
хоста необходимо отслеживать пакеты на других хостах, записывая их в trace-файлы, а
затем собрать все эти файлы на одном компьютере и провести offline-тест. Оба теста
будут описаны далее.
Файл с описанием пакетов, который задается через опцию –f, может выглядеть так:
fasttest
INCLUDE tcp
// нужно всегда вставлять вначале в случае online-теста
fullmask
tcp.flags = syn
dstport http
send drop accept
dstport ssh
send accept drop
dstport ftp
send drop accept
Здесь описано три пакета. Они отделены друг от друга командой SEND. Эта
команда не во всех режимах генерирует пакеты, а иногда просто служит для отделения
пакетов друг от друга. Пакеты отличаются значениями TCP порта назначения (dstport).
Также явно указано значение флагов TCP (tcp.flags), которое будет одинаковым для всех
пакетов. Значения остальных полей определяются содержимым заголовочного файла tcp.
После каждой команды SEND указано несколько требований к пакету (ACCEPT или
DROP). Подробнее о синтаксисе написано в другом разделе.
О команде FULLMASK сказано чуть далее.
Offline-тест
Перед запуском offline-теста надо параллельно запустить генератор пакетов на
одном компьютере, например:
anettest –f packets.fws –d eth0
и снифферы на других компьютерах, например:
anettest –d eth0 –t trace1.fws
anettest –d eth0 –t trace2.fws
anettest –d eth0 –t trace3.fws
затем собрать все полученные trace-файлы в одном месте и провести offline-тест:
anettest –f packets.fws –c trace1 –c trace2 –c trace3
Во время offline-теста каждый из пакетов, описанных в сценарии packets.fws, будет
искать в trace-файлах. При сравнении пакетов используется маска пакета. Результат
5
поиска сопоставляется с требованиями к пакету, о которых упомянуто ранее. Первое
требование после команды SEND будет относиться к файлу trace1, второе и третье – к
файлам trace2 и trace3. ACCEPT – означает, что пакет должен быть найден в trace-файле,
DROP – наоборот. Таким образом, программа проверяет соответствие требований,
прописанных в файле packets.fws, и содержимого trace-файлов. Будет выведено
сообщение о том, что все требования выполнены, или список несоответствий.
Режим offline-теста всегда включается опцией –с.
Online-тест
Trace-файл является частным случаем приемного интерфейса. Файлы trace1,
trace2, trace3 были соответственно первым, вторым и третьим приемными интерфейсами.
Ранее был показан пример offline-теста с использованием trace-файлов. Для
быстрого online-теста необходим только один запуск:
anettest –f packets.fws –d eth1#1 –d eth2#2 –d eth3#3
После символа # указывается пользовательский номер интерфейса.
Для проведения данного теста в самом начале файла packets.fws должна стоять
команда FASTTEST, которая включает режим online-теста. Если не использовать эту
команду, то пакеты из сценария будут просто сгенерированы.
После описанного запуска пакеты будут генерироваться с интерфейса eth1
(главный интерфейс) и регистрироваться на приемных интерфейсах: eth2, eth3. Первое
требование будет относиться к eth2, второе – eth3. В других режимах работы (режим
сниффера, использование команды WAIT в режиме генератора пакетов) все открытые
физические интерфейсы являются приемными, т.е. первое требование относилось бы к
eth1. Только в данном режиме происходит смещение.
Во время теста сначала будут запущены снифферы на всех интерфейсах, затем
произойдет моментальная генерация сразу всех пакетов из сценария на главном
интерфейсе. После генерации пакетов снифферы будут остановлены, и будет выполнен
поиск пакетов из сценария среди зарегистрированных снифферами пакетов (аналогично
поиску в trace-файлах).
Пауза между запуском снифферов и началом генерации пакетов = 100 мс.
Пауза между окончанием генерации пакетов и остановкой снифферов = 200 мс.
Если пакеты в начале или в конце списка оказываются не принятыми (хотя на
самом деле они просто доходят либо слишком быстро, либо слишком медленно)
попробуйте увеличить паузы с помощью команды PAUSE сценария, вставив ее в начале
или в конце.
Отчеты
Вывод программы для любого типа теста может быть таким:
Packet on line 10 (./test.fws) : accepted (dev 2)
Packet on line 14 (./test.fws) : droped (dev 2)
Packet on line 19 (./test.fws) : accepted (dev 2)
Для каждого найденного несоответствия приводится имя файла и строка в файле,
где встречено описание пакета (точнее позиция команды SEND, перед которой идет
описание пакета), результат поиска для конкретного приемного интерфейса (номер
интерфейса указывается в скобках). Будет указан либо пользовательский номер
интерфейса (с пометкой dev), если он был указан в опции –d, либо его
последовательный номер в соответствии с порядком открытия интерфейсов (с пометкой
sdev).
Команда NAME позволяет задать свое имя для пакета, которое будет выводиться в
отчете.
Команда REP позволяет указать требование приема не одного, а нескольких
пакетов.
Замечание:
Если в предыдущем примере не использовать команду FULLMASK, то при
сравнении пакетов будут гарантировано учитываться только поля, значения
которых указаны в файле (tcp.flags, dstport). Поля tcp заголовка (и других), значения
6
которых указаны в заголовочном файле tcp.fws, могут не участвовать в сравнении, т.к. в
стандартные заголовочные файлы включена команда RESET (это сделано для удобства
работы в других режимах программы). Таким образом, можно не заметить некоторого
изменения содержимого пакетов на пути следования или принять «левые» tcp пакеты за
свои.
См. примеры samples\compare_mode.fws и samples\compare_mode1.fws.
См. пример samples\fasttest.fws.
4.4.
Расширенный режим
Расширенный режим необходим, когда пакеты во время теста должны посылаться с
разных интерфейсов.
Включается командой EXTENDED.
В этом режиме главный интерфейс можно менять (команда MI). Таким образом, в
одном сценарии можно генерировать пакеты с разных физических интерфейсов.
Требования для пакетов в этом режиме должны указываться иначе:
<требование1> ::= “DROP” | “ACCEPT” | “ANY”
<требование2> ::= “<<” | “>>”
<требование для интерфейса> ::= (<требование1> “ “ <пользовательский
номер интерфейса>)|(<требование2> [“ “] <пользовательский номер
интерфейса>)
<список требований> ::= {<требование для интерфейса>}
То есть после каждого требования должен идти пользовательский номер
интерфейса, к которому это требование относится.
Пример:
SEND <<0 >>1 <<2
SEND ANY 2 ACCEPT 1 DROP 0
Аналогично должны указываться требования в команде DEFAULTS, в командах
аналогичных WAIT.
4.5.
Чередование посылки и приема пакетов
Чередование посылки и приема пакетов можно осуществить в общем режиме
работы программы. Посылаемые и ожидаемые пакеты могут быть разными. Тест можно
растянуть во времени с помощью команды PAUSE. Можно выбирать моменты начала
ожидания того или иного пакета.
Программу следует запустить в обычном режиме:
anettest –d eth0 –f packets.fws
Генерировать пакеты можно командой SEND, не указывая требований после нее.
Ожидать пакеты можно командами WAIT, OR, WAITALL. Можно указывать таймаут
ожидания командой TIMEOUT.
Результаты ожидания пакетов, что были добавлены командами WAIT или OR, будут
выведены в отчете.
4.6.
Режим сниффера
Сниффер будет выводить статистику для пакетов, описанных
в сценарии,
показывать их интенсивность (по числу пакетов и количеству данных) в реальном
времени, выводя периодически отчет. Этот режим также является альтернативой тесту
пакетного фильтра, так как выводится информация о соответствии текущего состояния
сети требованиям, прописанным в сценарии. Как и в тесте пакетного фильтра пакеты
разделяются командой SEND, после которой можно указать требования к пакету.
Пример запуска программы:
anettest -d eth0 -r –v srcport 22
Программа в этом случае будет считать и показывать интенсивность пакетов с
номером порта источника 22. Режим сниффера включается с помощью опции –r.
7
Используемый сетевой адаптер указывается через опцию –d. Описание пакета в данном
примере приведено в командной строке. Можно описать несколько пакетов в файле
(опция -f), тогда программа будет периодически выводить информацию о каждом из
пакетов в виде таблицы (отчета). Для работы в этом режиме следует понимать понятие
маски пакета, потому что именно она должна быть описана для каждого пакета.
В предыдущем примере в концу описания пакета автоматически добавляется
команда SEND (как и в режиме генератора пакетов).
Приемными интерфейсами будут ВСЕ открытые физические интерфейсы,
указанные через опцию –d. В отличие от теста пакетного фильтра в режиме сниффера
первый сетевой адаптер, который указывается через опцию –d, будет являться и первым
приемным интерфейсом (т.е. первое требование к пакету будет относиться к нему). Все
последующие адаптеры будут считаться вторым, третьим… приемными интерфейсами. Это
отличие следует учитывать при задании требований в командах SEND и DEFAULTS.
Если не использовать опцию –v, то будет выводиться только информация о
пакетах, для которых не выполнены требования (как в тесте пакетного фильтра).
Периодические отчеты программы в этом режиме аналогичны отчетам в тесте пакетного
фильтра. Синтаксис файла с описанием пакетов также аналогичен.
См. пример tracing_packets.fws в папке SAMPLES.
Подробнее о режиме сниффера: опция –r (включение режима сниффера), -u
(изменение периода вывода отчетов).
4.7.
Автоматизация тестов
Для автоматизации тестов можно использовать как тест пакетного фильтра, так и
режим сниффера.
В случае offline-теста для теста пакетного фильтра необходимо вручную или через
автоматизированную систему синхронно запускать генератор пакетов и снифферы на
различных компьютерах, а потом собирать вместе полученные trace-файлы. При запуске
генератора пакетов и при непосредственном offline-тесте (запуск программы с опцией –c)
можно использовать один и тот же файл с описанием пакетов.
Если удается все сегменты сети подключить к единственному компьютеру, то можно
провести простой online-тест.
Режим сниффера – некоторая альтернатива тесту пакетного фильтра, когда
удобней держать постоянно запущенный сканер сети, а источник(и) пакетов работает
абсолютно независимо от него.
Работа с генератором пакетов в расширенном режиме и с использованием
команды WAIT и ее аналогов позволяет реализовать наиболее гибкие тесты.
4.8.
Изменение trace файлов
Программа позволяет изменять trace файлы (формата libpcap) с помощью
специальных команд. Trace файл может быть открыт командой TRACE. Чтобы записать
измененный файл на диск есть команда WRITE.
После открытия файла можно воспользоваться рядом простых команд:
getpac – загружает пакет из файла в текущий описываемый пакет;
setpac – записывает текущий пакет в файл поверх существующего;
inspac – вставляет новый пакет в файл;
delpac – удаляет пакет из файла.
Существует еще одна команда для изменения сразу нескольких пакетов: chtrace.
См. примеры samples\work_with_traces.fws, samples\work_with_traces1.fws.
4.9.
Имитация работы приложений
Имитация работы приложений выполняется в соответствии с информацией из trace–
файла (указывается командой trace).
Во время теста программа имитирует работу одного или нескольких сетевых
приложений, посылая пакеты в строгой последовательности с разных физических
интерфейсов, соответствующих каждому из приложений. Программа не только посылает
пакеты, но и следит, чтобы они были успешно приняты. В требованиях к результатам
теста можно указать, какие пакеты должны быть приняты, а какие нет. Программа может
посылать пакеты с одного физического интерфейса и ожидать их на другом. При этом
8
предполагается, что между физическими интерфейсами находится промежуточная точка,
которая не пропускает некоторые пакеты.
Перед запуском имитации всегда нужно сначала определить конечные точки (см.
команду EP).
Во время имитации пакеты из trace-файла просматриваются последовательно.
Каждая генерирующая конечная точка может послать свой пакет, только когда все
предыдущие пакеты приняты ожидающими конечными точками. Если ожидающая
конечная точка ждет нужного пакета слишком долго, то будут повторно сгенерированы
все пакеты после последнего успешно принятого одной из ожидающих конечных точек.
После нескольких повторных генераций пакет будет отмечен как отброшенный, и тест
будет продолжен. Ожидается всегда один определенный пакет. Когда пакет приходит (или
отмечается как отброшенный), осуществляется переход к следующему пакету. Будут
ожидаться только пакеты, принадлежащие одной из ожидающих конечных точек, только
на интерфейсе, указанном для соответствующей конечной точки. Таким образом,
ожидание пакетов синхронизирует процесс их посылки.
Каждый пакет может принадлежать только одной генерирующей конечной точке и
одной ожидающей. Если ожидающих конечных точек не указано, то пакеты будут просто
сгенерированы, если генерирующих конечных точек не указано, то пакеты будут просто
ожидаться. Таким образом, можно запустить две стороны имитатора на разных хостах. На
этот случай таймаут для первого пакета увеличен до 3 секунд, чтобы после запуска
ожидания успеть запустить посылку пакетов.
Сконфигурированный тест запускается командой RUN.
Программу можно запустить в общем режиме:
anettest –d eth0#0 –d eth1#1 –f session_test.fws
После проведения первого теста можно сбросить его конфигурацию командой
DEFAULTTEST.
Если некоторая промежуточная точка меняет пакеты определенным образом по
пути следования, то можно использовать команду RM.
Если перед началом теста неизвестно, как промежуточная точка будет менять
пакеты, но это станет известно во время теста, то можно использовать команду ARM.
Если значения некоторых полей пакетов не нужно учитывать при сравнении, то
можно использовать команду CIEVE.
Количество повторных посылок: команда NUMRET.
Таймаут повторной посылки: команда TIMEOUT.
Пример:
Содержимое trace-файла:
1 0.000000
194.85.99.33
Seq=0 Len=0 WS=1
2 0.013321
88.210.60.143
ACK] Seq=0 Ack=1
3 0.013750
194.85.99.33
Seq=1 Ack=1
4 0.030554
88.210.60.143
imap.r-and-k.com ESMTP
5 0.030996
194.85.99.33
Seq=1 Ack=37
6 0.032663
194.85.99.33
xperts1.rtc.ru
7 0.046934
88.210.60.143
imap.r-and-k.com
88.210.60.143
TCP
54840 > smtp [SYN]
194.85.99.33
TCP
smtp > 54840 [SYN,
88.210.60.143
TCP
54840 > smtp [ACK]
194.85.99.33
SMTP
Response: 220
88.210.60.143
TCP
54840 > smtp [ACK]
88.210.60.143
SMTP
Command: EHLO
194.85.99.33
SMTP
Response: 250-
Конфигурация теста (см. команду EP):
// генерирующая конечная точка 1
ep gen 0 srcip 194.85.99.33 // посылка пакетов для клиента на
интерфейсе 0
// генерирующая конечная точка 2
9
ep gen 2 srcip 88.210.60.143 // посылка пакетов для сервера на
интерфейсе 2
// ожидающая конечная точка 3
ep recv 2 srcip 194.85.99.33 // ожидание пакетов для для клиента на
интерфейсе 2
// ожидающая конечная точка 4
ep recv 0 srcip 88.210.60.143 // ожидание пакетов для сервера на
интерфейсе 0
Эту же самую конфигурацию можно записать так:
// генерирующая конечная точка 1
ep gen 0 srcip first // посылка пакетов для для клиента на интерфейсе
0
// генерирующая конечная точка 2
ep gen 2 srcip second // посылка пакетов для сервера на интерфейсе 2
// ожидающая конечная точка 3
ep recv 2 srcip first // ожидание пакетов для для клиента на
интерфейсе 2
// ожидающая конечная точка 4
ep recv 0 srcip second // ожидание пакетов для сервера на интерфейсе 0
При начале имитации будет сначала найден пакет, который следует ожидать. Это
пакет 1, принадлежащий конечной точке 3. Пакет будет ожидаться на интерфейсе 2.
Затем будет найден пакет, который следует сгенерировать. Это пакет 1, принадлежащий
конечной точке 1.
Пакет 1 будет сгенерирован на интерфейсе 0. Следующий пакет, который нужно
сгенерировать – это пакет 2, принадлежащий конечной точке 2. Этот пакет не может быть
сгенерирован, пока ожидается пакет 1 на интерфейсе 2. Когда пакет 1 будет принят на
интерфейсе 2, то будет осуществлен переход к следующему ожидаемому пакету. Это
пакет 2, принадлежащий конечной точке 4. После такого перехода пакет 2 может быть
сгенерирован конечной точкой 2.
Если пакет 1 не будет принят в течение таймаута на интерфейсе 2, то пакет 1 будет
повторно сгенерирован на интерфейсе 0. После нескольких повторных генераций пакет 1
может быть отмечен как отброшенный и начнет ожидаться пакет 2.
Полное содержимое тестового сценария может выглядеть следующим образом:
trace smtp_client.pcap
// генерирующая конечная точка 1
ep gen 0 srcip 194.85.99.33 // посылка пакетов для клиента на
интерфейсе 0
// генерирующая конечная точка 2
ep gen 2 srcip 88.210.60.143 // посылка пакетов для сервера на
интерфейсе 2
// ожидающая конечная точка 3
ep recv 2 srcip 194.85.99.33 // ожидание пакетов для для клиента на
интерфейсе 2
// ожидающая конечная точка 4
ep recv 0 srcip 88.210.60.143 // ожидание пакетов для сервера на
интерфейсе 0
run drop 6-
// пакеты, начиная с 6 должны быть не приняты
См. также примеры samples\convtest1.fws, samples\convtest2.fws.
Стандартная конфигурация имитации сессии клиент-сервер представлена в файле
headers\configSession.fws.
Стандартная конфигурация имитации сессии клиент-сервер при использовании NAT
– файл headers\natConfigSession.fws.
Конфигурация NAT должна храниться в файле headers\natDefines.fws.
10
Таблица 1. Опции и режимы работы программы
Название
Список
адаптеров (-i)
Выбор
адаптера (-d)
Работа с traceфайлами
(-c)
Запись в файл
(отслеживание
пакетов)
(-t)
Сценарий
(-f)
Описание
Пример
Имеется в виду только список адаптеров для
генерации и отслеживания пакетов на канальном
уровне. После номера адаптера идет его имя, а в
дальнейшем описании можно найти присвоенный
ему IP адрес.
В опции нужно указать имя открываемого
адаптера. По умолчанию открываются адаптеры
для работы на канальном уровне (опции –p, -T
позволяют это изменить). Адаптер можно указать
по его имени или IP адресу (DNS имени). Можно
сначала посмотреть список адаптеров для работы
на канальном уровне (опция -i). Для простой
генерации пакетов нужно открыть один адаптер
(главный интерфейс). Имя адаптера может
содержать символ #, после которого указывается
пользовательский номер адаптера. Этот номер
будет использоваться при выводе различной
информации пользователю.
AnetTest –i
В опции нужно указать имя одного или
нескольких открываемых файлов с отслеженными
пакетами – trace-файлов - в формате libpcap.
Переданные файлы будут выступать как первый,
второй и последующие приемные интерфейсы.
Каждый пакет из файла сценария (задается с
помощью опции –f) по команде SEND будет
искаться в trace-файлах. Результаты поиска будут
сопоставляться
с
требованиями
к
пакету,
указанными в команде SEND.
Если указана хотя бы одна опция -c, то программа
будет работать в тесте пакетного фильтра.
Если в trace-файле размер сохраненной части
пакета меньше, чем размер пакета из скрипта, то
пакеты сразу считаются не равными. Каким бы
сниффером не пользовались, позаботьтесь о том,
чтобы он сохранял достаточно большую часть
пакета (традиционно опция –s у снифферов).
Если в имени trace-файла встречается число, то
оно
становится
пользовательским
номером
интерфейса, который будет встречаться при
выводе статистики.
Читайте также про правила описания пакетов
для данного режима.
В опции нужно указать имя trace-file, в который
будет
производится
запись
информации
о
пакетах. Копируются пакеты полностью. Формат
полученного файла libpcap.
Сценарий работы программы (описание пакетов и
др.). В большинстве режимов работы его нужно
задавать.
Описание
синтаксиса
сценария
приведено
в
отдельном
разделе
документации.
Описание пакетов можно передавать в командной
строке. Первое слово не похожее на опцию будет
anettest –c
file1.pcap –c
file2.pcap –c
file3.pcap –f
packets.fws
11
anettest –d eth0
–f packets.fws
anettest –d
10.0.0.10 –d
10.0.1.10 –d
10.0.2.10 –f
packets.fws
anettest –d
10.0.0.10#0 –d
10.0.1.10#1 –d
10.0.2.10#2 –f
packets.fws
anettest –t
file.pcap –d
eth0
AnetTest –f
packets.fws –d
eth0
Режим
сниффера
(-r)
RAW IP
(-p)
Генерация TCP
сессий
(-T)
считаться описанием пакета.
Команда
сценария
SEND
будет
добавлять
описанный пакет в список ожидаемых. Первым
приемным
интерфейсом
будет
первый
интерфейс, указанный в опции –d. Периодически
будет выводиться информация о том, какие
пакеты
пришли,
а
какие
нет,
а
также
интенсивности пакетов. По умолчанию будет
выводиться только та информация, которая не
соответствует
требованиям
к
пакетам,
прописанным после SEND. Обратите внимание
также на опцию –v, -u.
Читайте также про правила описания пакетов
для данного режима.
Указывает
использовать
генерацию
и
отслеживание пакетов не на канальном уровне, а
на сетевом (протокол IP). Имена адаптеров,
указанные в опции –d, должны быть IP адресами.
Для генерации пакетов не нужно указывать IP
адрес.
Отслеживание
пакетов
на
сетевом
уровне
невозможно.
Генерация большинства пакетов в ОС Windows XP
будет блокироваться системой с Service Pack 2
(любые TCP пакеты, пакеты с произвольным IP
адресом источника).
В Linux нельзя генерировать дейтаграммы с
размером большим MTU.
Во
FreeBSD
ни
генерация
пакетов,
ни
отслеживание невозможно.
В этом режиме программе по-прежнему можно
указать значения заголовка канального уровня,
но это ни на что не повлияет.
Работа не с пакетами, а с блоками данных,
посылаемых по TCP соединению.
Имя адаптера (опция –d) нужно указать в
формате client:host:port (режим клиента) или
server:host:port (режим сервера). В режиме
клиента программа попытается установить сессию
на указанный адрес, а режиме сервере она будет
ждать
соединений
на
указанном
адресе
(соответственно адрес должен быть локальным).
В сценарии можно использовать поле с именем
tcp.data (или td, определенное в заголовочном
файле tcp), чтобы указать, какие данные нужно
посылать (по команде SEND) или ждать от
сервера (по команде WAIT).
Параметром для опции является таймаут ожидая
соединений, когда программа работает в режиме
сервера.
По команде WAIT программа берет весь блок
данных, который прислан сервером и сравнивает
его с тем пакетом, который описан перед ней. Т.е.
до использования команды присланные данные
будут накапливаться, а по команде WAIT они все
будут прочитаны как один пакет. Если прислан
хотя бы один байт, то это уже будет считаться
присланным
пакетом.
Любой
тест
дает
нестабильные результаты в теории, требует
12
anettest –r –f
packets.fws –d
eth0
anettest –p …
anettest –T 9999
–d cl:lpc10:21 –
f tcpdata.fws
хорошего
знания
особенностей
работы
прикладного протокола. Результат зависит от
того, какими порциями данные доходят до хоста,
какими порциями выдаются приложению TCP
модулем, и моментов вызова команды WAIT.
Может
понадобиться
использовать
команду
PAUSE. Команды OR, WAITALL также доступны
для работы с TCP сессией.
-h
-v
-w
-q
-u
-I
-k
Числа
в
сценарии
будут
считаться
шестнадцатеричными
по
умолчанию.
Без
использования опции – десятичные.
В тесте пакетного фильтра или сниффера
выводится информация не только о пакетах, для
которых не выполнены требования, но обо всех
пакетах.
Программа просит нажать любую клавишу в конце
работы.
Сетевые адаптеры не переводятся в promisc mode
(неразборчивый режим).
В режиме сниффера интервал между выводом
отчетов в миллисекундах.
Добавление
пути,
где
будут
искаться
заголовочные файлы. См. описание команды
INCLUDE.
Вывод информации о полях сетевых заголовков.
Кроме указания этой опции необходимо передать
в командной строке имя интересуемого заголовка.
Программа обработает указанный заголовочный
файл, затем выведет таблицу с информацией о
полях.
Имя заголовка идет как описание пакета в
командной строке, поэтому может следовать
только после всех опций.
Можно указать несколько заголовков.
Некоторые поля программа знает априори,
поэтому всегда будет их выводить вначале.
AnetTest –
Iheaders –I..
AnetTest –k tcp
AnetTest –k
tcp_header
Возвращаемое программой значение
Если работа программы завершилась без ошибок и сам тест прошел без ошибок
(требования ко всем пакетам выполнены), то программа возвращает 0. Если ошибка не в
тесте (ошибка пользователя, программы, системы), то возвращается 1. Если работа
прошла без ошибок, но в самом тесте найдены ошибки (не все требования выполнены), то
возвращается 2.
13
5. Синтаксис файла с описанием пакетов
Файл с описанием пакетов (файл скрипта) - обычный текстовой файл, который
можно редактировать в любом текстовом редакторе. Рекомендуется создавать такие
файлы с расширением fws (например: packets.fws), а также использовать подсветку
синтаксиса для языка C/C++ при редактировании.
Комментарии:
В стиле языка C/C++.
// - начало комментариев до конца строки.
/* … */ - комментарии на любое количество строк
Встреченные в файле слова (наборы символов, разделенные пробелами,
табуляцией, переходами на новую строку) могут принадлежать одной из следующих
категорий:
o
o
o
o
Имя команды – специальное ключевое слово,
Имя поля заголовка одного из сетевых протоколов (сетевой заголовок),
Имя включаемого в описание заголовочного файла,
Определение нового поля сетевого заголовка.
Кроме того, после имени команды могут следовать ее параметры, а после имени
поля (или его определения) – значение поля.
Команды, имена полей и др. – регистронезависимые.
Пример содержимого файла скрипта:
include udp.fws
шаблона пакетов,
// включение заголовочного файла - определение общего
// файл udp.fws в папке headers содержит пример
описания udp пакета,
// содержимое файла udp.fws можно было бы вставить
прямо в этот файл,
// включение заголовочного файла всегда рекомендуется,
если надо генерировать
// корректные пакеты того или иного типа
// теперь изменим значения некоторых полей, т.е. нам нужны не те значения,
которые определены
// в заголовочном файле udp.fws
udp.len 14
// имена полей следует смотреть в файле udp.fws
(или в включенных в него файлах)
udp.data 'hollow'
srcip 1.1.1.1
SEND // первый пакет полностью описан
// эта команда сгенерирует его в режиме генерации или сделает еще
что-либо в другом режиме
// для второго пакета изменим только одно поле
// по сравнению с первым
dstip www.google.ru
SEND
// второй пакет полностью описан
SEND
// третий пакет
srcport 10000
dstport = 80
// символ = всегда можно вставить, он не несет
дополнительного смысла
14
srcport 10001
srcip != 1.1.1.1
SEND
srcip = any
пакета
udp.len 11
udp.data “hol”
// сам пакет не изменится, только маска пакета
// пакет 4
// сам пакет не изменится, это исключение поля из маски
SEND
Список команд – смотрите в пункте «Команды скрипта».
Имя поля сетевого заголовка – одно из изначально известных программе полей,
либо одно из полей, определенных ранее в текущем файле или в одном из включаемых
заголовочных файлов. После имени поля должно следовать его значение. Имена полей
следует смотреть в заголовочных файлах в папке HEADERS дистрибутива или можно
воспользоваться опцией -k. Имя файла совпадает с именем сетевого протокола (ip.fws,
tcp.fws). Если один файл включает другой с помощью команды INCLUDE, то возможно
потребуется посмотреть и его. Если имя поля в заголовочном файле начинается с точки это означает, что поле определяется. В дальнейшем точку писать не надо.
Некоторые поля сетевых протоколов изначально известны программе (ethernet, ip,
tcp, udp, icmp), поэтому включать заголовочные файлы, соответствующие этим
протоколам, не требуется. Не смотря на это, при генерации пакетов рекомендуется
всегда включать нужные заголовочные файлы перед описанием своих пакетов.
Иначе пакеты могут получиться некорректными (не того размера, с некорректными
значениями полей).
В папке SAMPLES дистрибутива программы собраны различные примеры
сценариев.
Содержимое пакета никак не влияет на позиции и размеры полей. Если
поставить неправильные размеры заголовков или что-либо еще, то программа только
сообщит о том, что некоторые контрольные суммы в заголовках не будут автоматически
вычислены.
Буфер генерируемого пакета изначально заполнен нулями. Задавая значения
полей или включая заголовочные файлы, можно постепенно формировать нужное
содержимое пакета. Команда SEND и ее аналоги только берут текущее содержимое
буфера пакета, не изменяя его. Включая заголовочный файл, можно заполнить весь
сетевой заголовок значениями по умолчанию. Указывая значение поля с позицией,
например 90, можно гарантировать, что размер каждого следующего пакета будет не
меньше 90, если не будет использована команда CLEAR. Дополнительно о размере
генерируемого пакета написано далее.
Каждый следующий пакет наследует содержимое предыдущего.
Если пакеты не только генерируются, а осуществляется их поиск в trace-файлах
или они ожидаются на сетевых интерфейсах, то начинает играть роль понятие маски
пакета, о которой можно почитать здесь.
Имя заголовочного файла – часть имени файла или полный путь к нему.
Дополнительно смотрите команду include.
Перед обработкой любого файла программа попытается найти файл base.fws и
обработает его перед началом обработки файла, который явно указан. Файл base.fws
можно хранить в папке headers. В нем можно прописать свои включения заголовочных
файлов, определения и др.
5.1.
Типы значений полей
Число
По умолчанию число считается десятичным, но при использовании опции –h оно
будет считаться шестнадцатеричным. Чтобы явно определить тип числа используйте
префикс 0x для шестнадцатеричных чисел и точку в конце для десятичных чисел.
Например: 11., 0x11.
15
Размер числа может определяться программой по типу поля, если это поле известно
программе или было определено ранее. Если написать «srcport 22», то программа знает,
что размер поля порта источника = 2 байта.
При определении новых полей нужно явно указывать размер числа, если он не
равен 1 байт. Для десятичных чисел размер указывается с помощью символа s. Для
шестнадцатеричных чисел размер определяется по виду числа.
Пример определения новых полей:
.new_field_name1
.new_field_name2
11s2.
// размер 2 б., число десятичное
0x11223344 // размер 4 б., число шест-ное
После таких определений можно далее писать:
new_field_name1
12 // число по умолчанию считается десятичным
// размер числа = размеру поля = 2 б.
В следующем случае будет ошибка:
new_field_name2
0x11
нужно написать:
new_field_name2
0x00000011
То есть программа требует прописывать все разряды шестнадцатеричного числа, а
для больших чисел будет требовать, чтобы число разрядов было четным.
Строковый тип
Это набор символов заключенный в кавычки “”, либо обрамленный апострофами.
Если тип поля строковый, а строка не содержит пробелов и др., то можно
обходиться без кавычек.
.my_new_field “string” // определение нового поля, кавычки указывают
на строковый тип
my_new_field string // известно, что тип поля my_new_field –
строковый, кавычки не обязательны
my_new_field ‘string space string’ // строка содержит пробелы,
кавычки обязательны
Допустимы символы \r, \n, \’, \”, \t, \a, \b (например: “string\r\n”).\r, \n – это
символы возврата каретки и перехода на новую строку соответственно.
Можно вставлять в строку не символы, а байты с произвольными значениями
(кроме нулевого байта):
“hello\x22”
// после слова hello вставлен байт со значением 0x22
При описании пакета в текстовом редакторе можно перейти на новую строку внутри
кавычек.
Вместо
my_new_field “string\r\nnew_line”
можно написать
my_new_field
new_line”
“string
Символ \n или сразу два символа \r\n будут добавлены автоматически между string
и new_line. Как именно, зависит от операционной системы, поэтому используйте это
свойство с осторожностью.
Для строкового типа нет фиксированного размера. Можно всегда указывать строки
произвольного размера.
Если в строке стоит символ равно, то строка должна быть обязательно в кавычках
(апострофах).
16
IP адрес
Примеры:
srcip
srcip
srcip
srcip
1.1.1.1
localhost
mycomp
www.yandex.ru
При определении нового поля адрес можно писать только в первом формате (тем
самым указать, что значением поля будет IP адрес). Далее для указания значения поля
можно будет использовать любое DNS имя.
MAC адрес
Примеры:
srcmac
srcmac
srcmac
srcmac
11:22:33:44:55:66
11-22-33-44-55-66
0x112233445566
112233445566
При определении нового поля нужно всегда использовать первые два формата,
чтобы программа поняла, что типом поля будет MAC адрес.
IPv6 адрес
ip6.src 1122:3344:5566:7788:99aa:bbcc:ddee:ff00
ip6.src 0:0:0:0:0:0cc:d00:0
DNS имя не принимается.
5.2.
Автоматические значения
Имена значений: IPlen, IPcrc, IPv6len, TCPcrc, UDPcrc, UDPlen, ICMPcrc.
Такие значения можно указать для соответствующих полей сетевых заголовков.
Для того, чтобы сосчитать эти значения, программа иногда будет требовать, чтобы
были определены нужные поля. Например, для значений IPlen, IPcrc должно быть
определено поле с именем ip.ver, позиция которого будет указывать на начало IP
заголовка. Если используются стандартные заголовочные файлы, то это поле в них уже
определено. Таким образом, не важно, какие протоколы будут использоваться на
канальном уровне, главное чтобы было корректно определено поле ip.ver, и значения
будут правильно сосчитаны.
Можно и не использовать автоматические значения. Они будут по умолчанию
считаться только потому что уже прописаны в заголовочных файлах. Исправить это очень
легко, указав свое значение при описании пакета (не в заголовочном файле), например:
ip.crc
5.3.
0
Создание своих заголовков
Может понадобиться определять новые поля при описании заголовков сетевых
протоколов, неизвестных программе, или чтобы переопределять параметры полей, уже
известных программе.
Для любого поля программа знает его позицию, как смещение в байтах от начала
заголовка канального уровня, размер поля и тип поля (как тип значения).
Определение нового поля выглядит так:
.new_field1
.new_field2
.new_field3
.new_field4
.new_field5
поля
11 // однобайтовое поле, тип: десятичное число
0x1122 // двухбайтовое поле, тип: шестнадцатеричное число
11s2. // двухбайтовое поле, 11 в десятичном формате
‘GET host’ // тип: строка
1.2.3.4
// тип: IP адрес
Имя надо начинать с точки, что обозначает определение нового поля. Тип
и его размер определяется по тому значению, которое указывается. Читайте о
17
типах значений. Тип и размер указанного значения везде далее будет считаться типом и
размером поля. Если написать строку в кавычках, то тип поля будет строковым. Если
написать IP адрес, то типом поля будет IP адрес.
При определении поля указанное значение сразу будет записано в буфер пакета,
т.е. описание генерируемого пакета может происходить одновременно с описанием новых
полей. Как определяется позиция в буфере, куда записать указанное значение, и
одновременно та позиция, которая далее будет считаться позицией поля ? По текущему
значению указателя байт.
Изначально указатель байт устанавливается на начало заголовка канального
уровня. При вводе значения известного программе поля (когда пишете, например:
«srcport 10000»), он будет установлен сразу за только что записанным значением. При
определении нового поля, указатель просто сместится на размер указанного значения
(т.е. также будет установлен сразу за только что записанным значением). Смотрите
дополнительно команды скрипта POS, PASS и BACK.
В отдельных заголовочных файлах можно описывать свои заголовки, одновременно
задавая значения полей по умолчанию. Описания полей должны идти в строгой
последовательности. Когда все поля определены, можно легко изменять значения
отдельных полей при описании конкретных пакетов.
Смотрите примеры определения полей и целых заголовков в заголовочных файлах
в папке HEADERS: ip_header.fws, ipx.fws, ipx_heaedr.fws, ospf.fws, tcp_header.fws,
vlan.fws.
5.4.
Сборка заголовков
Самый обычный пакет может содержать набор заголовков для различных сетевых
протоколов. Эти заголовки удобно хранить в отдельных заголовочных файлах. Чтобы
использовать полный заголовок нужно будет просто последовательно перечислить его
подзаголовки для каждого отдельного протокола.
Пример:
// заголовочный файл tcp_over_vlan.fws
include vlan
include ip_header
include tcp_header
// описание пакетов
Имена включаемых заголовков соответствуют именам заголовочных файлов в папке
HEADERS дистрибутива.
В показанном примере определяется tcp пакет с заголовком vlan. Дополнительно
смотрите пример в файле tcp_with_vlan.fws (папка SAMPLES).
Заголовки с именами ip_header и tcp_header отличаются от стандартных заголовков
ip, tcp, vlan. Эти два заголовка нужно использовать только при «сборке» заголовков. С их
помощью заголовок ip или tcp можно вставить в любом месте какого-либо более сложного
заголовка пакета. Самостоятельно (т.е. вне какой-либо сборки) эти заголовки
использоваться не могут. Все сказанное относится также ко всем заголовкам с именами
*_headers, где * - имя заголовка. Если имя заголовочного файла состоит только из имени
протокола (ip.fws), следовательно заголовок протокола уже вставлен в какой-либо
заголовок нижнего уровня (посмотреть и изменить это можно в самом заголовочном
файле).
Можно отредактировать файл ip_header.fws, добавив опции в ip заголовок. Размер
заголовка при этом станет больше, но при определении полей tcp заголовка (в файле
tcp_header.fws) они встанут как раз за ip заголовком, какого бы размера тот не был. В
этом состоит гибкость при сборке заголовков.
Заголовок vlan автоматически вставляется в заголовок Ethernet II. То же самое
касается заголовка ip-пакета (файл ip.fws). Заголовок tcp-пакета (файл tcp.fws)
автоматически вставляется в заголовок ip. Во всем этом можно убедиться, посмотрев
соответствующие заголовочные файлы. Таким образом, используя, например, заголовок
tcp.fws, можно не заниматься сборкой заголовков, а сразу получить обычный tcp пакет.
18
5.5.
Размер генерируемого пакета
Если последовательно описывать пакеты, разделяя их описания командами
генерации пакетов, то следующий пакет по умолчанию не может быть меньше
предыдущего. Размер увеличится, если указать значения для полей с позицией больше,
чем у предыдущих полей. При определении размера пакета программой (например, когда
встречается команда SEND) он будет сначала равен максимальному значению указателя
байт, которое было при описании текущего пакета (т.е. максимальная позиция поля, для
которого было указано знание + размер поля), а затем будет увеличен до размера
предыдущих пакетов. Если размер слишком мал (для генерации на канальном уровне), то
он будет увеличен до минимального. Такое дополнение будет заполнено нулями или
содержимым предыдущих пакетов, если они были больше текущего.
include tcp
srcport 1000 SEND
srcport 1001 SEND
// полное заполнение заголовка TCP
В показанном выше примере оба генерируемых пакета будут корректными TCP
пакетами. Для первого пакета определяются все поля TCP заголовка, поэтому TCP
заголовок не окажется обрезанным, даже если последним полем указано srcport
(максимальное значение указателя байт будет указывать на конец TCP заголовка). Размер
второго пакета будет автоматически увеличен до размера предыдущего пакета, поэтому
для него TCP заголовок также не будет обрезан.
Только в следующем случае размер пакета станет меньше
include tcp
tcp.data ‘hollow’ SEND
tcp.data ‘hol’
SEND
// полное заполнение заголовка TCP
// TCP заголовок с данными
// размер пакета станет меньше
// т.к. TCP данных стало меньше
То есть размер пакета может стать меньше только, если размер поля с
максимальной позицией стал меньше. Если изменять значение всех остальных полей, то
размер генерируемого пакета от этого не уменьшится.
Читайте также про команду CLEAR. Это способ генерировать маленькие пакеты
после больших.
Чтобы посылать большие пакеты пользуйтесь командой PASS.
PASS 1400
PASS 65000
// канальный уровень
// сетевой уровень
Или POS.
POS 1514
POS 65549
// максимальный размер пакета на канальном уровне
// максимальный размер IP дейтаграммы + 14 байт
// заголовка канального уровня
После включения заголовочных файлов устанавливается минимальный размер
пакета равный размеру включенного заголовка. Таким образом, включение заголовочных
файлов гарантирует, что пакет не будет обрезанным.
5.6.
Маска пакета
В тесте пакетного фильтра, режиме сниффера, режиме генератора (если
используется команда WAIT) пакет будет не только генерироваться, а искаться в traceфайлах (опция –c), либо ожидаться на каком-либо интерфейсе. При этом нужно
учитывать, что в сценарии описывается не только пакет, но еще и маска пакета. Любые
значения полей, которые задаются в сценарии, добавляются к маске (например, если
написать: «srcport 80», или когда определяется новое поле). Пакет (из trace-файла или
принятый на физическом интерфейсе) будет удовлетворять маске, если значения полей
маски совпадают со значениями соответствующих полей из пакета. Если включаются
заголовочные файлы (например: «include tcp.fws»), то маска может соответствовать уже
конкретному пакету, который описан в заголовочном файле. Чтобы сбросить ее
используйте команду RESET. После сброса маска будет соответствовать любому пакету,
т.е. можно заполнять ее заново. Буфер пакета при этом не изменится. Команда SEND
(WAIT) не будет сбрасывать маску, т.е. те поля, которые были определены до нее, так и
останутся в маске.
19
Команда RESET должна быть уже вставлена в заголовочные файлы для того, чтобы
после включения заголовка маска содержала только значения полей, которые указывают
на тип пакета (поля вроде «тип протокола» в Ethernet, IP заголовках). Т.е. маска будет
соответствовать произвольному пакету определенного типа.
Пример:
include tcp.fws
RESET
srcport 22
SEND
В показанном примере при встрече команды SEND маска пакета будет состоять
только из одного поля srcport, т.е. будет ожидаться пакет с srcport = 22. Существует риск
получить вообще не TCP пакет.
В режиме генерации перед командой WAIT также должна быть маска. Перед ее
описанием можно использовать команду RESET (если до этого было описание
генерируемых пакетов), иначе маска будет соответствовать ранее сгенерированному
пакету.
Неравенства
Кроме указания того, что поля должны иметь определенные значения, маска может
содержать и противоположные требования:
srcip != 1.1.1.1.1
Таким образом, указывается требование, что значение поля srcip не должно быть
равно 1.1.1.1.
Данная запись не повлияет на содержимое буфера пакета, только на маску.
Также допустимо
ip.len
ip.len
ip.len
ip.len
< 400
<= 400
> 400
>= 400
Исключение поля из маски
srcip
any
Специальное знание any указывает на то, что поле надо исключить из маски, если
оно ранее было добавлено.
Данная запись не повлияет на содержимое буфера пакета, только на маску.
20
5.7.
Команды скрипта
SEND – генерация пакета, отделение пакетов друг от друга
SEND <список требований>
Команда генерации пакета, которая в более общем случае отделяет описание
одного пакета от другого.
Если нужно просто генерировать пакеты, можно писать SEND без параметров.
Если планируется использовать тест пакетного фильтра или режим сниффера,
то после команды может быть непустой список требований. Если для какого-либо пакета
не все требования указываются, значит будут по умолчанию (см. команду DEFAULTS).
В расширенном режиме требования должны указываться иначе.
Список требований может быть указан всегда, но будет иметь смысл только если
используется тест пакетного фильтра или сниффера.
Примеры:
SEND
SEND ACCEPT
SEND DROP
SEND DROP ACCEPT …
>> - команда SEND c требованием ACCEPT
>> <список требований>
Аналог команды SEND с первым требованием = ACCEPT. Далее идет список
остальных требований.
Команда может быть использована только в тесте пакетного фильтра.
Примеры:
!описание пакета! >>
!описание пакета! >> << >> // аналог SEND ACCEPT DROP ACCEPT
<< - команда SEND c требованием DROP
<< <список требований>
Аналог команды SEND с первым требованием = DROP. Далее идет список остальных
требований.
Команда может быть использована только в тесте пакетного фильтра.
Примеры:
!описание пакета! <<
!описание пакета! << >> << // аналог SEND DROP ACCEPT DROP
PAUSE – пауза при генерации пакетов
PAUSE <количество миллисекунд>
Пауза в режиме генерации пакетов. Интервал указывается в миллисекундах.
Примеры:
SEND
PAUSE 1000
21
SEND
REP – генерация нескольких одинаковых пакетов
REP <число генерируемых пакетов>
Указание генерировать пакет несколько раз подряд.
Будет применено только к пакету, при описании которого была встречена эта
команда. В примере 10000 раз будет послан пакет 1. Пакет 2 будет послан только один
раз.
Эта команда также указывает, сколько раз пакет должен быть принят. Если в
списке требований будет указано несколько требований принять пакет, то он должен
быть принят количество раз, указанное в команде REP (для каждого интерфейса, для
которого указано требование «принять»).
Примеры:
!описание пакета 1!
REP 10000
SEND
// пакет будет послан 10000 раз
!описание пакета 2!
SEND
INC – автоматический инкремент значения поля при генерации нескольких
пакетов
INC
Без параметров. Указывается перед тем, как задать значение какого-либо поля (но
не определением нового поля), которое в этом случае становится автоинкрементируемым.
Если с помощью команды REP генерируется много пакетов, то значение
автоинкрементируемого поля будет автоматически инкрементироваться для каждого
следующего пакета. В зависимости от размера поля будет инкрементироваться 1, 2, 4
байтовые значения. Можно применять к числу или IP адресу. В приведенном примере
будет послано 65000 пакетов с различными номерами портов источника.
Примеры:
!описание пакета!
REP 65000
INC
srcport 1
SEND
// будет послано 65000 пакетов с номерами портов 1-65000
POS – установка позиции указателя байт
POS {<новое значение указателя байт>, <имя поля>}
Установка значения указателя байт, т.е. смещение
канального уровня. Читайте про определение своих полей.
Если указано имя поля, то будет взята его позиция.
Примеры:
POS 34
!определение нового поля!
PASS – смещение указателя байт вперед
22
от
начала
заголовка
PASS <количество байт, которые надо пропустить>
Увеличение значения
определение своих полей.
указателя
байт
на
указанное
число.
Читайте
про
Примеры:
PASS 12
!определение нового поля!
DEFINE – подстановка
DEFINE <то, что будет заменяться> <то, на что будет заменяться>
Замена будет действовать в большинстве случаев, но не глобально, как в случае
использования GDEF.
Примеры:
DEFINE http 80
DEFINE «HyperText Transfer Protocol» 80
// далее можно везде писать
dstport http
dstport “HyperText Transfer Protocol”
INCLUDE – включение файла в обработку
include <имя файла>
Включение заголовочного файла. Если имя ip, то программа будет искать файлы:
ip, ip.fws. Поиск будет производиться сначала в текущем каталоге, затем во всех
переданных программе путях поиска (опция -I). Также для каждого пути будет
производиться поиск в папках samples, headers, traces.
При открытии любого файла его директория также будет добавлена в список путей
(в конец списка), т.е. не будет проблем с открытием других файлов из той же директории.
Примеры:
include tcp
include tcp.fws
tcp // можно просто написать имя заголовка и программа будет
// искать заголовочный файл
DEVICES – указание имен используемых сетевых интерфейсов
DEVICES <тип устройства> <имя интерфейса> [<имя интерфейса> [, …]]
Тип устройства может быть ethernet, ip (см. опцию -P), tcp (см. опцию -T).
После имени команды идет список интерфейсов компьютера. Имена аналогичные
тем, которые можно задать в командной строке (опция –d). Можно задать только один
главный интерфейс для генерации пакетов. Если задано более одного – это приемные
интерфейсы. В общем, то же самое, если в командной строке передать список
интерфейсов (опция –d).
Таким образом, команда позволяет определять физическую конфигурацию теста в
самом сценарии.
Примеры:
DEVICES 10.0.1.0 10.0.1.1 10.0.1.2
23
DEVICES 10.0.1.0#0 10.0.1.1#1 10.0.1.2#2
// после знака # можно определить пользовательский номер
// интерфейса, который будет использован при выводе статистики
Имена адаптеров можно задавать и стандартным образом (eth0, eth1, eth2, …).
DEFAULTS – установка требований по умолчанию
DEFAULTS {“ANY” | “ACCEPT” | “DROP” | “REVERS” | “<<” | “>>”}
Параметры: немного дополнительный список требований.
Требования по умолчанию имеют смысл, когда для одного или более пакетов в
сценарии после команды, например, SEND указано число требований меньше чем число
приемных интерфейсов, задействованный в тесте, т.е. для некоторых интерфейсов
требования явно не прописаны.
Изначально требование по умолчанию равно ACCEPT для первого приемного
интерфейса. Для остальных интерфейсов – не заданы, т.е. статистика для них не будет
выводиться даже с использованием опции –v.
Требование по умолчанию REVERS указывает инвертировать явно прописанное
требование для каждого пакета (для одного конкретного интерфейса). С помощью этой
команды можно временно поменять требования для всех пакетов на обратные. Если
требование для пакета не будет указано, то REVERS ничего не изменит.
В примерах ниже статистика будет не важна по умолчанию для первого
интерфейса, для второго интерфейса – должно быть выполнено ACCEPT (если для пакета
не будет явно указано требование). Для пакета 1 никаких требований не указано => он
должен будет быть принят на втором приемном интерфейсе, и не важно, что будет на
первом.
См. файл compare_mode1.fws в SAMPLES.
В расширенном режиме требования должны указываться иначе.
Примеры:
// Первый пример
DEFAULTS ANY ACCEPT
!описание пакета 1!
SEND
// здесь требования к пакету не были явно указаны,
// поэтому будут применены требования по умолчанию так,
// как будто мы написали “SEND ANY ACCEPT”
// Второй пример
DEFAULTS ANY ACCEPT
!описание пакета 2!
SEND DROP
// здесь явно указано требование только для первого интерфейса,
// для второго интерфейса будет применено требование по
24
// умолчанию = ACCEPT
EXIT – окончание обработки сценария
EXIT <возвращаемое программой значение>
Завершение обработки сценария.
WAIT – ожидание пакета
WAIT <список требований>
Если команда указана без параметров, то происходит ожидание пакета на главном
интерфейсе. Перед командой должно быть описание маски пакета, т.к. она будет
использовать именно ее. Можно использовать эту команду в режиме генерации пакетов
наряду с командой SEND. Когда первый пакет, удовлетворяющий маске, приходит,
команда заканчивает работу.
Команда позволит чередовать генерацию одних пакетов с ожиданием других.
Можно начинать генерацию только если принят нужный пакет, или после генерации
нужных пакетов начинать ожидать другие.
Если указаны конкретные требования в параметрах команды, то происходит
ожидание пакета на всех тех интерфейсах, для которых указаны строгие требования
(drop или accept). Приемными интерфейсами будут все открытые физические
интерфейсы, включая самый первый.
Более точно: ожидание происходит на тех интерфейсах, для которых прописаны
строгие требования либо в требованиях по умолчанию (DEFAULTS), либо в параметрах
команды. Изначально по умолчанию установлено только одно строгое требование для
главного интерфейса, поэтому ожидание происходит только на главном интерфейсе
(если команда без параметров). Когда приходит первый пакет, удовлетворяющий маске,
причем на интерфейсе, на котором этот пакет ожидается (в соответствии с прописанными
требованиями), то команда заканчивает работу.
Указав в параметрах команды требование ANY для главного интерфейса, можно
сделать так, что на нем пакет как раз и не будет ожидаться, т.е. команда будет
продолжать работу после приема такого пакета.
Результаты ожидания для каждого пакета запоминаются, и после работы
программы будет выведен общий отчет, как в тесте пакетного фильтра.
Можно указать ожидать не один, а несколько различных пакетов с помощью
команды OR.
Также иногда более удобно использовать команду WAITALL.
Если с помощью команды OR было добавлено несколько пакетов в список
ожидаемых, то команды WAIT, WAITALL закончат работу после принятия одного из таких
пакетов. Каждый из этих пакетов может ожидаться на своем наборе интерфейсов в
соответствии с требованиями, указанными в параметрах команды OR: действуют те же
правила, что были ранее описаны.
Пример:
Часто необходимо послать какой-нибудь пакет с одного интерфейса (например,
второго) и убедиться, что он дошел до другого интерфейса (например, первого). Для этого
необходимо сначала добавить этот пакет в список ожидаемых пакетов командой OR,
указав в ее параметрах требование accept для первого интерфейса. После этого
необходимо
сгенерировать
пакет
со
второго
интерфейса,
а
потом
начать
непосредственное ожидание пакетов командой WAITALL. Это команда будет ожидать
пакеты, которые ранее были добавлены в список ожидаемых (командой OR). Когда
первый из них прийдет, то она закончит работу.
Соответствующий сценарий:
INCLUDE tcp
extended
Srcport 1
25
Mi 1
Or // добавляет пакет, который будет ожидаться, для него
устанавливается
// по умолчанию требование accept для главного интерфейса (с
номером 1)
Mi 2
Send // генерация этого же пакета на втором интерфейсе
Waitall // ожидание пакета
/*
пакет может очень быстро дойти со 2 на 1 интерфейс (если они связаны),
тогда команда выдаст «already recieved», т.е. пакет был реально
получен во время обработки команды send, до начала непосредственного
ожидания командой WAITALL
Если добавлять пакет уже после генерации, то он может быть пропущен.
*/
По умолчанию пакеты будут ожидаться вечно, но можно установить таймаут с
помощью команды TIMEOUT.
Результаты ожидания:

recieved – ожидание было начато, и один из пакетов был получен

timeout – ни один из пакетов не был получен

already recieved – один из пакетов был получен еще до начала ожидания
(был добавлен, затем был принят, затем только было начато ожидание
всех пакетов)
В расширенном режиме требования должны указываться иначе.
Примеры:
RESET
!описание маски пакета! WAIT
MASK – установка специальной маски для следующего определяемого поля
MASK <маска поля>
Параметр – маска поля, шестнадцатеричное число. Переданная маска становится
текущей маской поля. Команда должна использоваться перед определением нового
поля. По умолчанию текущая маска вся заполнена единичными битами. Маска,
присвоенная полю, будет работать для этого поля постоянно (становится его атрибутом).
Запись значения для поля будет производиться только в биты, соответствующие
единичным битам маски.
После определения нового поля текущая маска снова
становится равной по
умолчанию. Это значит, что команду MASK нужно использовать перед определением
каждого поля с нестандартной маской (у которой не все биты единичные). Если маска у
поля стандартная – то команду MASK не нужно использовать.
Если размер маски меньше размера поля, то маска будет дополнена нулевыми
битами слева.
См. файл vlan.fws в папке HEADERS.
Примеры:
MASK 0xe0
.ip.flags 0x80
// к полю относятся только 3 бита
26
MASK 0x1fff
.ip.offset 0
// 3 старших бита не относятся к этому полю
ip.flags
// изменятся только 3 старших бита
0xff
OFFSET – установка специального смещения бит для следующего
определяемого поля
OFFSET <смещение в битах>
Параметром является смещение в битах от 1 до 7.
Команда должна быть использована перед определением нового поля.
Смещение, присвоенное полю будет действовать для него постоянно. Каждое
значение для поля будет смещаться влево на указанное количество бит. Если не
использовать команду MASK, то младшим битам в крайнем правом байте будут
присваиваться нули при каждой записи в поле (хотя эти биты по сути не принадлежат
полю, так как оно смещено влево). Проще говоря, любое значение поля будут умножаться
на степень двойки.
Если младшие биты в правом байте принадлежат другому полю, то нужно
использовать команду MASK (показано в примере ниже).
Смещения битов в соседние поля слева (в соседние байты) не будет. Эти биты
просто удаляются и на значения полей слева не влияют.
После определения поля смещение по умолчанию снова становится равным 0.
Задавать явно такое значение явно не следует.
См. также файл tcp.fws в папке HEADERS.
Примеры:
OFFSET 1
// смещение на один бит
MASK
// младший бит не принадлежит полю
0xfe
.field 1
// определение поля
// любое значение для этого поля будет умножаться
// на 2
RESET – сброс маски пакета
RESET
Маска пакета сбрасывается, т.е. она будет соответствовать любому пакету.
Удобно сбрасывать маску после включения заголовочных файлов или детального
описания пакетов, а затем заново заполнить ее, добавив только несколько полей.
Дополнительно читайте о тесте пакетного фильтра.
Файл compare_mode.fws, compare_mode1.fws в папке SAMPLES.
Примеры:
INCLUDE tcp
RESET
// сброс маски, определенной в заголовке tcp
srcport 80 // маска, состоящая из одного поля
WAIT
// ожидание пакета, соответствующего маске
CLEAR – очистка истории пакетов
CLEAR
По этой команде информация о максимальном размере предыдущих пакетов
удаляется, но само содержимое буфера пакета остается неизменным. Размер нового
27
пакета уже может быть меньше всех предыдущих. Кроме того, сбрасывается информация
о максимальной позиции указателя байта, которая была при формировании текущего
пакета.
Дополнительно читайте пункт «Размер генерируемого пакета».
Примеры:
INCLUDE tcp
CLEAR
srcport 50
SEND
// TCP пакет будет обрезан после поля srcport
BACK – смещение указателя байт назад
BACK <на сколько байт нужно вернуться назад>
Параметром является число, на которое будет уменьшен указатель байт. В
примере показано, как определяется новое поле «порт_источника», используя уже
известное программе поле «srcport».
См. tcprus.fws в папке headers.
Примеры:
// определение русского аналога поля scrport
srcport 1000
BACK 2
// вернемся на две позиции назад
.порт_источника 1000s2 // определение нового поля
NAME – имя пакета
Name <имя пакета>
Устанавливает имя пакета, которое будет приведено в отчете или где-то еще. Эта
команда может быть вставлена среди описания пакета (установки значений полей и др.).
После использования команды SEND, WAIT и др. имя будет сброшено.
MES – сообщение, выводимое при получении пакета
Mes <сообщение>
Сообщение, которое будет выводиться каждый раз при получении пакета. Эта
команда может быть вставлена среди описания пакета (установки значений полей и др.).
Сообщение может содержать вставки $имя_поля$, которые будут замены на
значения полей из принятого пакета.
Пример:
INCLUDE tcp
dstport 22
Mes «ip = $srcip$, port = $srcport$»
wait
FULLMASK – полностью заполняет маску пакета
Без параметров.
Эта команда берет текущий размер описываемого пакета и изменяет маску
пакета так, что в нее входит весь пакет (в соответствии с текущим размером).
Пример:
28
INCLUDE tcp
FULLMASK
Wait
В этом примере команда wait будет ждать точно такой пакет, какой описан в
заголовочном файле tcp. Если убрать команду FULLMASK, то wait будет ждать любой TCP
пакет, так как в маску будут включены только поля ethproto и ip.proto (так сделано в
заголовочном файле).
EXTENDED – включение расширенного режима
Без параметров.
О расширенном режиме написано в соответствующем параграфе.
MI – изменение главного интерфейса
MI <пользовательский номер интерфейса>
Команда работает только после включения расширенного режима. Эта команда
также меняет требования по умолчанию, устанавливая единственное требование
ACCEPT для главного интерфейса.
WAITALL – ожидание пакетов
Без параметров.
По действию аналогична команде WAIT. В отличие от нее не добавляет описанный
перед ней пакет в список ожидаемых. Все интересующие пакеты могут быть добавлены
ранее с помощью команды OR.
OR – добавление пакета в список ожидаемых
OR <список требований>
Аналогична команде WAIT. В отличие от нее не начинает ожидание пакета, а
только добавляет пакет в список ожидаемых. Тем не менее, сразу после добавления пакет
уже может быть зарегистрирован как принятый, если появится. В этом случае, когда
непосредственное ожидание начнется (командой WAIT, WAITALL), то оно может быть
сразу прекращено, так как один пакет уже пришел раньше.
Таким образом, можно описать несколько пакетов, которые будут ожидаться.
Описание каждого следует заканчивать этой командой.
Пример:
Srcport 80
Or
Srcport 22
Or
Srcport 21
wait
TIMEOUT – установка таймаута для команды WAIT
Timeout <значение таймаута в миллисекундах>
Если команда WAIT не дождется пакета в течение таймаута, то она завершит
работу, а все ожидаемые пакеты будут зарегистрированы, как отброшенные. Нулевое
значение означает бесконечный таймаут.
В случае отрицательного значения будет взято его абсолютное значение, но работа
команды WAIT изменится: она всегда будет ждать время, установленное таймаутом, не
заканчивая работу по принятии первого пакета. Таким образом, сразу несколько пакетов
могут быть зарегистрированы как принятые, если они придут в течение таймаута. Также
пакеты будут зарегистрированы как отброшенные, только если они не придут в течение
29
таймаута.
При имитации работы приложений таймаут до повторной посылки пакета будет
также определяться через эту команду. Бесконечный таймаут не будет применяться.
FASTTEST – установка режима быстрого теста
Без параметров.
Эта команда должна стоять в самом начале сценария (еще до включения
заголовочных файлов). В этом режиме программа перед тем, как начать генерировать
пакеты, сначала иначе обрабатывает сценарий, регистрируя каждый из генерируемых
пакетов. Перед генерацией она запустит снифферы, которые будут фиксировать прием
каждого из зарегистрированных пакетов. После генерации будет выведен отчет.
Подробнее...
GDEF – автозамена
GDEF <то, что будет заменяться> <то, на что будет заменяться>
Замена будет действовать при чтении любого слова из текста.
Пример:
GDEF client_side 1
имя
// вместо номера интерфейса можно будет писать его
EXTENDED
Send << client_side
TRACE – открытие trace файла для работы ним
TRACE <имя файла>
Файл должен иметь формат libpcap.
Поиск файлов будет производиться там же, где происходит поиск заголовочных
файлов (команда INCLUDE). Если файл имеет расширение pcap, то расширение можно не
указывать, но только если файл находится в папке traces.
WRITE – запись измененного trace файла
Без параметров.
Может быть использована после открытия trace файла (команда TRACE) и его
изменения. Записывает в файл с тем же именем, которое было указано при открытии
файла.
GETPAC – загружает пакет из открытого trace файла
GETPAC <номер пакета в файле>
Нумерация пакетов начинается с 1. Работает с файлом, открытым командой TRACE.
Команда очищает историю пакетов (команда CLEAR), сбрасывает маску пакета
(команда RESET), а затем записывает пакет из файла, как значение одного большого
поля.
SETPAC – записывает текущий пакет в trace файл
SETPAC <номер пакета в файле>
Нумерация пакетов начинается с 1. Работает с файлом, открытым командой TRACE.
Берет текущее содержимое пакета, как это происходит в команде SEND, и
записывает его в файл вместо пакета с указанным номером. Время пакета не меняет.
INSPAC – вставляет текущий пакет в trace файл
INSPAC <номер пакета, который будет сдвинут>
Нумерация пакетов начинается с 1. Работает с файлом, открытым командой TRACE.
Берет текущее содержимое пакета, как это происходит в команде SEND, и
30
вставляет его в файл, сдвигая все пакеты с указанным номером и выше. Для нового
пакета берет время, равное времени смещенного пакета.
Если номер пакета больше количества пакетов в файле, то добавляет пакет в конец
с нулевым временем.
DELPAC – удаление пакета из trace файла
DELPAC <номер пакета >
Нумерация пакетов начинается с 1. Работает с файлом, открытым командой TRACE.
CHTRACE – изменение нескольких пакетов с trace файле
CHTRACE “{“
<список изменений>
“}”
Работает с файлом, открытым командой TRACE.
Перед командой должна быть описана маска пакета. Команда будет работать со
всеми пакетами из файла, удовлетворяющими этой маске.
Список изменений – это просто задание значений полей, часть сценария без
команд.
Пример:
/*
В данном примере во всех пакетах c портом назначения = 80 будут
заменены номер порта назначения и адрес назначения. Если не включать
заголовочный файл tcp, то данный сценарий может некорректно изменить
не TCP пакеты, если найдет в них значение 80 на определенной позиции.
В заголовочном файле определена маска, которая соответствует любому
TCP пакету (но только TCP пакету), поэтому изменение будет всегда
корректным.
*/
INCLUDE tcp
Trace http_client
Dstport 80
Chtrace
{
Dstip 1.1.1.1
Dstport 21
}
GETCH – запрос ввода Enter
Без параметров.
HELP – вывод описания команды
HELP ( <имя команды> | «all» )
Если указано all, то будет выведено описание всех команд.
DEFAULTTEST – сброс параметров для имитации работы приложений
Без параметров
Команда не только сбрасывает параметры, но также удаляет всю конфигурацию,
которая была сделана ранее для предыдущего теста (конечные точки и т.п.).
EP – определение конечной точки
31
ep <тип> <пользовательский номер интерфейса > <имя поля > (<значение
поля> | “first” | “second”)
Конечные точки используются при имитации работы приложений (имитация
взаимодействия).
Предполагается, что в каждом сетевом взаимодействии могут участвовать
несколько сторон (приложений). Пакеты от каждой из сторон в trace-файле можно
отличать по адресу на канальном или сетевом уровне (или как-то еще). При имитации
взаимодействия каждой из сторон должна соответствовать хотя бы одна или две
конечные точки разных типов.
<тип> ::= (“recv” | “gen”)
Тип gen указывает, что пакеты от данной стороны будут посылаться в сеть
(генерирующая конечная точка). Тип recv указывает, что пакеты от данной стороны
должны быть приняты (ожидающая конечная точка). Если для какой-то стороны
определено две конечные точки, то пакеты будут и посылаться и должны быть приняты.
Точнее: посылаться на одном интерфейсе, а должны быть приняты на другом.
Номер интерфейса указывает на интерфейс, с которого пакеты будут посылаться
или на котором они будут ожидаться.
Имя поля указывает поле пакета, значение которого будет использоваться для
нахождения пакетов в trace файле, принадлежащих стороне, соответствующей данной
конечной точке. Можно ввести обычное значение, посмотрев trace-файл, но часто удобно
использовать специальные значения first (значение из первого пакета) или second (из
второго пакета). Пакеты, в которых указанное поле имеет указанное значение, будут
обрабатываться конечной точкой.
Пример:
ep gen 0 srcip first // посылка пакетов для первой стороны на
интерфейсе 0
ep gen 2 srcip second // посылка пакетов для второй стороны на
интерфейсе 2
ep recv 2 srcip first // ожидание пакетов для первой стороны на
интерфейсе 2
ep recv 0 srcip second // ожидание пакетов для второй стороны на
интерфейсе 0
В примере показана стандартная конфигурация при имитации сессии клиентсервер. Две стороны. Стороны выделяются по значениям IP адресов источника. Первая
сторона имеет адрес из первого пакета, вторая сторона – из второго пакета. Пакеты
первой стороны будут посылаться с нулевого интерфейса, второй – со второго. При
ожидании пакетов – наоборот.
RUN – запуск имитации работы приложений
run <основное требование> <список пакетов>
Команда запускает имитацию работы приложений.
В параметрах команды указывается требование к результатам теста: какие из
пакетов должны быть успешно приняты ожидающими конечными точками (см. команду
EP), а какие нет. Если пакет не принадлежит ни к одной из ожидающих конечных точек,
то он всегда отмечается, как принятый.
Результат для каждого пакета в «списке пакетов» должен удовлетворять
«основному требованию».
<основное требование> ::= (“accept” | “drop” | “any”)
Результат для пакетов вне списка должен удовлетворять требованию,
противоположному от основного. Основное требование any означает отсутствие
требований ко всем пакетам.
Пример списка пакетов:
32
1,2,3-4,7Номер означает номер пакета в trace-файле, открытом командой TRACE.
Минус в конце означает продолжение списка до последнего пакета в trace файле.
То есть
1,2,3-4,7-<последний пакет в файле>
Список «any» эквивалентен списку “1-“.
Run accept any
-
означает требование, что все пакеты должны быть пропущены.
Run drop 6-
- означает, что все пакеты, начиная с 6, должны быть отброшены, а все до 6 –
пропущены.
Run any any
- означает отсутствие требований.
RM – определение автозаменителя во время имитации работы приложений
rm <тип> <имя поля> <искомое значение> <вставляемое значение>
<тип> ::= (“recv” | “gen”)
Автозамена используется в том случае, когда пакеты по пути следования
изменяются (NAT) или просто, когда надо использовать свои значения полей, а не те, что
указаны в trace файле.
Тип указывает, когда использовать автозамену: при генерации (gen) или приеме
пакетов (recv).
Автозамена будет выполняться перед генерацией пакета или перед его ожидаем
(т.е. ожидаться будет измененный пакет).
В параметрах команды указывается имя поля, значение которого может быть
изменено, искомое значение поля и значение, на которое искомое будет заменено.
Пример:
rm gen srcip 1.1.1.1 10.0.0.1
rm recv srcip 1.1.1.1 10.0.0.2
В показанном примере при генерации любых пакетов адрес источника 1.1.1.1 будет
изменен на 10.0.0.1. При приеме тех же пакетов из trace-файла адрес 1.1.1.1 будет
заменен 10.0.0.2. То есть предполагается, что какая-то промежуточная точка (NAT)
меняет адрес источника в пакетах с 10.0.0.1 на 10.0.0.2, поэтому генерировать нужно
одни пакеты, а ожидать немного другие.
CIEVE – указание поля, значение которого не будет проверяться во время
имитации работы приложений
Cieve <имя поля>
При ожидании пакета и его сравнении с любым принятым значение указанного
поля не будет рассматриваться.
ARM – создание адаптивной автозамены во время имитации работы
приложений
arm <имя поля> <значение поля>
Адаптивная автозамена необходима, когда пакеты по пути следования не только
изменяются, но даже неизвестно, как они будут изменены (например, номер порта
клиента при работе NAT).
При встрече данной команды два автозаменителя (команда RM), которые были
определены перед ней, будут сначала отмечены как неактивные: как будто их нет. Во
33
время имитации работы приложения, когда будет принят пакет, у которого указанное
поле имеет указанное значение (см. параметры команды), то произойдет инициализация
этих двух автозаменителей: для каждого из них «вставляемое значение» (см. команду RM)
будет взято из принятого пакета. После этого они будут отмечены активными и станут
работать.
Более точно: оба автозаменителя должны иметь не обязательно одинаковые поля,
но с одинаковым размером и типом. Если поля разные, то из принятого пакета будет взято
значение поля, соответствующего первому автозаменителю. Оно будет скопировано во
«вставляемое значение» для второго.
Замечание: первый из автозаменителей должен всегда иметь тип recv, а второй
gen.
Пример:
rm recv srcport first 3
rm gen
dstport second 4
arm syn 1
В данном примере указывается, что необходимо ждать пакет с флагом SYN. Из
этого пакета следует взять значение порта источника и установить это значение вместо 3
и 4.
NUMRET – установка количества повторных посылок во время имитации
работы приложений
numret <количество повторных посылок>
По умолчанию производится одна повторная посылка пакета (пакетов). После
выполнения указанного числа повторных посылок пакет будет отмечен, как отброшенный.
RANGE – установка диапазона пакетов по время имитации работы
приложений
Range <первый пакет> <последний пакет>
По умолчанию рассматривается весь trace файл целиком. Эта команда позволяет
указать более узкий диапазон из файла. Нулевое значение для первого пакета означает
первый пакет из файла, нулевое значение для последнего пакета означает последний
пакет из файла.
34
35