Протокол идентификации

Идентификатор
Протокол связи
Цель	Идентификация
Разработчик(и)	Майкл Сент-Джонс в Министерстве обороны США
Введение	февраль 1993 г .; 31 год назад
На основе	RFC 931
Уровень OSI	Прикладной уровень (уровень 7)
Порт(ы)	TCP/113
RFC(ы)	RFC 1413

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

Функция

Протокол Ident предназначен для работы в качестве демона сервера на компьютере пользователя , где он получает запросы к указанному TCP-порту , обычно 113. В запросе клиент указывает пару TCP-портов (локальный и удаленный). порт), закодированный десятичными числами ASCII и разделенный запятой (,). Затем сервер отправляет ответ, который идентифицирует имя пользователя, запускающего программу, использующую указанную пару TCP-портов, или указывает на ошибку.

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

6191, 23

Поскольку TCP-соединения обычно используют один уникальный локальный порт (в данном случае 6191), хост B может однозначно идентифицировать программу, которая инициировала указанное соединение с портом 23 хоста A, если он существует. Затем хост B выдаст ответ, идентифицирующий пользователя («stjohns» в этом примере), которому принадлежит программа, инициировавшая это соединение, и имя его локальной операционной системы :

6193, 23 : USERID : UNIX : stjohns

Но если окажется, что на хосте B такого соединения не существует, вместо этого он выдаст ответ об ошибке:

6195, 23 : ERROR : NO-USER

Все идентификационные сообщения должны быть разделены последовательностью конца строки, состоящей из символов возврата каретки и перевода строки (CR+LF). ^{[ 1 ]}

Полезность идентификатора

Хосты коммутируемого доступа или общие серверы оболочки часто предоставляют идентификаторы, позволяющие отследить злоупотребления конкретным пользователям. В случае, если злоупотребления обрабатываются на этом хосте, беспокойство по поводу доверия к демону ident практически не имеет значения. Подмены службы и проблем конфиденциальности можно избежать, предоставив различные криптостойкие токены вместо реальных имен пользователей.

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

Полезность Ident для подтверждения известной личности удаленному хосту ограничена обстоятельствами, когда:

Подключающийся пользователь не является администратором аппарата. Это возможно только для хостов, предоставляющих доступ к оболочке Unix , общих серверов, использующих конструкцию типа suEXEC , и т.п.
Человек доверяет администраторам машины и знает их пользовательскую политику. Это наиболее вероятно для хостов в общем домене безопасности, например, в одной организации.
Человек верит, что машина — это та машина, за которую он себя выдает, и знает эту машину. Это легко организовать только для хостов в локальной сети или виртуальной сети, где все хосты в сети являются доверенными, а новые хосты не могут быть легко добавлены из-за физической защиты. В удаленных и обычных локальных сетях ответы на ложные идентификационные данные могут быть получены путем подмены IP-адреса и, если используется DNS, с помощью всех видов мошенничества с DNS. Демон идентификации может предоставлять ответы с криптографической подписью, которые, если они могут быть подтверждены, решают эту последнюю, но не первую проблему.
Не существует никаких промежуточных препятствий для подключения к identd, таких как брандмауэр, NAT или прокси-сервер (например, если вы используете ident с Apache httpd). Это обычное явление при переходе между доменами безопасности (как в случае с общедоступными серверами HTTP или FTP ).

Безопасность

Протокол идентификации считается опасным, поскольку он позволяет взломщикам получить список имен пользователей в компьютерной системе , который впоследствии может быть использован для атак. Общепринятым решением этой проблемы является установка общего/сгенерированного идентификатора, возвращающего информацию об узле или даже тарабарщину (с точки зрения запрашивающей стороны), а не имена пользователей. Администратор идентификаторов может превратить эту тарабарщину в настоящие имена пользователей, когда с ним или с ней свяжутся по поводу возможного злоупотребления, что означает, что полезность отслеживания злоупотреблений сохраняется.

Использование

Идентификация важна для IRC , поскольку большое количество людей подключаются к IRC с сервера, которым пользуются несколько пользователей, часто используя баунсер . Без Ident не было бы возможности заблокировать одного пользователя, не заблокировав при этом весь хост. Администратор сервера также может использовать эту информацию для идентификации злоупотребляющего пользователя.

В большинстве сетей IRC, когда серверу не удается получить ответ Ident, он возвращается к имени пользователя, указанному клиентом, но помечает его как «не проверенное», обычно добавляя префикс тильды; например, ~ Джош . Некоторые IRC-серверы даже блокируют клиентов без ответа на идентификатор. ^{[ 2 ]} Основная причина в том, что это значительно усложняет подключение через « открытый прокси » или систему, в которой вы скомпрометировали одну учетную запись той или иной формы, но не имеете root (в Unix-подобных системах только root может прослушивать сетевые соединения). на портах ниже 1024).

Однако Ident не обеспечивает дополнительную аутентификацию, когда пользователь подключается непосредственно со своего персонального компьютера, на котором у него также есть достаточно привилегий для управления демоном Ident. ^{[ 1 ]}

См. также

oidentd (для Unix-подобных систем)
SMTP
ННТП
SSH
SOCKS- прокси

Ссылки

^ Jump up to: ^а ^б Джонс, Майкл (февраль 1993 г.). Протокол идентификации . IETF . дои : 10.17487/RFC1413 . РФК 1413 . Проверено 1 апреля 2013 г.
^ «Новости для пользователей IRCNet на T-Online» . немецкие оперы IRCnet . Проверено 26 декабря 2011 г.

Дальнейшее чтение

RFC 912 – Служба аутентификации
RFC 931 — Сервер аутентификации
Дэниел Дж. Бернштейн : Интернет-проект TAP , июнь 1992 г.
Дэниел Дж. Бернштейн : Почему TAP? Белая книга , 20 августа 1992 г.
RFC 1413 – Протокол идентификации
RFC 1414 – Идентификация MIB
Питер Эрикссон: TAPvsIDENT , 3 ноября 1993 г.
Дэмиен Долигез : Зачем шифровать ответы ident/TAP? , 22 февраля 1994 г.

[rfc-1] Jump up to: ^а ^б Джонс, Майкл (февраль 1993 г.). Протокол идентификации . IETF . дои : 10.17487/RFC1413 . РФК 1413 . Проверено 1 апреля 2013 г.

[2] «Новости для пользователей IRCNet на T-Online» . немецкие оперы IRCnet . Проверено 26 декабря 2011 г.

[ 1 ]

[ 2 ]