Механизм MTPSec защиты от атак DoS в ОКС№7
В качестве механизма защиты большинство производителей оборудования предусматривают брандмауэры (firewalls), выполняющую процедуру просеивания. В частности, в оборудовании фирмы Cisco предусмотрен только такой механизм защиты от атак DoS. Зарубежные авторы работ [200-202] отмечают ограниченные возможности этого механизма защиты. Для обеспечения необходимой ИБ от атак DoS в ОКС№7 в этих работах предлагается использовать разработанный ими механизм MTPSec аутентификации и защиты целостности сигнальных сообщений между всеми соседними пунктами сигнализации SP (Signaling Point).
На рис. 22.10. приведен механизм безопасности MTPSec, являющийся усовершенствованием подсистемы передачи сообщений MTP системы сигнализации ОКС№7.
Рис. 22.10. Схема усовершенствования подсистемы MTP
Как видно из рисунка MTPSec относится в MTP к обработке сигнальных сообщений (Signaling Message Handing), выполняющей функции маршрутизации сообщений (Message Routing), распознаванию сообщений (Message Discrimination), распределению сообщений (Message Distribution). На рисунке показано так же взаимодействие MTPSec с управлением сетью сигнализации (Signaling Network Management), выполняющем функции управления маршрутами сигнализации (Signaling Route Management), управления трафиком сигнализации (Signaling Traffic Management), управления звеном сигнализации (Signaling Link Management). Для создания алгоритма протокола MTPSec были заимствованы принципы работы протокола IPSec сети TCP/IP. MTPSec включает две фазы протокола обмен ключами KE (Key Exchange). Протокол KE основан на протоколе IKE (Internet Key Exchange), определенный в стандартах RFC 2409 и RFC 4306. Протокол KE выполняет взаимную аутентификацию соседних пунктов сигнализации SP (Signaling Point) и устанавливает общий ключ сессии, который используется для обеспечения целостности сообщений с помощью протокола HMAC. Протокол обмена ключами KE включает две фазы. В фазе 1 при обмене сообщениями последовательно выполняются следующие функции: 1) Создается защищенный канал SA (Security Association), по которому оба соседние SP на канальном уровне ОКС№7 (MTP2) согласовывают параметры – алгоритмы шифрования, аутентификации и др. 2) с помощью алгоритма Диффи-Хеллмана создается общий мастер-ключ. На основе этого ключа формируются три ключа для обеспечения ИБ сообщений KE (для шифрования сообщений KE, обеспечения целостности сообщений KE, для создания ключа сессии в фазе 2. 3) выполняется аутентификация соседних SP ОКС№7. Для этого используется алгоритм с открытым ключом RSA. Закрытым ключом SP шифруется хэш сообщения, включающие идентификатор SP, открытые ключи при обмене по протоколу Диффи-Хеллмана и др. параметры. В фазе 2 проводится согласование параметров для выполнения функции защищенной связи SA по выполнению аутентификации сообщений между соседними устройствами ОКС№7 по протоколу AH (Authentication Header). Создается ключ сессии, используемой протоколом AH. Производится его периодическая регенерация (создание нового ключа) без использования фазы 1. При регенерации используются другие нонсы (случайные числа).
Аутентификация по протоколу AH предназначена для обеспечения целостности сообщений MSU по управлению сетью сигнализацией и поверки подлинности источника этих сообщений. Для выполнения AH в MTP вводится дополнительная функция MTPSec, позволившая изменить формат значащей сигнальной единицы MSU (Message Signal Unit). На рис. 22.11 приводится приведенный в работах [201,202] формат сообщения MSU ОКС№7 в MTPSec. Заголовок аутентификации AH определяет целостность принятого сообщения и подлинность пункта сигнализации-отправителя.
Рис.22.11. Формат сообщения MSU ОКС№7 в MTPSec
Предлагается хэшировать отдельные поля сообщений MTP и SCCP. При этом не потребуется шифрование длинных массивов при определении хэш функции с помощью кода аутентичности сообщения MAC. Как показано на рис. 22.11 заголовок AH расположен между этикеткой маршрутизации и сообщением пользователя. Предложенный заголовок AH состоит из следующих полей. Поле “Идентификатора вида службы” определяет относится ли это сообщение к SCCP, ISUP, управлению сетью и др. Поле идентификатора службы вместе с “Типом сообщения” определяют к каким полям и параметрам сообщений относится хэширование. Например, в значении “Идентификатора вида службы” указано на сообщение функции управления сетью сигнализации, а в значении тип сообщения – TFP. Поле “Длина” указывает на длину, подлежащую хэшированию. Поле «Индекс параметров защиты SPI» – это идентификатор соединения.
Поле «Порядковый номер» используется механизмом окна защиты от угрозы «повтор». Поле «Данные аутентификации» содержит результат аутентификации данных, включающих OPC, DPC и требуемые параметры сообщений.
200.H.Sengar, D. Wijesekera. S.Jajodia. Authentication and Integrity in telecommunication Signaling Network. Engineering of Computer-Based Systems, 12th IEEE International Conference and Workshops, 2005 163 – 170 p.
201.Sengar H., Wijesekera D., Jajodia S., “MTPSec:customizable secure MTP3 tunnels in the SS7 network”.Parallel and Distributed Processing Symposium, 2005.Proceedings. 19th IEEE International.
202.Yucun Yang1, Weiwei He 2, Suili Feng1. Security Analysis and Amendment of 3G Core Network Based on MTPsec, IEEE Pacific-Asia Workshop on Computational Intelligence and Industrial Application, 2008, 519-523 p