
Протокол imap
Область применения протокола IMAP аналогична области применения протокола POP3: он тоже предназначен для получения почты и используется на участке между MUA-получателя(Mail User Agent — пользовательский почтовый посредник, MUA) и хранилищем сообщений (Рис.1.4.1). IMAP предоставляет более широкие возможности работы с почтовыми ящиками, чем POP3: он позволяет работать с несколькими почтовыми ящиками на одном или нескольких серверах IMAP как с файлами и каталогами на собственной машине пользователя. Обычно почтовые ящики сервера IMAP действительно представляют собой файлы в специальном каталоге сервера и его подкаталогах.
Сервер IMAP способен анализировать сообщение: выделять заданные поля заголовка и разбирать структуру тела сообщения.
В отличие от серверов POP3, серверы IMAP не должны блокировать ящик на время сеанса – несколько клиентов могут одновременно работать с одним и тем же ящиком. Множественный доступ к почтовым ящикам связан с рядом проблем, особенно, если информация в ящиках доступна для записи.
Довольно часто IMAP используется в организациях, где пользователям нужно предоставить возможность совместно работать с одними и теми же почтовыми ящиками. Он удобен для работы с новостями USENET (система телеконференций Internet: организована как большой (содержащий более 12 тысяч конференций) иерархический каталог, узлами которого являются группы новостей по определённым предметным областям). Также протокол можно использовать для работы с личными каталогами и файлами пользователя, расположенными на сервере. Впрочем, для этой цели целесообразнее использовать протоколы, специально предназначенные для работы с каталогами на файловом сервере.
Рис. 1.4.1 Принцип работы протокола IMAP
Хотя программное обеспечение, реализующее протокол IMAP , постоянно совершенствуется, IMAP менее защищен, чем POP3. Возможность хранить сообщения на сервере может стать причиной злоупотреблений со стороны пользователей, которые будут переполнять хранилище сообщений ненужной информацией.
Протокол IMAP предполагает в основном работу пользователей с почтовыми ящиками непосредственно на сервере, в отличие от протокола POP3, который ориентирован на то, что клиент забирает пришедшую почту и разбирает ее уже на своей машине. Это делает IMAP неудобным для пользователей, подключающихся к сети кратковременно, только для того, чтобы получить или отослать почту. Во всяком случае, многие преимущества IMAP таким пользователям недоступны. При работе по протоколу IMAP клиенту желательно иметь доступ к сети все время, пока он работает с почтой.
Протокол IMAP позволяет пользователю работать с множеством почтовых ящиков, расположенных, возможно, на разных серверах.
Допускается иерархическое расположение почтовых ящиков в каталогах и их подкаталогах, причем имена каталогов и почтовых ящиков сами по себе не различаются. Почтовый ящик может быть только конечным элементом иерархической структуры, он не может содержать никаких нижестоящих элементов. Каталог может содержать подкаталоги и почтовые ящики, но он не содержит сообщений и не может быть выбран командой «выбор».
Допускается использование различных пространств имен почтовых ящиков и, соответственно, разных иерархических разделителей. Например, если сервер IMAP предоставляет доступ к ящикам, расположенным в каталогах файловой системы UNIX и к группам новостей USENET , то в первом случае в качестве иерархического разделителя используется косая черта, а во втором – точка. Чтобы использовать и различать разные пространства имен на одном сервере IMAP , имена, принадлежащие каждому из используемых пространств, должны начинаться с некоторого префикса, обычно начинающегося символом "#". Естественно, запросы, в которых путь к ящику начинается с одного префикса, будут давать отличные результаты от таких же запросов, начинающихся с другого префикса. Используемое по умолчанию пространство имен может префикса не иметь.
Клиент может выяснить, какие именно пространства имен для почтовых ящиков каких типов поддерживаются данным сервером IMAP , если сервер поддерживает расширение NAMESPACE (пространство имён). Префикс и иерархический разделитель конкретного имени почтового ящика или каталога можно выяснить при помощи команды LIST (список).
Большие возможности, предоставляемые протоколом IMAP , создают большие сложности при разработке, настройке и эксплуатации серверов и клиентов. В общем случае можно посоветовать использовать прото-кол IMAP только в том случае, если возможности протокола POP3 не достаточны для работы пользователей с их почтовыми ящиками.
Сервер IMAP ожидает соединения от клиентов на порту TCP 143. После установления соединения сервер посылает свое приветствие клиенту, и начинается диалог, в котором клиент посылает серверу команды, а сервер сообщает о результатах их выполнения или присылает затребованную клиентом информацию. Как и сеанс POP3, сеанс IMAP делится на несколько состояний. Допустимый набор команд зависит от текущего состояния сеанса. Сеанс может находиться в одном из следующих состояний:
неаутентифицированное состояние: клиент должен пройти процедуру аутентификации прежде, чем сможет выполнять большинство команд;
аутентифицированное состояние: клиент аутентифицирован и должен выбрать почтовый ящик, прежде чем сможет работать с отдельными сообщениями;
выбранное состояние: почтовый ящик выбран;
состояние выхода: сеанс завершается[6].
Основные типы переходов между состояниями сеанса IMAP представлены далее на рисунке (Рис. 1.4.2):
соединение без предварительной аутентификации;
соединение с предварительной аутентификацией;
отвергнутое соединение;
успешная аутентификация;
успешное выполнение команды «выбор» или «осмотр»;
команда «закрытие» или неудачное завершение команды «выбор» или «осмотр»;
команда LOGOUT (выход из системы) или потеря связи[6].
Рис. 1.4.2 Состояния сеанса IMAP
Для того чтобы обеспечить гибкость и многофункциональность операций работы с сообщениями, почтовые системы IMAP присваивают сообщениям определенные атрибуты.
Атрибуты сообщений системы IMAP: каждое сообщение в почтовой системе для работы с IMAP имеет уникальный идентификатор, по которому можно получить доступ к этому сообщению. Уникальный идентификатор UID (unique identifier – уникальный идентификатор) представляет собой 32-битное число, которое идентифицирует сообщение в данной папке. Каждому сообщению, попавшему в папку, присваивается максимальное число из UID-сообщений, попавших в данную папку ранее. Уникальные идентификаторы сообщений сохраняются от сессии к сессии и могут использоваться, например, для синхронизации каталогов мобильных пользователей.
Каждая папка в системе также имеет уникальный действительный идентификатор. Вместе с UID-сообщение эта пара образует 64-битное число, идентифицирующее каждое сообщение. Если UID-сообщение сохраняется постоянным, то уникальный действительный идентификатор данной папки в текущей сессии должен быть больше, чем в предыдущей сессии[7].
Кроме уникального идентификатора, сообщение в системе IMAP имеет порядковый номер, т. е. все сообщения в данном почтовом ящике последовательно нумеруются. Если в почтовый ящик добавляется новое сообщение, ему присваивается номер на 1 больше количества сообщении в почтовом ящике. При удалении какого-либо сообщения из данной папки порядковые номера всех сообщений пересчитываются, поэтому порядковый номер сообщения может меняться во время сессии. Большинство команд IMAP4 работают с порядковыми номерами сообщений, а не с UID.
Помимо числовых идентификаторов, сообщениям назначаются флаги. Одни флаги могут быть действительны для данного сообщения постоянно от сессии к сессии, другие — только в данной сессии. Наиболее употребительные из них (табл.№1):
Табл. 1.4.1. Флаги сообщений системы IMAP.
"\Seen" |
обозначает, что данное сообщение было прочитано |
"\Answered" |
на сообщение был дан ответ |
"\Deleted" |
сообщение помечено на удаление |
"\Draft" |
формирование данного сообщения еще не завершено |
"\Recent" |
сообщение "только что" поступило в почтовый ящик, т. е. данная сессия — первая, которая может прочитать это сообщение, либо пример флага, который не сохранится в следующей сессии |
Кроме того, на сервере IMAP хранятся дата и время получения сообщения сервером. Например, если сообщение получено по SMTP, то фиксируется дата и время доставки по адресу назначения, общий размер сообщения, состав конверта (заголовка) сообщения (не путать с конвертом SMTP), структура сообщения (MIME-структура).
IMAP4 — гибкий и многофункциональный протокол с широкими возможностями. Он обслуживает более 20 различных команд клиента по управлению состоянием своей почты.
IMAP4 поддерживает текстовые команды и ответы сервера, т. е. ASCII-последовательности символов. Строка команды или данных завершается последовательностью <CRLF>. 8-битные данные, в соответствии с спецификацией MIME, не могут передаваться по IMAP4 в "открытом" виде. Как правило, реализации IMAP4 перед передачей двоичных данных кодируют их base64.
Так же как и РОРЗ-сервер, IМАР4-сервер обрабатывает команды в зависимости от одного из четырех состояний, в котором он находится:
Состояние вне аутентификации, в котором клиент должен для начала работы зарегистрироваться в сервере.
Состояние аутентификации, в котором клиент может выбрать для работы папку с сообщениями.
Состояние работы с почтовой папкой, в котором клиент производит основную работу с сообщениями.
Состояние отсоединения, в котором сервер завершает транзакцию работы клиента[7].
Протокол SSH (Secure Shell)
Для определения локального адреса по IP-адресу используется протокол разрешения адреса ARP (Address Resolution Protocol — протокол разрешения адресов). Протокол ARP работает различным образом в зависимости от того, какой протокол канального уровня работает в данной сети - протокол локальной сети с возможностью широковещательного доступа одновременно ко всем узлам сети, или же протокол глобальной сети (X.25, frame relay — «ретрансляция кадров»), как правило не поддерживающий широковещательный доступ. Существует также протокол, решающий обратную задачу - нахождение IP-адреса по известному локальному адресу. Он называется реверсивный ARP - RARP (Reverse Address Resolution Protocol — протокол разрешения обратных адресов) и используется при старте бездисковых станций, не знающих в начальный момент своего IP-адреса, но знающих адрес своего сетевого адаптера.
В локальных сетях протокол ARP использует широковещательные кадры протокола канального уровня для поиска в сети узла с заданным IP-адресом.
Узел, которому нужно выполнить отображение IP-адреса на локальный адрес, формирует ARP запрос, вкладывает его в кадр протокола канального уровня, указывая в нем известный IP-адрес, и рассылает запрос широковещательно. Все узлы локальной сети получают ARP запрос и сравнивают указанный там IP-адрес с собственным. В случае их совпадения узел формирует ARP-ответ, в котором указывает свой IP-адрес и свой локальный адрес и отправляет его уже направленно, так как в ARP запросе отправитель указывает свой локальный адрес. ARP-запросы и ответы используют один и тот же формат пакета. Так как локальные адреса могут в различных типах сетей иметь различную длину, то формат пакета протокола ARP зависит от типа сети.
В поле типа сети для сетей Ethernet указывается значение 1. Поле типа протокола позволяет использовать пакеты ARP не только для протокола IP, но и для других сетевых протоколов. Для IP значение этого поля равно 080016.
Длина локального адреса для протокола Ethernet равна 6 байтам, а длина IP-адреса - 4 байтам. В поле операции для ARP запросов указывается значение 1 для протокола ARP и 2 для протокола RARP.
Узел, отправляющий ARP-запрос, заполняет в пакете все поля, кроме поля искомого локального адреса (для RARP-запроса не указывается искомый IP-адрес). Значение этого поля заполняется узлом, опознавшим свой IP-адрес.
В глобальных сетях администратору сети чаще всего приходится вручную формировать ARP-таблицы, в которых он задает, например, соответствие IP-адреса адресу узла сети X.25, который имеет смысл локального адреса. В последнее время наметилась тенденция автоматизации работы протокола ARP и в глобальных сетях. Для этой цели среди всех маршрутизаторов, подключенных к какой-либо глобальной сети, выделяется специальный маршрутизатор, который ведет ARP-таблицу для всех остальных узлов и маршрутизаторов этой сети. При таком централизованном подходе для всех узлов и маршрутизаторов вручную нужно задать только IP-адрес и локальный адрес выделенного маршрутизатора. Затем каждый узел и маршрутизатор регистрирует свои адреса в выделенном маршрутизаторе, а при необходимости установления соответствия между IP-адресом и локальным адресом узел обращается к выделенному маршрутизатору с запросом и автоматически получает ответ без участия администратора.
SSH, одно из самых распространенных программных средств повышения компьютерной безопасности при работе Unix-систем в Internet.
Число как средств защиты, так и инструментов, способствующих взлому, в Internet огромно.
Хотя SSH появился лишь в 1995 г., в настоящее время он уже рассматривается как проект стандарта Internet, подготовкой которого занимается специальная рабочая группа. Строго говоря, в этой рабочей группе стандартизуется, конечно, не SSH как программный продукт, а набор протоколов SSH.
Тем временем, SSH уже завоевал статус фактического стандарта Internet на безопасные терминальные соединения. Автором первоначального варианта SSH является Т. Ялонен. В настоящее время выпущена вторая версия SSH; разработкой программного продукта SSH2 занимается компания «SSH Communication Security». Кроме версии SSH, доступной бесплатно, имеется и усовершенствованный коммерчески доступный вариант. Кроме того, с использованием этой программы разработаны и некоторые другие коммерческие продукты.
Под SSH понимают как собственно программу, так и задействованный в ней протокол. Что касается программы, то для ее краткой характеристики следует сказать, что SSH представляет собой средство организации безопасного доступа к компьютерам при работе по небезопасным каналам связи. Для организации безопасного доступа применяется процедура аутентификации с использованием асимметричного шифрования с открытым ключом. Это обеспечивает более высокую безопасность, чем при использовании симметричного шифрования, хотя и порождает дополнительную вычислительную нагрузку. При последующем обмене данными применяется уже симметричное шифрование, более экономичное в смысле затрат процессорного времени.
Что касается типов обеспечиваемого удаленного доступа, SSH поддерживает возможности работы с telnet (сетевой теледоступ): Протокол виртуального терминала в наборе интернет-протоколов; позволяет пользователям одного хоста подключаться к другому удаленному хосту и работать с ним как через обычный терминал; безопасную работу с протоколом X11 благодаря возможности перенаправления соответствующих данных по надежным SSH -каналам; безопасную замену многим r-командам Unix, с которыми традиционно связаны проблемы обеспечения безопасности.
Проект стандарта SSH описывает протоколы SSH и состоит из нескольких документов, которые описывают общую архитектуру протокола, а также протоколы трех уровней: протокол транспортного уровня, протокол аутентификации и протокол соединения. Их задача обеспечивать безопасную сетевую службу наподобие удаленного входа в систему поверх небезопасной сети.
Протокол транспортного уровня обеспечивает аутентификацию сервера, конфиденциальность и целостность. Протокол аутентификации обеспечивает аутентификацию клиента для сервера. Наконец, протокол соединения SSH мультиплексирует безопасный (шифруемый) канал, представляя его в виде нескольких логических каналов, которые используются для различных целей (различных видов служб).
Протокол транспортного уровня предусматривает возможность сжатия данных. Этот протокол работает поверх соединения TCP/IP. Протокол аутентификации работает поверх протокола транспортного уровня, а протокол соединения ' поверх протокола аутентификации.
С целью повышения безопасности осуществляется не только аутентификация клиента для сервера, к которому обращается клиент, но и аутентификация сервера клиентом другими словами, происходит аутентификация обеих сторон.
Клиент шлет запрос на обслуживание в первый раз, когда устанавливается безопасное соединение транспортного уровня SSH. Второй запрос направляется уже после завершения аутентификации пользователя (клиента).
Прежде чем анализировать протоколы SSH подробнее, следует определить понятие ключ хоста. Каждый работающий с SSH хост, на котором может выполняться как клиент, так и сервер, может иметь не менее одного ключа, причем для шифрования допускаются различные криптографические алгоритмы. Несколько хостов могут иметь общий ключ хоста. Однако каждый хост должен иметь хотя бы один ключ, с которым работает каждый из требуемых алгоритмов работы с открытыми ключами. В проекте стандарта в настоящее время требуемый алгоритм только один DSS (Digital Signature Standard — стандарт цифровой подписи)[8].
Ключ хоста-сервера используется при обмене открытыми ключами с целью проверки того, что клиент действительно общается с настоящим (а не подмененным) сервером. Для этого клиент должен знать открытый ключ хоста-сервера. Это знание реализуется в рамках одной из двух моделей.
В первой клиент просто имеет некий локальный файл, в котором каждому имени хоста ставится в соответствие его открытый ключ. Во второй модели вводится понятие сертификационного агента, который и отвечает за проверку соответствия имени хоста его открытому ключу. При этом клиент знает только открытый ключ самого сертификационного агента. В последнем случае упрощается поддержка клиента (ему нужно знать всего один открытый ключ), но появляются высокие требования к сертификационному агенту, который должен иметь открытые ключи всех хостов, к которым обращаются клиенты.
Протоколом предусмотрена возможность отказа от проверки ключа хоста-сервера при самом первом обращении клиента к этому серверу. При этом соединение клиент-сервер будет защищено от пассивного прослушивания сети, но возникает опасность атаки типа «человек в середине», т. е. попытки временной подмены сервера. Если эта возможность используется, ключ хоста-сервера будет автоматически передан клиенту и сохранен в его локальном файле.
Разработчики проекта протокола SSH особенно заботились о его долголетии. Протокол будет расширяемым; планируется возможность дополнения криптографических алгоритмов, используемых при работе SSH. C этой целью проектом предусмотрено, что между клиентом и сервером происходят переговоры, в результате которых выбираются методы шифрования, форматы открытых ключей и т.п., которые будут использованы в данном сеансе. При этом с целью обеспечения операбельности должен поддерживаться некоторый минимальный.
Номера сообщений SSH и их назначение: отдельного упоминания заслуживают вопросы увеличения трафика в связи с применением протоколов SSH. Ясно, что при передаче в сети больших пакетов дополнительная нагрузка, вызванная передачей управляющих заголовков SSH, невелика. Основное внимание следует обратить на приложения, для которых характерны короткие пакеты например, telnet. Минимальный размер заголовка TCP/IP равен 32 байта; минимальный же размер пакета при использовании SSH увеличится с 33 до (примерно) 51 байта.
Учитывая, что в Ethernet минимальная длина поля данных пакета равна 46 байт, дополнительный нагрузкой в 5 байт можно пренебречь. Наиболее существенным влияние SSH оказывается, вероятно, при использовании протокола PPP (Point to Point Protocol — протокол соединения "точка - точка") на низкоскоростных модемных соединениях, поскольку PPP сжимает заголовки TCP/IP. Однако существенный прогресс в скоростях передачи данных позволяет рассчитывать, что дополнительные задержки будут измеряться несколько миллисекундами и останутся незаметны человеку.
Наконец, несколько слов о кодировании сетевых адресов. Поскольку DNS (domain name server — служба имён доменов) ненадежный протокол, в SSH он не используется. При адресации применяются IP-адреса, причем в проекте заложена поддержка IPv6.
Все сообщения (пакеты) SSH содержат номер сообщения: число от 1 до 255. Этот диапазон разбит на подинтервалы, причем разным уровням протокола SSH отвечают разные диапазоны[8].