Диплом. А.П. Горбачев

РОССИЙСКАЯ ФЕДЕРАЦИЯ
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ МАТЕМАТИКИ, И КОМПЬЮТЕРНЫХ НАУК
КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
Допустить к защите в ГАК
Заведующий кафедрой
информационной безопасности
д.т.н., профессор
___________________А.А. Захаров
(подпись)
«____» _________ 20__ г.
Горбачев Александр Павлович
РАЗРАБОТКА СИСТЕМЫ УДАЛЕННОГО МОНИТОРИНГА И
УПРАВЛЕНИЯ СЕТЕВЫМ ОБОРУДОВАНИЕМ СРЕДСТВАМИ
КЛИЕНТОВ ОБМЕНА МГНОВЕННЫМИ СООБЩЕНИЯМИ
(Выпускная квалификационная работа)
Научный руководитель:
к.т.н. доцент
__________________ /Е.А. Оленников/
(подпись)
Автор работы:
___________________/А.П. Горбачев/
(подпись)
Тюмень – 2014
Содержание
ВВЕДЕНИЕ .............................................................................................................. 3
ГЛАВА 1.
ОСОБЕННОСТИ И СПЕЦИФИКА РЕАЛИЗАЦИИ
ПРОТОКОЛОВ ПЕРЕДАЧИ УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ И
ОБМЕНА МГНОВЕННЫМИ СООБЩЕНИЯМИ ............................................... 7
1.1.
Классические протоколы управления сетевым оборудованием ............ 7
1.2.
Протоколы передачи мгновенных сообщений ...................................... 11
1.3.
Выбор протоколов взаимодействия с сетевым оборудованием для
реализации их в разрабатываемой системе ........................................................ 13
ГЛАВА 2.
РАЗРАБОТКА И ТЕСТИРОВАНИЕ СИСТЕМЫ
ВЗАИМОДЕЙСТВИЯ ПРОТОКОЛОВ УПРАВЛЕНИЯ СЕТЕВЫМ
ОБОРУДОВАНИЕМ И ОБМЕНА МГНОВЕННЫМИ СООБЩЕНИЯМИ .... 16
2.1.
Определение сущностей проектируемой системы и схемы их
логического взаимодействия................................................................................ 16
2.2.
Общие сведения о приложении ............................................................... 18
2.3.
Функциональное назначение ................................................................... 19
2.1.
Структура приложения ............................................................................. 20
2.2.
Используемые технические средства ..................................................... 24
2.3.
Требования к программному окружению .............................................. 25
2.4.
Предварительная настройка сетевого оборудования ............................ 25
2.5.
Процедура установки................................................................................ 27
2.6.
Процедура настройки ............................................................................... 28
2.7.
Эксплуатация приложения ....................................................................... 36
2.8.
Тестирование в лабораторной среде ....................................................... 39
ГЛАВА 3.
АНАЛИЗ РИСКОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
ПРИ ИНТЕГРАЦИИ РАЗРАБОТАННОГО ПРИЛОЖЕНИЯ В
КОРПОРАТИВНУЮ ИНФОРМАЦИОННУЮ ИНФРАСТРУКТУРУ ........... 47
ЗАКЛЮЧЕНИЕ ..................................................................................................... 50
СПИСОК ЛИТЕРАТУРЫ..................................................................................... 51
3
ВВЕДЕНИЕ
Актуальность темы дипломной работы определяется быстрым
ростом
количества
компаний,
имеющих
сложную
информационную
структуру. Наряду с этим даже малый и средний бизнес переходит к графику
работы, значительно более широкому, чем стандартный восьмичасовой
рабочий день. Этому способствует появление высокоскоростного доступа в
интернет для домашних пользователей, удешевление технологии удаленного
доступа. Благодаря появлению виртуализации, термин «удаленное рабочее
место» приобрел новый смысл: теперь сотрудники компаний могут работать,
не выходя из дома, в удобное для себя время. Все эти факторы приводят к
тому, что работа по администрированию информационной инфраструктуры
компании должна выполняться фактически 24 часа в день 7 дней в неделю.
Обеспечить такой график администрирования возможно двумя способами.
Первый заключается в том, чтобы дополнительно нанять штат
администраторов, работающих посменно и постоянно контролирующих
работоспособность инфраструктуры. В этом случае, при появлении
неисправностей в функционировании оборудования администратор может
сигнализировать ответственному инженеру о проблеме в любое время суток.
Однако, необходимо увеличить операционные затраты на заработную плату
администраторов, при этом их общая загруженность будет довольно низкая не всегда пользователи работают с 2 ночи до 6 утра. Таким образом, в
большинстве случаев ночные дежурства будут пустой тратой денег для
компании.
Решение
кажется
единственно
верным,
но
является
неоптимальным.
Второй подход к решению проблемы является оптимизацией первого с
точки зрения операционных затрат и человеческих ресурсов. Для этого
необходимо разработать механизмы прямого взаимодействия, позволяющие
оборудованию воздействовать на инженера (информируя его о возможности
появления проблем) независимо от времени обращения последнего. При этом
4
такие
механизмы
должны
обеспечивать
возможность
моментальной
обратной связи, как со стороны инженера, так и со стороны оборудования.
Скорость реакции на появление проблемы пропорциональна количеству
реализуемых интерфейсов взаимодействия. Время решения проблемы
сводится к минимуму, т.к. в процессе больше не участвует третье звено
(администратор), взаимодействие происходит напрямую. Данный подход
позволяет
предупредить
инцидент
информационной
безопасности
за
максимально короткое время.
Степень
разработанности
проблемы.
Проблемы
управления
информационной инфраструктурой предприятий рассматривались в работах
многих отечественных исследователей и специалистов: Теленика С., Ролика
А., Можаровского П., Волошина А., Тарасова В., Горбатова В., Ясько С., а
также иностранных авторов - Д. Фалона, Д. Тана, А. Уижттенброека, Д.
Лошина и др.
Вместе с тем проведенные исследования охватывают только методы
управления
информационной
представлении
взаимодействия
и
только
как
инфраструктурой
частично
клиенты
обмена
касаются
в
классическом
таких
мгновенными
их
интерфейсов
сообщениями,
электронная почта и службы коротких сообщений, которые ориентированы
на текстовый ввод, как и классические методы терминального управления
устройствами. Системы обмена мгновенными сообщениями представляют
для управления информационной инфраструктурой больший интерес, так как
они сами по себе ориентированы на отражение состояния присутствия
человека (а в данном контексте, устройства) на другом конце. Все это и
предопределило цели и задачи дипломной работы.
Цель дипломной работы состоит в разработке системы для
удаленного
круглосуточного
мониторинга
и
управления
сетевым
оборудованием посредством туннелирования классических протоколов
управления оборудованием через протокол обмена мгновенных сообщений.
5
Поставленная цель обусловила следующие задачи дипломной
работы:
 изучить
и
проанализировать
протоколы
управления
сетевым
оборудованием и передачи мгновенных сообщений, выбрать наиболее
подходящие для реализации их в разрабатываемой системе;
 определить сущности проектируемой системы и архитектуру их
взаимодействия, с последующей реализацией и тестированием в
лабораторной среде;
 провести анализ рисков информационной безопасности.
Объектом
исследования
выступает
системы
управления
информационными инфраструктурами малого и среднего бизнеса.
Предметом
исследования
в
дипломной
работе
являются
современные средства коммуникации и их интеграция в методы управления
информационной
инфраструктурой
для
повышения
таких
аспектов
информационной безопасности предприятия, как целостность и доступность.
Методологической и теоретической основой дипломной работы
явились труды отечественных и зарубежных специалистов в области
информационной безопасности и управления информационными ресурсами,
производителей
сетевого
и
серверного
оборудования,
разработчиков
протоколов и архитектуры сети Интернет. В ходе работы над дипломной
работой использовалась информация, описывающая принципы построения и
функционирования протоколов обмена мгновенными сообщениями, а так же
протоколов терминального доступа для управления оборудованием.
Теоретическая значимость дипломного исследования состоит в
развитии и совершенствовании методологии управления оборудованием
информационной инфраструктуры предприятия.
Практическая значимость работы определяется тем, что ее
результаты
позволяют
повысить
степень
эффективности
управления
информационной инфраструктурой предприятия и снизить связанные с этим
операционные
расходы
при
использовании
разработанной
системы,
6
направленной на повышение уровня таких аспектов информационной
безопасности, как целостность и доступность информации.
Новизна дипломной работы заключается в разработке и реализации
кроссплатформенной модели управления информационной инфраструктурой
и отслеживания состояния оборудования с помощью систем обмена
мгновенными сообщениями.
Наиболее существенные результаты, полученные в процессе
исследования:
 возможность круглосуточного мониторинга оборудования без
