2.1.2.4 Управление соединениями

Соединение — это совокупность информации о состоянии потока данных, включающая сокеты, номера посланных, принятых и подтвер­жденных октетов, размеры окон.

Каждое соединение уникально идентифицируется в Интернете парой

сокетов. Процедура установления соединения происходит следующим образом (рисунок 2.2).

Предположим, узел А желает установить соединение с узлом В. Первый отправляемый из А в В TCP-сегмент не содержит полезных данных, а служит для установления соединения. В его заголовке (в поле Flags) установлен бит SYN, означающий запрос начала сеанса, и содержится ISN (Initial Sequence Number — начальный порядковый номер) — число, начиная с которого узел А будет нумеровать отправляемые октеты. В ответ на получение такого сегмента узел В откликается посылкой TCP сегмента, в заголовке которого установлен бит АСК, подтверждающий установление соединения для получения данных от узла А. Так как протокол TCP обеспечивает полнодуплексную передачу данных, то узел В в этом же сегменте устанавливает бит SYN, означающий запрос начала сеанса для передачи данных от В к А, и передает свой ISN. Полезных данных этот сегмент также не содержит. Третий TCP-сегмент в сеансе посылается из А в В в ответ на сегмент, полученный из В. Так как соединение А→В можно считать установленным (получено подтверждение от В), то узел А может включить в свой сегмент полезные данные, нумерация которых начинается с номера ISN(A)+1. Данные нумеруются по количеству отправленных октетов. В заголовке этого же сегмента узел А устанавливает бит АСК, подтверждающий установление связи В→А, что позволяет хосту В включить в свой следующий сегмент полезные данные для А.

Рисунок 2.2 - Установка ТСР-соединения

Сеанс обмена данными заканчивается процедурой закрытия соедине­ния, которая аналогична процедуре установки, с той разницей, что вместо SYN для закрытия используется служебный бит FIN («данных для отправки больше не имею»), который устанавливается в заголовке последнего сегмента с данными, отправляемого узлом [30].

Аварийный разрыв соединения происходит при посылке одним участником соединения другому сегмента со служебным битом RST. В этом случае все недоставленные данные и управляющие структуры соединения немедленно уничтожаются, даже если второй участник не собирался завершать сеанс. RST-сегменты отправляются при возникновении нештатных ситуаций.

2.1.2.5 Заголовок тср-сегмента

TCP-сегмент состоит из заголовка и данных. Сегмент помещается в поле данных IP-датаграммы (рисунок 2.3). Заголовок ТСР-сегмента состоит из 32-разрядных слов и имеет переменную длину, зависящую от размера поля Options, но всегда кратную 32 битам. За заголовком непосредственно следуют данные — часть потока данных пользователя, передаваемая в данном сегменте.

Протокол TCP 21 1

Значения полей заголовка следующие.

Source Port (16 битов), Destination Port (16 битов) — номера портов процесса-отправителя и процесса-получателя соответственно [7].

Sequence Number (SN) (32 бита) — порядковый номер первого октета в поле данных сегмента среди всех октетов потока данных для текущего соединения, то есть если в сегменте пересылаются октеты с 2001 -го по 3000-й, то SN=2001. Если в заголовке сегмента установлен бит SYN(фаза установления соединения), то в поле SN записывается начальный номер (ISN). Номер первого октета данных, посылаемых после завершения фазы установления соединения, равен ISN+1. По достижении максимального значения (2³²-1) нумерация октетов продолжается с нуля — то есть происходит по циклу.

Даже если сегмент не несет данных, а предназначен только для под­тверждения получения данных от собеседника, порядковый номер все равно указывается. В этом случае он равен номеру последнего отправленного октета данных, увеличенному на 1 (то есть, номеру первого октета в доступном окне).

Acknowledgment Number (ACK SN) (32 бита) — если установлен бит AСК, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN+1 до ACK SN-1 включительно) были успешно получены.

Data Offset (4 бита) — длина TCP-заголовка в 32-битных словах, Диапазон допустимых значений от 5 (минимальная длина заголовка, Поле Options отсутствует) до 15 (то есть 60 октетов) [30].

Reserved (6 битов) — зарезервировано; заполняется нулями.

