Халявный интернет. Как и почему я бесплатно пользовался передачей данных в роуминге

Taya

Продавец
Проверенный покупатель
Подтвержденный
Регистрация
09.09.15
Сообщения
3,314
Реакции
1,062
Депозит
0
Покупок
7
Продаж
8

Год назад мы публиковали материал о том, как устроен предбиллинг — системы учета услуг мобильных операторов. В этот раз я хочу поделиться с тобой случаем из жизни, который демонстрирует слабую сторону таких систем и их потенциальную (а в моем случае — и вполне реальную) уязвимость.
Как ты знаешь, никакой код не безупречен. Все программы создаются людьми, и никто из них не может предугадать все возможные последствия работы в разных ситуациях. Иногда, особенно в сложных системах, это открывает совершенно неожиданные возможности. Это история именно такого случая.
Как-то раз (а точнее, в 2014 году) я был в Китае и пользовался телефоном в роуминге. А для доступа в интернет купил местную SIM-карту. Приехав домой в Россию, я забыл вытащить эту симку из планшета и продолжал ей пользоваться. Пока на ней были деньги, она прекрасно работала на чужбине, даже несмотря на то, что APN (Access Point Name) на ней было прописано китайского оператора. И это совершенно нормально: приезжая в роуминг, гостевой абонент не обязан постоянно переписывать APN вручную.

Прошел месяц, планшет с китайской симкой прекрасно продолжал работать в России. Мне стало интересно, что же такое происходит и почему баланс практически не меняется, да еще и в роуминге! Еще один волнующий вопрос — можно ли воспроизвести эту ситуацию. Благо у меня были все необходимые условия для поиска ответов.
Вся информация предоставлена исключительно в ознакомительных целях. Ни канал, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

Кто предоставляет интернет в роуминге?
В общем случае, когда ты приезжаешь со своим мобильным телефоном в другую страну и подключается роуминг, работает следующая схема.
  1. После включения телефона на оборудовании гостевого оператора выполняется процедура GPRS Attach (либо в обратную сторону отмена — detach).
  2. Наш телефон начинает общение с пакетной сетью гостевого оператора.
  3. У нас проверяют IMSI, ключ KSI (Key Set Identifier), доступные нам услуги.
Если попытаться упрощенно изобразить схему взаимодействия мобильного телефона в роуминге при использовании интернета, это будет выглядеть как на схеме.


В главных ролях — следующие компоненты.
  • GRX (Global Roaming Exchange) — сеть, созданная мобильными операторами для передачи пакетных данных абонентов в роуминге.
  • SGSN (Serving GPRS Support Node) — основное оборудование, которое обеспечивает функции передачи данных. Фактически это аналог коммутатора (MSC) в мобильной сети.
  • GGSN (GPRS Gateway Support Node) — маршрутизатор, который связывает мобильных абонентов с «внешним миром» и обеспечивает фактический доступ в интернет.
  • GTP (GPRS Tunneling Protocol) — протоколы туннелирования и управления пакетным трафиком в мобильной сети.
Понятно, что, когда мы находимся в роуминге, мы физически обслуживаемся оборудованием гостевого оператора. И настройки на оборудовании этого оператора могут (и, скорее всего, будут) отличаться от настроек домашнего оператора.
На самом деле вся эта схема сильно упрощена и нас интересует больше для понимания сути основных узлов. Более развернутая логическая схема выглядит слегка по-другому.


Как списываются деньги за использование интернет-трафика в роуминге? Здесь может быть два варианта развития событий.
  1. Списание идет напрямую (CAMEL-роуминг) через биллинговую систему домашнего оператора на основании данных с оборудования по записям из файлов оценки.
  2. Списание происходит на основании файлов оценки, полученных от роуминг-оператора вместе с другими записями (голос, SMS).
Во втором случае файлы оценки могут передаваться между операторами с существенной задержкой. В процессе обычно участвуют клиринговые центры сотовых операторов, которые принимают данные о своих пользователях роуминга и передают данные о гостях. Как правило, данные между операторами передаются все в одном потоке. Трафик интернета, SMS, голос — все идет вместе, иногда в одних файлах CDR.
Не буду подробно расписывать принцип работы сетей GRX. У них много своих уязвимостей, о которых в интернете уже немало написано. Если тебе интересно — поищи. Скажу только, что вся эта система построена и работает на основе стандартов, которые по большей части формирует консорциум 3GPP. И именно из-за стандартизации возникают проблемы и уязвимости. Сбить систему с толку может любое отклонение настроек от стандарта — причем настроек как оборудования, так и ПО.


Как такое могло произойти и кто виноват?
Возвращаемся к моей истории с неисчерпаемой китайской симкой. Скорее всего, если бы я не работал в компании, которая занимается обработкой мобильного трафика, я бы ничего и не заметил (и даже если бы заметил, не стал бы с этим возиться).
Когда я открыл настройки, мне бросилась в глаза строчка с названием точки доступа APN. Она выглядела так: « internet» — с пробелом в начале. Я решил свериться со стандартом допустимого значения APN и там увидел, что пробел запрещен.