необходимости подключения к сети предприятия по технологии
VPN;
 терминальный доступ к оборудованию без использования
терминальных клиентов на мобильных устройствах;
 возможность напрямую получать сообщения служб системного
журналирования
оборудования
без
использования
узкоспециализированного программного обеспечения
 возможность немедленной обратной связи после получения
уведомлений об ошибках на оборудовании.
Основные результаты работы успешно применяются в практической
деятельности ООО «Виндекс-Сервис».
7
ГЛАВА 1.
ОСОБЕННОСТИ И СПЕЦИФИКА
РЕАЛИЗАЦИИ ПРОТОКОЛОВ ПЕРЕДАЧИ
УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ И ОБМЕНА
МГНОВЕННЫМИ СООБЩЕНИЯМИ
1.1. Классические протоколы управления сетевым
оборудованием
1.1.1. Telnet
Telnet (англ.
TErminaL
NETwork)
—
классический
протокол
управления реализующий текстовый интерфейс управления по сети (на
сегодняшний день — по средством транспорта TCP). Данное название
(telnet) обычно имеют утилиты, реализующие клиентскую часть протокола.
Стандарт протокола описан в RFC 854 [1].
Основная
задача
протокола
заключается
в
возможности
взаимодействия терминальных устройств и терминальных процессов друг с
другом. Данный протокол может быть использован для связи вида терминалтерминал («связывание») или для связи процесс-процесс («распределенные
вычисления»). Протокол не предусматривает использования шифрования или
проверки подлинности данных. Поэтому он уязвим ко всем видам атак, к
которым уязвим его транспорт, то есть протокол TCP. Использование
данного протокола безопасно только в полностью контролируемой сети или с
применением защиты на сетевом уровне (различные реализации виртуальных
частных сетей). По причине ненадёжности от Telnet как средства управления
операционными системами давно отказались. Поэтому для организации
удаленного доступа, в настоящее время применяется протокол SSH, при
создании которого упор делался именно на вопросы безопасности.
8
1.1.2. SSH
SSH (англ. Secure SHell — «безопасная оболочка») — сетевой протокол
позволяющий производить безопасное удалённое управление операционной
системой и туннелирование TCP-сессий [2].
С помощью SSH можно не только удалённо управлять оборудованием
через командную оболочку, но и передавать по шифрованному каналу
различные мультимедиа потоки. По функциональности является схожим с
протоколами Telnet и rlogin, однако, в отличие от последних, шифрует весь
трафик, включая учетную информацию. Имеет достаточно широкий выбор
алгоритмов для реализации шифрования. Клиентские и серверные части
данного протокола доступны для большинства сетевых операционных
систем.
Протокол позволяет безопасно передавать в незащищённой среде
практически любой другой сетевой протокол.
Спецификация протокола описана в RFC 4251. Аутентификация
сервера происходит на основе алгоритмов электронно-цифровой подписи
(ЭЦП) RSA или DSA. Аутентификации клиента — аналогично, с помощью
ЭЦП RSA или DSA, однако, для обратной совместимости с Telnet
допускается также аутентификация при помощи пароля и сетевого адреса
клиентского
устройства
(для
обратной
совместимости
с
rlogin).
Аутентификация по паролю наиболее распространена — она безопасна, так
как пароль передается по зашифрованному виртуальному каналу.
1.1.3. RS-232
RS-232 (англ. Recommended Standard 232) — в телекоммуникациях,
стандарт последовательной асинхронной передачи двоичных данных между
терминалом (англ. Data Terminal Equipment, DTE) и коммуникационным
устройством (англ. Data Communication Equipment, DCE) [3].
Это интерфейс передачи информации между двумя устройствами на
расстоянии до 15 метров. Информация передается по проводам цифровым
сигналом с двумя уровнями напряжения. Логическому "0" соответствует
9
положительное напряжение (от +5 до +15 В для передатчика), а логической
"1" отрицательное (от -5 до -15 В для передатчика). Асинхронная передача
данных осуществляется с фиксированной скоростью при самосинхронизации
фронтом стартового бита. Данный стандарт был разработан для простого
применения, однозначно определяемого по его названию: «Интерфейс между
терминальным оборудованием и связным оборудованием с обменом по
последовательному двоичному коду».
Чаще всего используется в промышленном и узкоспециальном
оборудовании
(активное
сетевое
оборудование,
серверы,
блоки
автоматизации), встраиваемых устройствах. Присутствует на стационарных
персональных компьютерах и, как правило, отсутствует на портативных.
1.1.4. SNMP
SNMP (англ. Simple Network Management Protocol — простой протокол
управления сетью) — протокол управления на основе транспорта UDP.
Устройства, которые обычно поддерживают SNMP — это устройства, так
или иначе реализующие в себе стэк протоколов TCP/IP. SNMP состоит из
набора стандартов сетевого управления, включая протокол передачи данных
прикладного уровня, схему базы данных и набора объектов.
Данный протокол (как Telnet и SSH) реализуют управляемые и
управляющие системы. В состав управляемой системы входит агент,
отправляющий отчёты управляющей системе. По существу SNMP агенты
передают служебную информацию на управляющие системы как переменные
[4].
Управляющая система может получить информацию через операции
протокола GET, GETNEXT и GETBULK. Агент может самостоятельно без
запроса отправить данные, используя операцию протокола TRAP или
INFORM. Управляющие системы могут также отправлять конфигурационные
обновления или контролирующие запросы, используя операцию SET для
непосредственного управления системой. Операции конфигурирования и
управления используются только тогда, когда нужны изменения в сетевой
10
инфраструктуре. Операции мониторинга обычно выполняются на регулярной
основе.
Управляемый объект является одной из конкретных характеристик
управляемого устройства. Примером управляемого объекта является atInput
— скалярный объект, содержащий один экземпляр объекта, а именно
целочисленное значение, показывающее общее количество входных пакетов
AppleTalk на интерфейсе маршрутизатора. Управляемые объекты состоят из
одного или более экземпляра объекта (определяется их идентификаторами),
которые по существу являются переменными. Есть два типа управляемых
объектов — скалярные, которые определяют один экземпляр объекта и
табличные, определяющие несколько связанных экземпляров объектов,
сгруппированных в таблицы. Идентификатор объекта (OID) однозначно
определяет управляемый объект в иерархии MIB [5].
1.1.5. RLOGIN
Протокол RLOGIN (англ. Remote LOGIN — удалённый вход в систему)
— протокол прикладного уровня, позволяющий пользователям *nixподобных систем подключаться к другим машинам и работать так же, как
при прямом подключении терминала к машине. Этот протокол обеспечивает
такой же сервис, как протокол TELNET [6].
Данный протокол, как и Telnet, имеет значительные недостатки в
системе безопасности — вся информация, включая учетную, передается
незащищенной. Протокол частично доверяет клиенту rlogin удалённой
машины, предоставляя ему информацию честно (включая порт и имя хоста).
Таким образом, злоумышленник может воспользоваться этим и получить
доступ, в силу того, что этот протокол никак не подразделяет удалённые
хосты на зоны доверия. Общая практика монтирования домашних
директорий пользователей через NFS (Network File System) подвергает rlogin
атаковать путем подделывания файлов .rhosts (в которых хранится учетная
информация) — это означает, что единственной защитой в этом случае
является безопасность самой NFS.
11
1.2. Протоколы передачи мгновенных сообщений
1.2.1. XMPP
XMPP (Extensible Messaging and Presence Protocol — расширяемый
протокол обмена сообщениями и информацией о присутствии) — набор
технологий для обмена мгновенными сообщениями, информацией о
присутствии, конференц-чата, видео и голосовых звонков и др. [7].
XMPP изначально был разработан сообществом Jabber для обеспечения
открытой,
безопасной,
свободной
от
спама,
децентрализованной
альтернативы закрытым коммерческим сервисам обмена мгновенными
сообщениями на тот момент. XMPP имеет несколько ключевых достоинств
по сравнению с подобными закрытыми системами:
Открытость — протокол XMPP открытый и легко изучаемый, в связи с
чем существует множество реализаций клиентских и серверных частей,
серверных компонентов и наборов библиотек для разработчиков.
Является стандартом — Internet Engineering Task Force (IETF)
официально утвердили XML-потоковые протоколы как технологию обмена
мгновенными сообщениями и информацией о присутствии. Спецификации
протокола были опубликованы в RFC 3920 и RFC 3921 в 2004 году. В 2011
году они были пересмотрены, в результате чего появились более
современные спецификации (RFC 6120, RFC 6121, и RFC 6122).
Надежность — первые приложения на основе технологий Jabber/XMPP
были разработаны в 1998 году, и являются стабильно работающими по сей
день [8]. Тысячи разработчиков работают над улучшением этих технологий,
десятки тысяч серверов на базе данных технологий функционируют на
сегодняшний день и миллионы людей используют XMPP для обмена
мгновенными сообщениями через публичные сервисы, такие как Facebook,
Google Talk, ВКонтакте, Одноклассники.ru, Я.Онлайн, QIP, LiveJournal и др.
Децентрализованность
—
архитектура
сети
XMPP
подобна
электронной почте; в результате чего, каждый может запустить свой XMPP
12
сервер, регистрировать на нём пользователей или целые организации, чтобы
контролировать обмен информацией внутри и за пределами организации [9].
Безопасность — любой XMPP сервер может быть изолирован от
публичной
сети
(например,
во
внутренней
сети
организации),
отказоустойчивые механизмы безопасности, реализованные с помощью
протоколов SASL и TLS, изначально заложены в спецификации XMPP.
Расширяемость — используя возможности XML, любой желающий
может спроектировать свой собственный функционал на базе основных
протоколов. А для поддержки взаимодействия, данные расширения
публикуются в сообществе и устанавливаются по желанию пользователя.
Гибкость — приложения на базе XMPP кроме обмена мгновенными
сообщениями включают в себя распространение контента, инструменты для
взаимодействия
пользователей,
передачу
файлов,
игры,
удаленный
мониторинг систем, веб-сервисы, облачные вычисления и многое другое.
Одним из удобных инструментов является возможность реализовать ICQтранспорт в случае, когда пользователь использует XMPP-клиент, но хочет
взаимодействовать с другими пользователями, использующими сервис ICQ.
1.2.2. OSCAR
OSCAR (Open System for CommunicAtion in Realtime) - открытый (с 5
марта 2008 года), но не свободный сетевой протокол, обеспечивающий обмен
мгновенными и офлайновыми текстовыми сообщениями. В данный момент
используется для двух систем: AIM (компания AOL, управляемая Time
Warner) и ICQ (компания Mail.Ru Group) [10].
Каждому пользователю присваивается UIN (англ. Unique Identification
Number)
—
уникальный
идентификационный
номер,
по
которому
пользователь однозначно определяется системой и другими пользователями
[11]. В AOL Instant Messenger функцию UIN играет SN (Screen Name) — так
называемые экранные имена, уникальные для каждого пользователя.
Существует большое количество альтернативных клиентов ICQ для
разных операционных систем, например: Miranda IM (Windows), QIP
13
(Windows, Android), &RQ (Windows), Pidgin (Windows, GNU/Linux), Licq
(GNU/Linux), Kopete (GNU/Linux), qutIM (Windows, GNU/Linux, Mac OS X),
Adium (Mac OS X) и пр.
5 марта 2008 года AOL открыла спецификации протокола [12] (как
оказалось в дальнейшем, не полностью: с помощью изменения закрытых
деталей
спецификации
впоследствии
3
раза
блокировались
все
неофициальные клиенты) и разрешила создание альтернативных клиентов,
но с некоторыми ограничениями, установленными лицензией: например,
клиент, используемый более чем 100 000 пользователей, должен показывать
рекламу. 12 июля 2010 года AOL вновь закрыла спецификации протокола.
Так как неофициальные спецификации разнятся в той или иной мере, к тому
же являются достаточно устаревшими, можно сказать, что данный протокол
плохо документирован на сегодняшний день.
1.3. Выбор протоколов взаимодействия с сетевым
оборудованием для реализации их в
разрабатываемой системе
В первую очередь, необходимо выбрать один из двух протоколов —
Telnet или rlogin. По требуемому функционалу они практически идентичны.
Однако стоит отметить, что rlogin изначально разрабатывался в университете
Berkley для «доверенного» управления компьютерами на базе Unix систем.
На
сегодняшний
день
существуют
реализации
данного
протокола
практически для всех популярных операционных систем, однако сегодня он
используется довольно редко. Так как Telnet является более популярным
протоколом на сегодняшний день (серверная и клиентская часть реализована
практически в каждой операционной системе), в данной работе было решено
использовать его вместо rlogin.
Что касается безопасности протокола Telnet, стоить отметить, что в
контексте данного приложения данный протокол можно использовать, не
14
опасаясь
за
угрозы
безопасности,
т.к.
предполагается,
что
сеть
сегментирована и управление осуществляется внеполосно (out-of-band).
Протокол SNMP было решено реализовать частично – только в
качестве системы дополнительного мониторинга (серверная часть), т.к.
основная идея заключается именно в эмуляции виртуального терминала,
чтобы администратор пользовался уже знакомыми командами операционной
системы.
Управление сетевым оборудованием по протоколу SSH - довольно
распространенная практика, особенно в системах, где управление по
протоколу Telnet представляет угрозу информационной безопасности (где
невозможно внеполосное управление). В связи с этим, данный протокол так
же принят к реализации.
Кроме того, бывают случаи, когда управление оборудованием по
вышеописанным протоколам невозможно, например, в силу неисправности
оборудования (сервера Telnet или SSH). В таких случаях, для восстановления
конфигурации, обычно используется подключение по протоколу RS-232.
Понятно, что иметь резервную линию подключения по данному протоколу,
несомненно, удобно при удаленном администрировании. Данный протокол
принят к реализации.
В рамках данного исследования представляется необходимым так же
акцентировать внимание на распространенности, масштабируемости и
безопасности протоколов обмена мгновенными сообщениями.
Все традиционные протоколы стандартизованы в объемном наборе
документов, называемом RFC (Request For Comments). В RFC полностью
описаны все форматы данных и способы поведения в различных ситуациях.
Относительно же OSCAR сообщество разработчиков не располагает
подобным сводом стандартов. Более того, стандарты целиком и полностью
контролирует фирма-разработчик (Mirabilis, являющаяся частью America-online). Это означает, что обнаруженные уязвимости в системе безопасности
протокола будут устраняться с такими скоростью и качеством, какие
15
устраивают Mirabilis. Осложняет ситуацию то, что закрытый протокол
традиционно более уязвим для всевозможных вредоносных воздействий.
Кроме этого, согласно правилам использования сервиса ICQ, вся переписка
проходит
через
серверы
компании-владельца,
авторские
права
на
передаваемые сообщения передаются ей и она оставляет за собой право на
публикацию и распространение этой информации. Таким образом, ICQ не
гарантирует полной конфиденциальности передаваемых сведений [13]. В
самом
деле,
открытый
протокол
(например,
XMPP)
обсуждается
неограниченным кругом заинтересованных людей. Большое количество
разнообразных специалистов способно отловить потенциальные уязвимости
еще на этапе проектирования. Закрытый же протокол разрабатывается не
таким большим количеством специалистов, которые просто не в силах
охватить разнообразные ситуации, при которых программа может вести себя
некорректно. А еще более опасно то, что уязвимости в открытых стандартах
довольно
быстро
становятся
известны
и,
соответственно,
быстро
исправляются. Закрытый стандарт более неповоротлив и скрытен по самой
своей природе.
После обзора вышеописанных протоколов, в качестве протокола
передачи мгновенных сообщений был выбран протокол XMPP, в силу его
открытости, расширяемости и децентрализованности. Хотя поддержку
протокола OSCAR было решено не внедрять, при необходимости есть
возможность использовать ICQ-транспорт, как было описано выше.
Таким образом, был проведен обзор протоколов управления сетевым
оборудованием и обмена мгновенными сообщениями, а также были
рассмотрены их достоинства и недостатки. В качестве туннелируемых
протоколов управления были выбраны протоколы Telnet, SSH, RS-232 и
серверная часть протокола SNMP. В качестве туннелирующего протокола
обмена мгновенными сообщениями был выбран протокол XMPP.
16
ГЛАВА 2.
РАЗРАБОТКА И ТЕСТИРОВАНИЕ СИСТЕМЫ
ВЗАИМОДЕЙСТВИЯ ПРОТОКОЛОВ УПРАВЛЕНИЯ
СЕТЕВЫМ ОБОРУДОВАНИЕМ И ОБМЕНА
МГНОВЕННЫМИ СООБЩЕНИЯМИ
2.1. Определение сущностей проектируемой
системы и схемы их логического взаимодействия
Перед тем, как приступить к реализации системы (приложения),
необходимо определить ряд необходимых и достаточных сущностей и
построить логическую модель проектируемой системы.
Первая сущность, необходимая для работы системы – это, очевидно,
пользователь (User) – администратор сетевого оборудования. В рамках
данной системы пользователь должен использовать клиентское приложение
для
передачи
мгновенных
сообщений
по
протоколу
XMPP
для
взаимодействия с оборудованием.
Очевидно, что любое клиентское приложение, поддерживающее
протокол
XMPP,
может
взаимодействовать
только
с
приложением,
поддерживающим этот же самый протокол. Таким образом, вторая сущность
– XMPP-клиент (Client).
Для
того
чтобы
сетевое
оборудование
«понимало»
команды,
отправленные по протоколу XMPP, должна быть установлена сессия
(Session) (выделенная для каждого администратора) по одному из трех
протоколов – Telnet, SSH или RS-232, куда будут транслироваться
передаваемые команды управления сетевым оборудованием.
Рисунок 1. Минимальный набор необходимых сущностей
17
Так, определен минимальный набор сущностей (Рис. 1), для того,
чтобы система отвечала заявленному функционалу.
Возможны ситуации, администратору необходимо контролировать
несколько устройств, каждое из которых должно управляться по разным
протоколам? В таком случае необходимо ввести сущность устройства
(Device), чтобы была возможность логически сгруппировать множество
сессий. Теперь у каждого устройства есть свой собственный XMPP-клиент,
используя
который
можно
переключаться
между сессиями
данного
устройства. Но можно представить ситуацию, когда администратор
управляет очень большим количеством оборудования и, в этой связи, список
контактов в XMPP-клиенте на стороне администратора будет слишком
большим, что может доставлять неудобства. Поэтому, нужно ввести еще
одну сущность, которая будет олицетворять логическую группу устройств –
мост (Bridge).
Конечно, вполне может быть и так, что администратору необходимо
установить всего лишь одну сессию. Поэтому, по типу подключения мост
разделяется на «точка-точка» (point-to-point, p2p) и «точка-многоточка»
(multipoint). Так, определен набор достаточных сущностей (Рис. 2)
проектируемой системы.
Рисунок 2. Набор достаточных сущностей
18
Следует также рассмотреть случай, когда XMPP-клиент со стороны
моста может выйти из строя. Для отказоустойчивости будет правильным
иметь несколько XMPP-клиентов и сущность, которая их агрегирует –
XMPP-шлюз (Gateway).
Как отмечалось выше, было решено внедрить частичную поддержку
протокола SNMP для возможности дополнительного мониторинга. SNMPсервер (SNMP-monitor) должен прослушивать сеть на предмет snmpуведомлений от администрируемых устройств и в случае получения таких
уведомлений давать команду XMPP-шлюзу отослать данное уведомление
всем администраторам моста, в составе которого находится данное
устройство. Учитывая эти изменения, определена конечная логическая схема
взаимодействия определенных сущностей (Рис. 3).
Рисунок 3. Конечная схема взаимодействия определенных сущностей
2.2. Общие сведения о приложении
Система
реализована
в
виде
Win32-приложения
на
языке
программирования C# [14, 15, 16, 17], на базе набора библиотек .NET
Framework 4.0 [18]. Приложение не требует дополнительного программного
обеспечения для функционирования. Объем исходных текстов приложения
19
составляет 17,091 мегабайт. Объем исполняемых модулей приложения
составляет 3,067 мегабайт. Время работы приложения – линейное – в
среднем требуется одна секунда для установки сессии для каждого
пользователя при полосе пропускания 100Мбит/с.
2.3. Функциональное назначение
Данное приложение решает класс задач по удаленному управлению
любыми операционными системами, которые поддерживают управление
через протоколы SSH, TELNET и RS-232. В частности, данное приложение,
по большей части, адаптировано для управления операционной системой
Cisco IOS. Не смотря на это, с его помощью так же вполне можно управлять
серверами на базе Linux\UNIX\BSD\Windows систем.
На рис. 4 приведен пример использования приложения: практически
для каждой операционной системы существует XMPP-совместимый клиент,
который должен взаимодействовать с XMPP-сервером по протоколу TLS. В
управляемой сети должен быть сервер, на котором установлено данное
приложение, которое так же взаимодействует с XMPP-сервером по
протоколу TLS. К серверу, сетевое оборудование может быть подключено
как по консоли (RS-232) так и по сети (через управляющую подсеть).
Рисунок 4. Пример использования приложения
20
2.1. Структура приложения
Далее будет рассмотрена структура приложения (Рис. 5), созданная на
основе логической схемы взаимодействия сущностей, приведенной выше.
Помимо основных модулей, в структуру также включены дополнительные,
отвечающие
за
настройку,
управление
вводом\выводом
и
защиту
приложения.
Рисунок 5. Структура приложения
Main Service — корневой модуль, служба Windows. Запускается
автоматически при старте операционной системы. Таким образом, решена
проблема ручного запуска приложения при каждой перезагрузке, которая
присутствовала в предыдущих реализациях данного приложения. На данном
этапе служба предоставляет достаточно отладочной информации при старте,
остановке и возникших исключительных ситуациях.
XML Config Parser — данный модуль служит для создания и
редактирования файла конфигурации. Сам файл конфигурации представляет
21
собой разметку в формате XML. При запуске приложения данный модуль
проверяет наличие файла конфигурации, если он существует, данные из него
загружаются в приложение и используются при создании сессий.
В целом можно говорить о том, что данный модуль есть своеобразный
«каркас» (framework) для удобной работы с файлами XML [19, 20, 21]
разметки по данной предметной области.
В ходе работы было принято решение не внедрять поддержку
сторонних СУБД для хранения конфигурационной информации по причине
того, что любая сторонняя СУБД может стать уязвимым местом в
безопасности приложения. Кроме этого, промышленные СУБД, которые
могут обеспечить должный уровень безопасности стоят довольно дорого, изза чего конечный пользователь может понести большие расходы.
AES — используется компонентом XML Config Parser для шифрования
и расшифрования файла конфигурации на 256-битнном ключе.
GHOST Hash, Cipher — используется компонентом XML Config
Parser
для
используется
хэширования
как
ключ
секретного
для
ключа.
шифрования
Результат
и
хэш-функции
расшифрования
файла
конфигурации компонентом AES. Хэш-функция реализована по стандарту
ГОСТ Р 34.11-94.
Web GUI — веб-интерфейс для настройки приложения. Использует
модуль XML Config Parser. Работает на базе встроенного веб-сервера,
генерирующего весь HTML-код «на лету», что освобождает пользователя от
нужды в установке и настройке дополнительного программного обеспечения
выполняющее функции веб-сервера (например, IIS, Apache и т.д.).
Конфигурирование приложения осуществляется только по протоколу
SSL 3.0.
Bridge — в данном модуле сосредоточена значительная часть
функционала приложения. Он отвечает за инициализацию XMPP-шлюза и
пула сессий для каждого моста. Данным модулем можно управлять в
реальном времени, используя следующий список команд:
22
Команда
!help
Описание
Возвращает список доступных
управляющих команд.
!passwd=<user_password>
Открывает сессию.
!close
Закрывает сессию
!list
!sid
!switch <device> <connection>
!reboot
Возвращает список подключений
текущего моста.
Возвращает идентификатор текущей
сессии.
В случае если мост имеет тип «точкамноготочка», переключает сессию.
Перезагружает конфигурацию для
текущего моста.
!reload
Перезагружает текущую сессию.
!bstatus
Возвращает статус текущего моста.
!async
!sync
Активирует асинхронный режим
чтения (активирован по умолчанию).
Активирует синхронный (блочный)
режим чтения.
Таблица 1. Управляющие команды модуля Bridge
Необходимо заметить, что может возникнуть ситуация, когда в мосте
типа «точка-многоточка» может присутствовать подключение по протоколу
RS-232. Если количество подключений по протоколам Telnet и SSH
ограничено только количеством виртуальных терминалов управляемой
операционной системы, то подключение по протоколу RS-232 ограничено
физическим количеством портов на рабочей станции. В штатной ситуации
такой порт присутствует в единственном числе, вследствие чего по данному
протоколу может быть открыта только одна сессия на всю рабочую станцию.
23
Так как обычно такой тип соединения считается резервным, не исключена
возможность, что он может быть как неразделяемым, так и разделяемым.
Данный модуль разрешает конфликты, связанные с данным типом
подключения, в случае, если сессия неразделяемая и контролирует
правильность вывода для каждого администратора, использующего данную
сессию, если она разделяемая.
XMPP Client — модуль, реализующий клиентскую часть для обмена
мгновенными сообщениями по протоколу XMPP. По умолчанию все
подключения осуществляются по протоколам SASL и TLS 1.2.
SNMP Monitor — данный модуль реализует серверную часть
протокола
SNMP.
При
запуске
службы,
модуль
входит
в
режим
прослушивания сети на предмет SNMP-оповещений. Если модуль получает
подобное оповещение, он определяет устройство (идентификатор сессии) от
которого
пришло
данное
уведомление
и
посылает
его
каждому
администратору этого моста, в рамках которого сконфигурировано данное
устройство.
На
данном
этапе
модуль
поддерживает
только
базы
управляющей информации компании Cisco.
Session — промежуточный компонент между модулями Bridge и
Coordinator. Выполняет функцию аутентификатора. Чтобы получить доступ к
оборудованию, администратор должен каждый раз вводить пароль по
истечению срока сессии. Срок сессии устанавливается при создании
пользователя.
Coordinator — модуль, управляющий терминированием подключений
и вводом\выводом.
Terminal
Formatter
—
данный
компонент
предназначен
для
форматирования ввода\вывода. При получении команд от пользователя, в
случае,
если
команда
является
служебной
–
компонент
посылает
оборудованию необходимые escape-символы\последовательности. Далее
приведен список служебных команд:
24
Команда
ASCII-код (dec)
!c
\03 (CTRL + C)
!t
\09 (TAB)
!rn
\13\10 (ENTER)
!e
\30 (CTRL + SHIFT + 6)
!ret
\30\120 (CTRL + SHIFT + 6 + x)
Таблица 2. Служебные команды сервера трансляции
При получении ответных данных от оборудования, компонент
проверяет вывод на наличие любой учетной информации. В случае
нахождения таких данных, они удаляются из вывода, точнее заменяются на
строку !<output omitted>, что свидетельствует о том, что информация
присутствует в конфигурации, но не отображается в целях безопасности. В
дальнейшем
планируется
расширить
список
служебных
команд
(в
зависимости от оборудования) и дать пользователю возможность самому
назначать служебные команды.
Tamir.SharpSSH, Minimalistic Telnet и Serial Connector реализуют
подключения по протоколам SSH, Telnet и RS-232 соответственно.
2.2. Используемые технические средства
Минимальный набор технических средств, обеспечивающий работу
приложения, вытекает из системных требований к платформе, на которой
базируется приложение (.NET Framework 4.0) [22, 23]:
 процессор Pentium III с частотой 1 ГГц;
 не менее 512 МБ оперативной памяти;
 10 МБ свободного места на жестком диске;
 клавиатура, мышь или совместимое указывающее устройство;
 видеокарта и монитор, поддерживающие режим Super VGA с
