Nova
13.07.2006, 15:10
1. Введение
Использование сетевых файрволов и систем, эффективно скрывающих
организацию внутренней сетевой структуры от внешней сети, такой
как Интернет, становится все более популярным. Эти файрволы обычно
работают как гэйтэвэи прикладного уровня между сетями, предлагая
обычно администрируемый TELNET, FTP, и SMTP доступ. С появлением
более сложных протоколов прикладного уровня предназначенных для
облегчения глобального информационного взаимодействия, появилась
потребность в обеспечении общей основы для прозрачной и безопасной
работы через файрволл для этих протоколов.
Leech, et al Standards Track [Страница 1]
RFC 1928 Протокол SOCKS 5 Март 1996
Существует также необходимость в строгой аутентификации при работе через
файрволл, в некоторой степени похожей на используемые сейчас методы. Это
требование обусловлено тем, что отношения типа клиент-сервер появляются
между сетями различных организаций, и эти отношения должны быть
управляемыми и, зачастую, строго аутентифицированны.
Описываемый здесь протокол разработан чтобы обеспечить основу для
удобного и безопасного использования сервиса сетевых файрволов для
приложений типа клиент-сервер работающих по протоколам TCP и UDP.
Протокол представляет собой "уровень-прокладку" между прикладным
уровнем и транспортным уровнем, и, как таковой, не обеспечивает
сервиса гэйтэвэев сетевого уровня, такого как пересылка пакетов ICMP.
2. Текущее положение дел
Существующий сейчас протокол, SOCKS v4, предназначен для работы через
файрволл без аутентификации для приложений типа клиент-сервер работающих
по протоколу TCP, таких как TELNET, FTP и таких популярных протоколов
обмена информацией, как HTTP, WAIS и GOPHER.
Новый протокол расширяет модель SOCKS v4 добавляя к ней поддержку UDP,
обеспечение универсальных схем строгой аутентификации и расширяет
методы адресации, добавляя поддержку доменных имен и адресов IP v6.
Реализация протокола SOCKS обычно влечет за собой перекомпиляцию или
пересборку клиентских программ, работающих по протоколу TCP, для
использования оответствующх функций SOCKS-библиотеки.
Замечание:
Если не оговорено обратное, десятичные числа в диаграммах формата
пакетов обозначают длинну соответствующего поля в октетах (8-битных
элементах). Если октет должен иметь определенное значение, используется
обозначение X'hh' для определения значения октета в данном поле.
Если используется слово 'Variable', это означает, что соответствующее
поле имеет переменную длинну, определяемую либо связанным (одно- или
двух-октетным) полем длинны, либо типом данных данного поля.
3. Процедура для клиентов работающих по TCP
Когда работающий по TCP клиент хочет соединиться с объектом, доступным
только через файрволл, он должен открыть TCP-соединение c
соответствующим SOCKS-портом SOCKS-сервера. Сервис SOCKS обычно
находится на TCP-порту 1080. Если соединение прошло успешно, клиент
начинает переговоры о методе аутентификации, который будет
Leech, et al Standards Track [Страница 2]
RFC 1928 Протокол SOCKS 5 Март 1996
использоваваться, проходит аутентификацию по выбранному методу и
посылает свой запрос. SOCKS-сервер обрабатывает запрос и либо
пытается установить соответствующее соединение, либо отказывает в нем.
Клиент соединяется с сервером и посылает сообщение с номером версии
и выбором соответствующего метода аутентификации:
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
Значение поля VER равно X'05' для данной версии протокола. Поле
NMETHODS содержит число октетов в идентификаторах методов авторизации
в поле METHODS.
Серевер выбирает один из предложенных методов, перечисленных в METHODS,
и послылает ответ о выбранном методе:
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
Если выбранный метод в METHOD равен X'FF', то ни один из предложенных
клиентом методов не применим и клиент должен закрыть соединение.
Эти значения определены для поля METHOD:
o X'00' аутентификация не требуется
o X'01' GSSAPI
o X'02' USERNAME/PASSWORD (см. RFC1929)
o X'03' до X'7F' зарезервировано IANA
o X'80' до X'FE' преднозначено для частных методов
o X'FF' нет применимых методов
Затем клиент и сервер начинают аутентификацию согласно выбранному методу.
Leech, et al Standards Track [Страница 3]
RFC 1928 Протокол SOCKS 5 Март 1996
Описание методов аутентификации находится в отдельных документах.
Разработчики новых методов аутентификации применимых для этого протокола
должны обращаться в IANA для получения номера метода. Документ с
выделеными номерами должен дополнить текущий список номеров и
соответствущих им методов аутентификации.
Совместимые реализации должны поддерживать GSSAPI и могут поддерживать
аутентификацию USERNAME/PASSWORD.
4. Запросы
После того как аутентификация выполнена, клиент посылает детали запроса.
Если выбранный метод аутентификации требует особое формирование пакетов
с целью проверки целостности и/или конфедициальности, запросы должны
инкапсулироваться в пакет, формат которого определяется выбранным
методом.
SOCKS-запрос формируется следующим образом:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Где:
o VER версия протокола: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV зарезервировано
o ATYP тип адреса, следующего вида:
o IP v4 адрес: X'01'
o имя домена: X'03'
o IP v6 адрес: X'04'
o DST.ADDR требуемый адрес
o DST.PORT требуемый порт (в сетевом порядке октетов)
SOCKS-сервер обрабатывает запрос на основании исходного и целевого
адресов и посылает одно или несколько сообщений в ответ, в соответствии
с типом запроса.
Leech, et al Standards Track [Страница 4]
RFC 1928 Протокол SOCKS 5 Март 1996
5. Адресация
Тип адреса содержащегося в адресном поле (DST.ADDR, BND.ADDR),
определяется содержимым поля ATYP:
o X'01'
адрес является адресом IP v4, длинна адреса 4 октета
o X'03'
поле адреса содержит имя домена. Первый октет адресного поля содержит
число октетов в последующем за ним имени, завершающий NUL-октет в конце
строки не применяется.
o X'04'
адрес является адресом IP v6, длинна адреса 16 октет
Использование сетевых файрволов и систем, эффективно скрывающих
организацию внутренней сетевой структуры от внешней сети, такой
как Интернет, становится все более популярным. Эти файрволы обычно
работают как гэйтэвэи прикладного уровня между сетями, предлагая
обычно администрируемый TELNET, FTP, и SMTP доступ. С появлением
более сложных протоколов прикладного уровня предназначенных для
облегчения глобального информационного взаимодействия, появилась
потребность в обеспечении общей основы для прозрачной и безопасной
работы через файрволл для этих протоколов.
Leech, et al Standards Track [Страница 1]
RFC 1928 Протокол SOCKS 5 Март 1996
Существует также необходимость в строгой аутентификации при работе через
файрволл, в некоторой степени похожей на используемые сейчас методы. Это
требование обусловлено тем, что отношения типа клиент-сервер появляются
между сетями различных организаций, и эти отношения должны быть
управляемыми и, зачастую, строго аутентифицированны.
Описываемый здесь протокол разработан чтобы обеспечить основу для
удобного и безопасного использования сервиса сетевых файрволов для
приложений типа клиент-сервер работающих по протоколам TCP и UDP.
Протокол представляет собой "уровень-прокладку" между прикладным
уровнем и транспортным уровнем, и, как таковой, не обеспечивает
сервиса гэйтэвэев сетевого уровня, такого как пересылка пакетов ICMP.
2. Текущее положение дел
Существующий сейчас протокол, SOCKS v4, предназначен для работы через
файрволл без аутентификации для приложений типа клиент-сервер работающих
по протоколу TCP, таких как TELNET, FTP и таких популярных протоколов
обмена информацией, как HTTP, WAIS и GOPHER.
Новый протокол расширяет модель SOCKS v4 добавляя к ней поддержку UDP,
обеспечение универсальных схем строгой аутентификации и расширяет
методы адресации, добавляя поддержку доменных имен и адресов IP v6.
Реализация протокола SOCKS обычно влечет за собой перекомпиляцию или
пересборку клиентских программ, работающих по протоколу TCP, для
использования оответствующх функций SOCKS-библиотеки.
Замечание:
Если не оговорено обратное, десятичные числа в диаграммах формата
пакетов обозначают длинну соответствующего поля в октетах (8-битных
элементах). Если октет должен иметь определенное значение, используется
обозначение X'hh' для определения значения октета в данном поле.
Если используется слово 'Variable', это означает, что соответствующее
поле имеет переменную длинну, определяемую либо связанным (одно- или
двух-октетным) полем длинны, либо типом данных данного поля.
3. Процедура для клиентов работающих по TCP
Когда работающий по TCP клиент хочет соединиться с объектом, доступным
только через файрволл, он должен открыть TCP-соединение c
соответствующим SOCKS-портом SOCKS-сервера. Сервис SOCKS обычно
находится на TCP-порту 1080. Если соединение прошло успешно, клиент
начинает переговоры о методе аутентификации, который будет
Leech, et al Standards Track [Страница 2]
RFC 1928 Протокол SOCKS 5 Март 1996
использоваваться, проходит аутентификацию по выбранному методу и
посылает свой запрос. SOCKS-сервер обрабатывает запрос и либо
пытается установить соответствующее соединение, либо отказывает в нем.
Клиент соединяется с сервером и посылает сообщение с номером версии
и выбором соответствующего метода аутентификации:
+----+----------+----------+
|VER | NMETHODS | METHODS |
+----+----------+----------+
| 1 | 1 | 1 to 255 |
+----+----------+----------+
Значение поля VER равно X'05' для данной версии протокола. Поле
NMETHODS содержит число октетов в идентификаторах методов авторизации
в поле METHODS.
Серевер выбирает один из предложенных методов, перечисленных в METHODS,
и послылает ответ о выбранном методе:
+----+--------+
|VER | METHOD |
+----+--------+
| 1 | 1 |
+----+--------+
Если выбранный метод в METHOD равен X'FF', то ни один из предложенных
клиентом методов не применим и клиент должен закрыть соединение.
Эти значения определены для поля METHOD:
o X'00' аутентификация не требуется
o X'01' GSSAPI
o X'02' USERNAME/PASSWORD (см. RFC1929)
o X'03' до X'7F' зарезервировано IANA
o X'80' до X'FE' преднозначено для частных методов
o X'FF' нет применимых методов
Затем клиент и сервер начинают аутентификацию согласно выбранному методу.
Leech, et al Standards Track [Страница 3]
RFC 1928 Протокол SOCKS 5 Март 1996
Описание методов аутентификации находится в отдельных документах.
Разработчики новых методов аутентификации применимых для этого протокола
должны обращаться в IANA для получения номера метода. Документ с
выделеными номерами должен дополнить текущий список номеров и
соответствущих им методов аутентификации.
Совместимые реализации должны поддерживать GSSAPI и могут поддерживать
аутентификацию USERNAME/PASSWORD.
4. Запросы
После того как аутентификация выполнена, клиент посылает детали запроса.
Если выбранный метод аутентификации требует особое формирование пакетов
с целью проверки целостности и/или конфедициальности, запросы должны
инкапсулироваться в пакет, формат которого определяется выбранным
методом.
SOCKS-запрос формируется следующим образом:
+----+-----+-------+------+----------+----------+
|VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
+----+-----+-------+------+----------+----------+
| 1 | 1 | X'00' | 1 | Variable | 2 |
+----+-----+-------+------+----------+----------+
Где:
o VER версия протокола: X'05'
o CMD
o CONNECT X'01'
o BIND X'02'
o UDP ASSOCIATE X'03'
o RSV зарезервировано
o ATYP тип адреса, следующего вида:
o IP v4 адрес: X'01'
o имя домена: X'03'
o IP v6 адрес: X'04'
o DST.ADDR требуемый адрес
o DST.PORT требуемый порт (в сетевом порядке октетов)
SOCKS-сервер обрабатывает запрос на основании исходного и целевого
адресов и посылает одно или несколько сообщений в ответ, в соответствии
с типом запроса.
Leech, et al Standards Track [Страница 4]
RFC 1928 Протокол SOCKS 5 Март 1996
5. Адресация
Тип адреса содержащегося в адресном поле (DST.ADDR, BND.ADDR),
определяется содержимым поля ATYP:
o X'01'
адрес является адресом IP v4, длинна адреса 4 октета
o X'03'
поле адреса содержит имя домена. Первый октет адресного поля содержит
число октетов в последующем за ним имени, завершающий NUL-октет в конце
строки не применяется.
o X'04'
адрес является адресом IP v6, длинна адреса 16 октет