Dmitry Astapov (_adept_) wrote,
Dmitry Astapov
_adept_

Categories:

Траффик едет в Ростов - отчего, почему?

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

Если коротко, то написано, что российский оператор Rostov Cellular Communications (он же Tele2) сделал что-то такое эдакое, после чего звонки ряда украинских абонентов (МТС Украина) маршрутизировались ... через узлы сети Tele2. Это - как минимум - дает Tele2 полные метаданные о звонках (кто, кому, когда, как долго, ...), а как максимум - позволяет слушать исходящие звонки.

Справедливости ради надо сразу сказать, что атака совсем не МТС-специфична, и могла случится с любым другим оператором.

Как же это стало возможно?

Как всегда, в тексте много упрощений и аналогий, вся инфа взята из публичных источников (в частности, GSM 29.002).

У любого оператора есть база данных об абонентах, называемая HLR. Еще у любого оператора есть коммутатор, называемый MSC. Задача коммутатора - направлять входящие и исходящие звонки правильным элементам сети (в том числе - сети другого оператора), чтобы их там дальше обрабатывали.

Для того, чтобы маршрутизировать звонки, MSC периодически нужны данные из HLR:

+---+   +---+
|HLR|-->|MSC|
+---+   +---+


Эта картинка - неправильная :)

Как часто бывает с техническими решениями, на практике все сложнее: во-первых, коммутаторов в сети обычно много. Во-вторых, абоненты одной сети могут оказаться в зоне покрытия другой сети (роуминг), и тогда MSC надо будет обращаться к HLR-у, находящемуся черти-где (на другом континенте, например). То есть, каждый MSC обращается к куче HLR-ов, и соответственно каждый HLR отвечает на запросы кучи MSC и весь этот обмен сообщениями легко пересекает границы разных сетей:


+---------+   +---------+
|Tele2 HLR|-->|Tele2 MSC|
+---------+   +---------+
         `--,
            v  
+-------+   +---------+
|MTS HLR|-->|MTS MSC 1|
+-------+   +---------+
       `----,
            v
            +---------+
            |MTS MSC 2|
            +---------+


Чтобы несчастные HLR-ы не загнулись под потоком запросов, и чтобы MSC не страдали от задержек к HLR-ам на другом континенте, в стандарт GSM были введены такие себе "кэши" данных об абонентах под названием VLR:


+---------+   +---+---------+
|Tele2 HLR|-->|VLR|Tele2 MSC|
+---------+   +---+---------+
         `--,
            v  
+-------+   +---+---------+
|MTS HLR|-->|VLR|MTS MSC 1|
+-------+   +---+---------+
       `----,
            v
            +---+---------+
            |VLR|MTS MSC 2|
            +---+---------+


VLR - это visitor location register, и он содержит информацию об абонентах, которые "посетили" конкретный MSC и попали в зону покрытия, которую этот MSC обслуживает. Как только абонент оказывается в зоне покрытия MSC, информация о нем запрашивается из HLR, складывается в VLR, и живет там, пока этот абонент куда-то не денется (не выключит телефон, не уйдет в другому MSC, ...). Теперь MSC может ходить за информацией об абоненте в VLR -- это быстро, удобно, и снижает нагрузку на HLR-ы.

Но что делать, если информация об абоненте в HLR обновилась? Надо же каким-то образов обновить информацию и в VLR. На этот случай предусмотренно служебное сообщение (которое в документе по ссылке называется SAI_DN). HLR отправляет это сообщение нужному VLR-у, и тот обновляет у себя данные об абоненте.

Еще в сети оператора бывают такие себе "сервера приложений" под названием SCP (Service Control Point), на которых реализуются вещи вроде real-time биллинга, переносимости номеров, телефонные голосовалки и проч. В сведениях об абоненте будет записано, на каких фазах звонка коммутатор должен отдать управление SCP, и к какому именно SCP надо обратится:


