Безопасность SIP - Зайцев Я - Флудилка
^ В верх

Зайцев.Я

Все самое интересное в разделе "Флудилка"


Войти
x
x

Кто на сайте

Флудилка

Обсуждение Joomla , Virtuemart 2 , Cisco IOS , Asterisk , PHP

  • Категории
    Категории Страница отображения списка категорий системы блогов сайта.
Добавлено : Дата: в разделе: АТС Asterisk

Безопасность SIP

Члены рабочей группы IETF SIP Working Group разработали исчерпывающий набор базисных элементов защиты, предотвращающих прослушивание, перехват сессий и активные атаки SIP-систем, а также позволяющих убедиться в подлинности собеседника. Оставшаяся часть статьи посвящена рассмотрению этих элементов.

Аутентификация

Аутентификация в SIP принимает две формы. Первая – это аутентификация прокси-сервером, сервером переадресации или сервером регистрации пользовательского агента. Вторая – это аутентификация одним пользовательским агентом другого.

Аутентификация пользовательского агента прокси-сервером нужна для проверки законности доступа к определённой услуге или функции. К примеру, прокси-сервер может потребовать аутентификацию перед пересылкой полученного INVITE адресату или предоставлением любой другой услуги. Сервер регистрации может потребовать аутентификацию для предотвращения регистрации не легитимного клиента и перехвата им входящих вызовов. Взаимная аутентификация пользовательских агентов имеет смысл для проверки того, что каждый из них на самом деле тот, за кого он себя выдаёт, ведь заголовок From (содержимое которого отображается пользовательскими агентами в качестве номера и имени вызывающего абонента) может быть сфальсифицирован.

В SIP предусмотрено две схемы аутентификации: дайджест-аутентификация в стиле HTTP (RFC 2617), и аутентификация с использованием сертификатов (для SIP поверх TLS).

Дайджест-аутентификация

При использовании дайджест-аутентификации в стиле HTTP прокси-сервер отвечает на INVITE ответом 407 Proxy Authorization Required, в котором присутствует поле заголовка Proxy-Authenticate, с данными для вычисления отклика аутентификации. После отправки сообщения ACK на 407 Proxy Authorization Required пользовательский агент может переслать INVITE, но на этот раз – с заголовком Proxy-Authorization, содержащим удостоверение пользователя (см. рис. 1).

1sip1

Рисунок 1. Дайджест-аутентификация

Рассмотрим выполнение дайджест-аутентификации на примере. На рис. 1 показано содержимое начального INVITE, ответа 407 Proxy Authorization Required и INVITE с удостоверением пользователя. Нужно отметить, что пользовательские агенты, серверы регистрации и переадресации вместо 407 Proxy Authorization Required используют ответ 401 Unauthorized, а заголовок с данными для вычисления отклика аутентификации в нём называется просто Authenticate. В ответ на него UA должен прислать INVITE с заголовком Authorization.

Дайджест сообщения – это уникальная символьная строка фиксированного размера, она является результатом обработки данных (зашифрованных имени пользователя и пароля) с помощью односторонней хэш-функции MD5. Сервер SIP сравнивает данные заголовка Authorization с результатом применения той же хэш-функции к данным, хранящимся в базе.

Заголовок Authentication-Info позволяет пользовательскому агенту аутентифицировать прокси-сервер, используя тот же механизм дайджест-аутентификации. К сожалению, схема дайджест-аутентификации не обеспечивает аутентификацию тела сообщения и механизм проверки целостности сообщения – для этого следует использовать TLS или S/MIME. Возможно, в будущем дайджест-аутентификацию в SIP заменит более безопасный стандарт EAP-AKA (RFC 4178) базирующийся на протоколе EAP (Extensible Authentication Protocol, RFC 3478) и AKA (Authentication and Key Agreement, наработка мобильных сетей третьего поколения UMTS и CDMA2000).

Transport Layer Security (TLS)

Как и в случае с HTTP, передача SIP-данных может осуществляться с помощью протокола защищённого канала Transport Layer Security (TLS). SIP over TLS обеспечивает конфиденциальность и целостность информации в канале, осуществляет аутентификацию прокси-серверов с использованием сертификатов (которыми, согласно RFC 3261, должны обладать прокси-серверы, серверы регистрации и серверы переадресации). В рамках модели SIP over TLS безопасность достигается на каждом участке по пути следования сигнальных сообщений (см. рис. 2).

