Что такое SBC (Пограничный Контроллер Сессий) и зачем он нужен

Рынок пограничных контроллеров сессий с каждым годом набирает обороты, при этом для многих в области VoIP данное устройство остаётся неким вопросом – а зачем он нужен и где его правильно применять. Собственно, хотелось бы описать те функции и задачи, которые выполняет данное оборудование и почему установка данного устройства, если не обязательно, то уж точно крайне желательно на сети VoIP.
Пойдём от простого к сложному. Для начала определим те самые три функции, которые SBC выполняет на сети заказчика.

1. Безопасность
2. Совместимость
3. Обеспечение и контроль качества


В большинстве случаев для многих сразу возникает масса вопросов, так как, казалось бы, что есть Firewall, который отлично справляется с функцией безопасности и зачем сеть VoIP защищать дополнительно. Зачем обеспечивать совместимость, если есть стандарт RFC3261 и все работают согласно этому стандарту. А качество – есть мнение, что VoIP качество больше зависит от качества сети, а не от какого-то устройства. Теперь более подробно разберёмся, в чем собственно состоит обеспечение безопасности VoIP сети, и почему совместимости по RFC3261 (SIP v2) не достаточно, что именно обеспечивает, с точки зрения качества, Пограничный Контроллер Сессий.
1. Безопасность
Для начала, надо разобраться, а от чего мы хотим защитить и что может сделать злоумышленник? Самое первое и болезненное, что может сделать злоумышленник, это воровство траффика. Злоумышленник получает доступ к тому, чтобы от вашего лица была возможность звонить на оператора связи и далее делает достаточно дорогие вызовы куда-нибудь на солнечную Кубу через вашу систему. Чем это грозит, наверное, всем понятно – большой счет со стороны оператора связи.
Как происходит воровство и какие есть механизмы его предотвращения?
Как всегда, всё должно начинаться с самого примитивного. Причем, это примитивное обезопасит вас достаточно сильно. Злоумышленники в большинстве случаев начинают с того, что просто проверяют все IP адреса по ответу на порт SIP (UDP 5060). Например, посылая сообщение OPTIONS на данный порт последовательно на все IP адреса. Таким образом он просто ищет очередную жертву. Далее происходит следующее: как только они получают ответ, то сразу злоумышленник получает массу информации о вас. А именно – он знает, что у вас SIP доступен через Интернет и в 99% случаев он знает тип вашей IP-PBX. Как именно он это делает? Легко. Когда IP-PBX отвечает на SIP запрос, она дает ответ, где указано поле User-Agent с именем и версией устройства. Например: user-agent: Asterisk 1.2.3. Сразу хочу извиниться перед всеми любителями Asterisk, буду упоминать именно её, так как она является наиболее популярной для взлома системой. Что делает SBC в данном случае: по рекомендации он использует отличный от 5060 порт и легко подменяет значение поля User-Agent. Тут мы сразу ставим злоумышленника в более сложную ситуацию – во-первых, его система не всегда определяет, что вы используете SIP, так как в большинстве случаев вы на его запросы просто не отвечаете; во-вторых, даже получив ответ, он не будет знать, что у вас за станция и каким боком к ней подступиться. Почему второе так же является очень важным. А всё просто. Например: злоумышленник определил, что у вас Asterisk версии 1.2.3, на который был баг, который позволял позвонить на внутренний номер и далее с помощью DTMF набора установить переадресацию этого внутреннего номера. А далее он звонит на этот внутренний номер, где стоит переадресация на нужный ему номер. И в целом, чем больше функционал у АТС, тем больше есть различных способов воспользоваться этим функционалом в не тех целях, для которых предназначается данный функционал.
А если уж говорить о переадресации, то она является одним из самых тонких, с точки зрения безопасности в VoIP. Так как в большинстве случаев никто не думает, как и где передавать номер, кто совершал вызов, а он просто без вариантов подменяется на номер, кто переадресовал вызов. Это тоже важно и нужно проверять, что SBC так же делает. В данной статье не буду углубляться в тему переадресации номера.
Еще важный вопрос – это управление и доступ к управлению. SBC изначально имеет множество интерфейсов и возможности настройки VLAN, что позволяет интерфейс управления вынести в отдельную защищенную подсеть, что делает вопрос получения доступа к нему очень сложным.
С точки зрения безопасности, стоит уделить отдельное внимание маршрутизации вызовов и проверки SIP пакетов. Важно, чтобы любой пакет был максимально доверенным. Для этого SBC имеет достаточно много инструментов. Во-первых, это проверка по различным полям. Например, вы знаете, что от оператора всегда приходит сообщение, с полем User-Agent: ITSP_SIP и еще что-то добавляет. Либо при подключении к IP АТС телефона через Интернет требуется обязательно проверять, что регистрация проходит с того телефонного аппарата, который разрешен в вашей сети. Также, требуется максимально правильно определить маршруты, на которые можно звонить, с которых можно звонить. Это так же позволяет SBC обеспечить правильный уровень безопасности.
Еще очень важный момент, который обеспечивает SBC безопасность вашей IP-АТС, это разграничение VoIP трафика в вашей сети. Он позволяет выделить отдельную подсеть для вашей IP-АТС и сделать доступ к ней только с другого физического интерфейса, тем самым обеспечив доступ к вашей VoIP сети только через Пограничный Контроллер Сессий.
А далее, это набор стандартных вещей, типа регулярного Firewall, который так же находится на SBC.
Собственно, именно эти инструменты на SBC позволяют обеспечить вам безопасность от попытки взлома системы для воровства трафика или еще каких-то действий. Конечно, SBC имеет и другие методы и способы защиты, но тут я описал скорее самые популярные и важные действия для защиты вашей VoIP сети:
a. Есть еще DoS/DDoS атаки. С одной стороны, они более безобидны, так как, только лишь отключают сервис телефонии, но есть и другая сторона этой проблемы:
b. Тут надо четко понимать, если отключается IP-АТС, то у вас пропадает вся телефония, что само по себе не приятно и может влиять на бизнес-процесс.
c. Также не маловажным фактором является то, что чаще всего эти атаки делаются с целью подбора паролей пользователей с дальнейшими действиями этого пользователя. В том числе и воровства трафика.
SBC имеет встроенный Firewall, который работает по двум принципам – статический и динамический. Первый вариант понятен и описывать его, наверное, нет никакого смысла. Второй вариант работает следующим образом. Если вы допускаете возможность регистрации SIP абонентов из сети Интернет, то теоретически он может регистрироваться с любого источника и фильтровать статически просто невозможно. Например, если ваши сотрудники улетели куда-нибудь в Китай и хотят подключиться к вашей IP-АТС, вам будет необходимо открыть полный доступ, или как минимум для всех Китайских IP адресов. Единственный способ обезопасить вашу сеть IP телефонии – это динамические списки контроля доступа, когда SBC закрывает только те IP адреса на сетевом уровне, с которых идет аномальный трафик. Причем степень аномальности вы выставляете сами.
Есть еще вопрос подслушивания и единственный способ обойти это – шифрование. Но, так как в нашей стране службы безопасности относятся к этой теме очень скрупулезно, то эту тему я оставлю без внимания. Тем более, что в России шифрование никто не предоставляет всё по тем же причинам.

