Глава 4. Сертификаты для безопасности конечных точек

Нам должно повезти только один раз. Тебе должно везти каждый раз.

IRA к Маргарет Тэтчер после неудачной попытки убийства

Если вы действительно хотите что-то сделать, вы найдете способ. Если вы этого не сделаете, вы найдете оправдание.

Джим Рон

Неудобство безопасности

Безопасность VoIP можно рассматривать как две отдельные (но взаимосвязанные) проблемы:

Защита система от мошенничества с платными услугами (что, как правило, является целью попыток атак на основе SIP)
Защита системы от перехвата вызовов (что касается конфиденциальности, а также улучшения защиты от мошенничества)

Конечно, есть много других аспектов безопасности вашей системы, но большинство из них являются общими понятиями безопасности, не специфичными для VoIP.

В этой главе мы сосредоточимся на области безопасности, которая слишком часто упускается из виду, а именно на создании и применении сертификатов и ключей для обеспечения безопасности связи между конечными точками и вашей системой. В SIP-связи шифрование является необязательным (и, к сожалению, не используется большую часть времени). В WebRTC это необходимо.

Эта глава ни в коем случае не должна рассматриваться как последнее слово в защите вашей системы Asterisk; в Главе 22 будет рассмотрено больше. Однако мы надеемся, что это обеспечит вам прочную основу для построения безопасного решения.

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

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

ПРЕДУПРЕЖДЕНИЕ

Мы не шутим здесь; не пренебрегайте вашей безопасностью SIP или вы, вероятно, окажетесь жертвой очень дорогой атаки мошенничества.

Имена подписчиков

Абонентская часть учетных данных SIP (userinfo часть URI) слишком часто устанавливается как добавочный номер. Эта практика хороша для целей адресации вызовов, но совсем не рекомендуется для целей аутентификации конечной точки. Имя подписчика конечных точек не должно иметь значения за пределами организации. MAC-адрес идеально подходит для этого. Без фактического адреса для исследования работа злоумышленника станет намного сложнее.

Вы увидите множество УАТС типа SIP (включая на основе Asterisk, к сожалению), которые назначают добавочный номер учетным данным телефона. В этой книге вы увидите, что добавочный номер не является частью учетных данных телефона. В этом есть несколько преимуществ, но с точки зрения безопасности преимущество заключается в том, что если злоумышленник знает внутренний номер, он не имеет никаких знаний о том, как аутентифицировать вызов через систему.

Таким образом, у вас может быть пользователь с SIP-адресом 100@shifteight.org, которого система Asterisk свяжет с устройством по адресу 0000f3101010@yourpbx.com. Когда вызов направлен на 100, он будет звонить на 0000f3101010, но вызывающий абонент никогда ничего не знает об этой конечной точке.

На протяжении всей этой книги вы увидите, что мы установим связь между внутренним номером (расширением) (который, по нашему мнению, должен быть связан с пользователем или услугой) с идентификатором устройства (который может быть устройством SIP или номером телефона) и что простая таблица может использоваться для их связи (и впоследствии повысит как безопасность, так и гибкость).

Безопасность SIP-сигнализации

По умолчанию сообщения SIP передаются в открытом виде без эффективной защиты. При атаке человек посередине (MITM) злоумышленник способен получить всевозможную информацию о Ваших звонках. Протокол защиты транспортного уровня (TLS) используется, чтобы минимизировать этот риск.

О том, как настроить устройства на использование TLS, мы поговорим в следующей главе. Все, что нам нужно сделать сейчас — это создать сертификаты.

Существует три распространенных способа создания сертификатов. Мы приведем примеры для двух из них (самозаверенные - self-signed и LetsEncrypt), но оставим осуществление получения официально выданных сертификатов читателю.

САМОЗАВЕРЕННЫЕ СЕРТИФИКАТЫ

Основное преимущество самозаверенного сертификата заключается в том, что его не нужно проверять с помощью внешнего объекта. Недостатком является то, что из-за этого, внешние объекты не будут доверять ему.

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

В этом мире, полном автоматизированной преступности, многое можно узнать о конфиденциальности и безопасности, а также криптографии, необходимой для обоех сторон. Тем не менее, это книга об Asterisk, так что мы собираемся предоставить шаблон для создания необходимых компонентов, и вам необходимо продолжить исследование.

Инструментарий openssl предоставляет инструмент, который сделает работу за нас.

Мы запустим его следующим образом:

$ sudo su asterisk -
$ mkdir /home/asterisk/certs
$ openssl req -x509 -nodes -newkey rsa:2048 -days 3650 \
-keyout /home/asterisk/certs/self-signed.key \
-out /home/asterisk/certs/self-signed.crt

Вам будет предложено предоставить некоторую информацию, а затем ваш ключ и сертификат будут записаны в папку /home/asterisk/certs.

Вы можете добавить следующее в команду, чтобы обойти вопросы (измените информацию в соответствии с вашей ситуацией):

-subj "/C=CA/ST=Ontario/L=Toronto/O=ShiftEight/CN=shifteight.org"

Полная команда будет выглядеть примерно так:

$ openssl req -x509 -nodes -newkey rsa:2048 -days 3650 \
> -keyout /home/asterisk/certs/self-signed.key \
> -out /home/asterisk/certs/self-signed.crt \
> -subj "/C=CA/ST=Ontario/L=Toronto/O=ShiftEight/CN=shifteight.org"

Это создаст самозаверенный сертификат и закрытый ключ и сохранит их в /home/asterisk/certs/. Мы сможем использовать их позже, когда будем настраивать наши конечные точки SIP.