Control Bits (6 битов) — управляющие биты; активным является положение «бит установлен». URG — поле срочного указателя (Urgent Pointer) задействовано; АСК — поле номера,подтверждения (Acknowledgment Sequence Number) задействовано; PSH — осуществить «проталкивание» — если модуль TCP получает сегмент с установленным флагом PSH, то он немедленно передает все данные из буфера приема процессу-получателю для обработки, даже если буфер не был заполнен; RST— сброс текущего соединения — при получении сегмента с установленным флагом RST соединение ликвидируется, недоставленные данные уничтожаются; SYN — запрос на установление соединения; FIN — нет больше данных для передачи.

Window (16 битов) — размер окна в октетах. Checksum (16 битов) — контрольная сумма; представляет из себя 16 битов, дополняющие биты в сумме всех 16-битовых слов сегмента (само поле контрольной суммы перед вычислением обнуляется). Контрольная сумма, кроме заголовка сегмента и поля данных, учитывает 96 битов псевдозаголовка, который ставится перед TCP заголовком для внутреннего употребления. Этот псевдозаголовок содержит IP-адрес отправителя (4 октета), IP-адрес получателя (4 октета), нулевой октет, 8-битное поле Protocol, аналогичное полю в IP-заголовке, и 16 битов длины TCP сегмента, измеренной в октетах (рисунок 2.4).

Рисунок 2.4 - Псевдозаголовок TCP

Такой подход обеспечивает защиту протокола TCP от ошибшихся в маршруте сегментов. Информация для псевдозаголовка передается через интерфейс «Протокол TCP/сетевой уровень» в качестве аргументов или результатов запросов от протокола TCP к протоколу IP [29].

Urgent Pointer (16 битов) — используется для указания длины срочных данных (для обозначения срочных данных используется также термин ООВ — out of band, вне основного потока), которые размещаются в начале поля данных сегмента. Указывает смещение последнего октета со срочными данными относительно первого октета в сегменте. Например, в сегменте передаются октеты с 2001-го по 3000-й, при этом первые 100 октетов являются срочными данными, тогда Urgent Pointer= 100. Протокол TCP не определяет, как именно должны обрабатываться срочные данные, но предполагает, что прикладной процесс будет предпринимать усилия для их адекватной и быстрой обработки. Поле Urgent Pointer задействовано, если установлен флаг URG.

Options — поле переменной длины; может отсутствовать или содержать одну опцию или список опций, реализующих дополнительные услуги протокола TCP. Поле опций состоит из октета Kind (тип опции), за которым могут следовать октет Length (длина опции в октетах) и октеты с данными для опции. Максимальная длина поля Options равна 40 октетам.

Стандарт протокола TCP определяет три опции (типы 0, 1, 2).

Опции типов 0 и 1 (Конец списка опций и Нет операции соответственно) состоят из одного октета, содержащего значение типа опции. При обнаружении в списке опции Конец списка опций разбор опций прекращается, даже если длина заголовка сегмента (Data Offset) еще не исчерпана. Опция Нет операции может использоваться для выравнивания между опциями по границе 32 битов.

Опция типа 2 (Максимальный размер сегмента) состоит из 4 октетов: одного октета типа опции (значение равно 2), одного октета длины (значение равно 4) и двух октетов, содержащих максимальный размер сегмента, который способен получать TCP-модуль, отправивший сегмент с данной опцией (MSS — Maximum Segment Size). Предполагается, что отправитель опции устанавливает максимальный размер сегмента равным величине MTU сети, к которой он непосредственно подключен. Опцию следует использовать только в SYN-сегментах на этапе установления соединения [7].

Опция Дайджест MD5 (MD5 Signature) предназначена для защиты сегмента, в котором она находится, от искажения или фальсификации злоумышленником. Перед вычислением дайджеста отправитель добавляет к сегменту секретный ключ, а полученный результат помещает в поле данных опции. Сам секретный ключ по сети не передается. Оба участника соединения должны владеть одним и тем же секретным ключом. Приняв сегмент, получатель вычисляет дайджест так же, как это делал отправитель, и сравнивает полученный результат с тем, что прислал отправитель. Если результаты не совпадают, то сегмент считается фальсифицированным. Опция была разработана для защиты сообщений протокола BGP.

Padding — выравнивание заголовка по границе 32-битного слова, если список опций занимает нецелое число 32-битных слов. Поле Padding заполняется нулями.

2.1.2.6 Состояния соединения

Деятельность программы протокола TCP можно рассматривать как реагирование на события в зависимости от состояния соединения (так называемый конечный автомат, finite state machine).

Ниже описаны состояния соединения и приведены диаграммы переходов. Под термином «процесс» здесь понимается процесс ТСР­ модуля, работающий с данным соединением на локальном узле; термин «чужой» относится к процессу, работающему с данным TCP-соединением на удаленном узле [30].

