Комментарии 6
Прочитал. Очень интересная статья, спасибо! Но очевидный вопрос - это безопасность. В описанном протоколе Autoprovision не применяется шифрование. По сути идентификация только по MAC-адресу телефона. Получается, что по DHCP опция 66 легко опознать присутствие Autoprovision, а если подделать "MAC-адрес" легко и ненапрягаясь можно получить конфигурацию аккаунта для любого телефона. Конечно, я надеюсь, регистрационные данные (пароль для SIP аккаунта) зашифрованы MD5, но современными техническими средствами MD5 легко вскрывается: https://habr.com/ru/articles/595013/ Как защитить персональные настройки от взлома?
В идеале ваша телефонная сеть и основная с компьютерами, как минимум разделена виланами, а максимум - это две разные физических сети, с своей сетевой обвязкой в виде роутера, dhcp и dns, а так же vpnом для ужаленных сотрудников к носимыми устр-ми
В своё время работал с провиженингом девайсов от разных производителей (ealink, правда, мало застал, в основном Cisco и Polycom), лучшая защита передаваемых данных - это использовать HTTPS, а не TFTP. Тогда можно использовать клиентские сертификаты устройств и двустороннюю TLS аутентификацию.
Многие, если не все, производители добавляют в прошивку клиентские сертификаты, содержащие Mac-адрес телефона. В этом случае можно отсекать нелигитимные запросы прямо на этапе хэндшейка (мак-адрес из сертификата, название запрашиваемого файла, intermediate сертификат производителя, которым подписан сертификат телефона), и заодно китайские подделки с клонированными чипами. Правда мы это делали в промышленном масштабе, 5+20 - это мало, у нас были пяти-шестизначные цифры, но, тем не менее, приципиально это ничего не меняет. Просто валидация CA на сервере, без всего остального, сильно усложняет запросы от всего, что не телефон, причем быстро.
TFTP в пределах одной организации вполне себе может быть, если SIP-шлюз тоже внутри. Не все хотят заморачиваться с безопасностью в локальной сети в малых организациях. Любой выход наружу - HTTPS, плюс защитные меры выше, плюс еще кучу проверок можно добавить если запрос каким-то чудом проскочил mutual authentication, можно валидировать вообще всё, что приходит в запросе, до отдачи конфига (заголовки HTTP-запроса, например, размер запроса, и так далее). Ломать SSL/TLS - так себе занятие. Дорого, скучно, проще другого провайдера найти, с защитой попроще. Ломать SSL/TLS + проверки провиженинг-сервера - это надо быть очень целеустремлённым.
Сами телефоны обычно пароль не отображают, в открытом виде или в виде хэша, в гуе, и многие при скачивании конфигов его в эти конфиги не пишут. Передача - внутри HTTPS, что уменьшает шансы перехвата, оставляя, в общем, только MITM с кучей дополнительных телодвижений, что, опять же, и долго, и недёшево, и явно того не стоит.
В общем, хотите безопасности - используйте провиженинг-сервер и HTTPS, а не DHCP+TFTP.
Коллеги, резюмируя и подытоживая все вышесказанное:
Если пароли извлекли из конф. файла, который не выходит за пределы локальной сети, то это проблема некорректной архитектуры сети или наличия в ней уязвимостей, но никак не схемы провижининга.
Если схема провижининга не предполагает внешнего размещения сервера с конф. файлами или телефонов, в шифровании конфигов при обеспечении безопасности самой сети принципиальной необходимости нет, в противном случае:
• Общая рекомендация: использовать https для обеспечения безопасной передачи конф. файлов.
• Для обеспечения дополнительной безопасности можно шифровать конф. файлы методом AES через специальную утилиту (что может вызвать дополнительные затраты времени из-за необходимости загрузки ключей в телефонные аппараты).
Только наткнулся на статью, но из недавнего опыта возни с елинками есть что добавить
Возможно кому то пригодится
Если телефония разворачиваете не с нуля, а происходит переход на елинки с другого вендора, в одной подсети будут находиться устройства разных вендоров. Для разных вендоров используются разные источники провижининга. В таком случае будет полезно уметь выдавать 43-ю опцию не безусловно, а на основании параметра vendor-class-identificator (Option 60)
для isc-dhcp работает следующий конфиг
### YELINK ###
option space YeLink;
option YeLink.swserver code 02=text;
class "yealink" {
match if option vendor-class-identifier="yealink";
vendor-option-space YeLink;
option YeLink.swserver "http://10.x.y.z:8453";
}
Автопровижининг телефонов Yealink. Часть 3