Новая версия протокола обеспечит связь с брандмауэрами пятого уровня
Эрик фон Швебер
Целевая группа инженерной поддержки Интернета утвердила протокол SOCKS 5 не так давно, но он уже подвергся серьезной критике. Главным недостатком этой спецификации, призванной обеспечить безопасную связь между различными сетями, считается излишняя избыточность. Многие из заложенных в ней функций сегодня выполняются, причем гораздо более эффективно, современными программными средствами, такими, как шлюзы приложений.
Ответом на подобные замечания стала разработка нового стандарта SOCKS, призванного разрешить целый ряд острых проблем. Ожидается, что очередная версия этого протокола сможет гарантировать высокую безопасность многоадресных передач без их преобразования в одноадресные; проложит путь через брандмауэры для вызовов CORBA (Common Object Request Broker Architecture - общая архитектура посредника запросов к объектам), используя для этого протокол IIOP (Internet Inter-ORB Protocol - межсетевой протокол связи между посредниками к объектам); обеспечит высокую гибкость аутентификации с применением протокола IPSec (IP Security - безопасность в IP-сетях).
Инженеры корпораций Microsoft, Intel, NEC и Aventail уже предложили целый ряд расширений к спецификации SOCKS 5. Сейчас рассматривается вопрос об организации рабочей группы SOCKS 6, в задачи которой войдет совершенствование функций управления, регистрации и анализа, заложенных в этот стандарт, а также повышение его производительности.
Корпорация Aventail уже планирует включить некоторые опции SOCKS 6 в версию 3.0 своего клиентского и серверного ПО SOCKS, выпуск которой ожидается в конце нынешнего года. Сюда, в частности, войдет поддержка протокола UDP (User Datagram Protocol - протокол дейтаграмм пользователя) и группового вещания, а также функция автоматического определения многоадресных передач, которая должна намного упростить конфигурирование системы.
Что такое SOCKS?
SOCKS (сокращение от “sockets” - гнезда) представляет собой брандмауэрную технологию, относящуюся к уровню 5 (сеансовому) иерархической модели OSI. Именно этим данный протокол отличается от систем фильтрации пакетов и маршрутизаторов, где решение на ретрансляцию пакета принимается с учетом информации уровня 3. Не похож он и на шлюзы приложений, выполняющие роль посредника между клиентскими и серверными приложениями. Здесь учитывается информация как о пользователе, так и о приложении, но обмен сетевыми данными между ними не производится.
К тому же шлюз приложений способен обслуживать лишь системы конкретного типа, например электронную почту, средства просмотра Web-узлов или клиент-серверного подключения к базам данных, тогда как серверу SOCKS достаточно знать только адрес хоста получателя и его порт. Благодаря проведению согласования с клиентским приложением и аутентификации пользователей на пятом уровне на работу сервера SOCKS не влияют ни вид приложения, ни применяемые протоколы. По сравнению с фильтрацией пакетов SOCKS обеспечивает гораздо большую безопасность, ведь в первом случае во внимание принимаются только IP-адреса отправителя и получателя, тогда как во втором производится полная аутентификация пользователя.
Когда дело доходит до защиты многоадресных передач, выбор у сетевого администратора оказывается весьма ограниченным. Ему приходится либо забыть о требованиях безопасности (то есть не учитывать ни того, на какой именно порт, отправляется сообщение, ни того, что за пользователь его запросил), либо ретранслировать групповой трафик в одноадресном режиме.
Ни одну из таких перспектив привлекательной не назовешь. Мало добиться четкого контроля над проведением конференций и гарантировать безопасность информации в масштабах всей группы - нужно еще обеспечить эффективную доставку всех сообщений. Для решения этой проблемы исследовательский центр Intel Architecture Labs предложил многоадресное UDP-расширение для SOCKS 5, позволяющее следить за составом группы и определять, какие каналы доступны тому или иному пользователю.
Предложение Intel дает возможность подключаться к телеконференции и передавать свои сообщения лишь тем пользователям, которые прошли аутентификацию и получили соответствующее разрешение. Данная схема предусматривает фильтрацию пакетов на основе групповых IP-адресов и портов, а также ведение подробного контрольного журнала. Развернув такие многоадресные расширения, администратор сможет ограничить права отдельных пользователей только прослушиванием многоадресных каналов или разрешить им передавать по ним собственные сообщения. Кроме того, появляется возможность регулировать полосу пропускания, отводимую для потока многоадресных данных.
При таком подходе сервер SOCKS производит фильтрацию трафика с учетом групповых адресов и портов, блокируя его передачу в те группы, где может производиться скрытое подслушивание одноадресных передач. При необходимости сервер SOCKS и здесь может преобразовать групповую передачу в одноадресную, что еще больше повысит защищенность информации.
Проект спецификации, обеспечивающий поддержку этих функций, уже внесен на рассмотрение рабочей группы Authenticated Firewall Traversal (аутентифицированный проход через брандмауэры) Целевой группы инженерной поддержки Интернета. А корпорация Intel, не дожидаясь решения этого органа, уже предложила практическую реализацию SOCKS, в которой пока поддерживаются только многоадресные передачи на клиентах Windows 95 и Windows NT, а также на сервере-посреднике для NT.
Созданный прототип SOCKS уже проверен в работе с готовыми многоадресными приложениями, в том числе IP/TV фирмы Precept Software, и Intel выразила готовность лицензировать свою технологию. Но инициатива этой корпорации в области стандартизации SOCKS не снижает активности других разработчиков. Так, фирма Trusted Information Systems предложила собственный метод, позволяющий шлюзам приложений выполнять такие же функции. Что ж, нам остается только ждать, кто из разработчиков первым выйдет на рынок с готовыми продуктами.
Путь через брандмауэр
Спецификация SOCKS поможет решить и проблему протоколов, работающих поверх TCP/IP, непосредственную поддержку которых не закладывают в свои продукты ни производители брандмауэров, ни разработчики шлюзов приложений. Наглядным примером такого протокола может служить CORBA IIOP.
По мере того как вычисления с использованием распределенных объектов выходят за рамки корпоративной интрасети, перед разработчиками возникает новая проблема: как пропустить через брандмауэр удаленные вызовы к объектам, лежащим позади него? Установить простой фильтр IIOP для конкретного порта невозможно, так как порты IIOP распределяются динамически. А бесконтрольный пропуск запросов CORBA через брандмауэр открывает доступ ко всем объектам на удаленном сервере, создавая серьезную угрозу безопасности целой системы.
Здесь на помощь приходит SOCKS. Функционируя на сеансовом уровне, этот протокол анализирует IIOP-трафик примерно так же, как обрабатываются НТТР-сообщения на серверах-посредниках. Конечно, существуют и другие решения этой проблемы, но они не столь универсальны. Скажем, пакет Wonderwall фирмы Iona Technologies совместим только с продуктами этого же производителя, а рекомендации по туннелированию, которые предлагает корпорация Inprise, могут затруднить поиск объектов.
SOCKS 6 должен также способствовать распространению протокола IPSec. Продукты, поддерживающие шестую версию этой спецификации, смогут взять на себя роль шлюза между сетями, где для аутентификации пользователя и шифрования применяется протокол IPSec, и сетями, где он не поддерживается. Благодаря этому удастся обеспечить софункционирование сетей, столь необходимое для широкомасштабного внедрения технологии IPSec.
Кроме того, SOCKS 6 сможет дополнить IPSec в области преобразования сетевых адресов. Такая функция в протоколе безопасности отсутствует (и никогда не будет введена в него), поскольку все используемые адреса здесь шифруются. Но при пересылке пакетов получатель SOCKS вполне может обойтись без адреса, ему достаточно знать имя хост-компьютера, а во фрагментированном пространстве имен никаких проблем с использованием перекрывающихся IP-адресов не возникает.
Ожидается, что SOCKS 6 повысит качество администрирования, отчетности и анализа в сетевых структурах. Одно из предложенных расширений должно обеспечить серверное управление политикой безопасности и частично автоматизировать настройку клиента. Предполагается также стандартизировать базы управляющей информации MIB для хранения правил обеспечения безопасности SOCKS.
Сегодня SOCKS 5 способен учитывать количество байтов, но для имен файлов и локаторов URL требуется анализ прикладного протокола, который невозможно произвести на сеансовом уровне. Чтобы решить эту проблему, корпорация Aventail не только включила в свой сервер SOCKS фильтр НТТР, но и построила его на базе подключаемой архитектуры, позволяющей потребителю самостоятельно создавать фильтры для других протоколов.
Версия SOCKS 6 может обеспечить и более высокую производительность, так как в нее, по всей вероятности, будет заложена возможность мультиплексирования подключений между серверами SOCKS.
Эрик фон Швебер - руководитель научно-исследовательской организации Infomaniacs (Сидона, шт. Аризона), которая специализируется в области конвергенции технологий. Связаться с ним можно по адресу: thinktank@infomaniacs.com или через Интернет: www.infomaniacs.com.
Что нового несет пользователям SOCKS 6?
- Обеспечивает безопасную многоадресную передачу информации с возможностью возврата к одноадресной
- Открывает для вызовов CORBA путь через брандмауэры, не нанося при этом урона безопасности системы
- Создает безопасные шлюзы между сетями, где поддерживается протокол IPSec и где его поддержка отсутствует
- Производит преобразование сетевых адресов в рамках протокола IPSec
- Дает возможность применять базы управляющей информации для обеспечения политики безопасности
- Обеспечивает полуавтоматическую настройку клиентов SOCKS
- Повышает производительность системы за счет мультиплексирования подключений между серверами SOCKS
- Поддерживается такими производителями, как NEC, Intel, Microsoft и Aventail