Обрати внимание на выделение цветом
Все предельно понятно: в APN могут быть только буквы латинского алфавита (заглавные и строчные), цифры и дефис. И больше ничего быть не может.
Поскольку тот оператор, в роуминге которого оказалась симка, — это оператор, где я работаю, я смог пойти дальше в своем расследовании. Добравшись до записей оборудования SGSN, я посмотрел, как выглядит шестнадцатеричное представление этой записи. Значение APN было равно « 20696e7465726e6574». Это и есть слово internet, но пробел в начале никак не закодирован — это по-прежнему просто пробел.


Осталось проверить, что происходит в предбиллинге, когда туда приходит такая запись. Ничего удивительного, что она вызывает ошибку.
11:14:27.120 MSK main (TLVParser) DEBUG4: TLVParser.callback(): received node 78.7[5]
11:14:27.120 MSK main (TLVParser) DEBUG3: TLVParser.callback(): calling parselet[5] with node [78.7[5]] : [20696e7465726e6574]
11:14:27.120 MSK main (APNStringParselet) : APNStringParselet.parse()
11:14:27.121 MSK main (StreamSource) : StreamSource.byteRead()
11:14:27.122 main ERROR: Error in decoding an attribute APN Value = 20696E7465726E6574, Node TagPath = 78.7[5], Matching TagPath = 78.7[*], Bad length in the APN string at index 21 : 20696E7465726E6574.
В итоге эта запись в предбиллинге просто отбрасывается как ошибочная, и оператор спокойно забывает о ней. Оборудование SGSN и GGSN вроде бы должно отфильтровывать таких абонентов, но не обязано. В итоге клиентов с неправильно прописанным APN без проблем пускают в сеть и разрешают использовать передачу данных.
В стандарте нет четкого указания того уровня, на котором должно происходить их отсечение, и не прописано, как именно подменять ошибочное APN и на что именно. Отсюда и недопонимание того, как должно быть настроено оборудование.
В идеальном варианте, если бы оборудование было настроено согласно стандарту, гостевой абонент не смог бы пользоваться интернетом в гостевой сети. Но при установке оборудования очень часто ставятся настройки по умолчанию, которые допускают отклонения от стандарта. Так или иначе, ошибка возникала уже на стадии обработки этой записи в биллинге, еще до передачи ее домашнему оператору абонента (в нашем случае — в Китай).
Здесь встает спорный вопрос о том, пропускать ли записи в таком виде в клиринг, чтобы отдать домашнему оператору. Правильно ли будет изменить ее и привести к стандарту? Обычно в таких случаях домашний оператор «вкатывает» претензию гостевому оператору за то, что тот передает ему некорректные данные. Ведь в девяти случаях из десяти они вызовут у него такую же ошибку-исключение.
В реальной жизни все оказывается проще. Поскольку поток таких записей от абонентов-роумеров совсем небольшой, эти записи просто отметаются и никто не хочет возиться с этим вопросом. У сотрудников обычно хватает головных болей и без китайского роуминга.
В итоге домашний оператор ничего не получает и, соответственно, ничего не тарифицирует, а абонент прекрасно живет в роуминге и пользуется интернетом в сети гостевого оператора.


И это все?
На самом деле это не все. Такие исключения возникают часто и на разных типах трафика. Все решает объем этих записей. Если системы обнаружения потерь (FMS-RLC и так далее) не могут выцепить эти проблемы в потоке всего трафика, так как они попросту неощутимы, то эти финты «прощаются» абоненту и никто ничего не замечает.
В другом схожем случае мне однажды попались записи SMS, в которых номер абонента-получателя заканчивался какими-то иероглифами. Неведомым образом они таки доставлялись до адресата, а с отправителя ничего не списывалось. Вероятно, оборудование одинаково игнорировало лишние символы на обоих концах, а биллинг выдавал ошибку.
Я ни в коем случае не призываю тебя пытаться повторить мой опыт. Во-первых, дело было давно и описанная уязвимость уже исправлена. Во-вторых, при слегка другом сочетании обстоятельств метод не сработает. Согласись, будет особенно неприятно это обнаружить после того, как ты накрутишь в роуминге приличное количество трафика. Да и продолжительное или массовое использование, скорее всего, вынудит сотрудников оператора изменить настройки.
Мораль этой истории совсем другая. Мы посмотрели, насколько легко вызвать ошибку при обработке записей в предбиллинговой и биллинговой системе сотового оператора. Можно инициировать звонок, отправить SMS, MMS, USSD и передавать данные, которые не предусмотрены стандартом, но проходят через оборудование оператора. И чем длиннее цепочка (в нашем случае гостевой оператор → его предбиллинг → клиринг → домашний оператор), тем больше вероятность того, что записи будут помечены как ошибочные и затеряются в общем потоке.
 
Сверху Снизу