IP телефония

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

  Случайное однократно используемое число помогает агенту обнаруживать попытки воспроизведения более раннего законного ответа, посланного сервером аутентификации. Если злоумышленник воспроизводит более раннее сообщение, например корректное сообщение «Доступ разрешен» с согласующимся восьмибитовым идентификатором запроса, то хеш аутентификатора ответа не будет выводиться из соответствующего случайного числа. Агент способен обнаружить это, повторив процесс, показанный на рис. 3.4 (исключая просмотр базы данных пользователей). Если хешированное значение, полученное в результате работы алгоритма MD5, не совпадет с хешем аутентификатора ответа, то агент отбросит сообщение как недействительное.

  Вторым и более очевидным средством защиты в сообщении «Запрос на доступ» является шифрование пароля пользователя. Это не дает злоумышленнику возможности перехватить пароли пользователей в момент их прохождения между агентом и сервером аутентификации. Перед отсылкой сообщения «Запрос на доступ» агент шифрует пароль пользователя. В отличие от шифрования пароля в ОС UNIX, сервер аутентификации может провести обратную процедуру по получении сообщения «Запрос на доступ». На рис. 3.5 показаны основные операции процедуры шифрования. 

 На первом этапе строится 128-разрядный ключ шифрования, для чего хешируется поле данных, содержащее базовый секрет протокола RADIUS, и случайное одноразовое число этого запроса. Чтобы получить зашифрованное значение, биты пароля объединяются с битами ключа с помощью логической  операции «исключающее или». Если пароль короче 128 бит, то он дополняется нулями. Если же он длиннее, то генерируются дополнительные ключи шифрования, что делается с помощью процедуры формирования цепочек,

описанной в спецификации протокола RADIUS.

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

  Может возникнуть вопрос, зачем конструировать другой ключ, объединяя его со случайным одноразовым числом, если уже имеется совместный базовый секрет в виде ключа протокола RADIUS? Во-первых, этим устраняется одно из слабых мест, связанное с использованием для шифрования операции «исключающее или». Если злоумышленникам удастся получить два или более сообщений, зашифрованных с использованием «исключающего или» с одним и тем же ключом, то они смогут легко определить зашифрованные данные. Хешируя секретный ключ и случайное однократно используемое число, получаем новый ключ всякий раз, шифруется другой пароль.

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

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

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

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

3.4. Выработка рекомендации  по обеспечению  безопасности

соединения  в сетях IP-телефонии.

3.4.1. Варианты доступа  к услугам IP-телефонии

  Если говорить о способах, к которым может прибегнуть абонент, чтобы воспользоваться услугами телефонии, то можно выделить следующие три основных варианта. Во-первых, это наиболее распространенный и хорошо всем знакомый способ подключения к сети IP-телефонии через обычный  телефон. Причем он может, как поддерживать передачу DTMF сигналов, так и нет (в последнем случае пользователь прибегает к услугам оператора, который «проключает» его в указанном направлении). Вторым вариантом можно считать использование специализированных устройств – IP-телефонов. IP Ethernet-телефон – это новое устройство, которое похоже на обычный телефон, но, в отличие от него, подсоединяется к Ethernet-порту коммутатора. IP- телефон обеспечивает качество речи, сравнимое с обычным телефоном, а также имеет расширенный набор программируемых функций. У IP-телефона много общего с ПК. Он может работать как обычное IP-устройство и иметь собственный IP-адрес. Поскольку IP-телефон полностью совместим со стандартами IP-телефонии, с его помощью можно связаться с любым другим совместимым устройством или ПО, например с Microsoft NetMeeting. И, наконец, третьим вариантом может стать применение специального программного обеспечения, установленного у пользователя на его ПК (например, та же программа Microsoft NetMeeting). Если сравнивать эти варианты с существующими сценариями IP-телефонных соединений, то мы не найдем противоречий; в качестве терминала H.323 мы взяли IP-телефон и несколько расширили понятие, указав еще как вариант использование ПК с соответствующим ПО. Все дело в том, что, в основном, первый и третий способы применяются обычными рядовыми пользователями (частными лицами, в домашних условиях), что же касается использования IP-телефонов, то сейчас к этому прибегают молодые, энергично развивающиеся компании.

  В связи с такой градацией, должны и вырабатываться методики обеспечения

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

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