Вероятно, это хорошая идея, чтобы применить chmod к вашим сертификатам так, чтобы только соответствующий пользователь/группа могли получить к ним доступ:

$ chmod 640 /home/asterisk/certs/*

Выйдите из аккаунта пользователя asterisk.

$ exit
$ who am i # You should be astmin again.

Существует альтернатива использованию самозаверенных сертификатов: если у вас есть доменное имя, назначенное вашему серверу, доступному из общедоступного интернета, вы можете создать проверенный сертификат с помощью LetsEncrypt. Читайте дальше.

СЕРТИФИКАТЫ LETSENCRYPT

Если вы заинтересованы в безопасной связи через общедоступный Интернет (которому вы будете доверять), то наличие сертификатов домена, предоставляемых Центром сертификации (ЦС) полезно.

Проект LetsEncrypt предоставляет цифровые сертификаты бесплатной проверки домена (Domen Validation - DV). Бесплатный инструмент, предоставляемый Let’s Encrypt Foundation под названием certbot, позволяет автоматизировать получение и обслуживание доверенных сертификатов.

Как минимум, вашему серверу потребуется полное доменное имя (FQDN), которое сопоставляется с внешним IP-адресом, поступающим на компьютер. Любой брандмауэр между ними должен будет передавать трафик для этого имени хоста в систему, для которой вы получаете сертификат. Если вы не можете сделать это по какой-либо причине, получение доверенного сертификата становится более сложным (и выходит за рамки этой книги).

certbot может быть установлен посредством yum следующим образом:

$ sudo yum -y install certbot

После его установки Вам просто нужно выполнить следующее:

$ sudo certbot certonly
How would you like to authenticate with the ACME CA?
-------------------------------------------------------------------------------
1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

Если у вас работает веб-сервер или вы уверены в Варианте 2, это нормально, но эти шаги предполагают, что у вас нет веб-сервера и, следовательно, вам необходимо/требуется использовать встроенный временный веб-сервер, который certbot будет использовать для аутентификации. Этот сервер используется для подтверждения управления доменом, для которого запрашивается сертификат.

При необходимости ответьте на следующие вопросы, а затем вставьте имя хоста, назначенное IP-адресу сервера:

Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel): asteriskbook.shifteight.org

(замените asteriskbook.shifteight.org на назначенное доменное имя).

certbot будет выполнять свою магию, и если все прошло хорошо, вы должны получить сообщение похожее на следующее:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/asteriskbook.shifteight.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/asteriskbook.shifteight.org/privkey.pem
   Your cert will expire on 2018-07-23. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:
   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Не забудьте сделать пожертвование Internet Security Research Group (ISRG) или Electronic Frontier Foundation (EFF); они выполняют важную работу и заслуживают нашей поддержки.

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

Не слишком сложно, а?

ЗАМЕЧАНИЕ

Имейте в виду, что большинство сертификатов, которые вы получаете из внешнего источника, будут иметь срок действия.

В случае LetsEncrypt текущий срок действия составляет три месяца.

Если вы собираетесь запустить сертификаты в продакшен, Вам нужно понять как ими управлять (например, автоматизировать обновление, где люди из LetsEncrypt проделали хорошую работу по упрощению).

ПРИОБРЕТЕНИЕ СЕРТИФИКАТОВ В ОФИЦИАЛЬНОМ ЦЕНТРЕ СЕРТИФИКАЦИИ

Если сертификаты LetsEncrypt не обеспечивают требуемый уровень проверки (например, если вам нужна проверка организации (OV) или расширенная проверка (EV)), вам нужно будет получить услуги центра сертификации, который предоставляет такие вещи. Эти вопросы выходят за рамки данной книги.

Если вы проработали примеры для разделов самозаверенных и LetsEncrypt сертификатов, у Вас будет хотя бы базовое представление о некоторых процессах получения сертификатов из центра сертификации, так как многие шаги будут аналогичны.

Защита медиапотока

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

Шифрование RTP

Шифрование протокола реального времени позволит достичь эффекта защиты наших медиа-потоков.

Для обеспечения шифрования медиа обычно используются два механизма: SDES и DTLS-SRTP. SDES — это механизм шифрования мультимедиа, который доверяет безопасности сигнализации. Другими словами, если вы используете TLS для защиты сигнализации SIP, то SDES, вероятно, также обрабатывает шифрование мультимедиа.

DTLS-SRTP, с другой стороны, не доверяет сигнализации. Это важно, потому что стандарт WebRTC требует чтобы медиапоток был зашифрован таким образом.

Сертификаты, которые мы создали здесь, должны работать в обоих сценариях. В следующих главах, когда мы будем настраивать конечные точки SIP или WebRTC, мы рассмотрим более подробно как использовать сертификаты. На данный момент достаточно того, что мы сгенерировали сертификаты и сделали их доступными для использования.

Вывод

Не ошибитесь: безопасность все усложняет. В старые добрые времена вы могли запустить SIP-соединение с полудюжиной строк конфигурации и назвать это днем. Это больше не летает, и хотя этот тип конфигурации по-прежнему будет работать (просто используйте UDP вместо TLS, и все, что вам нужно — это пароль), мы решили что начиная с этого выпуска все примеры конфигурации будут выбирать более безопасные параметры где это возможно. Мы не претендуем на то, чтобы представить последнее слово о безопасности VoIP, но мы собираемся привести примеры, которые заплатят больше, чем на словах концепции.

Далее мы обсудим, как настроить конечные точки в системе Asterisk (используя ключи и сертификаты, которые мы только что создали).

Глава 3. Установка Asterisk

Содержание

Глава 5. Конфигурация пользовательских устройств