1sip2

Рисунок 2. TLS

На пути от пользовательского агента до прокси-сервера применяется TLS, а сигнализация между серверами может быть защищена с помощью TLS или IPSec (который считается опциональным, но более стойким). После успешной аутентификации прокси-серверы SIP дешифруют каждое сообщение (на каждом участке пути применяется отдельный ключ), что даёт им возможность «видеть» все заголовки и корректно выполнять маршрутизацию сообщений. Однако конечные абоненты должны безоговорочно «доверять» прокси-серверам.

Среди слабых мест протокола TLS традиционно упоминают подверженность атакам «человек посередине» (Man-in-the-Middle). Есть и специфические для SIP проблемы: хотя TLS-соединение служит свидетельством аутентичности обеих сторон, этого мало для того, чтобы быть уверенным в аутентичности (или обеспечить невозможность отречения) от произвольного SIP-сообщения, передаваемого по этому каналу.

TLS способен обеспечить эти цели в рамках протокола HTTPS, где появление иконки с изображением замка в браузере автоматически означает наличие безопасного канала между браузером и веб-сервером. SIP же гораздо более сложен. Представьте, например, TLS-соединение между двумя прокси-серверами: через него может передаваться трафик, принадлежащий разным транзакциям или диалогам. Следовательно, злоумышленник из одного домена может провести атаку с инжекцией трафика в другой домен, и это не будет обнаружено или предотвращено TLS-соединением. Корень проблемы в том, что конечные точки TLS-соединения не «знакомы» со структурой передаваемых через них сообщений протокола SIP настолько, чтобы применить достаточно жесткую политику безопасности.

Наконец, формирование доверительных отношений в рамках TLS и даже установка TCP-соединений может стать настоящей проблемой для сервис-провайдера, обслуживающего уже несколько сотен тысяч абонентских устройств. Не нужно обладать богатой фантазией, чтобы представить, на что будет похож поток SYN-пакетов во время формирования TLS-соединений.

Интересующиеся перспективными разработками могут обратиться к RFC 4347, описывающему протокол DTLS, работающий поверх UDP. А текущая версия протокола TLS описана в RFC 4346.

Secure MIME (S/MIME)

Давайте посмотрим, что может стать известным злоумышленнику, перехватившему SIP-сообщения, относящиеся к этапу установки сессии:

  • SIP URI и IP-адреса обеих участников диалога.
  • Факт, что две стороны установили диалог.
  • IP-адреса и номера портов, относящиеся к медиа-потоку, что делает возможным перехват медиаданных.
  • Presence-информация: сведения о географическом положении сторон, их статусе, активности и т. д.

Сквозное (в отличие от протокола TLS, действующего от узла к узлу) обеспечение целостности, конфиденциальности и аутентификации SIP-сообщений возможно при помощи технологии S/MIME (RFC 3851). Замечу, что в предыдущих редакциях SIP RFC в качестве метода обеспечения аутентификации и секретности предлагался PGP, но сейчас его использование признано устаревшим. 23-я глава RFC 3261 описывает применение схемы S/MIME. Рассмотрим, как она интегрируется в модель использования SIP.

Сертификат S/MIME удостоверяет то, что его обладатель идентифицируется в сети SIP определённым списочным адресом. Эти сертификаты также ассоциируются с ключами шифрования. Тело сообщения подписывается личным ключом и шифруется открытым ключом предполагаемого получателя сообщения. Открытый ключ может быть вложен в само сообщение. Предполагается, что отправитель сообщения уже установил подлинность открытого ключа получателя. Сами же открытые ключи хранятся в UA на некой связке ключей в виде пар «списочный адрес – ключ». Как и любой другой, основанный на инфраструктуре открытых ключей протокол, S/MIME полагается на надёжную схему распределения ключей, а значит, каждый пользователь должен иметь сертификат подлинности, а также безопасный способ его передачи собеседнику.