3.4.2. Доступ к сети IP-телефонии  через обычный  телефон.

  Основная проблема, которая может возникнуть в этом случае и на предотвращение которой стоит обратить внимание провайдеру IP-телефонии – это кража сервиса. Все дело в том, что в данном случае система аутентификации носит простейший характер: пользователь указывает свой номер карты и ПИН-код, на основании которых сервер аутентификации делает вывод о том, разрешен ли доступ пользователю к ресурсам или нет. Часть проблем, связанная непосредственно с процессом аутентификации, авторизации и аудита была рассмотрена выше, в разделах, посвященных серверам аутентификации. Если вспомнить, то там предотвращение взломов рассматривалось на участке сервер доступа – сервер аутентификации, а вот про участок пользователь – сервер доступа ничего сказано не было. Здесь постараемся осветить и эту проблему.

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

  Конечно, невнимательность и неосторожность пользователя – это ключевой момент данной проблемы, и бороться с этим провайдеру услуг IP-телефонии трудно. Именно поэтому на обратной стороне таких карт можно часто встретить надпись о том, что провайдер не несет ответственности за потерю пользователем его атрибутов, а также просит сохранять карту до тех пор, пока не будут израсходованы все средства на ней. Это действительно все так, но все равно с этим приходится постоянно сталкиваться, и поэтому какие-то механизмы все-таки нужны.

1). Возможность смены ПИН-кода пользователем на web-интерфейсе.

  В случае возникновения ситуации, когда атрибутами абонента воспользовалось постороннее лицо, эта функция может оказаться весьма полезной. Абонент самостоятельно заходит на сайт провайдера по гостевым параметрам и через web-интерфейс меняет ПИН-код на другой. Технически это реализуемо, причем, как правило, реализуема смена именно ПИН-кода, поскольку номер карты напрямую связан с персональным порядковым номером этой карты, который потом проходит в отчетной документации.

  Очевидные минусы: во-первых, не все пользователи карт IP-телефонии имеют

ПК и  возможность посещения этого  самого web-интерфейса. Во-вторых, пользователю не нужно запоминать последовательность цифр (а это от 12 до 16 цифр), так как они занесены у него на карте; при смене ПИН-кода велика вероятность того, что пользователь забудет его. В-третьих, доступ к web- интерфейсу возможен только при вводе на сайте номера вашей карты и соответствующего ей ПИН-кода, если посторонний человек, обладая вашими реквизитами, воспользуется услугой смены ПИН-кода на web-интерфейсе, то мало того, что вы не сможете больше на него попасть, но вы не сможете и продолжать пользоваться услугами IP-телефонии, так как ваш ПИН-код уже устарел, и при аутентификации сервер будет выдавать сообщение «в доступе отказано».

  Решения: при отсутствии ПК и доступа к web-интерфейсу в случае необходимости смены ПИН-кода можно обратиться по телефону в службу технической поддержки и там вам сменят его. Рекомендуется в этом случае при изготовлении карт предусматривать на обратной стороне под полем «ПИН-код» одно или два дополнительных поля, в которые пользователь сможет вписать новый ПИН-код при его смене. При невозможности попасть на свою страницу через web-интерфейс или при получении сообщения в момент авторизации, что вам отказано в доступе по причине неправильного указания номера карты или ПИН-кода свяжитесь с службой технической поддержки своего провайдера. Специалист службы техподдержки сможет определить по ряду уточняющих вопросов, кто в действительности является подлинным абонентом (например, уточнив, где была приобретена карта, или, если она проходила предварительную регистрацию, по дополнительному паролю), при этом специалист техподдержки по просьбе абонента может сделать запись в соответствующей базе данных, что при повторном обращении с таким номером карты выполнять действия (в том числе и смену ПИН-кода) только, если пользователь назовет ключевое слово, причем оно не будет видно через web-интерфейс. Таким образом, можно избежать ситуации, когда третье лицо выдает себя за пользователя, у которого уже украли реквизиты и он не может воспользоваться услугами IP-телефонии.