+---------+   +---+---------+   +---------+
|Tele2 HLR|-->|VLR|Tele2 MSC|-->|Tele2 SCP|
+---------+   +---+---------+   +---------+    
         `--,                     ^ 
            v                     |
+-------+   +---+---------+-------'
|MTS HLR|-->|VLR|MTS MSC 1|----,
+-------+   +---+---------+    v
       |                     +-------+
       |                     |MTS SCP|
       |    +---+---------+  +-------+
       `--->|VLR|MTS MSC 2|----^
            +---+---------+


Как видите, на картинке есть стрелка между "MTS MSC" и "Tele2 SCP" - казалось бы, зачем она? А вот зачем: допустим, абонент Tele2 уехал в роуминг в сеть МТС Украина, и у этого абонента есть сервисы, которые реализуются SCP: автоматическая трансляция набранных номеров в правильные международный формат, мгновенный обсчет стоимости интернета или что-то там еще. Когда абонент в домашней сети, Tele2 MSC общается с Tele2 SCP, который выполняет все необходимые действия (уменьшает баланс абонента, транслирует номера в начале соединения и т.п.).

Когда же абонент находится в роуминге, происходит вот что: данные об абоненте приезжают из Tele2 HLR в MTS VLR, там записано, что в ходе звонка надо в определенные моменты дергать Tele2 SCP, и при исходящих звонках коммутатор MTS MSC будет так и делать, и Tele2 SCP будет по-прежнему исполнять все необходимые для реализации сервиса функции (ну, или почти все. желающие гуглят и читают про CAMEL roaming).

Как видите, архитектура глобальной сети GSM подразумевает, что узлы разных сетей могут обращаться друг к другу. Если МТС и Tele2 имеют договор о взаимном подключении к сетям друг друга, то это как правило означает, что HLR-ы, MSC и SCP одной сети могут общаться с элементами другой сети и наоборот. Можно, конечно, ставить аналоги файрволов с deep packet inspection на разных уровнях сетевого взаимодействия, и иногда так и делают, но чаще всего - нет.

Все вышеизложенное открывает простор для манипуляции, описанной в документе.

Есть такой себе абонент МТС Украина - назовем его Петя. О Пете есть запись в MTS HLR, там написано, что все Петины звонки должны отправляться на MTS SCP. Петя звонит, звонки обслуживаются MTS SCP (напрмер, считаются деньги за звонки), все счастливы.

В один прекрасный день из сети Tele2 приезжает запрос: "Мы хотим послать Пете смс, где же он?". Сеть МТС Украина говорит: "Так вот же он, возле MTS MSC 1, шлите SMS прямо туда!". Однако никакого СМС-а Пете никто не посылает, а вместо него в MTS VLR 1 присылается сообщение SAI_DN, в котором говорится: "Обновите Петины данные, теперь информация о его звонках должна уходить на Tele2 SCP".

Петины данные, хранящиеся в MSC VLR 1, обновляются! Это выглядит странно, почему вообще такое возможно? Проблема в том, что обычно сеть Tele2 обновляет таким образом информацию о своих абонентах, но с точки зрения стандарта ничто не мешает обновлять таким же образом данные других абонентов. Стандарт не требует проверять, обновляет ли другая сеть данные о своих абонентах (см. выше про файрволы, но тут их, похоже, не было).

Теперь все исходящие Петины звонки маршрутизируются через Tele2 SCP, который может делать с ними что угодно - просто записать, кто кому звонил, или же отправить "голосовой канал" через оборудование для записи разговоров. В качестве утешительного бонуса у Пети отключается тарификация звонков - т.к. ее делал MTS SCP, который теперь в процессе не участвует.

Если Петя выключит телефон или перейдет к другому MSC, то "перенаправление" на Tele2 SCP исчезнет, т.к. из HLR будут считаны исходные неизменные данные о Пете. В этом случае манипуляции с выяснением адреса VLR и заменой информации о SCP придется произвести заново.

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

The End
Tags: gsm
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 164 comments