Ident
|
Протокол идентификации (Identification Protocol, ident, Ident Protocol) — это протокол, описанный в RFC 1413. Он обеспечивает способ идентификации пользователя для конкретного соединения TCP. Используя на входе номера пары соединенных между собой портов TCP, протокол возвращает строку символов, идентифицирующую владельца данного соединения на стороне сервера. Первоначально протокол идентификации называли Authentication Server Protocol (протокол аутентификации сервера). Сервер, реализующий протокол ident, называется identd (идэнт дэ). ОбзорПротокол представляет собой сервис на основе соединений TCP. Сервер слушает соединения TCP для порта 113 (десятичный номер). После установления соединения сервер читает строку данных, содержащую сведения о цели соединения. При существовании идентификатора пользователя для соединения сервер передает этот идентификатор в качестве отклика. После этого сервер может закрыть соединение или продолжить диалог "запрос-отклик". Серверу следует закрывать соединение по истечении заданного конфигурационными параметрами тайм-аута (60-180) при отсутствии каких-либо запросов. Клиент может закрыть соединение в любой момент, однако для компенсации возможных задержек в сети клиенту следует выждать по крайней мере 30 секунд после запроса прежде, чем закрыть соединение. ОграниченияПередача запросов допустима только для полностью организованных соединений. Запрос содержит номера пары портов (локальный - удаленный), используемых для идентификации соединения и получаемых с указанием локального и удаленного адресов. Это означает, что пользователь с адресом A может запрашивать у сервера B только информацию о соединении между A и B. Схема работыНачальные условия: на компьютере клиента работает identd. Клиент обращается к внешнему серверу, который умеет выполнять ident-проверку. Формат запросов и откликовСервер воспринимает простые текстовые запросы в формате: <port-on-server>, <port-on-client>где <port-on-server> указывает порт TCP (десятичное значение) для адресата (хоста, где работает сервер ident), а <port-on-client> указывает порт TCP (десятичное значение) на клиентской системе. Важно отметить, что если клиент на хосте A хочет сделать запрос серверу на хосте B о соединении, заданном локально (на хосте A) парой портов 23, 6191 (входящее соединение TELNET), клиент должен сделать запрос для пары 6191, 23 (идентификация соединения с точки зрения хоста B). Например: 6191, 23Отклик имеет формат: <port-on-server>, <port-on-client> : <resp-type> : <add-info>где <port-on-server> и <port-on-client> совпадают с номерами портов в запросе, <resp-type> идентифицирует тип отклика, а <add-info> содержит зависящие от контекста данные. Возвращаемая информация связана с соединением TCP, заданным параметрами <server-address>, <client-address>, <port-on-server>, <port-on-client> (<server-address> и <client-address> - IP-адреса обеих сторон соединения, а <port-on-server> и <port-on-client> - параметры запроса) Например: 6193, 23 : USERID : UNIX : stjohns 6195, 23 : ERROR : NO-USERТипы откликовОтклики могут быть двух типов: USERIDВ этом случае строка <add-info> содержит название операционной системы (возможно, с указанием поддерживаемого набора символов), за которым следует разделитель ":" и строка идентификации. Если отклик содержит набор символов, последний отделяется от имени операционной системы запятой (,). Для обозначения набора символов используются стандартные идентификаторы. Если набор символов не указан, предполагается US-ASCII (см. ниже). Идентификаторы операционной системы должны указываться в соответствии с документом RFC 1340, "Assigned Numbers" или его "наследниками". В дополнение к идентификаторам ОС, указанным в "Assigned Numbers" можно использовать специальный идентификатор "OTHER" (прочие ОС). Если в качестве операционной системы не возвращается значение "OTHER", предполагается, что сервер возвращает "нормальную" идентификацию пользователя, который владеет данным соединением (строка символов, позволяющая однозначно определить пользователя — например, имя пользователя в системе или пользовательская часть почтового адреса). Если указана операционная система (т.е., строка отклика не содержит "OTHER"), предполагается, что имя пользователя также имеет смысл (например, для использования в качестве аргумента команды finger или как части почтового адреса). Значение "OTHER" говорит о том, что дальнейшие данные являются неформатированной строкой печатных символов используемого в системе набора. Отклик "OTHER" следует возвращать, если идентификатор пользователя не соответствует описанным выше требованиям. Например, такой отклик следует передавать, если вместо имени пользователя возвращается реальное имя или телефонный номер из пользовательской записи UNIX. Предполагается, что идентификатор пользователя содержит только печатные символы используемого в системе набора. Идентификатор представляет собой строку октетов, не включающую символов (восьмеричное представление) 000 (NUL), 012 (LF) и 015 (CR). Важно подчеркнуть, что символы пробела (040), следующие за двоеточием, являются частью строки идентификатора и не должны игнорироваться. Обычно строка отклика завершается последовательностью CR/LF. Подчеркнем, что строка может содержать печатные символы, но не обязана содержать только их. ERRORЕсли по каким-то причинам владелец соединения не может быть определен, строка <add-info> сообщает о причине. Возможны следующие значения <add-info>:
В дальнейшем могут быть добавлены другие коды отклики. При использовании нестандартных откликов они должны начинаться с символа "X". В дополнение к возврату откликов сервер может разрывать соединения, не возвращая никакого отклика. Преждевременное завершение соединения (клиент не получил символа EOL) должно трактоваться клиентом как отклик "ERROR : UNKNOWN-ERROR". Формальный синтаксис<request> ::= <port-pair> <EOL> <port-pair> ::= <integer> "," <integer> <reply> ::= <reply-text> <EOL> <EOL> ::= "015 012" ; CR-LF End of Line Indicator <reply-text> ::= <error-reply> | <ident-reply> <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type> <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field> ":" <user-id> <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR" | "HIDDEN-USER" | <error-token> <opsys-field> ::= <opsys> [ "," <charset>] <opsys> ::= "OTHER" | "UNIX" | <token> ...etc. ; (See "Assigned Numbers") <charset> ::= "US-ASCII" | ...etc. ; (See "Assigned Numbers") <user-id> ::= <octet-string> <token> ::= 1*64<token-characters> ; 1-64 characters <error-token> ::= "X"1*63<token-characters> ; 2-64 chars beginning w/X <integer> ::= 1*5<digit> ; 1-5 digits. <digit> ::= "0" | "1" ... "8" | "9" ; 0-9 <token-characters> ::= <Any of these ASCII characters: a-z, A-Z, - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; > ; upper and lowercase a-z plus ; printables minus the colon ":" ; character. <octet-string> ::= 1*512<octet-characters> <octet-characters> ::= <any octet from 00 to 377 (octal) except for ASCII NUL (000), CR (015) and LF (012)>Примечания: Применение ident
Вопросы безопасности
Уровень достоверности информации, возвращаемой данным протоколом, зависит от настроек запрашиваемого хоста и политики поддерживающей хост организации. Например, ПК, используемый в открытой лаборатории, может возвращать о себе любые сведения, которые пожелает указать пользователь. Более того, хост может возвращать специально искаженную (ложную) информацию. Протокол Identification Protocol не предназначен для авторизации (проверки полномочий) или управления доступом. В лучшем случае этот протокол обеспечивает некоторые дополнительные сведения о соединениях TCP, в худшем - возвращает ошибочную, некорректную или умышленно искаженную информацию. Использование возвращаемых протоколом сведений для каких-либо целей, кроме аудита, настоятельно не рекомендуется. В частности, использование Identification Protocol для принятия решений о предоставлении доступа в качестве основного (т. е., при отсутствии других проверок) или дополнительного средства может существенно снизить уровень безопасности хоста. Сервер идентификации может собирать сведения о пользователях, объектах и процессах, которые зачастую могут содержать приватные данные. Сервер идентификации обеспечивает услуги по типу служб CallerID, поддерживаемых некоторыми телефонными компаниями, и требования к сообщаемым сервером сведениям формируются так же, как к данным CallerID. Если вы не желаете поддерживать службу finger из соображений ограничения доступа к сведениям о пользователях, вам нецелесообразно использовать и протокол идентификации. РеализацииПротокол ident — это de-facto наиболее популярная тема для продвинутого «Hello, World» (то есть лучшее направление при серьёзном изучении программирования). В связи с этим, количество демонов, его реализующих, огромно. Ниже даны ссылки на наиболее распространённые и чаще всего используемые сервера такого класса.
|