LISTEN— процесс пассивно ждет запроса со стороны чужих сокетов. SYN-SENT — процесс отправил свой SYN и ждет чужого SYN.

SYN-RECEIVED — процесс получил чужой SYN, отправил (раньше или только что) свой SYN и ждет АСК на свой SYN.

ESTABLISHED — процесс отправил АСК на чужой SYN, получил АСК на свой SYN; соединение установлено.

FIN-WAIT-1 — процесс первым отправил свой FIN и ждет реакцию той стороны; при этом он, возможно, продолжает получать данные.

FIN- WAIT-2 — процесс получил АСК на свой ранее отправленный FIN, но не получил чужой FIN; ждет чужой FIN; при этом, возможно, про­должает получать данные.

CLOSE-WAIT — процесс, не отправив свой FIN (возможно, не собираясь прекращать соединение), получает чужой FIN; он отправляет АСК на чужой FIN, но при этом, возможно, продолжает отправлять данные.

LAST-ACK— процесс отправил свой FIN, но ранее он уже получил FIN с той стороны и отправил на него АСК; поэтому процесс ожидает чужой АСК на свой FIN для окончательного закрытия соединения.

CLOSING — процесс ранее отправил свой FIN и еще не получил на него подтверждение, но получил чужой FIN (и отправил на него АСК); ждет АСК на свой FIN.

TIME-WAIT — процесс ранее отправил свой FIN и получил на него подтверждение, получил чужой FIN и только что отправил на него ACK Теперь процесс ждет некоторое время (два времени жизни сегмента, обычно 4 минуты) для гарантии того, что та сторона получит отправленный АСК (если АСК потеряется, то чужой FIN будет выслан еще раз), после чего соединение будет окончательно закрыто. Некоторые приложения, попадая в состояние TIIME-WAIT, предпочитают не ждать, а вместо этого вдогонку последнему АСК отправляют для надежности несколько RST-сегментов и немедленно ликвидируют соединение.

Однако, гарантия доставки последнего АСК— не единственная цель пребывания в состоянии TIME_WAIT. В сети могут находиться «заблудившиеся» сегменты соединения, которые считались потерянными, но на самом деле были задержаны каким-то промежуточным маршрутизатором. Если соединение слишком быстро перешло в состояние CLOSED, а модуль TCP тут же открыл новое соединение между теми же самыми сокетами, то заблудившийся сегмент в принципе может попасть в окно нового соединения, подменив собой легитимные данные, что может привести к серьезным последствиям для процесса-получателя. Удержание соединения в состоянии TIME-WAIT гарантирует, что все заблудившиеся сегменты будут либо получены (и проигнорированы), либо уничтожены по истечении времени жизни.

CLOSED — соединение отсутствует.

В диаграммах на рисунок 2.5 и 2.6 состояния соединения заключены в прямоугольники, переходы между ними показаны стрелками, с каждой стрелкой соотносится овал, поясняющий причину перехода. В овале над горизонтальной чертой указывается событие, вызвавшее переход; под горизонтальной чертой — действие, сопутствующее переходу.

2.2 Основные методы, применяемые при сканировании портов

2.2.1 Методы сканирования tcp-портов

2.2.1.1 Методы открытого сканирования

2.2.1.1.1 Метод icmp-сканирования

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

В сетях, организованных на базе стека протоколов TCP/IP, для этой цели используется протокол ICMP. Данный протокол является вспомогательным и позволяет маршрутизатору сообщать конечному узлу об ошибках либо непредвиденных ситуациях, которые имели место при передаче IP-дейтаграммы от этого узла.

Обмен информацией между маршрутизатором и узлом реализован с помощью ICMP-сообщений. Помимо сообщений об ошибках, в протоколе ICMP предусмотрен ряд стандартных запросов, позволяющих хосту получить различного рода информацию о состоянии объектов сети [24].

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

Для программной реализации данного метода пользователю необходимо знать некоторые особенности построения подобных запросов. Любое ICMP-сообщение имеет два уровня инкапсуляции в IP-дейтаграмму (см. рисунок 2.7). В начале любого ICMP-сообщения находятся три поля: «Тип сообщения», «Код» (причина ошибки) и «Контрольная сумма» [54]. Поле “Тип” определяет смысл ICMP-сообщения и соответствующий ему формат. Значения этого поля приведены в таблице 2.1.

Рисунок 2.7 - Инкапсуляция ICMP-сообщения

Таблица 2.1. Значения поля “Тип”