О применении данного документа в отношении федерального государственного контроля в области связи см. Распоряжение Правительства РФ от 15.12.2020 N 3340-р.

Таблица N 6

BLACKBERRY

19988

DHCP

67

Diameter

3868

DNS

53

DHCP

67

Exchange

135

FRING

46904

FTP

21

FTPdata

20

GTP

2123

H.323

1720

HTTP

80

HTTP (WebSocket)

8080

IAX2

4569

ICQ

5190

IMAP4

143

IRC

194

KERBEROS

88

MeGaCo

2944

MGCP

2427

MSN

1863

NNTP

119

OPERA MINI

1080

POP3

110

PPTP

1723

QQ

8001

Radius

1812

RDP

3389

RFB (VNC)

5900

SGsAP

29118

SIP,

5060

Skinny

2000

SKYPE

12350

SMB

445

SMTP

25

SNMP

161

Snmp

161

SSH

22

SSL/TLS

443

TACACS

49

TELEGRAM

5224

Telnet

23

Tor

9001

VTP

16666

Viber

4244

WAP (MMS)

9200

WhatsApp

5223

XMPP

5222

Yahoo

5050

Zello

28225

3.3.4.2. Коды событий прикладных протоколов.

Базовый перечень значений элемента описания данных:

а) код события прикладного протокола" (код свойства 78):

1 - удачная попытка входа на сервер;

2 - неудачная попытка входа на сервер;

3 - выход с сервера;

б) код события электронной почты:

4 - e-mail удачно отослан;

5 - неудачная попытка отправки e-mail (актуально для SMTP);

6 - e-mail получен;

7 - получен заголовок e-mail (актуально для IMAP4);

8 - получена часть письма (не заголовок);

9 - получено вложение web-mail;

10 - отправлено вложение web-mail;

в) код события FTP:

11 - отправка файла сервер FTP,

12 - добавление данных в файл на сервере FTP,

13 - получение файла с сервера FTP (кроме результата выполнения команды LIST);

14 - получение файла с сервера FTP в результате выполнения команды LIST;

г) код события VoIP:

15 - поток (однонаправленный) данных VoIP завершен;

16 - начало попытки звонка;

17 - нормальное завершение звонка;

18 - завершение звонка, отличное от нормального;

19 - окончание попытки звонка - занято;

20 - окончание попытки звонка - ошибка;

д) код события HTTP:

21 - контент отправлен на сервер HTTP;

22 - контент получен от сервера HTTP;

е) код иных событий:

24 - отчет о данных недекодированного потока;

25 - отсылка одного сообщения клиентом IM;

26 - завершение передачи файла клиентом IM;

27 - окончание попытки звонка - вызываемый абонент не отвечает;

28 - отсылка списка контактов клиентом IM;

29 - просмотр клиентом IM своего профиля;

30 - просмотр клиентом IM профиля другого пользователя;

31 - сообщение из истории переписки.

3.3.5. Передача IP-пакетов.

При передаче IP-пакетов поля блоков служебных данных заполняются в соответствии со структурой, представленной в подпунктах 3.3.3.1 и 3.3.3.2 настоящего приложения.

В блоки служебных данных в обязательном порядке должны входить следующие элементы описания данных и их значения:

"уровень протокола" - со значением равным 3 (сетевой);

"код протокола" - со значением равным 1;

"параметр отбора".

Поля блока отобранных данных заполняются в соответствии со структурой, представленной в подпункте 3.3.3.3 настоящего приложения.

3.3.6. Процедуры передачи данных, декодированных до сообщений прикладных протоколов.

3.3.6.1. Передача данных для прикладных протоколов с одним логическим каналом.

При передаче данных, полученных при декодировании прикладных протоколов, использующих один логический канал, поля блоков служебных данных заполняются в соответствии со структурой, представленной в подпунктах 3.3.3.1 и 3.3.3.2 настоящего приложения.

В блоки служебных данных в обязательном порядке должны входить следующие элементы описания данных и их значения:

"уровень протокола" - LP равно 7 (прикладной);

"код протокола" - в качестве кода протокола указывается номер порта протокола в соответствии со спецификацией RFC 1700, принимающий следующие значения:

25 - SMTP;

80 - HTTP;

110 - POP3;

143 - IMAP4;

"параметр отбора";

"IP адрес ресурса";

"порт ресурса";

"URL ресурса", если таковой существует.

Поля блока отобранных данных заполняются в соответствии со структурой, представленной в подпункте 3.3.3.3 настоящего приложения.

