Мини-Сервер своими руками - это просто! - IP телефония /books/ip-telephony/75-ip2 2021-06-25T01:38:43+03:00 Мини-Сервер singlwolf@mini-server.ru Joomla! - Open Source Content Management 8.9. Реализация функций СОРМ в IP-телефонии 2011-12-05T11:43:00+04:00 2011-12-05T11:43:00+04:00 /books/ip-telephony/75-ip2/1138-8-9-realizaciya-funkcij-sorm-v-ip-telefonii <p>Так как в сетях IP-телефонии используется передача речевой информации между або­нентами, то такие сети подпадают под <strong>действие</strong> системы оперативно-разыскных мероприя­тий (СОРМ). Для реализации необходимых функций СОРМ необходимо обеспечить возмож­ность фиксации не только всей справочной информации о телефонных вызовах (источник и получатель вызова, дата и время разговора и др.), но и возможность полной записи разговора.</p> <p>В <b>сети</b> IP-телефонии реализация функций СОРМ может быть выполнена различными способами. В том случае, когда вызывающий абонент включен в телефонную <i>сеть</i> общего пользования (например, сценарии 2 и 3 проекта TIPHON), то функции СОРМ реализуются существующими средствами на телефонных станциях.</p> <p>При включении исходящих терминалов (например, терминалов Н.323 на базе персо­нальных компьютеров) непосредственно в IP-сеть вопросы реализации функций СОРМ должны решаться в оборудовании доступа сети с пакетной коммутацией (серверы доступа, маршрутизаторы, коммутаторы и др.).</p> <br/> <p>Так как в сетях IP-телефонии используется передача речевой информации между або­нентами, то такие сети подпадают под <strong>действие</strong> системы оперативно-разыскных мероприя­тий (СОРМ). Для реализации необходимых функций СОРМ необходимо обеспечить возмож­ность фиксации не только всей справочной информации о телефонных вызовах (источник и получатель вызова, дата и время разговора и др.), но и возможность полной записи разговора.</p> <p>В <b>сети</b> IP-телефонии реализация функций СОРМ может быть выполнена различными способами. В том случае, когда вызывающий абонент включен в телефонную <i>сеть</i> общего пользования (например, сценарии 2 и 3 проекта TIPHON), то функции СОРМ реализуются существующими средствами на телефонных станциях.</p> <p>При включении исходящих терминалов (например, терминалов Н.323 на базе персо­нальных компьютеров) непосредственно в IP-сеть вопросы реализации функций СОРМ должны решаться в оборудовании доступа сети с пакетной коммутацией (серверы доступа, маршрутизаторы, коммутаторы и др.).</p> <br/> 8.8. Обеспечение безопасности IP-телефонии на базе VPN - Часть 5 2011-12-03T17:55:00+04:00 2011-12-03T17:55:00+04:00 /books/ip-telephony/75-ip2/1137-8-8-obespechenie-bezopasnosti-ip-telefonii-na-baze-vpn-chast-5 </td> <td> <p>Операции, связанные с шифрованием данных, могут чрезмерно загружать ЦП и снижать производительность брандмауэра. В случае интегриро­ванных продуктов VPN и брандмау­эра оба они могут оказаться не луч­шими в своем классе.</p> </td> </tr> <tr> <td> <p>VPN на базе маршрутиза­тора или ком­мутатора</p> </td> <td> <p>Интегральные <strong>сети</strong> VPN могут не по­требовать дополнительных расходов на приобретение. Упрощение админи­стрирования VPN.</p> </td> <td> <p>Функционирование VPN может от­рицательно повлиять на другой тра­фик.</p> </td> </tr> <tr> <td> <p>VPN на базе автономного программного обеспечения</p> </td> <td> <p>Завершение VPN нередко представля­ет собой сложную задачу. При повы­шении производительности серверных продуктов аппаратное обеспечение может потребоваться модернизиро­вать. Старые аппаратные средства мо­гут послужить для решения новых задач.</p> </td> <td> <p>Администрирование VPN может по­требовать отдельного приложения, возможно, выделенного каталога.</p> </td> </tr> <tr> <td> <p>VPN на базе аппаратных средств</p> </td> <td> <p>Многофункциональные устройства облегчают конфигурацию и обслужи­вание в удаленных офисах. Одно-функциональные устройства допуска­ют тонкую настройку для достижения наивысшей производительности.</p> </td> <td> <p>В многофункциональных блоках производительность одного прило­жения повышается зачастую в ущерб другому. Однофункциональные уст­ройства могут требовать отдельных инструментов администрирования и каталогов. Модернизация для повы­шения производительности нередко оказывается слишком дорогостоящей или невозможной.</p> </td> </tr> </table> <p></p> </td> </tr> </table> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p>Таблица 8.2. Категории систем VPN</p> </td> </tr> </table> <img src="//images/stories/knigi/ip-phone/image139.gif" width="536" height="558" class=""/><br/> В табл. 8.2 представлены некоторые системы для организации взаимодействия между пользователями VPN в <i>сети</i> Интернет-телефонии.</p> </td> <td> <p>Операции, связанные с шифрованием данных, могут чрезмерно загружать ЦП и снижать производительность брандмауэра. В случае интегриро­ванных продуктов VPN и брандмау­эра оба они могут оказаться не луч­шими в своем классе.</p> </td> </tr> <tr> <td> <p>VPN на базе маршрутиза­тора или ком­мутатора</p> </td> <td> <p>Интегральные <strong>сети</strong> VPN могут не по­требовать дополнительных расходов на приобретение. Упрощение админи­стрирования VPN.</p> </td> <td> <p>Функционирование VPN может от­рицательно повлиять на другой тра­фик.</p> </td> </tr> <tr> <td> <p>VPN на базе автономного программного обеспечения</p> </td> <td> <p>Завершение VPN нередко представля­ет собой сложную задачу. При повы­шении производительности серверных продуктов аппаратное обеспечение может потребоваться модернизиро­вать. Старые аппаратные средства мо­гут послужить для решения новых задач.</p> </td> <td> <p>Администрирование VPN может по­требовать отдельного приложения, возможно, выделенного каталога.</p> </td> </tr> <tr> <td> <p>VPN на базе аппаратных средств</p> </td> <td> <p>Многофункциональные устройства облегчают конфигурацию и обслужи­вание в удаленных офисах. Одно-функциональные устройства допуска­ют тонкую настройку для достижения наивысшей производительности.</p> </td> <td> <p>В многофункциональных блоках производительность одного прило­жения повышается зачастую в ущерб другому. Однофункциональные уст­ройства могут требовать отдельных инструментов администрирования и каталогов. Модернизация для повы­шения производительности нередко оказывается слишком дорогостоящей или невозможной.</p> </td> </tr> </table> <p></p> </td> </tr> </table> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p>Таблица 8.2. Категории систем VPN</p> </td> </tr> </table> <img src="//images/stories/knigi/ip-phone/image139.gif" width="536" height="558" class=""/><br/> В табл. 8.2 представлены некоторые системы для организации взаимодействия между пользователями VPN в <i>сети</i> Интернет-телефонии.</p> 8.8. Обеспечение безопасности IP-телефонии на базе VPN - Часть 4 2011-11-11T15:31:00+04:00 2011-11-11T15:31:00+04:00 /books/ip-telephony/75-ip2/1136-8-8-obespechenie-bezopasnosti-ip-telefonii-na-baze-vpn-chast-4 <p>Как и любая другая вычислительная функция, работа по созданию <strong>сетей</strong> VPN прово­дится с помощью программного обеспечения. Между тем программное обеспечение для VPN может выполняться на самых разных аппаратных платформах. Маршрутизаторы или комму­таторы третьего уровня могут поддерживать функции VNP по умолчанию (или в качестве дополнительной возможности, предлагаемой за отдельную плату). Аппаратно и программно реализуемые брандмауэры нередко предусматривают модули VPN со средствами управления трафиком или без них. Некоторые пограничные комбинированные устройства включают в себя маршрутизатор, брандмауэр, средства управления пропускной способностью и функции VPN (а также режим конфигурации). Наконец, ряд чисто программных продуктов выполня­ется на соответствующих серверах, кэширует страницы Web, реализует функции брандмау­эра и VPN.</p> <p>Механизм VPN немыслим без идентификации. Инфраструктура с открытыми ключами (Public Key Infrastructure, PKI) для электронной идентификации и управления открытыми ключами является в настоящее время основной. Данные PKI целесообразнее всего хранить в глобальном каталоге, обращаться к которому можно по упрощенному протоколу доступа к каталогу (Lightweight Directory Access Protocol, LDAP).</p> <p> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <table class=msonormaltable border=0 cellspacing=0 cellpadding=0 style='margin-left:2.0pt;border-collapse:collapse;mso-padding-alt:0cm 2.0pt 0cm 2.0pt'> <tr> <td> <p>Категория системы</p> </td> <td> <p>Достоинства</p> </td> <td> <p>Недостатки</p> </td> </tr> <tr> <td> <p>Программное обеспечение VPN для брандмауэров</p> </td> <td> <p>Общее администрирование VPN. Если VPN должны завершаться вне бранд­мауэра, то канал между окончанием туннеля и брандмауэром может стать уязвимым звеном в системе <i>защиты</i>. При повышении производительности серверных продуктов аппаратное обес­печение потребуется модернизировать.</p> <p>Как и любая другая вычислительная функция, работа по созданию <strong>сетей</strong> VPN прово­дится с помощью программного обеспечения. Между тем программное обеспечение для VPN может выполняться на самых разных аппаратных платформах. Маршрутизаторы или комму­таторы третьего уровня могут поддерживать функции VNP по умолчанию (или в качестве дополнительной возможности, предлагаемой за отдельную плату). Аппаратно и программно реализуемые брандмауэры нередко предусматривают модули VPN со средствами управления трафиком или без них. Некоторые пограничные комбинированные устройства включают в себя маршрутизатор, брандмауэр, средства управления пропускной способностью и функции VPN (а также режим конфигурации). Наконец, ряд чисто программных продуктов выполня­ется на соответствующих серверах, кэширует страницы Web, реализует функции брандмау­эра и VPN.</p> <p>Механизм VPN немыслим без идентификации. Инфраструктура с открытыми ключами (Public Key Infrastructure, PKI) для электронной идентификации и управления открытыми ключами является в настоящее время основной. Данные PKI целесообразнее всего хранить в глобальном каталоге, обращаться к которому можно по упрощенному протоколу доступа к каталогу (Lightweight Directory Access Protocol, LDAP).</p> <p> <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <table class=msonormaltable border=0 cellspacing=0 cellpadding=0 style='margin-left:2.0pt;border-collapse:collapse;mso-padding-alt:0cm 2.0pt 0cm 2.0pt'> <tr> <td> <p>Категория системы</p> </td> <td> <p>Достоинства</p> </td> <td> <p>Недостатки</p> </td> </tr> <tr> <td> <p>Программное обеспечение VPN для брандмауэров</p> </td> <td> <p>Общее администрирование VPN. Если VPN должны завершаться вне бранд­мауэра, то канал между окончанием туннеля и брандмауэром может стать уязвимым звеном в системе <i>защиты</i>. При повышении производительности серверных продуктов аппаратное обес­печение потребуется модернизировать.</p> 8.8. Обеспечение безопасности IP-телефонии на базе VPN - Часть 3 2011-10-18T03:04:00+04:00 2011-10-18T03:04:00+04:00 /books/ip-telephony/75-ip2/1135-8-8-obespechenie-bezopasnosti-ip-telefonii-na-baze-vpn-chast-3 <p>Шифрование информации, передаваемой между инициатором и терминатором тунне­ля, часто осуществляется с помощью защиты транспортного уровня (Transport Layer Security, TLS), ранее протокола защищенных сокетов (Secure Sockets Layer, SSL). Для стандартизации аутентифицированного прохода через брандмауэры IETF определил протокол под названием SOCKS, и в настоящее время SOCKS 5 применяется для стандартизованной реализации по­средников каналов.</p> <p>В SOCKS 5 клиентский компьютер устанавливает аутентифицированный сокет (или сеанс) с сервером, выполняющим роль посредника (proxy). Этот посредник - единственный способ связи через брандмауэр. Посредник, в свою очередь, проводит любые операции, за­прашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сокета, он мо­жет осуществлять тщательный контроль, например, блокировать конкретные приложения пользователей, если они не имеют необходимых полномочий. Для сравнения, виртуальные частные <em>сети</em> уровня 2 и 3 обычно просто открывают или закрывают канал для всего трафика по аутентифицированному туннелю. Это может представлять проблему, если нет гарантии защиты информации на другом конце туннеля.</p> <p>Следует отметить на наличие взаимосвязи между брандмауэрами и VPN. Если туннели завершаются на оборудовании провайдера Интернет, то трафик будет передаваться по вашей локальной сети или по линии связи с провайдером Интернет в незащищенном виде. Если конечная точка расположена за брандмауэром, то туннелируемый трафик можно контроли­ровать с помощью средств <strong>контроля</strong> доступа брандмауэра, но никакой дополнительной за­щиты при передаче по локальной сети это не даст. В этом случае конечную точку будет свя­зывать с брандмауэром незащищенный канал.</p> <p>Расположение конечной точки внутри защищаемой брандмауэром зоны обычно озна­чает открытие прохода через брандмауэр (как правило, через конкретный порт TCP). Некото­рые компании предпочитают применять реализуемый брандмауэром контроль доступа ко всему трафику, в том числе и к туннелируемому, особенно если другую сторону туннеля представляет пользователь, стратегия <strong>защиты</strong> которого неизвестна или не внушает доверия. Одно из преимуществ применения тесно интегрированных с брандмауэром продуктов тунне-лирования состоит в том, что можно открывать туннель, применять к нему правила защиты брандмауэра и перенаправлять трафик на конечную точку на конкретном компьютере или в защищаемой брандмауэром подсети.</p> <p>Шифрование информации, передаваемой между инициатором и терминатором тунне­ля, часто осуществляется с помощью защиты транспортного уровня (Transport Layer Security, TLS), ранее протокола защищенных сокетов (Secure Sockets Layer, SSL). Для стандартизации аутентифицированного прохода через брандмауэры IETF определил протокол под названием SOCKS, и в настоящее время SOCKS 5 применяется для стандартизованной реализации по­средников каналов.</p> <p>В SOCKS 5 клиентский компьютер устанавливает аутентифицированный сокет (или сеанс) с сервером, выполняющим роль посредника (proxy). Этот посредник - единственный способ связи через брандмауэр. Посредник, в свою очередь, проводит любые операции, за­прашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сокета, он мо­жет осуществлять тщательный контроль, например, блокировать конкретные приложения пользователей, если они не имеют необходимых полномочий. Для сравнения, виртуальные частные <em>сети</em> уровня 2 и 3 обычно просто открывают или закрывают канал для всего трафика по аутентифицированному туннелю. Это может представлять проблему, если нет гарантии защиты информации на другом конце туннеля.</p> <p>Следует отметить на наличие взаимосвязи между брандмауэрами и VPN. Если туннели завершаются на оборудовании провайдера Интернет, то трафик будет передаваться по вашей локальной сети или по линии связи с провайдером Интернет в незащищенном виде. Если конечная точка расположена за брандмауэром, то туннелируемый трафик можно контроли­ровать с помощью средств <strong>контроля</strong> доступа брандмауэра, но никакой дополнительной за­щиты при передаче по локальной сети это не даст. В этом случае конечную точку будет свя­зывать с брандмауэром незащищенный канал.</p> <p>Расположение конечной точки внутри защищаемой брандмауэром зоны обычно озна­чает открытие прохода через брандмауэр (как правило, через конкретный порт TCP). Некото­рые компании предпочитают применять реализуемый брандмауэром контроль доступа ко всему трафику, в том числе и к туннелируемому, особенно если другую сторону туннеля представляет пользователь, стратегия <strong>защиты</strong> которого неизвестна или не внушает доверия. Одно из преимуществ применения тесно интегрированных с брандмауэром продуктов тунне-лирования состоит в том, что можно открывать туннель, применять к нему правила защиты брандмауэра и перенаправлять трафик на конечную точку на конкретном компьютере или в защищаемой брандмауэром подсети.</p> 8.8. Обеспечение безопасности IP-телефонии на базе VPN - Часть 2 2011-10-04T05:12:00+04:00 2011-10-04T05:12:00+04:00 /books/ip-telephony/75-ip2/1134-8-8-obespechenie-bezopasnosti-ip-telefonii-na-baze-vpn-chast-2 <p>Компания Cisco Systems разработала протокол пересылки на втором уровне модели OSI (Layer-2 Forwarding, L2F), с помощью которой удаленные клиенты могут связаться по каналам провайдера Internet и быть идентифицированы. При этом ISP не нужно осуществ­лять конфигурацию адресов и выполнять идентификацию. Протокол L2F стал компонентом операционной системы IOS (Internetwork Operating System) компании Cisco и поддерживает­ся во всех выпускаемых ею устройствах межсетевого взаимодействия и удаленного доступа.</p> <p>Оба этих тесно связанных друг с другом протокола IETF были объединены, и полу­чившийся в результате протокол, включивший лучшее из РРТР и L2F, называется протоко­лом туннелирования второго уровня (Layer-2 Tunneling Protocol, L2TP). Его поддерживают компании Cisco, Microsoft, 3Com, Ascend и многие другие производители. Как и предшест­вующие протоколы второго уровня, спецификация L2TP не описывает методы идентифика­ции и шифрования.</p> <p>Спецификацией IETF, где описаны стандартные методы для всех компонентов VPN, является протокол Internet Protocol Security, или IPSec, - иногда его называют туннелирова-нием третьего уровня (Layer-3 Tunneling). IPSec предусматривает стандартные методы иден­тификации пользователей или компьютеров при инициации туннеля, стандартные способы использования шифрования конечными точками туннеля, а также стандартные методы обме­на и управления ключами шифрования между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для од­ной задачи обычно не зависят от методов реализации других задач. Идентификацию можно выполнять с помощью спецификации IPSec, причем она является обязательным компонентом протокола IPv6.</p> <p>IPSec может работать совместно с L2TP, в результате эти два протокола обеспечивают более надежную идентификацию, стандартизованное шифрование и целостность данных. Следует отметить, что спецификация IPSec ориентирована на IP и, таким образом, бесполез­на для трафика любых других протоколов <i>сетевого</i> уровня. Туннель IPSec между двумя ло­кальными <b>сетями</b> может поддерживать множество индивидуальных каналов передачи дан­ных, в результате чего приложения данного типа получают преимущества с точки зрения масштабирования по сравнению с технологией второго уровня.</p> <p>Некоторые поставщики VPN используют другой подход под названием «посредники каналов» (circuit proxy), или VPN пятого уровня. Этот метод функционирует над транспорт­ным уровнем и ретранслирует трафик из защищенной сети в общедоступную <i>сеть</i> Internet для каждого сокета в отдельности. (Сокет IP идентифицируется комбинацией TCP-соединения и конкретного порта или заданным портом UDP. Протокол IP не имеет пятого - сеансового - уровня, однако ориентированные на сокеты операции часто называют операциями сеансово­го уровня.)</p> <p>Компания Cisco Systems разработала протокол пересылки на втором уровне модели OSI (Layer-2 Forwarding, L2F), с помощью которой удаленные клиенты могут связаться по каналам провайдера Internet и быть идентифицированы. При этом ISP не нужно осуществ­лять конфигурацию адресов и выполнять идентификацию. Протокол L2F стал компонентом операционной системы IOS (Internetwork Operating System) компании Cisco и поддерживает­ся во всех выпускаемых ею устройствах межсетевого взаимодействия и удаленного доступа.</p> <p>Оба этих тесно связанных друг с другом протокола IETF были объединены, и полу­чившийся в результате протокол, включивший лучшее из РРТР и L2F, называется протоко­лом туннелирования второго уровня (Layer-2 Tunneling Protocol, L2TP). Его поддерживают компании Cisco, Microsoft, 3Com, Ascend и многие другие производители. Как и предшест­вующие протоколы второго уровня, спецификация L2TP не описывает методы идентифика­ции и шифрования.</p> <p>Спецификацией IETF, где описаны стандартные методы для всех компонентов VPN, является протокол Internet Protocol Security, или IPSec, - иногда его называют туннелирова-нием третьего уровня (Layer-3 Tunneling). IPSec предусматривает стандартные методы иден­тификации пользователей или компьютеров при инициации туннеля, стандартные способы использования шифрования конечными точками туннеля, а также стандартные методы обме­на и управления ключами шифрования между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для од­ной задачи обычно не зависят от методов реализации других задач. Идентификацию можно выполнять с помощью спецификации IPSec, причем она является обязательным компонентом протокола IPv6.</p> <p>IPSec может работать совместно с L2TP, в результате эти два протокола обеспечивают более надежную идентификацию, стандартизованное шифрование и целостность данных. Следует отметить, что спецификация IPSec ориентирована на IP и, таким образом, бесполез­на для трафика любых других протоколов <i>сетевого</i> уровня. Туннель IPSec между двумя ло­кальными <b>сетями</b> может поддерживать множество индивидуальных каналов передачи дан­ных, в результате чего приложения данного типа получают преимущества с точки зрения масштабирования по сравнению с технологией второго уровня.</p> <p>Некоторые поставщики VPN используют другой подход под названием «посредники каналов» (circuit proxy), или VPN пятого уровня. Этот метод функционирует над транспорт­ным уровнем и ретранслирует трафик из защищенной сети в общедоступную <i>сеть</i> Internet для каждого сокета в отдельности. (Сокет IP идентифицируется комбинацией TCP-соединения и конкретного порта или заданным портом UDP. Протокол IP не имеет пятого - сеансового - уровня, однако ориентированные на сокеты операции часто называют операциями сеансово­го уровня.)</p> 8.8. Обеспечение безопасности IP-телефонии на базе VPN - Часть 1 2011-09-30T17:30:00+04:00 2011-09-30T17:30:00+04:00 /books/ip-telephony/75-ip2/1133-8-8-obespechenie-bezopasnosti-ip-telefonii-na-baze-vpn-chast-1 <p>Одним из механизмов обеспечения безопасности IP-телефонии может быть использо­вание виртуальных частных сетей (Virtual Private Network, VPN).</p> <p>Сети VPN создаются, как правило, для решения двух задач. Во-первых, они служат для организации взаимодействия индивидуальных пользователей с удаленной сетью через Интернет, а во-вторых, - для связи двух сетей. В первом случае, они используются в качестве альтернативы удаленному доступу. Вместо того, чтобы устанавливать соединение с корпора­тивной средой по междугородной или международной связи, пользователи локально под­ключаются к Интернет и связываются с сетью компании. Во втором - они часто применяют­ся для организации так называемых виртуальных выделенных линий.</p> <p>Виртуальная частная <b>сеть</b> (VPN) создается между инициатором туннеля и терминато­ром туннеля. Обычная маршрутизируемая <i>сеть</i> IP (она не обязательно включает в себя обще­доступную сеть Интернет ) определяет маршрут между инициатором и терминатором. Ини­циатор туннеля инкапсулирует пакеты в новый пакет, содержащий наряду с исходными дан­ными новый заголовок с информацией об отправителе и получателе. Хотя все передаваемые по туннелю пакеты являются пакетами IP, в принципе, инкапсулируемые пакеты могут при­надлежать к протоколу любого типа, включая пакеты немаршрутизируемых протоколов, на­пример, NetBEUI. Терминатор туннеля выполняет процесс, обратный инкапсуляции, удаляя новые заголовки и направляя исходный пакет в локальный стек протоколов или адресату в локальной сети.</p> <br/> <p>Сама по себе инкапсуляция никоим образом не повышает конфиденциальности или целостности туннелируемых данных. Конфиденциальность обеспечивается с помощью шиф­рования. Поскольку методов шифрования данных существует множество, очень важно, что­бы инициатор и терминатор туннеля использовали один и тот же метод. Кроме того, для ус­пешного дешифрования данных они должны иметь возможность обмена ключами. Чтобы туннели создавались только между уполномоченными пользователями, конечные точки тре­буется идентифицировать. Целостность туннелируемых данных можно обеспечить с помо­щью некоей формы выборки сообщения или хэш-функции для выявления изменений или удалений.</p> <p>Для реализации унифицированного способа инкапсуляции трафика третьего уровня (и более высоких уровней) на клиентах и серверах Windows компании Microsoft, Ascend Communications и 3Com разработали туннельный протокол между двумя точками (Pointto-Point Tunneling Protocol, РРТР), представляющий собой расширение протокола РРР. В РРТР не специфицируется конкретный метод шифрования, однако, клиенты удаленного доступа в Windows NT 4.0 и Windows 95 с Dial-Up Networking 1.2 поставляются с версией шифрования DES компании RSA Data Security, получившей название «шифрование двухточечной связи Microsoft)) (Microsoft Point-to-Point Encryption, MPPE).</p> <p>Одним из механизмов обеспечения безопасности IP-телефонии может быть использо­вание виртуальных частных сетей (Virtual Private Network, VPN).</p> <p>Сети VPN создаются, как правило, для решения двух задач. Во-первых, они служат для организации взаимодействия индивидуальных пользователей с удаленной сетью через Интернет, а во-вторых, - для связи двух сетей. В первом случае, они используются в качестве альтернативы удаленному доступу. Вместо того, чтобы устанавливать соединение с корпора­тивной средой по междугородной или международной связи, пользователи локально под­ключаются к Интернет и связываются с сетью компании. Во втором - они часто применяют­ся для организации так называемых виртуальных выделенных линий.</p> <p>Виртуальная частная <b>сеть</b> (VPN) создается между инициатором туннеля и терминато­ром туннеля. Обычная маршрутизируемая <i>сеть</i> IP (она не обязательно включает в себя обще­доступную сеть Интернет ) определяет маршрут между инициатором и терминатором. Ини­циатор туннеля инкапсулирует пакеты в новый пакет, содержащий наряду с исходными дан­ными новый заголовок с информацией об отправителе и получателе. Хотя все передаваемые по туннелю пакеты являются пакетами IP, в принципе, инкапсулируемые пакеты могут при­надлежать к протоколу любого типа, включая пакеты немаршрутизируемых протоколов, на­пример, NetBEUI. Терминатор туннеля выполняет процесс, обратный инкапсуляции, удаляя новые заголовки и направляя исходный пакет в локальный стек протоколов или адресату в локальной сети.</p> <br/> <p>Сама по себе инкапсуляция никоим образом не повышает конфиденциальности или целостности туннелируемых данных. Конфиденциальность обеспечивается с помощью шиф­рования. Поскольку методов шифрования данных существует множество, очень важно, что­бы инициатор и терминатор туннеля использовали один и тот же метод. Кроме того, для ус­пешного дешифрования данных они должны иметь возможность обмена ключами. Чтобы туннели создавались только между уполномоченными пользователями, конечные точки тре­буется идентифицировать. Целостность туннелируемых данных можно обеспечить с помо­щью некоей формы выборки сообщения или хэш-функции для выявления изменений или удалений.</p> <p>Для реализации унифицированного способа инкапсуляции трафика третьего уровня (и более высоких уровней) на клиентах и серверах Windows компании Microsoft, Ascend Communications и 3Com разработали туннельный протокол между двумя точками (Pointto-Point Tunneling Protocol, РРТР), представляющий собой расширение протокола РРР. В РРТР не специфицируется конкретный метод шифрования, однако, клиенты удаленного доступа в Windows NT 4.0 и Windows 95 с Dial-Up Networking 1.2 поставляются с версией шифрования DES компании RSA Data Security, получившей название «шифрование двухточечной связи Microsoft)) (Microsoft Point-to-Point Encryption, MPPE).</p> Функции безопасности Функции обслуживания вызовов RAS Н.225.0 Н.245 Аутентификация Цифровая подпись SHA1/MD5 (Процедура А) Цифровая подпись SHA1/MD5 (Процедура А) Цифровая подпись SHA1/MD5 (Процедура А) Отказ при Наличии Долгов Цифровая подпись SHA1/MD5 ( 2011-09-23T22:21:00+04:00 2011-09-23T22:21:00+04:00 /books/ip-telephony/75-ip2/1132-funkcii-bezopasnosti-funkcii-obsluzhivaniya-vyzovov-ras-n-225-0-n-245-autentifikaciya-cifrovaya-podpis-sha1-md5-procedura-a-cifrovaya-podpis-sha1-md5-procedura-a-cifrovaya-podpis-sha1-md5-procedura-a-otkaz-pri-nalichii-dolgov-cifrovaya-podpis-sha1-md5-pro <p></p> <p></p> Функции безопасности Функции обслуживания вызовов RAS Н.225.0 Н.245 Аутентификация Цифровая подпись SHA1/MD5 (Процедура А) Цифровая подпись SHA1/MD5 (Процедура А) Цифровая подпись SHA1/MD5 (Процедура А) Отказ при Наличии Долгов Цифровая подпись SHA1/MD5 ( 2011-08-13T12:59:00+04:00 2011-08-13T12:59:00+04:00 /books/ip-telephony/75-ip2/1131-funkcii-bezopasnosti-funkcii-obsluzhivaniya-vyzovov-ras-n-225-0-n-245-autentifikaciya-cifrovaya-podpis-sha1-md5-procedura-a-cifrovaya-podpis-sha1-md5-procedura-a-cifrovaya-podpis-sha1-md5-procedura-a-otkaz-pri-nalichii-dolgov-cifrovaya-podpis-sha1-md5-pro <p>Компании 3Com, Cisco Systems, GRIC Communications, iPass и TransNexus сообщили о поддержке предварительного стандарта IP-телефонии - Open Settlement Protocol (OSP), - ко­торый предназначен для решения вопросов взаимодействия <b>сетей</b> различных провайдеров.</p> <p>Это простой протокол, позволяющий различным компаниям - владельцам средств свя­зи осуществлять коммуникации в пределах всей страны. К примеру, он позволяет устанавли­вать автора звонка, санкционировать обслуживание вызова и указывать расчетную информа­цию, которая будет включена в записи, содержащие подробные данные об этой транзакции (рис. 8.5).</p> <p>Рабочая группа института European Telecommunications Standards Institute (ETSI) одоб­рила этот протокол, а производители в ближайшее время намерены провести его тестирова­ние. Новый протокол был разработан в рамках проекта TIPHON. Протоколу OSP еще пред­стоит пройти процедуру окончательной ратификации. Однако ведущие компании, предос­тавляющие услуги IP-телефонии, включая Ascend, GTE, AT&amp;T и Internet Telephony Exchange Carrier (ITXC), уже заявили о поддержке протокола OSP. В то же время компании Lucent и Nortel выразили свою заинтересованность и в целом готовы поддержать стандарты на IP-телефонию, но от окончательной оценки OSP пока воздержалась.</p> <p>Основные характеристики спецификации Open Settlement Protocol (OSP):</p> <p>• шифрование Secure Sockets Layer;</p> <p>• безопасная аутентификация участников сеанса связи с помощью шифрования откры­тым и частным ключами;</p> <p>• поддержка технологии цифровой подписи;</p> <p>Обмен информацией с помощью XML. <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p></p> </td> </tr> </table> <img src="//images/stories/knigi/ip-phone/image138.gif" alt="подпись: " align="left" width="485" height="206" class=""/>Провайдера А провайдера В</p> <p></p> <p>Рис. 8.5. Использование протокола OSP</p> <p>При условии внедрения единого способа выполнения аутентификации и обеспечения взаимосвязи различных сетей значительно упростится задача выбора провайдера услуг IP-телефонии. В настоящее время ни один провайдер не может пока предлагать свои услуги во всех регионах, а стандартный подход позволит им обеспечить более «прозрачные» службы и в более широкой географической области. Однако при этом возникает целый ряд вопросов. В частности, пока не установлено, каким образом <b>сети</b> будут взаимодействовать друг с другом на уровне расчетов, то есть не определено, как именно передавать между <b>сетями</b> данные о распределении прибыли при обмене.</p> <p>Компании 3Com, Cisco Systems, GRIC Communications, iPass и TransNexus сообщили о поддержке предварительного стандарта IP-телефонии - Open Settlement Protocol (OSP), - ко­торый предназначен для решения вопросов взаимодействия <b>сетей</b> различных провайдеров.</p> <p>Это простой протокол, позволяющий различным компаниям - владельцам средств свя­зи осуществлять коммуникации в пределах всей страны. К примеру, он позволяет устанавли­вать автора звонка, санкционировать обслуживание вызова и указывать расчетную информа­цию, которая будет включена в записи, содержащие подробные данные об этой транзакции (рис. 8.5).</p> <p>Рабочая группа института European Telecommunications Standards Institute (ETSI) одоб­рила этот протокол, а производители в ближайшее время намерены провести его тестирова­ние. Новый протокол был разработан в рамках проекта TIPHON. Протоколу OSP еще пред­стоит пройти процедуру окончательной ратификации. Однако ведущие компании, предос­тавляющие услуги IP-телефонии, включая Ascend, GTE, AT&amp;T и Internet Telephony Exchange Carrier (ITXC), уже заявили о поддержке протокола OSP. В то же время компании Lucent и Nortel выразили свою заинтересованность и в целом готовы поддержать стандарты на IP-телефонию, но от окончательной оценки OSP пока воздержалась.</p> <p>Основные характеристики спецификации Open Settlement Protocol (OSP):</p> <p>• шифрование Secure Sockets Layer;</p> <p>• безопасная аутентификация участников сеанса связи с помощью шифрования откры­тым и частным ключами;</p> <p>• поддержка технологии цифровой подписи;</p> <p>Обмен информацией с помощью XML. <table cellpadding=0 cellspacing=0 width="100%"> <tr> <td> <p></p> </td> </tr> </table> <img src="//images/stories/knigi/ip-phone/image138.gif" alt="подпись: " align="left" width="485" height="206" class=""/>Провайдера А провайдера В</p> <p></p> <p>Рис. 8.5. Использование протокола OSP</p> <p>При условии внедрения единого способа выполнения аутентификации и обеспечения взаимосвязи различных сетей значительно упростится задача выбора провайдера услуг IP-телефонии. В настоящее время ни один провайдер не может пока предлагать свои услуги во всех регионах, а стандартный подход позволит им обеспечить более «прозрачные» службы и в более широкой географической области. Однако при этом возникает целый ряд вопросов. В частности, пока не установлено, каким образом <b>сети</b> будут взаимодействовать друг с другом на уровне расчетов, то есть не определено, как именно передавать между <b>сетями</b> данные о распределении прибыли при обмене.</p> 8.6. Механизмы безопасности в проекте TIPHON 2011-07-28T00:36:00+04:00 2011-07-28T00:36:00+04:00 /books/ip-telephony/75-ip2/1130-8-6-mexanizmy-bezopasnosti-v-proekte-tiphon <p>В проект TIPHON включены следующие механизмы <b>защиты</b> для обеспечения безопас­ной телефонной связи с конечных устройств, основанные на приложении J Рекомендации ITU-T Н.323:</p> <p>• механизм защиты, основанный на цифровых сертификатах (CBSP);</p> <p>• механизм защиты, основанный на паролях (PBSP);</p> <p>• механизм защиты, основанный на шифровании информации.</p> <p>Основным механизмом защиты является использование цифровых сертификатов. Реа­лизация функций безопасности в данном механизме показана в табл. 8.1. В тех странах, где технология CBSP не реализована, должен использоваться механизм на базе паролей. Однако следует отметить, что PBSP является самым простым механизмом и не обеспечивает уровень <i>защиты</i>, реализуемый при использовании CBSP.</p> <p>Криптографическая <em>защита</em> информации является необязательным требованием и ис­пользуется только в сценариях, когда необходимо обеспечить секретность передаваемой ин­формации. Оба механизма CBSP и PBSP используют модель безопасности при маршрутиза­ции через шлюз на базе Приложения F Рекомендации Н.323.</p> <p>В проект TIPHON включены следующие механизмы <b>защиты</b> для обеспечения безопас­ной телефонной связи с конечных устройств, основанные на приложении J Рекомендации ITU-T Н.323:</p> <p>• механизм защиты, основанный на цифровых сертификатах (CBSP);</p> <p>• механизм защиты, основанный на паролях (PBSP);</p> <p>• механизм защиты, основанный на шифровании информации.</p> <p>Основным механизмом защиты является использование цифровых сертификатов. Реа­лизация функций безопасности в данном механизме показана в табл. 8.1. В тех странах, где технология CBSP не реализована, должен использоваться механизм на базе паролей. Однако следует отметить, что PBSP является самым простым механизмом и не обеспечивает уровень <i>защиты</i>, реализуемый при использовании CBSP.</p> <p>Криптографическая <em>защита</em> информации является необязательным требованием и ис­пользуется только в сценариях, когда необходимо обеспечить секретность передаваемой ин­формации. Оба механизма CBSP и PBSP используют модель безопасности при маршрутиза­ции через шлюз на базе Приложения F Рекомендации Н.323.</p> 8.5. Обеспечение безопасности в системах. на базе стандарта Н.323 - Часть 2 2011-07-14T04:33:00+04:00 2011-07-14T04:33:00+04:00 /books/ip-telephony/75-ip2/1129-8-5-obespechenie-bezopasnosti-v-sistemax-na-baze-standarta-n-323-chast-2 <p>В целом следует отметить, что все основные механизмы аутентификации, определен­ные в Рекомендации Н.235, идентичны или получены из алгоритмов, разработанных Между­народной организации по стандартизации ISO, или основаны на протоколах IETF.</p> <p></p> <p>В целом следует отметить, что все основные механизмы аутентификации, определен­ные в Рекомендации Н.235, идентичны или получены из алгоритмов, разработанных Между­народной организации по стандартизации ISO, или основаны на протоколах IETF.</p> <p></p>