Рассмотрим пример сообщения с телом S/MIME (см. рис. 3).

1sip3

Рисунок 3. S/MIME

На рис. 3 показана методика защиты тела SIP-сообщения с помощью S/MIME. Для защиты SIP-заголовков сообщение может быть помещено в MIME-тело с типом «message/sip», и инкапсулировано в новое SIP-сообщение с дублированными из оригинального сообщения заголовками с маршрутной информацией. В свою очередь, к сообщению-контейнеру может применяться S/MIME-подпись. Наконец, может выполняться и шифрование SIP-заголовков: в таком случае в сообщение-контейнер инкапсулируется шифрованный объект S/MIME. Такие сообщения не воспринимаются как новый диалог или транзакция, но пользуются всеми преимуществами сквозного шифрования и аутентификации. Заголовки Request-URI, Via, Record-Route, Route, Max-Forwards, и Proxy-Authorization не должны учитываться при подсчёте контрольных сумм, поскольку они могут (или должны) изменяться при прохождении через промежуточные прокси-серверы.

Расширения SIP для обеспечения приватности имени и номера абонента

Набор расширений RFC 3323 и RFC 3325 обеспечивает поддержку функций приватности абонента: сокрытия и верификации сетью отображаемого имени и номера участвующего в диалоге абонента (сеть удостоверяет личность вызывающего абонента, тот ли он, за кого он себя выдаёт).

Поддержка приватности в сети SIP является сложной задачей уже потому, что протокол имеет текстовую природу, и участники диалога могут обмениваться сообщениями без привлечения какого-либо сервис-провайдера. В то же время от SIP UA требуется как минимум функции скрытия отображаемого имени и номера абонента, ставшие привычными в ТфОП.

Наиболее прямолинейный подход – предоставление ограниченной информации в заголовке From – может вызвать проблемы при терминации звонка в сеть другого оператора или ТфОП или сделать невозможным предоставление ряда услуг. В RFC 3325 описывает функции обеспечения приватности личных данных абонента с сохранением возможности его идентификации.

Такой механизм идентификации работает в рамках одного домена. Для его реализации были представлены новые заголовки P-Preferred-Identity и P-Asserted-Identity. Заголовок P-Preferred-Identity используется UA в транзакциях с доверенным прокси-сервером. Клиент конструирует запрос INVITE, не содержащий данных о личности абонента в поле From, но с реальным SIP URI и (опционально) отображаемым именем в поле P-Preferred-Identity. Также добавляется заголовок Privacy, принимающий одно из следующий значений:

  • «none» – приватность не требуется; прокси-сервер обязан не удалять заголовок P-Asserted-Identity;
  • «user» – приватность требуется; прокси-сервер обязан удалить заголовок P-Asserted-Identity;
  • «id» – приватность требуется только в рамках данного домена.

Прокси-сервер обязан выполнить дайджест-аутентификацию для узла, с которым не установлены доверительные отношения. После этого прокси-сервер должен добавить заголовок P-Asserted-Identity с идентификатором личности абонента, который был аутентифицирован. Если прокси-сервер получает запрос от узла, с которым доверительные отношения уже установлены, используется уже имеющийся там заголовок P-Asserted-Identity.

Процедура отправки сообщения следующая. Если вызываемый абонент расположен в домене доверия (см. рис. 4), прокси-сервер передаёт абоненту запрос без удаления заголовка P-Asserted-Identity.

1sip4

Рисунок 4. Механизм обеспечения приватности в рамках одного домена

Если же абонент находится за пределами домена доверия (см. рис. 5), при выходе сообщения за пределы домена доверия прокси-сервер выполняет удаление или изменение всех заголовков с информацией о личности отправителя (From, Contact, Reply-To, Call-ID, Call-Info, Via, User-Agent, Organization, Server, Subject, In-Reply-To, Record-Route и Warning). P-Asserted-Identity обрабатывается в соответствии со значением заголовка Privacy, а сам заголовок Privacy должен быть удален.

1sip5

Рисунок 5. Механизм обеспечения приватности вне домена доверия