Отобранные данные соответствуют содержимому TCP-сессии (без заголовка TCP).

3.3.6.2. Передача данных VoIP.

Поля блоков служебных данных заполняются в соответствии со структурой, представленной в подпунктах 3.3.3.1 и 3.3.3.2 настоящего приложения.

В блоки служебных данных в обязательном порядке должны входить следующие элементы описания данных и их значения:

"уровень протокола" - LP равно 7 (прикладной);

"код протокола";

"параметр отбора";

"номер вызывающего абонента";

"номер вызываемого абонента".

Поля блока отобранных данных заполняются в соответствии со структурой, представленной в подпункте 3.3.3.3 настоящего приложения.

Данные VoIP передаются попакетно, содержимое каждого пакета передается в отдельном фрейме, начиная с заголовка RTP. В случае использования одинаковых параметров передачи медиаданных в двунаправленном потоке оба потока медиаданных отправляются от технического средства ОРМ на ПУ в одном логическом канале.

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

3.3.7. Процедуры передачи пользовательских данных.

3.3.7.1. Передача сообщений почтовых протоколов.

При передаче сообщений почтовых протоколов поля блоков служебных данных заполняются в соответствии со структурой, представленной в подпунктах 3.3.3.1 и 3.3.3.2 настоящего приложения.

Отобранные данные соответствуют фрагменту TCP-сессии, содержащему выделенное письмо.

В блоки служебных данных в обязательном порядке должны входить следующие элементы описания данных и их значения:

"уровень протокола" - LP равно 8;

"код протокола" со значением поля CodProt равного:

25 - если письмо выделено из сессии SMTP;

110 - если письмо выделено из сессии POP3;

143 - если письмо выделено из сессии IMAP4;

"параметр отбора";

"IP адрес партнера" - IP-адрес почтового сервера;

"порт партнера" - порт почтового сервера.

В случае отбора почтовых сообщений, просмотренных на сервере через HTTP протокол, передача данных осуществляется в соответствии с подпунктом 3.3.3.3 настоящего приложения. В блок служебных данных входят следующие элементы описания данных и их значения:

"уровень протокола" - LP равно 7 (прикладной);

"код протокола" - 80-HTTP;

"параметр отбора";

"IP адрес партнера";

"порт партнера";

"URL партнера", если таковой существует.

Поля блока отобранных декодированных данных заполняются в соответствии со структурой, представленной в подпункте 3.3.3.3 настоящего приложения. Отобранные данные соответствуют фрагменту TCP-сессии, содержащему выделенное письмо.

3.3.8. Передача данных канального уровня.

При передаче данных канального уровня поля блоков служебных данных заполняются в соответствии со структурой, представленной в подпунктах 3.3.3.1 и 3.3.3.2 настоящего приложения.

В блоки служебных данных в обязательном порядке должны входить следующие элементы описания данных и их значения:

"уровень протокола" - LP = 2 (канальный);

"параметр отбора".

Поля блока отобранных данных должны заполняться в соответствии со структурой, представленной в подпункте 3.3.3.3 настоящего приложения. Отобранные данные соответствуют последовательности кадров канального уровня, которые передаются целиком (например, Ethernet-кадров, если используется технология Ethernet). Кадры передаются в той последовательности, в которой они прошли через точку съема.

4. Порядок подключения ТС ОРМ к ПУ.

4.1. Порядок установления TCP-соединений между ПУ и техническим средством ОРМ.

На логическом уровне соединение ПУ - технические средства ОРМ реализуется в виде TCP-сессии. В качестве транспортного и сетевого протоколов используются протоколы TCP и IP. Инициатором соединения является ПУ. Технические средства ОРМ должны находиться в режиме ожидания TCP-соединения.

Технические средства ОРМ должны обеспечивать возможность подключения до 16 ПУ (включая один головной ПУ). Для управления техническими средствами ОРМ и передачи отобранных данных для каждого ПУ используются отдельные TCP-соединения, которые идентифицируются как канал управления и канал передачи данных соответственно. В качестве номеров портов должны использоваться номера, находящиеся вне диапазона номеров портов стандартных служб. Номера портов для канала управления и канала передачи данных головного ПУ определяются следующим образом:

16117 - порт канала передачи данных, 16118 - порт канала управления.