разрешением не менее чем 800x600 точек;
 сетевой адаптер 10/100TX.
25
2.3. Требования к программному окружению
Минимально
допустимая
версия
операционной
системы
для
функционирования приложения – Microsoft Windows XP (x32) Service Pack 2.
Также необходимо наличие установленной платформы .NET Framework 4.0.
Для настройки приложения необходимо наличие установленного веббраузера Google Chrome (версии 17 или выше) или Mozilla Firefox (версии 10
или выше). Поддержка браузера Microsoft Internet Explorer не предусмотрена.
Тестирование на совместимость веб-интерфейса с другими браузерами не
производилась.
2.4. Предварительная настройка сетевого
оборудования
Перед тем, как произвести установку и настройку приложения,
рекомендуется предварительно сконфигурировать должным образом сетевое
оборудование. В приведенных ниже примерах рассматривается настройка
оборудования без какой-либо предварительной конфигурации (out-of-box)
для топологии, изображенной на рисунке 6. Так как характер конфигурации
является рекомендательным, пользователь может применять, не применять
или изменять отдельные настройки по своему усмотрению. Примеры
конфигурации будут приводиться в контексте сетевого оборудования
компании Cisco Systems в силу того, что приложение адаптировано именно
под операционную систему Cisco IOS.
Рисунок 6. Топология для примера конфигурации
26
После того как пользователь подключился к оборудованию, для начала
необходимо войти в привилегированный режим, установить на него пароль и
назначить имя устройства.
Router> enable
Router# configure terminal
Router(config)# enable secret verylongpassword
Router(config)# hostname R2
Далее войти в режим конфигурации каждого интерфейса, назначить сетевые
адреса и включить их.
R2(config)# interface FastEthernet0/1
R2(config-if)# ip address 192.168.1.250 255.255.255.0
R2(config-if)# no shutdown
R2(config-if)# exit
Добавить
на
оборудовании
учетную
запись,
под
которой
будет
авторизовываться приложение, и сконфигурировать терминальные линии.
R2(config)# username admin privilege 15 secret instant_shell
R2(config)# line vty 0 15
R2(config-line)# login local
R2(config-line)# privilege level 15
R2(config-line)# transport input telnet ssh
R2(config-line)# exit
Если приложению необходим консольный доступ, сконфигурировать так же
консольную линию.
R2(config)# line
R2(config-line)#
R2(config-line)#
R2(config-line)#
console 0
login local
privilege level 15
exit
Для того чтобы оборудование могло посылать приложению SNMPуведомления, например, об изменении состояния конфигурации и состоянии
процесса протокола маршрутизации eigrp, необходимо ввести настройки,
определяющие SNMP-сервер и типы уведомлений.
snmp-server community public RO
snmp-server trap-source FastEthernet0/1
R2(config)# snmp-server host 192.168.1.10 version 2c
my_community_string config eigrp
R2(config)# snmp-server enable traps config
R2(config)# snmp-server enable traps eigrp
27
2.5. Процедура установки
Установка приложения на рабочую станцию производится из пакета
установки, созданного стандартными средствами Microsoft Visual Studio
Приложение
2010.
устанавливается
в
системную
директорию
<RootDrive>:\Windows\System32 для 32-разрядных операционных систем или
<RootDrive>:\Windows\SysWOW64 для 64-разрядных операционных систем,
где <RootDrive> - буква диска, на котором установлена операционная
система.
После копирования файлов, установщик автоматически запускает
службу (Рис. 7) и показывает диалоговое окно, где сообщается адрес, порт,
имя пользователя и пароль для входа в систему по умолчанию, а так же
присутствует гиперссылка для перехода в консоль администрирования (вебинтерфейс) (Рис. 8).
Для удобства пользователя, помимо самой службы, на панель задач
устанавливается вспомогательное приложение, позволяющее контролировать
работу службы (Рис. 9) – запускать, останавливать или открыть консоль
администрирования.
Рисунок 7. Окно управления службами Windows
28
Рисунок 8. Окно завершения установки приложения
Рисунок 9. Вспомогательное приложение на панели задач
2.6. Процедура настройки
После завершения процедуры установки пользователь должен открыть
консоль управления через веб-браузер и произвести настройку приложения
на основе рассматриваемой топологии сети.
29
При входе в консоль управления пользователю необходимо выполнить
авторизацию (Рис. 10) в системе, используя учетные данные по умолчанию.
Рисунок 10. Страница авторизации консоли управления
После успешной авторизации пользователю будет представлена
титульная страница («Server»), отображающая информацию о сервере и
лицензии, а так же лента новостей касательно новых версий и критических
обновлений приложения. На данной странице пользователь должен ввести
выписанный ему лицензионный ключ, адрес электронной почты, на который
был выписан лицензионный ключ и, при необходимости, изменить адрес
сервера проверки лицензий.
Стоит отметить, что механизм лицензирования (выдачи и проверки
лицензий) выходит за рамки данной дипломной работы и, на момент ее
написания, находится на стадии разработки.
30
На
странице
«Users»
(Рис.
11)
отображается
информация
о
пользователях системы с возможностями добавления, редактирования и
удаления учетных записей. В целях обеспечения безопасности конфигурации
приложения и сетевого оборудования автор настоятельно рекомендует в
первую очередь сменить пароль учетной записи по умолчанию и, при
создании пользователей, не использовать тривиальные пароли.
Рисунок 11. Страница управления учетными записями
Для добавления учетной записи пользователь должен нажать на значок
добавления в правом верхнем углу рабочей области страницы. Далее
пользователю будет представлена страница (Рис. 12), на которой предложено
ввести следующую информацию:
 Instant messenger ID – идентификатор учетной записи пользователя,
