Для голосовой связи в IP-телефонии обычно используется протокол SIP. Трафик взаимодействия устройств по этому протоколу состоит из непосредственно трафика сигнализации SIP и трафика передачи голоса — RTP. Для корректной работы голосовой связи нам нужно обеспечить прохождение обоих видов этого трафика через НАТ. Продолжение статьи »

Преимущество использования IP PBX АТС заключается в том, что данная платформа обладает практически неограниченной возможностью дальнейшего расширения функционала с меньшими вложениями по сравнению с традиционными АТС типа Panasonic при одинаковой первоначальной стоимости устройств, а именно:

С помощью VoIP телефонии происходит объединение нескольких удаленных офисов в разных точках страны, области или города, что позволяет существенно уменьшить издержки на внутрикорпоративных звонках. Решение на базе ПО Asterisk реализует следующие возможности: единое номерное пространство (в т.ч. короткие внутренние номера), конференц-связь, получение факсимильных сообщений на e-mail, система записи и прослушивания разговоров, автодозвон, реализация callback, управление телефонами одного офиса из другого, оптимизация любых иных междугородних и международных звонков, система интерактивного голосового меню и многие другие.

Как известно, лучшим лечением является профилактика. Сегодня мы поговорим о профилактике взломов ip-атс и о том, как снизить тяжесть последствий инцидентов безопасности.

Защищайте периметр

Чаще всего взлом ip-атс происходит через сеть Интернет. Отсюда следует первое правило: если нет серьезной необходимости в обратном, закрывайте доступ к сервисам вашей АТС из сети Интернет .

Открытый веб-интерфейс является причиной взлома в 90% случаев. Закрывайте доступ к веб-интерфейсу в обязательном порядке.

Для совершения звонков через вашу АТС злоумышленникам требуется доступ по протоколу SIP. Если у вас нет необходимости подключаться к АТС из любой точки мира, закрывайте доступ по этому протоколу. Если такой доступ все же требуется (например, для объединения удаленных офисов или подключения сотрудников из дома), разрешайте доступ только через защищенные каналы связи VPN.

Взлом через консольный интерфейс SSH происходит крайне редко. В этой части хватает надежных паролей и средств защиты от их перебора, а так же переноса интерфейса на нестандартный порт.

Подстелите соломку

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

Операторов связи взламывают гораздо реже, чем их клиентов, да и ответственность за такой инцидент ложится на самого оператора. Если нет необходимости совершать международные звонки, ограничьте возможные направления звонков на уровне оператора связи. Если нужно, можно разрешить звонки только в ближнее зарубежье. Для этого достаточно обратиться с заявлением в абонентский отдел.

На этом все. Как видите, данные правила очень просты, однако уберегут вас от серьезных проблем в 99% случаев. Оставшийся 1% доверьте профессионалам! =)

В качестве офисной телефонии используется VoIP. В офисе был установлен один телефон. В один прекрасный день перестали приниматься входящие звонки. После звонка в службу поддержки было предложено подключиться к новому серверу. Входящие заработали, а вот исходящие через 30 секунд после разговора стали обрываться. Служба поддержки не смогла решить проблему. Сказали, что с их стороны все работает хорошо, возможно проблема с клиентским оборудованием. В качестве офисного телефона используется Linksys SPA921.

Принимаем решение внедрить между телефоном и провайдером Asterisk. Устанавливаем версию 1.6 из портов на FreeBSD. Настраиваем соединение с провайдером. При тестировании получаем тот же разрыв связи между Linksys и Asterisk. Только уже через 20 секунд исходящего разговора. Смотрим вывод в консоли и видим:

Maximum retries exceeded on transmission

Решение проблемы кроется в sip_answer(). Для решения этой проблемы, нужно пересобрать порт и перед установкой внеси правку в файле chan_sip.c. Находим строку

res = transmit_response_with_sdp(p, "200 OK", &p->initreq, 2, FALSE);

и меняем на

res = transmit_response_with_sdp(p, "200 OK", &p->initreq, 1, FALSE);

После этого разрывов связи не наблюдается.

UPD: в версии 1.6.2.15 описанная проблема не наблюдается.