Открыть список
Как стать автором
Обновить

Комментарии 28

К счастью уже сто лет в обед есть и всеми поддерживается secure sip, а связка SRTP+TLS снимает большинство проблем безопасности цифровой телефонии (кроме человеческого фактора).

Недавно как раз тоже исследовали безопасность железной АТС на базе астериска — в последних билдах уже практически никакие атаки на SIP не действуют, кроме спама инвайтами на конечные аппараты пользователей.
Да какое там всеми? Провайдера, дающего городской номер с поддержкой SRTP+TLS очень поискать надо. Но чаще номер привязан к конкретному провайдеру и выбирать вообще не из чего.
Нынче поднять свою PBX на астериске не сложнее, чем винду переставить и подключить к ней то, что дает провайдер, но на вход выставив пресловутый secure sip.
А что делать если провайдер secure SIP не поддерживает? А он обычно не поддерживает.
Заводить в Asterisk обычный SIP от провайдера, а на участке Asterisk-Client использовать TLS+SRTP.
Asterisk-Client и так внутри LAN, там особо опасаться нечего. А трафик через внешнюю сеть между астериском и провайдером по прежнему будет нешифрованный.
Так в статье большинство проблем уровня LAN, а проблемы небезопасного обмена информацией в Интернет — это уже не уровень телефонных воров, это уже проблемы государственного масштаба (коррупция, слежка, низкая ответственность сотрудников телекоммуникационных компаний).
Вот прослушка со стороны органов (и конкурентов) обычно куда опаснее чем прослушка внутри собственного LAN.
Тогда рецепт простой — удаленный максимально далеко Asterisk анонимно подключенный к SIP-провайдеру и линки SRTP+TLS до него от клиентов. Задача только в качественной реализации, доверии к исполнителю и соблюдении всех мер предосторожности.
Построить с провайдером, например, ipsec туннель.
Когда поднимал свой SIP, то из популярных звонилок, кроме последней версии Bria, добиться поддержки SSL не удалось больше ни от кого.
совсем недавно стали жертвой СИП-телефонии.
У нас стоял голосовой шлюз для городских телефонов прямиком в Интернете с белым ip.
Провайдера просили фильтровать наши логины по нашему ip
Но в итоге в субботу ночью через провайдера телефонии попер огромный международный трафик.
Об этом узнали только в понедельник. Итог счет на 225+т.р. за международку.
Ожидаем судебную тажбу.
Для исключения подобных атак единственный эффективный способ — заблокировать префикс 810.
будите смеяться, но я 810 заблокировал на самом шлюзе.
А по факту они звонили подключаясь напрямую к сип-прокси из Палестины.
«Провайдера просили фильтровать наши логины по нашему ip» если на бумаге зафиксировано то это уже не ваши проблемы.
просил, но на бумаге не зафиксировал
Зря не зафиксировали. Провайдеру теперь ничего не докажешь. Вот похожий случай (http://ain.ua/2013/10/10/497317), чем там закончилась история неизвестно, но все шло к тому что виноват конечный пользователь, не обеспечивший безопасность своей АТС.
А хотя бы переписка в электронке сохранилась? Или это все было устно?
сохранилась, но толку… по договору айпи телефония вобще не фигурирует.
а на каком основании Вам тогда предоставляли услуги? о_О
на основании договора местной телефонной связи.

Не могу всем ответить, т.к. лимит на 1 комментарий в час.
Я, конечно, не специалист в гражданском праве, но имхо вам стоит посоветоваться с грамотным юристом на тему того, не получится ли съехать, зацепившись за эту переписку. Прецеденты, когда суд принимал письма из электронной почты как доказательство, уже бывали.
тут вопрос кто на кого в Суд подавать будет. Должны то мы РОСТЕЛЕКОМУ. А сами телефоны подключены от ООО «Местный провайдер». И каким образом мы долг в Суде против нас от РОСТЕЛЕКОМА на основании электронной почты скинем на ООО «Местный провайдер». По поводу долга есть на что списать, т.к. услуга оказана не нам, то и оплачивать мы ее не должны.
Если FXS шлюз — Linksys spa8000 — то трафик пролили через него, и звонки прошли с вашего адреса. Есть уязвимость у них.
Для spa8000 один вариант, убирать за nat.
Все подобные железки надо убирать за NAT. По-хорошему, в интернет должна смотреть только IP-PBX с жестким ограничением доступа по IP только для транков провайдеров, а вся внутренняя телефония, если сеть распределенная, должна ходить по VPN с запретом регистрации извне. Либо, если внешние клиенты необходимы, опять-таки по возможности делать ограничение по адресам или подсетям, и пользоваться fail2ban либо его аналогом.
Был у меня похожий случай — с год назад делал одну задачу по телефонии на астериске фирмочке из Украины, так они FXO шлюз D-Link DVG-7111 на белый адрес повесили. Мне-то что, предупредил о возможных последствиях — сказали, мол, временно. Когда сдавал работу, предупредил их еще раз, чтобы убрали шлюз во внутреннюю сеть от греха подальше. Ну а далее классика жанра — «временное» стало постоянным, шлюз взломали «кубинские телефонисты», назвонили бедолагам на пару-тройку килобаксов. А поскольку шлюз был воткнут в аналоговую телефонную линию, то отпереться им не было никакой возможности. В итоге они выгнали своего местного админа, который забил на рекомендации по безопасности.
Еще можно слушать rtp в ulaw&alaw кодеке WireShark, для g.729 есть Hammer.
>Ложные вызовы
Что за такой интересный провайдер на последней картинке, который дает возможность слать инвайты без какой-либо авторизации?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2002
Местоположение
Россия
Сайт
www.ptsecurity.com
Численность
501–1 000 человек
Дата регистрации

Блог на Хабре