Первой между ПУ и техническим средством ОРМ инициируется процедура установления канала управления, затем - канала передачи данных. Инициатором установления TCP-соединений канала управления и канала передачи данных является ПУ. Установление канала передачи данных может выполняться параллельно с установлением канала управления. После установления TCP-соединения канала управления первой с ПУ на технические средства ОРМ передается команда идентификации (подпункт 2.2.1 настоящего приложения).

Передача команд постановки на контроль не должна производиться до завершения установления TCP-соединения канала передачи данных.

Передача извещений с ТС ОРМ на ПУ о нарушении прав доступа или функционировании этих ТС ОРМ может осуществляться в любой момент времени после создания канала управления.

4.2. Порядок установления TCP-соединений между дополнительными ПУ и техническим средством ОРМ.

Технические средства ОРМ должны обеспечивать возможность подключения до 15 дополнительных ПУ.

На физическом уровне дополнительные ПУ подключаются к головному ПУ. Подключение к аппаратно-программным средствам ТС ОРМ производится через головной ПУ по каналам: дополнительный ПУ - головной ПУ и головной ПУ - технические средства ОРМ.

На логическом уровне соединение дополнительного ПУ - технические средства ОРМ реализуется аналогично соединению ПУ - технические средства ОРМ. Инициатором соединения является дополнительное ПУ. При этом технические средства ОРМ находятся в режиме ожидания TCP-соединения.

Для передачи информации о критериях отбора и передачи отобранных данных используются отдельные TCP-соединения, которые идентифицируются как канал управления и канал передачи данных соответственно. В качестве номеров портов должны использоваться номера, зависящие от номеров портов, используемых при соединении ПУ - технические средства ОРМ и номера дополнительного ПУ.

Номера портов для канала управления и канала передачи данных дополнительного ПУ вычисляются по формуле:

PUPort = BasePUPort + VKTSId * 2,

где:

PUPort - номер порта дополнительного ПУ;

BasePUPort - номер порта головного ПУ;

VKTSId - номер дополнительного ПУ.

Первой между дополнительным ПУ и техническим средством ОРМ инициируется процедура установления канала управления. После инициирования процедуры установления канала управления инициируется процедура установления канала передачи данных. Инициатором установления TCP-соединений канала управления и канала передачи данных является дополнительный ПУ. Установление канала передачи данных может выполняться параллельно с установлением канала управления. После установления TCP-соединения канала управления первой с дополнительным ПУ на ТС ОРМ передается команда идентификации (подпункт 2.2.1 настоящего приложения).

По каналу управления от дополнительного ПУ к техническим средствам ОРМ должны передаваться только команды следующих типов:

идентификация (формат согласно подпункту 2.2.1 настоящего приложения);

постановка на контроль и изменение вида контроля (формат согласно подпункту 2.2.16 настоящего приложения);

снятия с контроля (формат согласно подпункту 2.2.17 настоящего приложения);

проверка работоспособности канала (формат согласно подпункту 2.2.4 настоящего приложения);

запрос системного времени (формат согласно подпункту 2.2.5 настоящего приложения).

Иные команды, полученные от дополнительного ПУ, должны игнорироваться.

По каналу управления от ТС ОРМ к дополнительному ПУ должны передаваться только сообщения следующих типов:

ответ на команду постановки на контроль и изменения вида контроля (формат согласно подпункту 2.3.16 настоящего приложения);

ответ на команду снятия с контроля (формат согласно подпункту 2.3.17 настоящего приложения);

ответ на команду инициализации (формат согласно подпункту 2.3.1 настоящего приложения);

ответ на команду проверки работоспособности канала (формат согласно подпункту 2.3.4 настоящего приложения);

ответ на команду запроса системного времени (формат согласно подпункту 2.3.5 настоящего приложения);

извещение о постановке на контроль (формат согласно подпункту 2.4.6 настоящего приложения);

извещение о снятии с контроля (формат согласно подпункту 2.4.7 настоящего приложения).

Постановка на контроль должна осуществляться только с ПУ по команде, описанной в подпункте 2.2.16 настоящего приложения, при условии полного совпадения параметров, указанных в сообщении о передаче критериев отбора, поступившем от дополнительного ПУ.

Передача данных между аппаратно-программными средствами ТС ОРМ и дополнительного ПУ осуществляется в соответствии с пунктом 3 настоящего приложения.

4.3. Процедура передачи сообщений по каналу управления.

В процессе передачи сообщений по каналу управления должны использоваться следующие внутренние переменные:

Tw - таймер неактивности передачи, по умолчанию 5 минут (на стороне ПУ и технического средства ОРМ);

