Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Пояснительная записка edited.doc
Скачиваний:
2
Добавлен:
23.09.2019
Размер:
1.11 Mб
Скачать
    1. Выбор протоколов взаимодействия с сетевым оборудованием

Данный раздел посвящен анализу протоколов, обзор которых был приведен выше.

Во-первых, хотелось бы сравнить между собой протоколы Telnet и rlogin. По требуемому функционалу они практически идентичны. Однако стоит отметить, что rlogin изначально разрабатывался в университете Berkley для «доверенного» управления компьютерами на базе Unix систем. На сегодняшний день существуют реализации данного протокола практически для всех популярных операционных систем, однако сегодня он используется довольно редко. Так как Telnet является более популярным протоколом на сегодняшний день (серверная и клиентская часть реализована практически в каждой операционной системе), в данной работе автором было решено использовать его вместо rlogin.

Что касается безопасности протокола Telnet, стоить отметить, что в контексте данного приложения данный протокол можно использовать, не опасаясь за угрозы безопасности, т.к. предполагается, что сеть сегментирована и управление осуществляется внеполосно (out-of-band).

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

Управление сетевым оборудованием по протоколу SSH - довольно распространенная практика, особенно в системах, где управление по протоколу Telnet представляет угрозу информационной безопасности (где невозможно внеполосное управление). В связи с этим, данный протокол принят к реализации.

Так же бывают случаи, когда управление оборудованием по вышеописанным протоколам невозможно, например, в силу неисправности оборудования (сервера Telnet или SSH). В таких случаях, для восстановления конфигурации, обычно используется подключение по протоколу RS-232. Понятно, что иметь резервную линию подключения по данному протоколу, несомненно, удобно при удаленном администрировании. Данный протокол принят к реализации.

Далее необходимо проанализировать протоколы мгновенных сообщений.

Все традиционные протоколы стандартизованы в объемном наборе документов, называемом RFC (Request For Comments). В RFC полностью описаны все форматы данных и способы поведения в различных ситуациях. Относительно же OSCAR мы не располагаем подобным сводом стандартов. Более того, стандарты целиком и полностью контролирует фирма-разработчик (Mirabilis, являющаяся частью America-on-line). Это означает, что обнаруженные уязвимости в системе безопасности протокола будут устраняться с такими скоростью и качеством, какие устраивают Mirabilis. Осложняет ситуацию то, что закрытый протокол традиционно более уязвим для всевозможных вредоносных воздействий. В самом деле, открытый протокол (например XMPP) обсуждается неограниченным кругом заинтересованных людей. Большое количество разнообразных специалистов способно отловить потенциальные уязвимости еще на этапе проектирования. Закрытый же протокол разрабатывается не таким большим количеством специалистов, которые просто не в силах охватить всевозможные разнообразные ситуации, когда программа может вести себя некорректно. А более опасно то, что уязвимости в открытых стандартах довольно быстро становятся известны и соответственно быстро исправляются. Закрытый стандарт более неповоротлив и скрытен по самой своей природе.

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