Что такое STIR/SHAKEN?

6 сентября 2021, 12:41
STIR/SHAKEN (Secure Telephony Identity Revisited / Signature-based Handling of Asserted information using toKENs)  это новая технология, которую телекоммуникационная отрасль использует для борьбы с телефонным мошенничеством. Мы все получали спам-звонки, и некоторые из нас, возможно, даже получили звонок с Caller ID абонента, который нам хорошо известен, но в итоге оказывались кем-то другим. Это было серьезной проблемой в течение многих лет, но с помощью STIR/SHAKEN мы можем резко снизить вероятность того, что это произойдет.

Как это работает?


STIR/SHAKEN - технология на основе сертификатов, которая использует закрытые и открытые ключи для идентификации источника вызова. Это устанавливает цепочку доверия от одной организации к другой. Доверенные поставщики будут хранить закрытый ключ, который они используют для подписи заголовков SIP (в частности, заголовок удостоверения будет иметь эту подпись), и они предоставят открытый ключ другим пользователям для загрузки и проверки по закрытому ключу. В этом заголовке хранится много информации, включая аттестацию, идентификатор вызывающего абонента, URL-адрес открытого ключа и многое другое. Аттестация будет использоваться для определения того, какой уровень доверия пытается установить этот звонок. Оттуда получатель вызова может решить, что он хотел бы сделать с этой информацией. Вот пример того, как может выглядеть заголовок идентификатора:

Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cDovL3Rlc3RpbmcxMjMifQ==.eyJvcmlnIjp7InRuIjoiMTIzNDU2NyJ9LCJhdHRlc3QiOiJCIiwib3JpZ2lkIjoiYXN0ZXJpc2siLCJpYXQiOjE1OTA1ODgzODV9.MEUCIQCmINlklk+fCxEEjgbbwE5X7DAEy19aPRfLvypXrKUwpwIgaDtEzKZoGRa/Omof9iC6tPQPzsKazN1hygDWOc9uWXQ=;info=<https://testing123.com/test.crt>alg=ES256;ppt=shaken

Заголовок, payload и подпись кодируются BASE64 и разделяются точками. Вот пример заголовка:

eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cDovL3Rlc3RpbmcxMjMifQ==

