Comments 28
К счастью уже сто лет в обед есть и всеми поддерживается secure sip, а связка SRTP+TLS снимает большинство проблем безопасности цифровой телефонии (кроме человеческого фактора).
Недавно как раз тоже исследовали безопасность железной АТС на базе астериска — в последних билдах уже практически никакие атаки на SIP не действуют, кроме спама инвайтами на конечные аппараты пользователей.
Недавно как раз тоже исследовали безопасность железной АТС на базе астериска — в последних билдах уже практически никакие атаки на SIP не действуют, кроме спама инвайтами на конечные аппараты пользователей.
Да какое там всеми? Провайдера, дающего городской номер с поддержкой SRTP+TLS очень поискать надо. Но чаще номер привязан к конкретному провайдеру и выбирать вообще не из чего.
Нынче поднять свою PBX на астериске не сложнее, чем винду переставить и подключить к ней то, что дает провайдер, но на вход выставив пресловутый secure sip.
А что делать если провайдер secure SIP не поддерживает? А он обычно не поддерживает.
Заводить в Asterisk обычный SIP от провайдера, а на участке Asterisk-Client использовать TLS+SRTP.
Asterisk-Client и так внутри LAN, там особо опасаться нечего. А трафик через внешнюю сеть между астериском и провайдером по прежнему будет нешифрованный.
Так в статье большинство проблем уровня LAN, а проблемы небезопасного обмена информацией в Интернет — это уже не уровень телефонных воров, это уже проблемы государственного масштаба (коррупция, слежка, низкая ответственность сотрудников телекоммуникационных компаний).
Построить с провайдером, например, ipsec туннель.
Когда поднимал свой SIP, то из популярных звонилок, кроме последней версии Bria, добиться поддержки SSL не удалось больше ни от кого.
совсем недавно стали жертвой СИП-телефонии.
У нас стоял голосовой шлюз для городских телефонов прямиком в Интернете с белым ip.
Провайдера просили фильтровать наши логины по нашему ip
Но в итоге в субботу ночью через провайдера телефонии попер огромный международный трафик.
Об этом узнали только в понедельник. Итог счет на 225+т.р. за международку.
Ожидаем судебную тажбу.
У нас стоял голосовой шлюз для городских телефонов прямиком в Интернете с белым ip.
Провайдера просили фильтровать наши логины по нашему ip
Но в итоге в субботу ночью через провайдера телефонии попер огромный международный трафик.
Об этом узнали только в понедельник. Итог счет на 225+т.р. за международку.
Ожидаем судебную тажбу.
Для исключения подобных атак единственный эффективный способ — заблокировать префикс 810.
будите смеяться, но я 810 заблокировал на самом шлюзе.
А по факту они звонили подключаясь напрямую к сип-прокси из Палестины.
А по факту они звонили подключаясь напрямую к сип-прокси из Палестины.
«Провайдера просили фильтровать наши логины по нашему ip» если на бумаге зафиксировано то это уже не ваши проблемы.
просил, но на бумаге не зафиксировал
Зря не зафиксировали. Провайдеру теперь ничего не докажешь. Вот похожий случай (http://ain.ua/2013/10/10/497317), чем там закончилась история неизвестно, но все шло к тому что виноват конечный пользователь, не обеспечивший безопасность своей АТС.
А хотя бы переписка в электронке сохранилась? Или это все было устно?
сохранилась, но толку… по договору айпи телефония вобще не фигурирует.
а на каком основании Вам тогда предоставляли услуги? о_О
Я, конечно, не специалист в гражданском праве, но имхо вам стоит посоветоваться с грамотным юристом на тему того, не получится ли съехать, зацепившись за эту переписку. Прецеденты, когда суд принимал письма из электронной почты как доказательство, уже бывали.
тут вопрос кто на кого в Суд подавать будет. Должны то мы РОСТЕЛЕКОМУ. А сами телефоны подключены от ООО «Местный провайдер». И каким образом мы долг в Суде против нас от РОСТЕЛЕКОМА на основании электронной почты скинем на ООО «Местный провайдер». По поводу долга есть на что списать, т.к. услуга оказана не нам, то и оплачивать мы ее не должны.
Если FXS шлюз — Linksys spa8000 — то трафик пролили через него, и звонки прошли с вашего адреса. Есть уязвимость у них.
Для spa8000 один вариант, убирать за nat.
Для spa8000 один вариант, убирать за nat.
Все подобные железки надо убирать за NAT. По-хорошему, в интернет должна смотреть только IP-PBX с жестким ограничением доступа по IP только для транков провайдеров, а вся внутренняя телефония, если сеть распределенная, должна ходить по VPN с запретом регистрации извне. Либо, если внешние клиенты необходимы, опять-таки по возможности делать ограничение по адресам или подсетям, и пользоваться fail2ban либо его аналогом.
Был у меня похожий случай — с год назад делал одну задачу по телефонии на астериске фирмочке из Украины, так они FXO шлюз D-Link DVG-7111 на белый адрес повесили. Мне-то что, предупредил о возможных последствиях — сказали, мол, временно. Когда сдавал работу, предупредил их еще раз, чтобы убрали шлюз во внутреннюю сеть от греха подальше. Ну а далее классика жанра — «временное» стало постоянным, шлюз взломали «кубинские телефонисты», назвонили бедолагам на пару-тройку килобаксов. А поскольку шлюз был воткнут в аналоговую телефонную линию, то отпереться им не было никакой возможности. В итоге они выгнали своего местного админа, который забил на рекомендации по безопасности.
Еще можно слушать rtp в ulaw&alaw кодеке WireShark, для g.729 есть Hammer.
>Ложные вызовы
Что за такой интересный провайдер на последней картинке, который дает возможность слать инвайты без какой-либо авторизации?
Что за такой интересный провайдер на последней картинке, который дает возможность слать инвайты без какой-либо авторизации?
Sign up to leave a comment.
Очерк безопасности SIP