Протоколы SSH, CMIP, Telnet

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ТРАНСПОРТА И СВЯЗИ УКРАИНЫ

ОДЕССКАЯ НАЦИОНАЛЬНАЯ АКАДЕМИЯ СВЯЗИ им. А.С.ПОПОВА

Кафедра сетей связи

Реферат

на тему: «Протоколы SSH, CMIP, Telnet»

Одесса 2013

Оглавление

• Стандарты и программные реализации
• SSH-серверы
• SSH-клиенты и оболочки
• Советы по безопасности использования SSH
• Примеры использования SSH
• SSH-туннелирование
• Техническая информация о протоколе
• Основные характеристики протокола CMIP
• Протокол CMIP и услуги CMIS
• Обзор
• Фильтрация
• Синхронизация
• Сравнение протоколов SNMP и CMIP
• Telnet
• Устройство
• Опции
• Принтер и клавиатура NVT
• Структура команд Telnet
• Применения
• Безопасность
• Telnet и другие протоколы

Стандарты и программные реализации

SSH (англ. Secure SHell -- «безопасная оболочка») -- сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). Схож по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы доступны для большинства сетевых операционных систем.

SSH позволяет безопасно передавать в незащищённой среде практически любой другой сетевой протокол. Таким образом, можно не только удалённо работать на компьютере через командную оболочку, но и передавать по шифрованному каналу звуковой поток или видео (например, с веб-камеры). Также SSH может использовать сжатие передаваемых данных для последующего их шифрования, что удобно, например, для удалённого запуска клиентов X WindowSystem.

Большинство хостинг-провайдеров за определённую плату предоставляют клиентам доступ к их домашнему каталогу по SSH. Это может быть удобно как для работы в командной строке, так и для удалённого запуска программ (в том числе графических приложений).

Первая версия протокола, SSH-1, была разработана в 1995 году исследователем Тату Улёненом из Технологического университета Хельсинки (Финляндия). SSH-1 был написан для обеспечения большей конфиденциальности, чем протоколы rlogin, telnet и rsh. В 1996 году была разработана более безопасная версия протокола, SSH-2, несовместимая с SSH-1. Протокол приобрел ещё большую популярность, и к 2000 году у него было около двух миллионов пользователей. В настоящее время под термином «SSH» обычно подразумевается именно SSH-2, т.к. первая версия протокола ввиду существенных недостатков сейчас практически не применяется.

В 2006 году протокол был утвержден рабочей группой IETF в качестве Интернет?стандарта.

Однако, в некоторых странах (Франция, Россия, Ирак и Пакистан) до сих пор требуется специальное разрешение в соответствующих структурах для использования определённых методов шифрования, включая SSH.

Распространены две реализации SSH: частная коммерческая и бесплатная свободная. Свободная реализация называется OpenSSH. К 2006 году 80 % компьютеров сети Интернет использовало именно OpenSSH. Частная реализация разрабатывается организацией SSH Communications Security, которая является стопроцентным подразделением корпорации Tectia, она бесплатна для некоммерческого использования. Эти реализации содержат практически одинаковый набор команд.

Протокол SSH-2, в отличие от протокола telnet, устойчив к атакам прослушивания трафика («снифинг»), но неустойчив к атакам «человек посередине». Протокол SSH-2 также устойчив к атакам путем присоединения посредине (англ. sessionhijacking), так как невозможно включиться в уже установленную сессию или перехватить её.

Для предотвращения атак «человек посередине» при подключении к хосту, ключ которого ещё не известен клиенту, клиентское ПО показывает пользователю «слепок ключа» (англ. keyfingerprint). Рекомендуется тщательно проверять показываемый клиентским ПО «слепок ключа» со слепком ключа сервера, желательно полученным по надёжным каналам связи или лично.

Поддержка SSH реализована во всех UNIX_подобных системах, и на большинстве из них в числе стандартных утилит присутствуют клиент и сервер ssh. Существует множество реализаций SSH-клиентов и для не-UNIX ОС. Большую популярность протокол получил после широкого развития анализаторов трафика и способов нарушения работы локальных сетей, как альтернативное небезопасному протоколу Telnet решение для управления важными узлами.

Для работы по SSH нужен SSH-сервер и SSH-клиент. Сервер прослушивает соединения от клиентских машин и при установлении связи производит аутентификацию, после чего начинает обслуживание клиента. Клиент используется для входа на удалённую машину и выполнения команд.

Для соединения сервер и клиент должны создать пары ключей -- открытых и закрытых -- и обменяться открытыми ключами. Обычно используется также и пароль.

SSH-серверы

· *BSD: OpenSSH

· Linux: dropbear, lsh-server, openssh-server, ssh

· Windows: freeSSHd, copssh, WinSSHD, KpyM Telnet/SSH Server, MobaSSH, OpenSSH через Cygwin

SSH-клиенты и оболочки

· GNU/Linux, *BSD: kdessh, lsh-client, openssh-client, putty, ssh, Vinagre

· MS Windows и Windows NT: PuTTY, SecureCRT, ShellGuard, Axessh, ZOC, SSHWindows, ProSSHD, XShell

· MS Windows Mobile: PocketPuTTy, mToken, sshCE, PocketTTY, OpenSSH, PocketConsole

· Mac OS: NiftyTelnet SSH

· Symbian OS: PuTTY

· Java: MindTerm, AppGateSecurityServer

· J2ME: MidpSSH

· iPhone: i-SSH, ssh (вкомплектес Terminal)

· Android: connectBot

· Blackberry: BBSSH

· MAEMO 5: OpenSSH

Советы по безопасности использования SSH

1. Запрещение удалённого root-доступа.

2. Запрещение подключения с пустым паролем или отключение входа по паролю.

3. Выбор нестандартного порта для SSH-сервера.