Если расшифровать BASE64 (через https://www.base64decode.org например) то получим:

{"alg":"ES256","ppt":"shaken","typ":"passport","x5u":"http://testing123"}

Заголовком является JSON-объект, как миниму содержащий алгоритм кодирования, ppt, тип и URL публичного ключа. На момент написания этой заметки ppt должен иметь значение “shaken и тип - “passport”..

Теперь payload:

eyJvcmlnIjp7InRuIjoiMTIzNDU2NyJ9LCJhdHRlc3QiOiJCIiwib3JpZ2lkIjoiYXN0ZXJpc2siLCJpYXQiOjE1OTA1ODgzODV9

После расшифровки BASE64 получим:

{"orig":{"tn":"1234567"},"attest":"B","origid":"asterisk","iat":1590588385}

Payload является также JSON-объектом, который содержит  номер caller ID, аттестацию, ID оригинатора и метку времени. Большая часть приведенной здесь информации будет использована для сравнения с условиями, которые необходимо выполнить для успешного выполнения вызова.

Подпись следует за payload (полезной информацией), вплоть до точки с запятой. После этого у нас есть:

info=<https://testing123.com/test.crt>alg=ES256;ppt=shaken

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

Конфигурация STIR/SHAKEN


Астериск уже имеет встроенный механизм поддержки STIR/SHAKEN. Это реализовано в виде опции в секции “endpoint” файла pjsip.conf:

[my_endpoint]
type=endpoint
stir_shaken=yes

По умолчанию для этого параметра установлено значение нет. Если вы хотите, чтобы ваши звонки поддерживали STIR/SHAKEN, вам нужно включить эту опцию для этих конечных пиров. Это все, что вам нужно сделать в pjsip.conf. Остальное настраивается в файле stir_shaken.conf. Вот пример того, как может выглядеть этот файл конфигурации:

[general]
ca_file=/etc/asterisk/stir/ca.crt
ca_path=/etc/asterisk/stir/ca
cache_max_size=1000
curl_timeout=2
signature_timeout=15

[my_cert]
type=certificate
path=/etc/asterisk/stir/mycert.pem
public_key_url=http://testing.com/test.crt
caller_id_number=1234567
attestation=C
origid=MyAsterisk

Использование STIR/SHAKEN в Диал-плане


Еще одна интересная вещь, которую вы можете сделать, - это проверять результаты STIR/SHAKEN в диалплане. Функция STIR_SHAKEN сообщит вам результат проверки, чтобы вы могли использовать его по своему усмотрению. Возможными результатами являются “Проверка отсутствует”, “Ошибка подписи”, “Несоответствие проверки” и “Проверка пройдена”. Если результат “Проверка отсутствует”, это означает, что не было никакой информации для обработки (без заголовка идентификации). “Несоответствие проверки” означает, что информация внутри полезной нагрузки не соответствует информации в сообщении SIP. “Проверка пройдена” означает, что проверка ПЕРЕМЕШИВАНИЯ/ВСТРЯХИВАНИЯ прошла успешно. “Ошибка подписи” означает, что либо подпись и открытый ключ не совпадают, либо подпись не удалась по другой причине. Основываясь на этих результатах, вы можете выбрать действия, которые можно предпринять. Вот несколько примеров:

exten => example1,1,STIR_SHAKEN(count)

exten => example2,1,STIR_SHAKEN(0, verify_result)

exten => example3,1,STIR_SHAKEN(5, identity)

exten => example4,1,STIR_SHAKEN(2, attestation)

Вы уже знаете, что означает verify_result, но есть и другая информация, которую также можно получить и обрабатывать.
Если просто вызвать функцию count, она вернет, сколько существует идентификаторов STIR/SHAKEN.
Затем вы можете просмотреть их все и получить информацию по каждому. Вот тут-то и появляются цифры. Чтобы получить результат проверки, вы должны сначала ввести индекс удостоверения, для которого вам нужна информация, а затем имя нужной вам информации. В настоящее время вы можете получить verify_result, идентификацию и аттестацию.

Выводы


Вот и всё как это устроено! Настройка довольно минимальна, но влияние, которое она окажет на клиентов, огромно. Выполнив описанные выше действия по настройке Asterisk для STIR/SHAKEN, вы сможете предотвратить несколько спам-звонков, сэкономив время и деньги. В будущем, по мере дальнейшего развития технологий и промышленности, будет проделана дополнительная работа по STIR/SHAKEN, но основа уже заложена и может быть использована сейчас. Попробуйте и помогите нам улучшить Asterisk своими отзывами!

Что такое STIR/SHAKEN?

Стремительное развитие WebRTC

23 июля 2021, 09:48
Часто спрашивают: "Безопасен ли WebRTC?" Одним словом...да.
WebRTC защищен и использует различные меры безопасности, чтобы гарантировать сохранность вашей информации. В целом - развивайте свой бизнес с помощью WebRTC, которая является технологией, обеспечивающей взаимодействие между интернет-браузерами и мобильными приложениями. Это известно также как веб-связь в режиме реального времени, расшифровывая аббревиатуру. Это упрощает передачу и интеграцию аудио, видео и данных из открытых источников, которые относятся к категории решений для веб-приложений в режиме реального времени.

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

Элементы защиты WebRTC: 

Часто спрашивают: "Безопасен ли WebRTC?" Одним словом...да. WebRTC защищен и использует различные меры безопасности, чтобы гарантировать сохранность вашей информации. К ним относятся:

Защита браузера:

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

Доступ к средствам массовой информации:

Технология WebRTC работает в 2021 году после того, как COVID-19, в частности, устраняет возможные проблемы, связанные с разрешением доступа к медиа активам, требуя специального разрешения на использование камеры или усилителя. Для приложения WebRTC невозможно получить доступ к гаджету без согласия. Кроме того, это будет продемонстрировано в пользовательском интерфейсе клиента и на его оборудовании в любой момент, когда используется гаджет.

Шифрование:

Шифрование является обязательной частью WebRTC и разрешено на всех этапах создания и поддержания соединения. Для звука и видео ключевая информация затем может быть использована для создания ключей AES (Advanced Encryption Standard), которые, таким образом, используются SRTP (Безопасный транспортный протокол реального времени) для шифрования и декодирования носителей. Эта аббревиатура "богатая куча инноваций" означает очень надежные ассоциации, которые трудно разорвать с текущими инновациями. И WebRTC, и ORTC заказывают этот конкретный стек, который, в свою очередь, жизнеспособен и совместим с фреймворками VoIP.

Стремительное развитие WebRTC

Семь ошибок безопасности (инфраструктура как код)

13 февраля 2021, 23:59

Проблема №1: Ярлыки безопасности

Проблема номер один — это неспособность обеспечить надлежащую безопасность, потому что для этого требуется много времени и знаний. Например, инженеры DevOps могут не требовать сертификатов на основе протокола SSL/TLS для всех микросервисов или не применять соответствующие роли управления идентификацией и доступом (IAM) к облачным ресурсам. Такие упущения могут сделать организации уязвимыми для злоумышленников, которые смогут сделать практически все, как только получат доступ к системе.

Соблюдение требований как кодекс может помочь решить эту проблему. Эта категория программного обеспечения применяет подход "инфраструктура как код" для автоматизации внедрения, проверки и мониторинга состояния соответствия требованиям, связанным с безопасностью, защитой данных и различными бюджетными ограничениями. Различные инструменты сканирования безопасности и тестирования на проникновение могут быть вставлены в конвейер DevOps, так что сканирование среды на предмет безопасности становится частью регулярного процесса развертывания при вводе версий в производство.

Проблема № 2: Не реализована сквозная автоматизация

Слишком часто инженеры DevOps выбирают то, что они решат автоматизировать в рамках развертывания облачной инфраструктуры — автоматизировать более простые процессы, продолжая выполнять более сложные шаги вручную. Эти ручные шаги затем становятся слабыми звеньями.

Вспомните о тех случаях, когда система авиакомпании выходит из строя из-за неудачного обновления системы, что мешает путешественникам забронировать билет. Чаще всего такие сбои вызваны каким-то неправильно выполненным ручным процессом обновления, на устранение которого у технической команды уходит до 24 часов. Это хорошие примеры того, как неспособность внедрить сквозную автоматизацию может привести к недовольству клиентов и потере доходов.

Проблема № 3: Недостаточное автоматизированное тестирование

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

Проблема № 4: Игнорирование лучших практик оптимизации затрат

Мы видели реальные примеры, когда развертывание может стоить либо 1000, либо 100 000 долларов в месяц, в зависимости от того, как управляется облачная инфраструктура. Оптимизация может принимать форму правильного определения размера ресурсов, использования преимуществ спотовых экземпляров, идентификации незанятых ресурсов или работы на нескольких облачных платформах.

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

Проблема № 5: Создание облачного мусора

Очень легко создать новую инфраструктуру, но не так легко ее удалить. Это часто оставляет организации с бесхозными ресурсами в облаке, которые больше не нужны. И предприятия платят облачным провайдерам за этот “облачный мусор”, который все еще работает неиспользуемым на их платформах. По этой причине инженеры DevOps должны убедиться, что они автоматически не развертывают неиспользуемые ресурсы как часть своего кода инфраструктуры.

Проблема №6: Жесткое кодирование значений параметров

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

Проблема № 7: Монолитные скрипты

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

WebRTC теперь официальный стандарт

2 февраля 2021, 13:50
  26 января 2021 года

Web Real-Time Communications (WebRTC) https://www.w3.org и https://www.ietf.org

Консорциум World Wide Web Consortium (W3C) и Целевая группа по разработке Интернета (IETF) объявили сегодня, что Web Real-Time Communications (WebRTC), которые поддерживают множество сервисов, теперь является официальным стандартом, обеспечивающим аудио-и видеосвязь в любом месте Сети.

WebRTC, состоящий из JavaScript API для веб-коммуникаций в реальном времени и набора коммуникационных протоколов, позволяет любому подключенному устройству в любой сети быть потенциальной конечной точкой связи в Интернете. WebRTC уже служит краеугольным камнем онлайн-коммуникаций и услуг совместной работы.

"Сегодняшнее знаковое достижение является своевременным. Столкнувшись с глобальной пандемией коронавируса COVID-19, мир становится все более виртуальным. Это делает Интернет еще более важным для общества в области обмена информацией, коммуникаций в реальном времени и развлечений",-сказал д-р Джефф Джаффе, генеральный директор W3C. “Отрадно видеть, что наши технологии играют ключевую роль в создании такой критически важной цифровой инфраструктуры. Сочетание универсального охвата Интернета с богатством живых аудио-и видеопереговоров изменило то, как мир общается.”

https://www.ietf.org/blog/webrtc-standardized/



WebRTC теперь официальный стандарт

Мировые тренды 2021 года в сетях - советы от Cisco systems

8 января 2021, 19:33
  1. Обеспечивайте безопасность сотрудников, где бы они ни находились. 

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

  2.  Привлекайте работников к  работе в офисе — смело!

    Работа в офисе будет протекать иначе, чем раньше. Потому что пандемия подталкивает многие компании к внедрению новых защитных мер. В качестве примеров:
    62% будут больше полагаться на видеоконференции
    32% будут следить за тем, сколько людей находится в одном месте
    30% будут использовать новые средства защиты, включая тепловые датчики и бесконтактное управление лифтом

    Чтобы это произошло, ваша сеть должна быть более гибкой, чем когда-либо. Поэтому ваша команда должна быть уверена, что она готова поддерживать большую доступность и автоматизацию.  

 
  1. Распределение на несколько общедоступных облаков.

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

  2. Автоматизировать общие задачи, адаптироваться быстрее.

    Ваша сеть должна быть готова к неожиданным скачкам из любого места. Когда разразилась пандемия, нам в Cisco пришлось масштабироваться, чтобы справиться с 300-процентным увеличением использования WebEx почти за одну ночь. И мы не смогли бы справиться с этим всплеском вручную—мы полагались на автоматизированные инструменты, чтобы сделать такие вещи, как обеспечение большей пропускной способности, балансировка пропускной способности и массовое привлечение новых людей.

    И вы можете сделать то же самое. В ближайшие пару лет 35% компаний планируют автоматизировать свою инфраструктуру и доступ к Сети Интернет на основе намерений — по сравнению всего с 4% в прошлом году.  

  3. Использование ИИ для управления штормового предупреждения.

    Среднестатистическое предприятие получает около 6000 квалифицированных сетевых оповещений каждый месяц. Слишком много событий, чтобы ваша команда могла быстро их заметить и исправить. Вот тут-то и появляется искусственный интеллект. Он может обрабатывать большую часть этих предупреждений, оставляя гораздо более управляемый срез проблем, с которыми может справиться человек. Например, было показано, что наши инструменты с поддержкой искусственного интеллекта сокращают количество сетевых оповещений на 99,6%.
Мировые тренды 2021 года в сетях - советы от Cisco systems

Утечка конфиденциальных данных Sangoma Corp

30 декабря 2020, 09:31
Маркхэм, Онтарио, 24 декабря 2020 года

Sangoma Technologies Corporation (TSXV: STC) объявила, что в результате кибератаки вымогателей на один из серверов компании вчера были раскрыты и опубликованы частные и конфиденциальные данные, принадлежащие компании.
Компания начала всестороннее расследование, чтобы полностью установить масштабы этого нарушения данных, и тесно сотрудничает со сторонними экспертами по кибербезопасности, чтобы поддержать эти усилия.

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

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

Как всегда, всем клиентам Sangoma, у которых есть вопросы, рекомендуется связаться с Sangoma традиционными методами или по электронной почте: sangoma-security@sangoma.com.

Оригинал: https://www.sangoma.com/press-releases/sangoma-technologies-confirms-data-breach-as-result-of-ransomware-attack/


Утечка конфиденциальных данных Sangoma Corp
Перейти к архиву