который используется для входа в клиентское приложение обмена
мгновенными сообщениями по протоколу XMPP.
31
 Password – пароль пользователя в системе. Используется для входа в
консоль
управления
(в
случае
если
пользователь
является
администратором системы) и для открытия сессии взаимодействия с
терминальным эмулятором.
 Confirm password – подтверждение пароля.
 Session timeout – временной интервал, по истечению которого,
пользователь должен вводить пароль от своей учетной записи при
взаимодействии с оборудованием через клиент обмена мгновенными
сообщениями.
 Is admin – определяет, имеет ли пользователь доступ к консоли
управления приложением.
Рисунок 12. Страница управления учетными записями
32
Далее необходимо сконфигурировать мост. Для этого нужно перейти
на страницу «Bridges» и нажать на значок добавления моста в правом
верхнем углу рабочей области страницы. Пользователю необходимо будет
ввести имя моста и указать его тип (p2p или multipoint) (Рис. 13).
Рисунок 13. Блок добавления моста
После нажатия кнопки «Create bridge» пользователь автоматически
попадает на страницу конфигурации созданного моста (Рис. 14). Рабочая
область состоит из 5 блоков описанных ниже.
Рисунок 14. Страница конфигурации моста
33
Bridge – отображает имя моста и его тип. При необходимости можно
изменить имя моста, нажав на значок редактирования в правом верхнем
углу блока.
Users – содержит список учетных записей, у которых есть права
доступа к этому мосту через клиент обмена мгновенными сообщениями. Для
того чтобы добавить учетную запись к данному мосту, необходимо нажать на
значок добавления в правом верхнем углу блока. Пользователю будет
представлен выпадающий список, где он может выбрать учетную запись из
существующих
в
приложении.
Для
удаления
учетной
записи
из
конфигурации моста необходимо нажать на значок удаления напротив
учетной записи.
Gateways – содержит список учетных записей XMPP-шлюза, через
которые пользователи моста будут обращаться к сетевому оборудованию.
Для добавления учетной записи пользователь должен нажать на значок
добавления в правом верхнем углу блока. Появится форма для ввода
идентификатора и пароля учетной записи. Предварительно рекомендуется
зарегистрировать учетную запись на предпочитаемом XMPP-сервере и
проверить её на работоспособность, используя любой XMPP-клиент. Для
удаления учетной записи XMPP-шлюза пользователь должен нажать на
значок удаления напротив идентификатора учетной записи.
Devices – содержит список устройств. Данный блок отсутствует в
режиме конфигурации моста типа «p2p». Для добавления устройства
пользователь должен нажать на значок добавления в правом верхнем углу
блока, после чего ему будет предложено ввести имя нового устройства. Для
того, чтобы переименовать или удалить устройство пользователь должен
нажать на значок изменения или удаления соответственно напротив имени
устройства. Как отмечалось выше, понятие устройства в данном приложении
весьма условно и необходимо только для логической группировки
терминальных соединений.
34
Connections – содержит список терминальных соединений. В режиме
конфигурации моста типа «multipoint» перед добавлением нового соединения
необходимо добавить хотя бы одно устройство. В режиме конфигурации
моста типа «p2p» пользователь может добавить не более одного соединения.
Для добавления нового соединения пользователь должен нажать на значок
добавления в правом верхнем углу блока. Пользователю будет предложена
форма для заполнения соединения:
 Device – выбор устройства (только для режима «multipoint»);
 Connection