Ntw - счетчик срабатывания таймера неактивности передачи, по умолчанию равно 3;

MaxNtw - максимальное число срабатываний таймера Tw, по умолчанию равно 3 (на стороне ПУ и технического средства ОРМ).

Начальные значения внутренних переменных должны определяться на этапе инсталляции системы.

После передачи сообщения передающая сторона должна обнулить таймер неактивности передачи и ожидать ответ (подтверждение). При получении ответа (подтверждение) таймер и счетчик Ntw должны обнулиться.

В случае если на какую-либо переданную команду (извещение) не получен ответ (подтверждение), передающая сторона в момент достижения таймером Tw своего максимального значения (по умолчанию 5 минут) должна повторить передачу, обнулить таймер, увеличить показания счетчика Ntw на 1 и ожидать ответ (подтверждение). Подобная процедура должна выполняться до получения ответа (подтверждения) или до достижения значения MaxNtw (максимального числа срабатываний таймера Tw). Если на передающей стороне не получен ответ (подтверждение) на посланную ей команду (извещение) по достижении значения MaxNtw, то это означает пропадание канала на недопустимо большой промежуток времени. Передающая сторона должна инициировать команду на разрыв TCP-соединений канала передачи данных и управления.

В случае отсутствия передачи сообщений по каналу управления в момент достижения на стороне ПУ таймером Tw своего максимального значения (по умолчанию 5 минут) ПУ должно передать на ТС ОРМ команду проверки работоспособности канала управления и ТС ОРМ (подпункт 2.2.4 настоящего приложения).

4.4. Процедура передачи отобранных данных.

Процедуры передачи данных используют следующие внутренние переменные:

Wp - значения окна на стороне ПУ (количество неподтвержденных ТС ОРМ фреймов);

Ws - значения окна на стороне ТС ОРМ (количество неподтвержденных ПУ фреймов);

NFs - количество подтверждаемых ПУ фреймов;

Tw - таймер неактивности передачи (на стороне ПУ и технического средства ОРМ);

Ntw - счетчик срабатывания таймера неактивности передачи;

MaxNtw - максимальное число срабатываний таймера Tw (на стороне ПУ и технического средства ОРМ);

FRp - номер фрейма на стороне ПУ;

FRs - номер фрейма на стороне технического средства ОРМ.

Значение внутренней переменной MaxNtw должно определяться на этапе инсталляции системы.

Передача каждого фрейма должна сопровождаться обнулением таймера Tw и увеличением на 1 циклической переменной FRp (при передаче фрейма от ПУ к техническим средствам ОРМ) и FRs (при передаче фрейма от ТС ОРМ к ПУ). Изменение переменной FRp должен осуществлять ПУ, изменение переменной FRs - ТС ОРМ. В случае отсутствия данных для передачи на ПУ в момент достижения таймером Tw максимального значения ТС ОРМ передачи данных должен обнулить таймер, увеличить величину счетчика Ntw на 1 и ожидать подтверждения. Если по достижении таймером Tw максимального значения подтверждение о получении фрейма не получено, ТС ОРМ должно повторить передачу на ПУ фрейма извещения контроля работоспособности канала передачи данных без изменения переменной FRs. При этом должен обнулиться таймер и должна увеличиться величина счетчика Ntw на 1. Приведенная процедура должна выполняться до получения подтверждения от ПУ, свидетельствующая о восстановлении канала после возможного сбоя или достижении максимального значения (MaxNtw) переменной Ntw, и свидетельствует о пропадании канала на недопустимо большой промежуток времени. При достижении счетчиком своего максимального значения MaxNtw ТС ОРМ должно уничтожить данные об объектах, а также уничтожить всю отобранную информацию и обнулить внутренние переменные. ТС ОРМ должно выдать команду на разрыв TCP-соединений каналов передачи данных и управления (если соединения продолжают осуществляться) и перейти в режим ожидания TCP-соединения с ПУ в соответствии с подпунктом 4.1 настоящего приложения.

Если на ПУ не поступают фреймы от ТС ОРМ в течение работы таймера Tw, то ПУ должен увеличить свой счетчик Ntw на 1, обнулить таймер Tw и послать подтверждение о получении последнего принятого извещения. При достижении показаний счетчика Ntw максимальных значений, равного MaxNtw (пропадание канала на недопустимо большой промежуток времени), ПУ инициирует команду на разрыв TCP-соединений каналов передачи данных и управления, если они продолжают осуществляться.

