- Автор темы
- #1
Год назад мы публиковали материал о том, как устроен предбиллинг — системы учета услуг мобильных операторов. В этот раз я хочу поделиться с тобой случаем из жизни, который демонстрирует слабую сторону таких систем и их потенциальную (а в моем случае — и вполне реальную) уязвимость.
Как ты знаешь, никакой код не безупречен. Все программы создаются людьми, и никто из них не может предугадать все возможные последствия работы в разных ситуациях. Иногда, особенно в сложных системах, это открывает совершенно неожиданные возможности. Это история именно такого случая.
Как-то раз (а точнее, в 2014 году) я был в Китае и пользовался телефоном в роуминге. А для доступа в интернет купил местную SIM-карту. Приехав домой в Россию, я забыл вытащить эту симку из планшета и продолжал ей пользоваться. Пока на ней были деньги, она прекрасно работала на чужбине, даже несмотря на то, что APN (Access Point Name) на ней было прописано китайского оператора. И это совершенно нормально: приезжая в роуминг, гостевой абонент не обязан постоянно переписывать APN вручную.
Прошел месяц, планшет с китайской симкой прекрасно продолжал работать в России. Мне стало интересно, что же такое происходит и почему баланс практически не меняется, да еще и в роуминге! Еще один волнующий вопрос — можно ли воспроизвести эту ситуацию. Благо у меня были все необходимые условия для поиска ответов.
В итоге эта запись в предбиллинге просто отбрасывается как ошибочная, и оператор спокойно забывает о ней. Оборудование SGSN и GGSN вроде бы должно отфильтровывать таких абонентов, но не обязано. В итоге клиентов с неправильно прописанным APN без проблем пускают в сеть и разрешают использовать передачу данных.
В стандарте нет четкого указания того уровня, на котором должно происходить их отсечение, и не прописано, как именно подменять ошибочное APN и на что именно. Отсюда и недопонимание того, как должно быть настроено оборудование.
В идеальном варианте, если бы оборудование было настроено согласно стандарту, гостевой абонент не смог бы пользоваться интернетом в гостевой сети. Но при установке оборудования очень часто ставятся настройки по умолчанию, которые допускают отклонения от стандарта. Так или иначе, ошибка возникала уже на стадии обработки этой записи в биллинге, еще до передачи ее домашнему оператору абонента (в нашем случае — в Китай).
Здесь встает спорный вопрос о том, пропускать ли записи в таком виде в клиринг, чтобы отдать домашнему оператору. Правильно ли будет изменить ее и привести к стандарту? Обычно в таких случаях домашний оператор «вкатывает» претензию гостевому оператору за то, что тот передает ему некорректные данные. Ведь в девяти случаях из десяти они вызовут у него такую же ошибку-исключение.
В реальной жизни все оказывается проще. Поскольку поток таких записей от абонентов-роумеров совсем небольшой, эти записи просто отметаются и никто не хочет возиться с этим вопросом. У сотрудников обычно хватает головных болей и без китайского роуминга.
В итоге домашний оператор ничего не получает и, соответственно, ничего не тарифицирует, а абонент прекрасно живет в роуминге и пользуется интернетом в сети гостевого оператора.
И это все?
На самом деле это не все. Такие исключения возникают часто и на разных типах трафика. Все решает объем этих записей. Если системы обнаружения потерь (FMS-RLC и так далее) не могут выцепить эти проблемы в потоке всего трафика, так как они попросту неощутимы, то эти финты «прощаются» абоненту и никто ничего не замечает.
В другом схожем случае мне однажды попались записи SMS, в которых номер абонента-получателя заканчивался какими-то иероглифами. Неведомым образом они таки доставлялись до адресата, а с отправителя ничего не списывалось. Вероятно, оборудование одинаково игнорировало лишние символы на обоих концах, а биллинг выдавал ошибку.
Я ни в коем случае не призываю тебя пытаться повторить мой опыт. Во-первых, дело было давно и описанная уязвимость уже исправлена. Во-вторых, при слегка другом сочетании обстоятельств метод не сработает. Согласись, будет особенно неприятно это обнаружить после того, как ты накрутишь в роуминге приличное количество трафика. Да и продолжительное или массовое использование, скорее всего, вынудит сотрудников оператора изменить настройки.
Мораль этой истории совсем другая. Мы посмотрели, насколько легко вызвать ошибку при обработке записей в предбиллинговой и биллинговой системе сотового оператора. Можно инициировать звонок, отправить SMS, MMS, USSD и передавать данные, которые не предусмотрены стандартом, но проходят через оборудование оператора. И чем длиннее цепочка (в нашем случае гостевой оператор → его предбиллинг → клиринг → домашний оператор), тем больше вероятность того, что записи будут помечены как ошибочные и затеряются в общем потоке.
Как ты знаешь, никакой код не безупречен. Все программы создаются людьми, и никто из них не может предугадать все возможные последствия работы в разных ситуациях. Иногда, особенно в сложных системах, это открывает совершенно неожиданные возможности. Это история именно такого случая.
Как-то раз (а точнее, в 2014 году) я был в Китае и пользовался телефоном в роуминге. А для доступа в интернет купил местную SIM-карту. Приехав домой в Россию, я забыл вытащить эту симку из планшета и продолжал ей пользоваться. Пока на ней были деньги, она прекрасно работала на чужбине, даже несмотря на то, что APN (Access Point Name) на ней было прописано китайского оператора. И это совершенно нормально: приезжая в роуминг, гостевой абонент не обязан постоянно переписывать APN вручную.
Прошел месяц, планшет с китайской симкой прекрасно продолжал работать в России. Мне стало интересно, что же такое происходит и почему баланс практически не меняется, да еще и в роуминге! Еще один волнующий вопрос — можно ли воспроизвести эту ситуацию. Благо у меня были все необходимые условия для поиска ответов.
В итоге эта запись в предбиллинге просто отбрасывается как ошибочная, и оператор спокойно забывает о ней. Оборудование SGSN и GGSN вроде бы должно отфильтровывать таких абонентов, но не обязано. В итоге клиентов с неправильно прописанным APN без проблем пускают в сеть и разрешают использовать передачу данных.
В стандарте нет четкого указания того уровня, на котором должно происходить их отсечение, и не прописано, как именно подменять ошибочное APN и на что именно. Отсюда и недопонимание того, как должно быть настроено оборудование.
В идеальном варианте, если бы оборудование было настроено согласно стандарту, гостевой абонент не смог бы пользоваться интернетом в гостевой сети. Но при установке оборудования очень часто ставятся настройки по умолчанию, которые допускают отклонения от стандарта. Так или иначе, ошибка возникала уже на стадии обработки этой записи в биллинге, еще до передачи ее домашнему оператору абонента (в нашем случае — в Китай).
Здесь встает спорный вопрос о том, пропускать ли записи в таком виде в клиринг, чтобы отдать домашнему оператору. Правильно ли будет изменить ее и привести к стандарту? Обычно в таких случаях домашний оператор «вкатывает» претензию гостевому оператору за то, что тот передает ему некорректные данные. Ведь в девяти случаях из десяти они вызовут у него такую же ошибку-исключение.
В реальной жизни все оказывается проще. Поскольку поток таких записей от абонентов-роумеров совсем небольшой, эти записи просто отметаются и никто не хочет возиться с этим вопросом. У сотрудников обычно хватает головных болей и без китайского роуминга.
В итоге домашний оператор ничего не получает и, соответственно, ничего не тарифицирует, а абонент прекрасно живет в роуминге и пользуется интернетом в сети гостевого оператора.
И это все?
На самом деле это не все. Такие исключения возникают часто и на разных типах трафика. Все решает объем этих записей. Если системы обнаружения потерь (FMS-RLC и так далее) не могут выцепить эти проблемы в потоке всего трафика, так как они попросту неощутимы, то эти финты «прощаются» абоненту и никто ничего не замечает.
В другом схожем случае мне однажды попались записи SMS, в которых номер абонента-получателя заканчивался какими-то иероглифами. Неведомым образом они таки доставлялись до адресата, а с отправителя ничего не списывалось. Вероятно, оборудование одинаково игнорировало лишние символы на обоих концах, а биллинг выдавал ошибку.
Я ни в коем случае не призываю тебя пытаться повторить мой опыт. Во-первых, дело было давно и описанная уязвимость уже исправлена. Во-вторых, при слегка другом сочетании обстоятельств метод не сработает. Согласись, будет особенно неприятно это обнаружить после того, как ты накрутишь в роуминге приличное количество трафика. Да и продолжительное или массовое использование, скорее всего, вынудит сотрудников оператора изменить настройки.
Мораль этой истории совсем другая. Мы посмотрели, насколько легко вызвать ошибку при обработке записей в предбиллинговой и биллинговой системе сотового оператора. Можно инициировать звонок, отправить SMS, MMS, USSD и передавать данные, которые не предусмотрены стандартом, но проходят через оборудование оператора. И чем длиннее цепочка (в нашем случае гостевой оператор → его предбиллинг → клиринг → домашний оператор), тем больше вероятность того, что записи будут помечены как ошибочные и затеряются в общем потоке.