type
–
выбор
протокола
соединения
(telnet,
ssh,
serial (RS-232);
 Username – имя учетной записи на физическом устройстве.
 Password – пароль учетной записи на физическом устройстве.
 Confirm password – подтверждение пароля.
Для соединения по протоколам telnet и ssh:
 IP address – сетевой адрес физического устройства;
 Port – порт физического устройства.
Для соединения по протоколу serial (RS-232):
 Portname – имя последовательного порта;
 Baudrate – скорость последовательного соединения (от 110 до
921600 бод);
 Parity – четность (0 – none, 1- odd, 2 – even, 3 – mark, 4- space);
 Databits – количество бит данных в каждом символе (от 5 до 9);
 Stopbits – количество стоп-битов (0 – none, 1 – one, 2 – two, 3 OnePointFive);
 Shared – определяет, является ли подключение разделяемым.
После того, как пользователь создал мост, необходимо перезапустить
службу через диспетчер служб Windows или вспомогательное приложение на
панели задач для того, чтобы изменения конфигурации приложения вступили
в силу. Далее, при изменении конфигурации созданного моста, пользователь
с правами администратора может перезагружать его конфигурацию прямо
35
через клиент обмена мгновенными сообщениями командой «!reboot». На
странице «Bridges» пользователь может просматривать информацию о
созданных мостах (Рис. 15). Пользователь может нажать на имя моста для
того, чтобы отобразить подробную информацию о подключениях.
Рисунок 15. Страница информации о существующих мостах
На странице «Log» (Рис. 16) пользователь может просматривать записи
системного журнала, наблюдая за ходом работы приложения. На данном
этапе в системный журнал выводится достаточно отладочной информации
для того, чтобы диагностировать возможные проблемы функционирования
приложения. Помимо сообщений об ошибках, отладочная информация
включает в себя SNMP-оповещения, информацию о переключении сессий,
запросы на перезагрузку конфигурации моста, сообщения XMPP-шлюза,
сообщения об установке и разрыве терминальных соединений и т.д.
36
Рисунок 16. Страница системного журнала
2.7. Эксплуатация приложения
После
того,
как
выполнена
предварительная
конфигурация
управляемого сетевого оборудования, приложение установлено и настроено,
пользователь должен войти в клиент обмена мгновенными сообщениями под
одной из учетных записей, которые были сконфигурированы в блоке «Users»
в настройках моста.
Далее пользователь должен добавить контакт, сконфигурированный в
блоке «Gateways» в настройках моста. После добавления в контакт-лист,
статус контакта должен быть «В сети» (Рис. 17). В системном журнале
должна появиться запись вида «<Дата>. Bridge: <Имя_моста>. Gateway:
<Имя_XMPP-шлюза>. <Имя_XMPP-шлюза>: subscribe;». Данная запись
означает, что пользователь был авторизован XMPP-шлюзом и может
получать информацию о присутствии для данной учетной записи.
37
Рисунок 17. Добавление XMPP-шлюза в контакт лист пользователя
Для
начала
взаимодействия
с
управляемым
оборудованием,
пользователь должен ввести пароль, с которым он зарегистрирован в
системе. Команда имеет вид !passwd=<password>, где <password> - пароль
пользователя в системе. Если пользователь попытается отправить любую
команду, предварительно не открыв сессию, приложение ответит ему
сообщением «Session expired. Enter !passwd=<your_session_password>».
Необходимо учесть, что перед открытием сессии или в процессе
работы разрыв терминального подключения может быть инициирован
оборудованием, т.к. по умолчанию время жизни удаленных подключений
составляет 5-10 минут. Если произойдет такая ситуация, при попытке
отправить какую-либо команду приложение ответит сообщением «Session is
down». Для перезапуска сессии пользователю достаточно ввести команду
!reload.
После
перезапуска,
описывалось выше.
сессия
должна
быть
открыта,
как
38
После того, как сессия открыта, приложение ответит сообщением
«Session opened for X minutes», где X – это количество минут времени жизни
сессии, которое вводилось в поле Timeout при добавлении пользователя в
систему. Если значение этого поля равно нулю, время жизни сессии
бессрочно, и приложение ответит сообщением «Session opened». У
пользователя по умолчанию значение этого поля равно нулю.
После того как сессия будет открыта, пользователь может отправлять
команды управляемому оборудованию, как если бы он взаимодействовал с
ним через терминальный эмулятор (Рис. 18).
Рисунок 18. Взаимодействие с оборудованием через XMPP-шлюз
Так же пользователь может вводить управляющие команды, описанные
выше в таблице 1.
При работе с мостом типа «muiltipoint», после того, как приложение
запустится, для каждого пользователя моста открывается сессия по
умолчанию – первое терминальное соединение в списке соединений первого
39
устройства в списке устройств моста. Это значит, что остальные соединения
по умолчанию не установлены и после переключения сессии командой
!switch
<имя_устройства>
<имя_соединения>
пользователь
должен
перезагрузить сессию командой !reload.
2.8. Тестирование в лабораторной среде
Разработанное приложение протестировано в лабораторной среде
Института математики и компьютерных наук Тюменского государственного
университета.
При
тестировании
использовалось
активное
сетевое
оборудование компании Cisco Systems:
 маршрутизаторы ISR 1841, 2801, 2811;
 коммутаторы Catalyst 2960;
 межсетевой экран Adaptive Security Appliance 5510.
Ниже представлена топология сетевой инфраструктуры, на которой
проводилось тестирование (Рис. 19).
Рисунок 19. Топология лабораторной сетевой инфраструктуры
Перед
началом
тестирования
все
сетевое
оборудование
было
сконфигурировано в соответствии с рекомендациями по предварительной
настройке описанными выше (кроме настроек SNMP-уведомлений). На
40
маршрутизаторе R2 дополнительно была произведена настройка статической
трансляции сетевых адресов для остального сетевого оборудования в сеть
192.168.1.0. Сопоставление сетевых адресов устройствам представлено ниже
(таблица 3).
Устройство
IP-адрес
R2
192.168.1.250
R1
192.168.1.251
R3
192.168.1.252
S1
192.168.1.246
S3
192.168.1.249
ASA
192.168.1.247
Таблица 3. Адресация тестируемой топологии
Маршрутизатор Standalone отсутствует в таблице адресации, т.к. он
напрямую подключен к серверу через консольный порт.
На сервер предварительно установлен XMPP-сервер Openfire 3.7.1. На
нем зарегистрированы следующие учетные записи.
Для авторизации мостов:
 routers@menus-mobile;
 switches@menus-mobile;
 asa@menus-mobile;
 console@menus-mobile.
Для авторизации удаленных пользователей:
 admin@menus-mobile;
 menus12@menus-mobile.
В процессе тестирования приложение было установлено на сервер и
настроено в соответствии с процедурами установки и настройки описанными
выше. В приложении были сконфигурированы 4 моста (Рис. 20):
41
 Routers – группа маршрутизаторов R1, R2 и R3 с подключениями по
протоколам Telnet и SSH;
 Switches – группа коммутаторов S1 и S3 по подключениями по
протоколу Telnet;
 ASA – подключение типа точка-точка к межсетевому экрану ASA по
протоколу SSH;
 Console – подключение типа точка-точка к маршрутизатору Standalone
по протоколу RS-232.
Рисунок 20. Конфигурация мостов для тестирования приложения
В
процессе
тестирования
вышеописанные
устройства
будут
сконфигурированы через клиент обмена мгновенными сообщениями Miranda
IM версии 0.9.52.
42
Необходимо отметить, что операционная система на межсетевых
экранах Cisco ASA отличается от операционной системы семейства
маршрутизаторов и коммутаторов компании Cisco Systems, и данное
приложение пока полностью не адаптировано под эту операционную
систему. Поэтому для межсетевого экрана можно ограничиться выводом
информации об утилизации процессора, существующих списках контроля
доступа и существующих маршрутах (Рис. 21).
Рисунок 21. Результат выполнения команд на межсетевом экране ASA
На маршрутизаторе Standalone будет создана виртуальная таблица
маршрутизации, 2 интерфейса типа «петля» и 2 интерфейса типа «туннель»,
один из которых лежит в виртуальной таблице маршрутизации. Далее будут
43
запущены 2 процесса протокола маршрутизации OSPF, один из которых
предназначен для обмена маршрутной информацией в основной таблице
маршрутизации, а другой – в виртуальной, созданной ранее. После этого
будет проверено состояние соседских отношений между процессами
протокола OSPF (Рис. 22).
Рисунок 22. Результат выполнения команд на маршрутизаторе Standalone
На рисунке 23 представлен результат выполнения команд для
маршрутизаторов R1 и R3. На маршрутизаторе R1 настроен механизм SNMPуведомлений при изменении состояния интерфейса. Для этого создан один
44
интерфейс типа «петля», после чего, приложение получает SNMPуведомление о том, что интерфейс перешел в состояние «включен». Далее,
при отключении этого интерфейса, приложение также получает SNMPуведомление об изменении состояния интерфейса.
Рисунок 23. Результат выполнения команд на маршрутизаторах R1 и R3
На маршрутизаторе R3 настроен лист контроля доступа, разрешающий
управляющий доступ к маршрутизатору только из сети 172.17.10.0 /23. На
маршрутизаторе R1 проверяется доступность управляющего доступа на
маршутизатор R3 (по внутреннему адресу 10.2.2.1, т.к. запрос происходит
внутри сети) до и после применения списка контроля доступа.
45
На рисунке 24 представлен результат выполнения команд на
коммутаторах S1 и S2.
Рисунок 24. Результат выполнения команд на коммутаторах S1 и S3
К интерфейсу FastEthernet0/6 коммутатора S1 подключен хост,
настроены SNMP-уведомления при изменении состояния интерфейсов,
интерфейс переведен в состояние «выключен административно». На
коммутаторе S3 получен вывод информации о программном обеспечении и о
состоянии коммутатора.
46
Таким
достаточные
образом,
сущности
дополнительные
в
данной
для
сущности
главе
определены
функционирования
для
повышения
необходимые
системы,
а
и
также
отказоустойчивости
и
дополнительных возможностей мониторинга. Разработана логическая схема
взаимодействия этих сущностей, система реализована в виде приложения,
которое успешно протестировано в лабораторной среде.
47
ГЛАВА 3.
АНАЛИЗ РИСКОВ
ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ПРИ
ИНТЕГРАЦИИ РАЗРАБОТАННОГО ПРИЛОЖЕНИЯ В
КОРПОРАТИВНУЮ ИНФОРМАЦИОННУЮ
ИНФРАСТРУКТУРУ
В
процессе
проанализированы
разработки
и
и
основные
учтены
тестирования
приложения
угрозы
были
информационной
безопасности, которые могут являться актуальными при интеграции
приложения в корпоративную информационную инфраструктуру.
Самая очевидная угроза конфиденциальности – это утечка учетных
данных для авторизации на сетевом оборудовании через файл конфигурации
приложения при физическом или сетевом доступе к серверу, где установлено
данное приложение. Поэтому файл конфигурации необходимо хранить в
зашифрованном виде. В качестве алгоритма шифрования
используется
алгоритм AES. Шифрование и расшифрование производится на ключе
длиной 256 бит. В исходном коде заранее прописан статический уникальный
128-битный идентификатор, от которого берется хэш-функция по стандарту
ГОСТ Р 34.11-94. Результат хэш-функции используется как ключ для
шифрования (расшифрования) файла конфигурации.
Актуальной угрозой целостности конфигурационной информации
оборудования является ее перехват и изменение при передаче данных не
доверенных сетях. Не смотря на то, что взаимодействие приложения с
пользователями происходит по протоколу TLS (SSL) [24, 25], который дефакто является индустриальным стандартом обеспечения защищенной
передачи данных на транспортном уровне модели OSI, некоторые его
реализации уязвимы к атакам типа «человек посередине».
В спецификацию TLS заложена возможность повторной установки
сессии любой стороной, что и позволяет злоумышленнику вклиниться в
процесс установки соединения с сервером [26]: задержать исходный пакет,
48
установить соединение самостоятельно, после чего пропустить исходный
пакет, что будет воспринято сервером как вполне легальное повторное
соединение. На этом этапе серверу было бы логично запросить сертификат
заново, но прикладному уровню «не очень интересно», что происходит на
нижних уровнях. Таким образом, атакующий оказывается в состоянии
подмешать в защищенную сессию некий дополнительный код (например,
заголовки, значения каких-либо полей или просто врезать в начало httpзапроса команду GET с произвольным путем), который будет воспринят
сервером как исходящий от легального пользователя. Такие манипуляции
позволяют прослушивать весь трафик в чистом виде. При такой атаке
злоумышленник может легко перехватить информацию о конфигурации
оборудования и методом грубого перебора подобрать пароли к учетным
записям администраторов оборудования.
Для противодействия данной угрозе как раз и был разработан модуль
Terminal Formatter, который перед отправкой пользователю любого вывода с
оборудования проверяет его на наличие вхождений строк типа username и
password. В случае нахождения таких вхождений они заменяются на строки
вида !<output omitted>. Даже если злоумышленник сможет обойти защиту
данного протокола, никакой полезной для себя информации в выводе он не
найдет. Однако остается нерешенной проблема с установкой паролей на
оборудование, которые в любом случае отправляются в чистом виде, пусть и
по зашифрованному каналу. Поэтому автор рекомендует работать удаленно с
данным приложением, находясь только в доверенных сетях.
Одна
из
самых
главных
угроз
конфиденциальности
учетной
информации и целостности конфигурации оборудования заключается в том,
что злоумышленник может украсть учетные данные от XMPP-клиента
администратора оборудования и с его помощью повредить конфигурацию
оборудования. Для предотвращения подобной угрозы была введена
двухфакторная авторизация.
49
Во-первых, при создании моста в него заносится список учетных
записей XMPP-клиентов, которые могут взаимодействовать с сервером
трансляции. Если на сервер приходит какое-либо сообщение от стороннего
XMPP идентификатора, отсутствующего в списке учетных записей моста,
сообщение игнорируется на уровне XMPP-шлюза.
Во-вторых, для того, чтобы начать работу с сервером трансляции,
предавторизованный пользователь должен ввести ключевое слово по
специальному
шаблону.
Если
ключевое
слово
введено
правильно,
открывается сессия, по истечению которой ключевое слово должно быть
введено снова. В этой связи, не рекомендуется использовать одинаковые
пароли для авторизации на XMPP-сервере и на сервере трансляции.
Угрозы доступности для данного приложения практически не
актуальны
за
исключением
случаев,
когда
используется
внутрикорпоративный XMPP-сервер, который возможно скомпрометировать
изнутри или снаружи периметра сети. Это также справедливо для сервера, на
котором установлено разрабатываемое приложение. Для минимизации
рисков, связанных с такими угрозами, необходимо обеспечить безопасность
серверов на сетевом уровне должным образом. Публичные XMPP-сервера,
как правило, рассчитаны на большую нагрузку, поэтому атаки типа «отказ в
обслуживании» применимы к ним крайне редко.
Таким образом, проанализированы возможные риски информационной
безопасности, которые в большей степени связаны с утечкой и порчей
конфигурации сетевого оборудования. Хочется отметить, что защита сетевой
инфраструктуры регламентируется политикой безопасности организации,
которая должна обязательно включать в себя политику разграничения
доступа. Предполагается, что данное приложение также должно быть
регламентировано
в
политике
безопасности
как
дополнительный
инструментарий для управления сетевой инфраструктурой. При должном
уровне защиты, даже имея на руках рабочую конфигурацию оборудования,
злоумышленник не сможет повредить его.
50
ЗАКЛЮЧЕНИЕ
В ходе дипломной работы были исследованы протоколы управления
сетевым оборудованием и обмена мгновенными сообщениями. Анализ их
достоинств
и
недостатков
позволил
выбрать
наиболее
подходящие
протоколы для реализации их в разрабатываемой системе.
Определены необходимые, достаточные и дополнительные сущности
проектируемой системы, разработана логическая схема взаимодействия этих
сущностей, и, как следствие, система реализована в приложении, которое
было успешно протестировано в лабораторной среде.
Разработанное приложение проанализировано на возможные риски
информационной безопасности, связанные с интеграцией приложения
в
корпоративную информационную инфраструктуру.
Как результат, разработана система для удаленного круглосуточного
мониторинга
и
управления
сетевым
оборудованием
посредством
туннелирования классических протоколов управления оборудованием через
протокол обмена мгновенных сообщений.
Таким образом, все поставленные задачи решены, поставленная цель
достигнута.
На
данный
технологический
момент
процесс
разработанное
по
приложение
обслуживанию
оборудования клиентов компании «Виндекс-Сервис».
внедрено
активного
в
сетевого
51
СПИСОК ЛИТЕРАТУРЫ
1. Telnet [Электронный ресурс] // wikipedia.org : Википедия — свободная
энциклопедия,
2012.
URL:
http://ru.wikipedia.org/wiki/Telnet
(дата
обращения 04.05.2012).
2. Secure Shell [Электронный ресурс] // wikipedia.org : Википедия —
свободная
энциклопедия,
2012.
URL:
http://ru.wikipedia.org/wiki/Secure_Shell (дата обращения 01.05.12)
3. Recommended Standard 232 [Электронный ресурс] // wikipedia.org :
Википедия
—
свободная
энциклопедия,
2012.
URL:
http://ru.wikipedia.org/wiki/RS-232 (дата обращения 05.05.12).
4. Simple
Network
Management
Protocol
[Электронный
ресурс]
//
wikipedia.org : Википедия — свободная энциклопедия, 2012. URL:
http://ru.wikipedia.org/wiki/SNMP (дата обращения 07.05.12).
5. Management Information Base [Электронный ресурс] // wikipedia.org :
Википедия
—
свободная
энциклопедия,
2012.
URL:
http://ru.wikipedia.org/wiki/Management_Information_Base (дата обращения
14.08.12).
6. Remote LOGIN [Электронный ресурс] // wikipedia.org : Википедия —
свободная энциклопедия, 2012. URL: http://ru.wikipedia.org/wiki/Rlogin
(дата обращения 01.05.12).
7. Extensible Messaging and Presence Protocol [Электронный ресурс] //
wikipedia.org : Википедия — свободная энциклопедия, 2012. URL:
http://ru.wikipedia.org/wiki/XMPP (дата обращения 07.05.12).
8. Знакомство с протоколом XMPP [Электронный ресурс] // IBM, 2010.
URL:
http://www.ibm.com/developerworks/ru/library/x-xmppintro/
(дата
обращения 14.08.12).
9. XMPP Technologies Overview [Электронный ресурс] // xmpp.org : XMPP
Standards Foundation, 2010. URL: http://xmpp.org/about-xmpp/technologyoverview/ (дата обращения 06.05.12).
52
10.OSCAR protocol [Электронный ресурс] // wikipedia.org : Википедия —
свободная
энциклопедия,
2012.
URL:
http://en.wikipedia.org/wiki/OSCAR_protocol (дата обращения 01.05.12).
11.Обзор протоколов работы ICQ [Электронный ресурс] // Азаров Роман :
Курсовая работа, 1999. URL: http://iserverd.khstu.ru/docum_ext/icqkurs.htm
(дата обращения 07.05.12).
12.Полное описание 8-ого протокола ICQ [Электронный ресурс] //
www.icqinfo.ru
:
ICQ
Information
Center,
2006.
URL:
http://www.icqinfo.ru/protocol_v8.shtml (дата обращения 01.05.12).
13.Acceptable Use Policy [Электронный ресурс] // ICQ.com : ICQ — it's about
communication, 2012. URL: http://www.icq.com/legal/usepolicy/ru (дата
обращения 14.08.12).
14.Мартынов Н.Н. С# для начинающих: — КУДИЦ-ПРЕСС, 2007.-272 c.
15.Бен Ватсон. С# 4.0 на примерах: — БХВ-Петербург, 2011.-608 c.
16.Кристиан Нейгел. C# 4.0 и платформа .NET 4 для профессионалов: —
Диалектика, 2011.-1440 c.
17.Михаил Фленов. Библия C#: — БХВ-Петербург, 2011.-560 c.
18.Библиотека MSDN [Электронный ресурс] // msdn.microsoft.com :
Microsoft,
2007.
URL:
http://msdn.microsoft.com/ru-ru/library/
(дата
обращения 04.05.12)
19.Пол Спенсер. XML. Проектирование и реализация: — Лори, 2001.-510 с.
20.Вугт В.В. Open XML кратко и доступно: — Microsoft Press, 2007.-109 c.
21.Changqing Li, Tok Wang Ling. Advanced Applications and Structures in Xml
Processing:
Label
Streams,
Semantics
Utilization
and
Data
Query
Technologies: — Information Science Reference, 2010.-376 c.
22.Требования к системе для .NET Framework версии 3.5 [Электронный
ресурс]
//
msdn.microsoft.com
:
Microsoft,
2007.
http://msdn.microsoft.com/ru-ru/library/bb882520(v=vs.90).aspx
обращения 14.08.12).
URL:
(дата
53
23..NET
Framework
System
Requirements
[Электронный
ресурс]
//
msdn.microsoft.com : Microsoft, 2007. URL: http://msdn.microsoft.com/enus/library/8z6watww.aspx (дата обращения 14.08.12).
24.HTTPS [Электронный ресурс] // wikipedia.org : Википедия — свободная
энциклопедия,
2012.
URL:
http://ru.wikipedia.org/wiki/HTTPS
(дата
обращения 14.08.12).
25.SSL [Электронный ресурс] // wikipedia.org : Википедия — свободная
энциклопедия,
2012.
URL:
http://ru.wikipedia.org/wiki/SSL
(дата
обращения 14.08.12).
26.TLS/SSL изнутри [Электронный ресурс] // Habrahabr, 2012. URL:
http://habrahabr.ru/post/44818/ (дата обращения 14.08.12).
27.Component Object Model [Электронный ресурс] // wikipedia.org :
Википедия
—
свободная
энциклопедия,
http://ru.wikipedia.org/wiki/Component_Object_Model
2012.
(дата
URL:
обращения
01.05.12).
28.Описание функций работы с COM-объектами [Электронный ресурс] //
HomeLisp,
2012.
URL:
http://homelisp.ru/help/com_funct.html
(дата
обращения 03.05.12).
29.Архив статей «Что такое «технология COM» [Электронный ресурс] //
developing.ru
:
Клуб
программистов,
2012.
URL:
[http://www.developing.ru/com/] (дата обращения 02.05.12).
30.Теленик С.Ф., Ролик А.И., Можаровский П.Ф., Волошин А.В. Система
управления
информационной
инфраструктурой
транспортного
предприятия // Автомобильный транспорт. — 2009. - Вып. 25. – С. 83–89.
31.Тарасов В.М., Горбатов В.А., Логиновский О.В. Интеллектуальные
информационные технологии в градостроительном проектировании //
Программные системы и продукты. — 1996. - Вып. 2. – С. 49–56.
32.Ясько С. А., Нашивочников Н.В. Информационная инфраструктура и ИБ
"в одном флаконе" // Информационная безопасность - 2007. — Вып. 5. С. 49–56.