WikiSort.ru - Не сортированное

Протокол идентификации (Identification Protocol, ident, Ident Protocol) — это протокол, описанный в RFC 1413. Он обеспечивает способ идентификации пользователя для конкретного соединения TCP. Используя на входе номера пары соединенных между собой портов TCP, протокол возвращает строку символов, идентифицирующую владельца данного соединения на стороне сервера. Первоначально протокол идентификации называли Authentication Server Protocol (протокол аутентификации сервера). Сервер, реализующий протокол ident, называется identd (идэнт дэ́).

Обзор^[1]

Протокол представляет собой сервис на основе соединений TCP. Сервер слушает соединения TCP для порта 113 (десятичный номер). После организации соединения сервер читает строку данных, содержащую сведения о цели соединения. При существовании идентификатора пользователя для соединения сервер передает этот идентификатор в качестве отклика. После этого сервер может закрыть соединение или продолжить диалог "запрос-отклик". Серверу следует закрывать соединение по истечении заданного конфигурационными параметрами тайм-аута (60-180) при отсутствии каких-либо запросов. Клиент может закрыть соединение в любой момент, однако для компенсации возможных задержек в сети клиенту следует выждать по крайней мере 30 секунд после запроса прежде, чем закрыть соединение.

Ограничения

Передача запросов допустима только для полностью организованных соединений. Запрос содержит номера пары портов (локальный - удаленный), используемых для идентификации соединения и получаемых с указанием локального и удаленного адресов. Это означает, что пользователь с адресом A может запрашивать у сервера B только информацию о соединении между A и B.

Схема работы

Начальные условия: на компьютере клиента работает identd. Клиент обращается к внешнему серверу, который умеет выполнять ident-проверку.

1. Клиент посылает запрос.
2. Перед посылкой ответа сервер спрашивает у клиентской машины по порту 113 имя пользователя, сделавшего запрос, и указывает номера портов соединения с обеих сторон.
3. identd, слушающий порт 113, отправляет ответ.
4. Сервер получает ответ и что-нибудь с ним делает (скажем, пишет в лог), после чего, в свою очередь, отсылает ответ клиенту.

Формат запросов и откликов

Сервер воспринимает простые текстовые запросы в формате:

<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

Типы откликов

Отклики могут быть двух типов:

Формальный синтаксис

<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)>

Примечания:

1. Для обеспечения интероперабельности различных реализаций в части трактовки символов пробела следует придерживаться общего принципа: "будь консервативным при передаче и либеральным на приеме". Клиентам и серверам не следует генерировать избыточных пробелов, но они должны воспринимать строки с лишними пробелами от других. Избыточные пробелы могут встречаться везде, кроме собственно маркеров (token). В частности, дополнительные пробелы могут встречаться в начале и в конце строк запросов и откликов. Однако дополнительные пробелы недопустимы в отклике с идентификатором пользователя после двоеточия вслед за именем операционной системы, поскольку в этом случае они будут трактоваться как часть имени пользователя (именем пользователя считается вся последовательность символов от двоеточия до символов завершения строки CR/LF). Символы CR/LF не должны рассматриваться как часть идентификатора пользователя.
2. Вопреки сказанному выше, серверам следует ограничивать число пробелов между элементами (маркерами) до минимально возможного (полезного). Клиент может разорвать соединение, получив более 1000 символов без сигнала завершения строки <EOL>.
3. Размер идентификатора пользователя следует ограничивать 512 символами, а размер маркера - 64 символами, поскольку: a) новые маркеры (т. е., OPSYS или ERROR-TYPE) будут иметь размер не более 64 символов и b) серверу не следует передавать более 512 октетов идентификатора пользователя, а клиент должен принимать первые 512 октетов идентификатора пользователя. Вследствие этих ограничений сервер должен возвращать наиболее важную часть идентификатора пользователя в первых 512 октетах.
4. Следует использовать только те наборы символов и идентификаторы этих наборов, которые указаны в RFC 1340, "Assigned Numbers" и более новых вариантах этого документа. Идентификаторы набора символов применимы только к полям идентификации пользователя, а все остальные поля должны использовать набор символов US-ASCII.
5. Хотя поле <user-id> было определено выше как <octet-string> (строка октетов), оно должно соответствовать по формату и набору символов значению поля <opsys-field>; описанного выше.
6. Идентификатор набора символов обеспечивает для клиента контекст, позволяющий печатать или сохранять строку идентификации пользователя. Если клиент не может распознать или использовать указанный набор символов, ему следует трактовать строку идентификации как строку октетов (OCTET), сохраняя вместе с ней идентификатор использованного набора символов. Строку октетов в таких случаях следует печатать, сохранять и обрабатывать в 16-ричном представлении (0-9a-f) в дополнение к используемому клиентской реализацией представлению (это обеспечивает возможность стандартного представления в различных реализациях).

Применение ident

• В IRC: некоторые IRC-сервера требуют обязательного ответа от identd на стороне входящего в сеть пользователя.
• Для фильтрации спама, исходящего с локального компьютера (например, на хостингах): программа sendmail спрашивает у identd, кто послал письмо, и приписывает к письму настоящее имя отправителя. Если «подписанное» письмо со спамом попадёт после этого на другой компьютер под тем же административным контролем, то локальный спамер будет моментально выявлен и (впоследствии) заблокирован.
• Для аутентификации в пределах одного компьютера в тех ОС, в которых нет возможности проверить отправителя сообщения через UNIX-сокет (т. н. схема unix credentials).

Вопросы безопасности

• Никогда нельзя доверять данным, которые поступают от чужих ident-серверов (то есть тех, которые настраивали не вы), потому что они могут быть подделаны/скрыты. Ни в коем случае нельзя использовать identd для аутентификации по сети, даже в случае с доверенными клиентами, так как взлом клиентской машины приведёт к взлому доверяющего ей сервера (см. также межсистемное доверие).
• Иногда для клиента бывает нежелательным «светиться» в интернете. Примером того могут служить разные боты, работающие по какой-либо причине с привилегиями пользователя root. Некоторые ident-сервера предоставляют возможность контролируемой маскировки некоторых пользователей.

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

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

Использование возвращаемых протоколом сведений для каких-либо целей, кроме аудита, настоятельно не рекомендуется. В частности, использование Identification Protocol для принятия решений о предоставлении доступа в качестве основного (т. е., при отсутствии других проверок) или дополнительного средства может существенно снизить уровень безопасности хоста.

Сервер идентификации может собирать сведения о пользователях, объектах и процессах, которые зачастую могут содержать приватные данные. Сервер идентификации обеспечивает услуги по типу служб CallerID, поддерживаемых некоторыми телефонными компаниями, и требования к сообщаемым сервером сведениям формируются так же, как к данным CallerID. Если вы не желаете поддерживать службу finger из соображений ограничения доступа к сведениям о пользователях, вам нецелесообразно использовать и протокол идентификации.

Реализации

Протокол ident — это de-facto наиболее популярная тема для продвинутого «Hello, World» (то есть лучшее направление при серьёзном изучении программирования). В связи с этим, количество демонов, его реализующих, огромно. Ниже даны ссылки на наиболее распространённые и чаще всего используемые сервера такого класса.

• Oidentd — наиболее распространенный Identd сервер
• FakeIdentd
• DummyIdentd — фальшивый агент

Примечания

1. ↑ M. St Johns. Identification Protocol (англ.). tools.ietf.org. Проверено 16 января 2019.
2. ↑ J. Postel, J. Reynolds. Assigned Numbers (англ.). tools.ietf.org. Проверено 16 января 2019.