Если от технического средства ОРМ получен фрейм извещения контроля работоспособности канала передачи данных, то ПУ должен послать подтверждение об этом, обнулить таймер Tw и счетчик Ntw. Получив подтверждение от ПУ, ТС ОРМ должно обнулить на своей стороне таймер Tw и счетчик Ntw. Посылка фрейма извещения контроля работоспособности канала передачи данных должна осуществляться только при достижении максимального значения таймера Tw на стороне технического средства ОРМ.

Во время обмена фреймами для подтверждения успешного получения переданной информации должны использоваться переменные FRp и FRs.

В передаваемом фрейме передающая сторона должна установить значение номера фрейма удаленной стороны равному последнему полученному. Для того, чтобы не подтверждать каждый полученный фрейм, должны использоваться переменные Wp и Ws, которые определяют число неподтвержденных фреймов. Максимальные значения переменных Wp и Ws должны быть равны 255. По достижении этими величинами своего максимального значения передача любой информации должна быть прекращена до получения с удаленной стороны любого фрейма, в соответствии с которым должен определяться номер последнего правильно принятого фрейма. После получения от ТС ОРМ NFs фреймов ПУ должна подтвердить последний принятый фрейм. Фреймы с номерами передачи вне диапазона окна должны сбрасываться без обработки.

Временная диаграмма взаимодействия ПУ и технического средства ОРМ при передаче сообщений по каналу передачи данных представлена на рисунке 128.

Рисунок (не приводится)

Fi - Fi+1 - подтверждающие фреймы со стороны ПУ

Fk - Fk+n - фреймы с данными, передаваемыми на ПУ

Рисунок 128

В процессе обмена фреймами прием каждого фрейма должен сопровождаться обнулением таймера Tw и счетчика Ntw. Если от технического средства ОРМ получен фрейм, свидетельствующий о том, что окно неподтвержденных фреймов на стороне технического средства ОРМ заполнено, то ПУ должен послать в ответ подтверждение и обнулить таймер Tw и счетчик Ntw. После получения подтверждения от ПУ ТС ОРМ должно обнулить таймер Tw и счетчик Ntw для возобновления передачи данных.

4.5. Процедура восстановления при сбоях.

Процедура восстановления при сбоях заключается в повторной передаче всех сообщений, на которые не получен ответ (подтверждение), а также всех неподтвержденных и непосланных фреймов на удаленную сторону после кратковременного (переменная Ntw не достигла MaxNtw - своего максимального значения) пропадания связи между ПУ и техническим средством ОРМ.

4.6. Реакция на ошибки.

Если на ТС ОРМ приходит сообщение с нарушенной структурой (нарушен формат сообщения/фрейма, неизвестная команда/подтверждение), ТС ОРМ должно уничтожить данные о параметрах отбора, а также уничтожить всю отобранную информацию и обнулить внутренние переменные. После этого ТС ОРМ должно выдать команду на разрыв TCP-соединений каналов передачи данных и управления и перейти в режим ожидания TCP-соединения с ПУ в соответствии с подпунктом 4.1 настоящего приложения.

Если количество поступающих на ТС ОРМ сообщений превышает границы окна, то ТС ОРМ должно уничтожить данные об объектах, всю отобранную информацию и обнулить внутренние переменные. После этого ТС ОРМ должно выдать команду на разрыв TCP-соединений каналов передачи данных и управления и перейти в режим ожидания TCP-соединения с ПУ в соответствии с подпунктом 4.1 настоящего приложения.

В случае если на ПУ приходит сообщение с нарушенной структурой (нарушен формат сообщения/фрейма, неизвестное извещение или ответ на команду, идентификатор принятого на ПУ сообщения находится за границами окна) ПУ должен выдать команду на разрыв TCP-соединений каналов передачи данных и управления. В этом состоянии ПУ должен возобновить функционирование с этим техническим средством ОРМ только после получения от оператора ПУ запроса на установление TCP-соединения с техническим средством ОРМ, которое осуществляется в соответствии с подпунктом 4.1 настоящего приложения.

При установлении повторного соединения управления должен произойти разрыв предыдущего соединения управления.

В случае если идентификатор ПУ, переданный в команде идентификации, совпадает с идентификатором, используемым в предыдущем соединении, разрыв соединений передачи данных не должен производиться, и передача данных должна быть продолжена. В случае несовпадения идентификаторов существующие соединения передачи данных и статистики должны быть разорваны.