ИС «Антифрод» создается в целях обеспечения соблюдения операторами связи обязанностей, предусмотренных пунктами 8, 9 и 10 статьи 46 Федерального закона от 7 июля 2003 года № 126 ФЗ «О связи» (далее – 126-ФЗ).
Статья 46.1 126-ФЗ. Система обеспечения соблюдения операторами связи требований при оказании услуг связи и услуг по пропуску трафика в сети связи общего пользования.
В рамках реализации данной функции ИС «Антифрод» обеспечивает выявление фактов неправомерной модификации абонентского номера (уникального кода идентификации) вызывающего абонента при установлении телефонного соединения, согласно пункту 10 статьи 46 Закона о связи. Данная функция осуществляется системой в режиме реального времени в процессе установления телефонного соединения в телефонной сети связи общего пользования Российской Федерации.
Рисунок 1 – Процедура верификации вызова в случае отсутствия подмены
Проверка подлинности абонентского номера (уникального кода идентификации) вызывающего абонента осуществляется в формате двухфакторной верификации.
1. Вызов абонента оператора связи ОС1 с номером А1 к абоненту оператора ОС2 с номером В2. Оператор связи, инициирующий соединение в телефонной сети связи, передает информацию об исходящем вызове в ИС «Антифрод». В системе обеспечивается краткосрочное хранение информации, полученной от оператора связи, инициировавшего соединение.
2. Оператор связи вызываемого абонента, завершающий установление соединения в телефонной сети связи, запрашивает в ИС «Антифрод» информацию о входящем вызове A1-В2. В частности, запрашивается подлинность значения номера вызывающего абонента.
3. В ИС «Антифрод» осуществляется сверка информации, полученной от оператора связи вызываемого абонента, завершающего телефонное соединение, и сохраненной ранее информации, полученной от оператора связи, инициировавшего вызов в сторону оператора связи вызываемого абонента. На основании результатов проведенной сверки, оператору связи вызываемого абонента, завершающему установление телефонного соединения, из ИС «Антифрод» предоставляется информация для принятия решения о дальнейшей обработке входящего вызова. Узел верификации оператора ОС1 дает положительный ответ о наличии вызова А1-В2.
4. Вызов продолжается к абоненту оператора ОС2 с номером В2.
Рисунок 2 – Процедура верификации вызова с подменой номера
1. В этом случае происходит вызов от оператора-нарушителя к абоненту оператора ОС2 с номером В2 с подменой номера A на номер A1 оператора ОС1.
2. Узел верификации оператора ОС2 осуществляет запрос наличия вызова A1-В2 к Узлу верификации оператора ОС1 (владелец номера А1) по протоколу Interworking/ОКС-7.
3. Узел верификации оператора ОС1 дает отрицательный ответ о наличии вызова А1-В2, информация об отрицательном ответе записывается в базу данных оператора- владельца УВр1 и хранится в ней 12 месяцев.
4. В случае «отрицательного» результата сверки, когда в ИС «Антифрод» не подтверждается информация об инициировании в части запрашиваемого соединения, оператору связи вызываемого абонента, завершающему установление соединения, направляется информация для принятия решения о прекращении пропуска трафика для соответствующего соединения.
Оператор-владелец УВр2 записывает в базу данных информацию об отрицательном ответе на запрос и должен хранить ее в течение 12 месяцев.
5. Данные о зафиксированном факте нарушения передаются в ЦСУ в виде инцидентов от ОС1 и ОС2. Это происходит не в режиме реального времени и не влияет на загрузку сигнального канала связи.
Процедура верификации вызова должна позволять оператору связи вызываемого абонента получать от ИС «Антифрод» информацию для принятия решения о прекращении пропуска трафика до момента установления телефонного соединения (в течение действия таймера ожидания ответа от системы).
Задача верификации – осуществление проверки фактического совершения абонентского вызова путем получения соответствующего подтверждения от оператора связи (владельца А-номера по ФАС) в реальном времени с последующей передачей данной информации оператору связи (владельцу Б-номера по ФАС) по его запросу в рамках системы межоператорского антифрода (ВымпелКом, МТС, МегаФон, Теле2). На основании данной информации оператор связи (владелец Б- номера по ФАС) принимает решение о пропуске/блокировке вызова на своего абонента.
Верификация вызова может происходить:
1. В коммерческой транковой группе (далее – КТГ) одномоментно с пропуском коммерческого трафика. Под КТГ понимается группа соединительных линий, объединенная под одним интерфейсом (SIP, TDM или др.), предназначенная для пропуска трафика.
2. По двум и более транковым группам: КТГ и верификационной транковой группе (далее – ВТГ), где КТГ используется для пропуска трафика и одновременной верификации входящего трафика, а ВТГ — для входящего трафика, направленного оператором А исключительно для целей верификации. Под ВТГ понимается группа соединительных линий, объединенная под одним интерфейсом (SIP, TDM или др.), предназначенная для верификации трафика.
3. По протоколу HTTP/RADIUS.
Реализация верификации происходит путем постановки существующего присоединения готовности оператора к верификации.
Рисунок 3 – Условная схема реализации верификации по КТГ
ВТГ организовывается в случае если:
1. У оператора есть абоненты, заключившие договоры на предоставление услуг внутри- зоновой и междугородной/международной связи с альтернативными операторами связи;
2. Транзитный трафик оператора планируется направлять на сеть крупного ОС исключи- тельно для целей верификации, при этом для дальнейшего коммерческого пропуска трафика используются альтернативные маршруты оператора.
ВТГ может быть организована с использованием ОКС-7 или SIP. В рамках присоединения SIP/ОКС-7 основная задача — настроить маршрутизацию трафика, предназначенного для альтерна- тивных маршрутов в ВТГ с возможностью дальнейшего рерутинга. Для этого необходимо выполнить следующие шаги:
Рисунок 4 – Условная схема реализции КТГ+ВТГ
Присоединение по протоколу ОКС-7:
1. Перейти в раздел «Внутренние ресурсы — Список причин отбоя Q.850», добавить спи- сок, добавить код отбоя, установленный крупным ОС (для примера выберем код 50):
2. Добавить ВТГ, во вкладке «Исходящая связь» указать в качестве резервной КТГ, выбрать созданный на предыдущем шаге список причин отбоя для перехода на резервную ТГ:
3. Добавить и настроить группу линий ОКС-7 (согласно настройкам, выданным крупным ОС для организации верификации) указав в ней ВТГ, созданную на предыдущем шаге, затем включить и настроить поток, указав в настройках созданную ранее группу линий;
4. В плане нумерации в нужных префиксах изменить транковую группу с КТГ на ВТГ.
Присоединение по протоколу SIP:
1. Перейти в раздел «Внутренние ресурсы — Список ответов SIP», добавить список, доба- вить код ответа, установленный крупным ОС (для примера выберем код 403):
2. Добавить SIP-интерфейс, указать IP-адрес, выданный крупным ОС для организации ВТГ, в пункте «Список ответов SIP для перехода на резервную ТГ» указать список, созданный на предыдущем шаге:
3. Добавить ВТГ и включить в её состав SIP-интерфейс, созданный на предыдущем шаге, затем во вкладке «Исходящая связь» указать КТГ в качестве резервной транк группы:
4. В плане нумерации в нужных префиксах изменить транковую группу с КТГ на ВТГ.
Вместо использования резервной транковой группы также есть возможность использовать транковое направление, создав его в разделе «Маршрутизация — Транковые направления». Здесь нужно добавить последовательно ВТГ, затем КТГ:
Созданное направление указываем в нужных префиксах плана нумерации, аналогично шагу 4.
Оператор направляет информацию о совершении вызовов своими абонентами в кэш АФ плат- формы крупного ОС. При поступлении запроса на верификацию вызовов АФ крупного ОС проверяет наличие данного вызова в кэше. Если информация о вызове оператора присутствует в кэше, то в сто- рону оператора отправитель запроса направляет подтверждение инициации вызова оператором. В противном случае, направляется уведомление о блокировке вызова.
Рисунок 5 – Условная схема реализации для RADIUS присоединения
В рамках процедуры получения базового доступа по протоколу HTTP/RADIUS предполагается использование схемы аутентификации с авторизационным заголовком в соответствии с RFC 7617.
На SMG для реализации присоединения по RADIUS необходимо выполнить следующие шаги:
1. Перейти в раздел «RADIUS — Серверы», указать IP-адрес, порт, пароль и группу сервера, на которую будут отправляться запросы. Также необходимо установить минимальные значения для параметров «Таймаут ответа сервера», «Число попыток отправки за- проса» и «Время неиспользования сервера при сбое». Таким образом, при неответе сервера задержка составит 0,6 секунды.
2. Создать профиль в разделе «RADIUS — Список профилей», активировать опцию «Ис- пользовать RADIUS-Authorization», указать группу, затем в блоке «Параметры RADIUS- Authorization» в пункте «Ограничение исходящей связи при сбое сервера» выбрать па- раметр «Нет ограничений».
3. В параметрах КТГ, для которой будет происходить верификация, перейти во вкладку
«Исходящая связь» и выбрать созданный на предыдущем шаге профиль RADIUS: