Лекции.Орг


Поиск:




Категории:

Астрономия
Биология
География
Другие языки
Интернет
Информатика
История
Культура
Литература
Логика
Математика
Медицина
Механика
Охрана труда
Педагогика
Политика
Право
Психология
Религия
Риторика
Социология
Спорт
Строительство
Технология
Транспорт
Физика
Философия
Финансы
Химия
Экология
Экономика
Электроника

 

 

 

 


Безопасность протокола Telnet




Имеются три главных проблемы связанные с использованием telnet, делая его плохим выбором для современных систем с точки зрения безопасности:

- используемые по умолчанию демоны telnet имеют несколько уязвимостей, обнаруженных за эти годы, и вероятно еще несколько до сих пор существуют;

- telnet не шифрует никакие данные, которые посылаются через установленную связь (включая пароли), и таким образом становиться возможным прослушивание связи и использовании пароль позже для злонамеренных целей;

- отсутствие системы аутентификации в telnet не дает никакой гарантии, что связь, установленная между двумя удаленными хостами не будет прервана в середине.

 

Нежелательно использование протокола telnet в системах, для которых важна безопасность, таких как общественный Интернет. Сеансы telnet не поддерживают шифрование данных. Это означает это любой, кто имеет доступ к любому маршрутизатору, коммутатору или шлюзу в сети между двумя удаленными компьютерами, соединенными сеансом связи по протоколу telnet, может перехватить проходящие пакеты и легко получить логин и пароль для доступа в систему (или завладеть любой другой информацией, которой обмениваются эти компьютеры) при помощи любой общедоступной утилиты подобно tcpdump и Ethereal.

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

Эксперты компьютерной безопасности, как например SANS Institute и члены телеконференции comp.os.linux.security рекомендуют отказаться от использования протокола telnet для удаленного доступа при всех нормальных обстоятельствах.

Когда telnet развивался в ранних 1980-ых (согласно некоторым источникам в 1969), большинство пользовательских компьютеров в сети было в компьютерных отделах академических учреждений, или в больших частных и правительственных научно-исследовательских институтах. В этой среде многие предприятия не были особого обеспокоены защитой до резкого увеличения пропускной способности 1990-ых. С экспоненциальным ростом числа пользователей сети Интернет, также резко увеличилось число людей, пытающихся взломать серверы этой сети. Как следствие протокол telnet не должен использоваться в сетях, имеющих доступ в Интернет.

Клиенты telnet до сих пор иногда используются для того, чтобы вручную «общаться» с некоторыми другими сервисами. Например это иногда бывает полезным для отладки сетевых служб типа SMTP или HTTP серверов, т.к этот способ делает простым отправку команд на сервер и изучение ответов сервера на те или иные команды. Telnet может также использоваться как элементарный IRC клиент, если Вы достаточно хорошо знаете протокол.

Telnet также может использоваться для Multi User Dungeon игр, которые работают через сеть Интернет.

История протокола SSH

В 1995 году Тату Илонен (Tatu Ylonen, Finland) представил на рассмотрение первую версию программы SSH и Интернет драфт (Internet draft) "The SSH (Secure Shell) Remote Login Protocol", который описывает протокол, используемый оригинальной программой SSH, который также известен как протокол SSH-1. Вскоре после этого была выпущена новая версия протокола SSH-2. В 1997 году по просьбе Тату Илонена, организация IETF организовала специальную группу SECSH, в обязанности которой входило дальнейшее развитие, усовершенствование и поддержкапротокола (см. ресурсы SSH).

Важно отметить, что сами по себе протоколы SSH-1 и SSH-2 различны. Т.е. если клиент запрашивает соединение с сервером протоколу SSH-1, а сервер поддерживает только протокол SSH-2, то соединение установлено не будет. Эта особенность связана с технической реализацией этих протоколов, которые, по большому счету, выполняют одни и теже функции. Более того использование протокола SSH-1 скорее всего свалится на системного администратора в виде лишней головной боли, чем предоставит реальную защиту передаваемых между системами данных.

 

Технология протокола SSH

SSH-1 vs. SSH-2

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

 

 
 

Описание технологии протокола SSH-1

Ниже на рисунке 1 дано описание работы протокола SSH-1:

Рисунок 1 алгоритм работы протокола SSH-1

 

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

Аутентификация сервера происходит исходя из его возможности расшифровки сессионного ключа, который зашифрован публичным ключом сервера. Аутентификация клиента может происходить различными способами, в том числе DSA, RSA, OpenPGP или по паролю.

Сессия продолжается до тех пор, пока и клиент и сервер способны аутентифицировать друг друга. Установленное соединение по протоколу SSH-1 позволяет защитить передаваемые данные стойким алгоритмом шифрования, проверкой целостности данных и сжатием.

 





Поделиться с друзьями:


Дата добавления: 2016-07-29; Мы поможем в написании ваших работ!; просмотров: 880 | Нарушение авторских прав


Поиск на сайте:

Лучшие изречения:

Чтобы получился студенческий борщ, его нужно варить также как и домашний, только без мяса и развести водой 1:10 © Неизвестно
==> читать все изречения...

2407 - | 2288 -


© 2015-2024 lektsii.org - Контакты - Последнее добавление

Ген: 0.008 с.