2. Совместимость
Второй вопрос, который встает перед SBC, это совместимость. Все рассказывают о том, что они поддерживают SIP v2 (он же RFC 3261) и всё будет работать и так. Но как показывает практика – это не сосем так, точнее совсем не так. Я бы сказал, что вопрос совместимости является самым сложным и комплексным в VoIP сети. Почему так? А для чего делаются IP АТС и системы унифицированных коммуникаций? Как бы все не рассказывали, что они стремятся к стандартизации, на самом деле приоритет главный в другом и он полностью противоречит самой идее сделать всё по стандарту. Задача производителей АТС – это предоставить максимально интересный и полный набор сервисов и если кто-то вдруг придумал новый сервис, то никакого варианта у них нет, кроме как сделать это по-своему. (Ну а потом сделать новый RFC и всем сказать – поддерживаете). Причем слив информации работает в нашем мире хорошо (но не отлично). И если конкурент прознал, что кто-то делает новую фичу, естественно он делает такую же, правда, по-своему и стандартизирует свою версию реализации данной функции и естественно, стандартизирует её. В итоге мир получает две отличные станции с одинаковой функцией, которые работают по-разному, при этом по стандарту, но между собой не совместимы. И если с базовым вызовом проблем уже ни у кого нет, то вот с расширениями SIP вопросов всегда предостаточно. Для статистики, на данный момент в мире более 100 расширений RFC для SIP. Станция обычно поддерживает не более 20, наш SBC поддерживает более 80. И если вам требуется, чтобы вы смогли использовать весь ваш функционал при работе с оператором связи, то SBC в этом случае просто необходим.
А еще на совместимость влияет та самая безопасность. И не ваша безопасность, а безопасность оператора связи. Как правило, оператор имеет свой собственный SBC и в большинстве случаев у него стоят четкие и понятные фильтры сообщений/полей/функций при работе с клиентом. Приведу два простых и понятных примера:
a. IP АТС использует SIP Refer для перевода вызова (это когда станция говорит вышестоящей станции, что Вы переводите вызов на внешнего абонента, и пускай дальше вызов соединяет между собой вышестоящая станция. Всё хорошо, но вот момент – а кому счет выставлять. Оператор в данном случае должен замкнуть вызов между двумя не его абонентами. Счет должен быть выставлен вам, да вот вызова с вами не было. По этой причине, оператор просто блокирует такой функционал (и правильно делает). SBC в данном случае забирает на себя вопрос коммутации вызова и отработки сообщения REFER и для оператора отображается два вызова (входящий и исходящий). И всё отлично работает.
b. Переадресация вызова. Например: Абонент А позвонил абоненту Б, у которого стоит переадресация на абонента В. И вот вызов идет от абонента Б на абонента В, при этом в качестве номера вызывающего отображается номер А. И это правильно, так как вызывающий номер – это номер А, а не тот который переадресует. Это телефонный стандарт. И если в ISDN (E1) всё это четко описано, так как есть поле Redirect number, то вот в SIP номер В для правильной идентификации может быть передан с использованием History-Info, Referred-By, Diversion. И исходя из этого, операторы просто любят блокировать такие номера, ссылаясь на то, что у них биллинг не правильно работает. То есть, биллинг оператора связи противоречит стандарту SIP или просто оператор не хочет принимать переадресованные вызовы, согласно стандарту. SBC позволяет всячески преобразовывать один формат в другой или просто переносить номер из любого поля в поле From и/или P-Asserted-Identity.
Остальные примеры не столь часто встречающиеся, при этом не менее важные, так как чем реже они встречаются, тем сложнее их решить стандартными методами телефонной станции. Отдельно хочется сказать про вопросы совместимости и адаптации голосовых кодеков. Прошло то время, когда все поддерживали кодеки G.711 и G.729 и этого достаточно. Тому массу причин, а главное производители АТС стремятся улучшить качество связи, используя собственные кодеки или специализированные кодеки, типа SILK/OPUS/MS-RTA. Тут причина проста (особенно если мы говорим про систему унифицированных коммуникаций) – сейчас все компании стремятся сделать телефонию не только на IP телефоне (который можно выделить в отдельный VLAN и дать трафику приоритет), но и сделать телефонию везде – на планшетах, лептопах, смартфонах, через WiFi, публичный Интернет. И тут далеко не всегда возможно приоритезировать трафик и обеспечить надлежащее качество в общем IP потоке, а адаптивные кодеки дают лучшее качество на таких сетях, относительно G.711/G.729.
Вот тут как раз SBC помогает использовать у вас в сети тот кодек, который требуется, а с оператором стыковаться с помощью того, который он поддерживает.
Отдельно стоит вопрос DTMF и факсов, которые в VoIP среде никто не отменял. Не хочу углубляться в эту тему, могу лишь сказать, что мы на данный момент поддерживаем все варианты передачи как DTMF, так и факсов.
На самом деле писать про совместимость можно достаточно долго и можно даже сделать отдельные статьи как решить ту или иную проблему с помощью нашего SBC. Но в любом случае, даже если ваш оператор говорит, что он добьётся полной совместимости с вами, не всегда оператор добивается этого и сроки настройки этой совместимости всегда большие. SBC позволит вам уменьшить риски и сократить расходы при подключении.

3. Обеспечение и контроль качества

Ну и в заключении, немного напишу об обеспечении и контроле качества:
a. Обеспечение качества – в первую очередь это работа с голосовыми кодеками.
b. Контроль качества – SBC отслеживает все вызовы по множеству параметров, таких как Эхо/задержка/потери пакетов/Jitter/MoS и когда у вас случается проблема, вы сразу четко и быстро понимаете с какой стороны и по какой причине произошло ухудшение связи, тем самым сократив сроки исправления проблем. Также SBC позволяет самостоятельно перестроить маршрут в случае, если с одним оператором качество связи падает. Это позволит сохранить качество вызова без внешнего вмешательства.
Также, не маловажным фактором с точки зрения обеспечения качества, является правильная настройка маршрутизации с возможностью балансировки и резервирования маршрутов. В том числе, если у вас есть резервный стык с сетью Интернет, то он должен включаться в том числе для VoIP, вне зависимости от настроек сетевого оборудования.

Не могу сказать, что это все функции и задачи, которые выполняет Пограничный Контроллер Сессий (SBC), тем более, что всё перечислить крайне сложно. Я бы даже сказал, что, с точки зрения безопасности, совместимости и качества универсальных рецептов просто нет и порой каждое подключение является уникальным и особенным. Наша задача тут предоставить максимальное количество возможностей, для того, чтобы ваше использование VoIP отвечало всем вашим бизнес требованиям к системе IP телефонии.

Автор: Victor_AC

Источник