Разумеется, картина защиты будет неполной без обеспечения целостности и конфиденциальности данных в рамках одного домена доверия на сетевом уровне. Узлы домена должны быть взаимно аутентифицированы, а транзакции между узлами (и между UA и узлами домена) должны быть защищены с помощью TLS или IPSec.

Протокол SRTP/ZRTP

Оптимальным с точки зрения производительности является SRTP (RFC 3711), позволяющий шифровать (AES) медиапоток и обеспечивать проверку подлинности (HMAC-SHA-1) информации. Однако этот протокол не обеспечивает защиту процесса аутентификации, и необходимо дополнительно использовать сторонние инструменты вроде TLS/SSL. Связку SRTP + TLS/SSL можно легко организовать на Asterisk (с 1.8), FreeSWITCH, SIP-коммутаторе OpenSIPS и других подобных решениях. Кроме того, Asterisk и FreeSWITCH поддерживают протокол ZRTP, который специально разработан для VoIP Филиппом Циммерманном, создателем PGP (отсюда и первая буква Z в названии). Протокол обеспечивает безопасную аутентификацию и обмен данными, стандартизирован в RFC 6189. Во время инициализации ZRTP-звонка используется метод обмена ключами Диффи — Хеллмана, для аутентификации применяется SAS (Short Authentication String). Весь разговор шифруется, причем пара ключей генерируется для каждого сеанса автоматически, что очень удобно, так как позволяет легко встроить этот механизм в уже существующие продукты и не требуется инфраструктура PKI.

В дополнение к SRTP, в канальном драйвере chan_sip из состава Asterisk 11 реализована поддержка безопасного транспортного протокола DTLS-SRTP, предназначенного для передачи мультимедийных RTP-потоков c использованием шифрования, которая может быть задействована для абонентов, использующих WebRTC и SIP.

Конечно, с SRTP и ZRTP должны уметь работать и клиенты (софтофоны и аппаратные): Linphone (TLS, SRTP, ZRTP), Jitsi (TLS, SRTP, ZRTP), Blink (TLS, SRTP), MicroSIP (TLS, SRTP). Некоторая информация доступна на страничке. Сам Циммерманн предложил собственный софтофон Zfone, работающий по ZRTP (есть версии для Windows, Linux и OS X). В настоящее время Zfone находится в состоянии бета, но уже два года по техническим причинам его нельзя скачать с официального сайта.

Настройка SRTP + TLS/SSL в Asterisk

Сервер Asterisk поддерживает TLS между серверами и сценарий клиент — сервер. Для активации TLS достаточно прописать в настройках (sip.conf) всего несколько команд:

tcpenable=yes
tcpbindaddr=0.0.0.0
tlscertfile=/etc/asterisk/cert/asterisk.pem
tlscafile=/etc/asterisk/cert/ca.crt
tlsprivatekey=/var/lib/asterisk/keys/voip.example.org.key
tlsclientmethod=tlsv1

Проверяем подключение:

# openssl s_client host localhost port 5061
В настройках клиента ставим transport=tls.

RSA-ключи, используемые для шифрования, можно сгенерировать при помощи команды openssl genrsa и специальных скриптов astgenkey (astgenkey -n keyname) или asttlscert (копируют ключи в /var/lib/asterisk/keys). Последние не всегда доступны в пакетах или специальных дистрибутивах вроде Elastix, взять их можно на SVN-сервере.

Теперь подключение безопасно и подсмотреть регистрационные данные нельзя, хотя сами переговоры не шифруются. Штатный для Asterisk протокол IAX2, как и SIP, можно настроить на поддержку шифрования SRTP (AES128). Для этого необходимо добавить всего одну строку в конфиг iax.conf или sip.conf:

encryption=yes

Перезапускаем настройки sip reload/iax2 reload, затем проверяем, загружен ли модуль:

CLI> module show like res_srtp.so

Команда iax show peers должна показать метку (E) напротив подключенных клиентов, означающую, что шифрование активно. В журналах появится запись вида encrypt_frame: Encoding.

Поставьте свой рейтинг этой записи блога:
0

Комментарии

  • Никаких комментариев пока не было создано. Будьте первым комментатором.

Оставить комментарий

Гость
Гость Вторник, 17 Сентябрь 2019
Яндекс.Метрика Рейтинг@Mail.ru