В среднем по статистике, в начале каждого месяца у 1-2 клиентов среднего оператора возникает ситуация. К ним приходит понимание — попали на деньги. Почему вначале месяца? В это время операторы печатают и отправляют счета клиентам за прошедший месяц.
Безопасность Asterisk обсуждается всеми, кто знает правильное написание этого слова. Хочется еще раз поднять вопрос безопасности в VoIP сетях, на этот раз со стороны работника SIP оператора, возможно, это близко к истине.
Мнение масс — Asterisk(далее *) ломается, очень часто, очень легко, очень *нужное вставить*. На деле ломается все. * чаще всего попадает в этот список потому что это open source, его устанавливают компании(в большинстве), которым не хватает денег на CUCM, с двумя CUBE и ASA в резерве. Дело не в его возможной “ущербности”, как открытого и бесплатного продукта, просто обычно он настроен не до конца, как и его окружение. И настраивают * администраторы и эникей, и делая это, они впервые знакомятся с VoIP.
Говорят делай — надо делать. Перво наперво, если Вам дали задание настроить * или внедрить IP телефонию в компании, нужно отбрехаться от всех дальнейших возможных моральных и финансовых проблем — “не несу ответственность, за подписью директора”, и только после этого настраивать.
Периодически на Хабре и в интернете встречаю такие статьи, в них пишут в основном нужные и полезные вещи. Специально не гуглил, но на глаза не попадались статьи, где бы затронули такую штуку, как endpoint. Возможно где-то есть упоминания о безопасности шлюзов.
Расписывать одно и тоже не буду, многому уделено достаточное внимание, со своей стороны выделю, на мой взгляд, кое где незатронутые моменты. Не делайте чужую работу, а если взялись за нее, то следующим пунктам уделите побольше внимания.
Объединим знания
Устанавливаем, допиливаем, настраиваем, защищаем, инспектируем, инспектируем #2, тестируем.
К вышеупомянутым статьям хочется добавить немного отсебятины.
Если от * требуется только SIP то, очевидно, остальные chan_* не нужны.
В файл modules.conf добавляем все, чем не будем пользоваться:
noload => chan_jingle.so
noload => chan_skinny.so
noload => chan_iax2.so
noload => chan_console.so
noload => chan_mgcp.so
noload => chan_gtalk.so
Удаляем дефолтные conf файлы:
rm /etc/asterisk/extensions.conf
rm /etc/asterisk/sip.conf
И по инструкциям выше пишем свои.
Дополнительно к sip.conf:
[general]
useragent=Linksys/SPA8000-5.1.10 #в SIP пакетах будем определяться как Linksys SPA8000 такой то версии
sdpsession=Linksys SPA8000-5.1.10 #в SDP есть поле, в котором так же пишется имя агента, его тоже меняем, тогда и не только боты запутаются
И дефолтный контекст в extensions.conf:
[default] #всем кто свалился в default контекст при вызове куда-либо делаем отбой
exten => _X.,1,Hangup
Чуть что, сразу “Косой!”
Сегодня * не герой дня. Подхожу к основной мысли этой статьи. Как многие могли заметить, администраторы в первую очередь хотят обезопасить * и это получается, если следуют рекомендациям. Но кто из Вас думает: а вдруг, слабым местом выступает endpoint?
Endpoint — это IP телефон, VoIP шлюз, к которому подключен факс, softphone, запущенный на компьютере менеджера, и другие точки попадания в VoIP сеть, установленные у конечного пользователя.
Побеспокойтесь о защите окружения, и не забывайте про это. На примерах объясню о чем речь.
Для удобства менеджмента и удаленного администрирования, часто, IP телефоны вывешивают наружу. В процессе работы для предупреждения возникновения возможных инцидентов сканировал адреса клиентов компании(оператора). Получались такие ссылки:
внешний_адрес:8101
внешний_адрес:8102
внешний_адрес:8103
В данном случае 101,102,103 — добавочный номер, заведенный на телефон(админу же удобней). Пройдя по ссылке попадаем в web-интерфейс телефона, далее все зависит от вендора. Если это Cisco — админу повезло; Linksys — админу тоже повезло, скорее всего счет за МН не придет. Лучше не проверять что будет, если человек со злым умыслом получит хотя бы web доступ к телефонам Polycom.
Существуют и другие производители, за примерами далеко ходить не нужно. Китай славится техникой, хорошей, кстати, техникой. Выпускают они и noname IP Phone, чаще всего можно встретить под названием Fanvil BW210 — звонит, форвардит, время показывает, дешевый и не глючит. У него есть несколько собратьев, отличаются названием, а в остальном даже коробка и web-интерфейс одинаковые. Выделяет его одна особенность, если память мне не изменяет, зайдя на него вот так:
ip_phone/config.txt — получим конфиг и все реквизиты открытым текстом.
VoIP шлюзы, к сожалению, еще чаще показывают всемирной паутине. Обычно шлюз выступает в качестве “смесителя” технологий, но он так же может выступать как ip2ip. С телефона можно стащить данные, а через шлюз пролить трафик.
Для того кто ищет, подбор пароля займет не так много времени, как хотелось бы. Поэтому строго ограничивайте и разрешайте доступ только со “своих” адресов. К сигнализации это так же относится. На шлюз возможны три типа воздействия:
- Подбор пароля и дальнейший доступ к админке.
- В случае, если на шлюзе есть sip аккаунты и проверки адреса нет, либо он не до конца настроен — подбираем реквизиты и льем трафик.
- Спам мусорным трафиком. 100% загрузка процессора, нормальные запросы не обрабатываются — полезному трафику отказ в сервисе.
Итоги
- Все endpoint должны сидеть внутри локальной сети, и доступ из внешнего мира к ним должен быть только через VPN.
- На любом IP телефоне или шлюзе есть возможность настроить syslog сервер — не пренебрегайте этим. Собирайте весь трафик и храните хотя бы месяц.
- Копию CDR * синхронизируйте на другой сервер.
- Конечным пользователям ограничивайте доступ к телефонам, компьютеры и телефоны не должны находиться в одной локалке.
- Закрывайте не нужные для компании МН направления, желательно бумажным письмом за подписью и печатью.
- Следите за транком Вашей версии *, не пропускайте свежие патчи и обновляйте PBX, в них закрывают уязвимости.
- Обновляйте прошивки телефонов и шлюзов, в них так же закрывают уязвимости.
- Стройте хорошие отношения с оператором. Как правило чем меньше провайдер, тем он больше ценит клиента, и старается предоставить лучший сервис, и будет делать как можно больше, чтобы удержать Вас.
P.S. Пара случаев из практики
1. Жил был админ — следил за компьютерами, сетью и “офисной АТС”. Настроил сам по мануалам. Но что-то не заладилось у него, посыпались ночные МН вызовы. Честный провайдер, заботящийся о благополучии своего клиента, первый раз такие вызовы отследит и заблокирует, перезвонит утром клиенту, откланяется и спросит: “не доставил ли неудобство, заблокировав ночной трафик в Папуа-Новая Гвинея”.
Доказывали клиенту несколько дней, что звонки его, прежде чем он понял и решил что-то с этим делать. Ради интереса решил зайти на его внешний_адрес:80, увидел там Trixbox, в интернете нашел default login/password администратора, ввел их и они подошли. Админ был настырный, винил нас, ругался и говорил, что у него все ОК! Клиент возмущался и требовал объяснений. Пришлось сделать несколько скриншотов внутреннего интерфейса Trixbox’а с детальным описанием ситуации, после чего контакт клиента по техническим вопросам сменился.
2. Оператор клиенту предоставляет услугу под названием “Виртуальная АТС”, “IP Centrex” и прочее. Услуга подразумевает VoIP трафик во внешних сетях, т.е оператор не привязывает регистрацию extension клиента к его IP адресу.
Админ клиента в биллинге увидел “левые” звонки и обратился за помощью. Сменили пароли к учеткам, перебили на телефонах. На следующий день ситуация повторилась. Просканировал адреса клиента, в открытом доступе висело порядка 50 телефонов(Polycom). Этого администратора не уволили.
Берегите себя и свою репутацию надежного специалиста!
Автор: caiser