4. Использование длинных SSH2 RSA-ключей (2048 бит и более). Системы шифрования на основе RSA считаются надёжными, если длина ключа не менее 1024 бит.

5. Ограничение списка IP-адресов, с которых разрешён доступ (например, настройкой файервола).

6. Запрещение доступа с некоторых потенциально опасных адресов.

7. Отказ от использования распространённых или широко известных системных логинов для доступа по SSH.

8. Регулярный просмотр сообщений об ошибках аутентификации.

9. Установка систем обнаружения вторжений.

10. Использование ловушек, подделывающих SSH-сервис (honeypots).

Примеры использования SSH

Команда подключения к локальному SSH-серверу из командной строки GNU/Linux или FreeBSD для пользователя pacify (сервер прослушивает нестандартный порт 30000): $ ssh -p 30000 pacify@127.0.0.1

Генерация пары ключей (в UNIX-подобных ОС) осуществляется командой $ ssh-keygen

Генерация пары SSH-2 RSA-ключей длиной 4096 бита программой puttygen под UNIX?подобными ОС:

$ puttygen -t rsa -b 4096 -o sample

Некоторые клиенты, например, PuTTY, имеют и графический интерфейс пользователя.

Для использования SSH в Python существуют такие модули, как python-paramiko и python-twisted-conch.

SSH-туннелирование

SSH-туннель -- это туннель, создаваемый посредством SSH-соединения и используемый для шифрования туннелированных данных. Используется для того, чтобы обезопасить передачу данных в Интернете. При пересылке через SSH-туннель незашифрованный трафик любого протокола шифруется на одном конце SSH-соединения и расшифровывается на другом. Практическая реализация может выполняться несколькими способами:

· Созданием Socks-прокси для приложений, которые не умеют работать через SSH-туннель, но могут работать через Socks-прокси

· Использованием приложений, умеющих работать через SSH-туннель.

· Созданием VPN-туннеля, подходит практически для любых приложений.

· Если приложение работает с одним определённым сервером, можно настроить SSH-клиент таким образом, чтобы он пропускал через SSH-туннель TCP-соединения, приходящие на определённый TCP-порт машины, на которой запущен SSH-клиент. Например, клиенты Jabber подключаются по умолчанию на порт 443. Тогда, чтобы настроить подключение к серверу Jabber через SSH-туннель, SSH-клиент настраивается на перенаправление подключений с любого порта локальной машины на удалённый сервер: $ ssh -L 4430:jabber.example.com:443 somehost. В данном случае Jabber-клиент настраивается на подключение к порту 4430 сервера localhost (если ssh-клиент запущен на той же машине что и Jabber-клиент). Для создания ssh-туннеля необходима машина с запущенным ssh-сервером и доступом к jabber.example.com. Такая конфигурация может использоваться в случае, если с локальной машины доступ к jabber.example.com закрыт файерволом, но есть доступ к некоторому ssh-серверу, у которого ограничения доступа в Интернет отсутствуют.

Техническая информация о протоколе

SSH -- это протокол прикладного уровня. SSH-сервер обычно прослушивает соединения на TCP-порту 22. Спецификация протокола SSH-2 содержится в RFC 4251. Для аутентификации сервера в SSH используется протокол аутентификации сторон на основе алгоритмов электронно-цифровой подписи RSA или DSA. Для аутентификации клиента также может использоваться ЭЦП RSA или DSA, но допускается также аутентификация при помощи пароля (режим обратной совместимости с Telnet) и даже ip-адреса хоста (режим обратной совместимости с rlogin). Аутентификация по паролю наиболее распространена; она безопасна, так как пароль передаётся по зашифрованному виртуальному каналу. Аутентификация по ip-адресу небезопасна, эту возможность чаще всего отключают. Для создания общего секрета (сеансового ключа) используется алгоритм Диффи -- Хеллмана (DH). Для шифрования передаваемых данных используется симметричное шифрование, алгоритмы AES, Blowfish или 3DES. Целостность передачи данных проверяется с помощью CRC32 в SSH1 илиHMAC-SHA1/HMAC-MD5 в SSH2. Для сжатия шифруемых данных может использоваться алгоритм LempelZiv (LZ77), который обеспечивает такой же уровень сжатия, что и архиватор ZIP. Сжатие SSH включается лишь по запросу клиента, и на практике используется редко.

Основные характеристики протокола CMIP

CMIP реализует весь набор услуг CMIS. С помощью этих услуг протокол CMIP поддерживает следующую услугу удаленных операций:

Запрос (invoke);

Возврат результата;

Возврат ошибки;

Отклонение запроса пользователем услуги;

Отклонение запроса провайдером услуги.

Управляющая информация от менеджера к агенту, передаваемая по протоколу CMIP кодируется в соответствии с правилами ASN.1 и BER.

Для каждой операции определен формат блока данных, переносимых по сети от менеджера агенту, и наоборот.

Формат протокольных блоков данных CMIP описывается нотацией ASN.1 и имеет гораздо более сложную структуру, чем блоки SNMP. Например, блок данных операции M-GET имеет поля для задания имен атрибутов, значения которых запрашивает менеджер, а также поля задания параметров обзора и фильтрации. Имеются также поля для задания параметров прав доступа к объекту.

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

Уведомления агента CMIP всегда передаются с помощью надежного транспортного протокола и в случае потери будут переданы повторно.

Протокол CMIP рассчитан на агентов, которые могут по одной простой команде от менеджера выполнить сложную последовательность действий.

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

MIB для протокола CMIP не имеют единого стандарта и разрабатываются каждым производителем телекоммуникационного оборудования только для своего собственного оборудования. Исключение составляет только стандарт на MIB по системам передачи G.722, G.774.

Протокол CMIP и услуги CMIS