Мультиплексирование разнесенного TCP/IP трафика

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

Министерство Путей Сообщения

Омский Государственный Университет Путей Сообщения

Расчётно-пояснительная записка к дипломному проекту

Мультиплексирование разнесенного TCP/IP трафика

Омск 2002

Реферат

В дипломном проекте содержится 101 страницы машинописного текста, 4 таблицы, 19 рисунков, 6 демонстрационных листов, приложение 1, 10 использованных источников литературы.

Система мультиплексирования, tcp/ip, интернет, интранет, архитектура сети, топология сети, канал связи, протокол, мультиплексор, демультиплексор, передатчик, вероятность несанкционированного доступа, информационная безопасность, криптоалгоритм.

В дипломном проекте разработана система мультиплексирования TCP/IP трафика с целью повышения безопасности передачи информации в сетях с избыточной топологией, разработаны программа, проведена отладка, мониторинг. Проведены расчеты, предложены модификации алгоритмов для использования программ в специфических условиях. Рассчитана себестоимость внедрения программы, рассмотрены вопросы обеспечения безопасности при работе с видеодисплейнми терминалами, а также вопросы безопасности жизнежеятельности в ЧС.

Cодержание

Введение

1. Основные понятия и принципы сетевого программного обеспечения

1.1 Архитектура клиент сервер

1.2 Семиуровневая модель ISO/OSI

1.3 Cтек протоколов TCP/IP

2. Классификация функций систем защиты информации, обзор протоколов

2.1 Классификация систем защиты информации от несанкционированного доступа. Методы защиты

2.2 Протоколы защиты информации ориентированные на разные уровни модели ISO/OSI

2.2.1 Канальный уровень

2.2.2 Сетевой уровень

2.2.3 Сеансовый уровень

2.3 Протокол сеансового уровня SOCKS

3. Сеансовый уровень стека TCP/IP,функционирование низлежащих протоколов, общие характеристики и принципы функционирования

3.1 Протоколы TCP и UDP, свойства, общие характеристики

3.2 Производительность TCP

3.3 Сравнение TCP и UDP, обоснование выбора протокола

4. Основные элементы построения сетевых приложений (API)

4.1 База элементов для построения Клиента

4.2 База элементов для построения Сервера

4.3 Завершение работы приложения и состояние TIME-WAIT

5. Описание и принципы действия основных инструментов отладки, мониторинга и управления

5.1 Система удаленного управления терминалом SSH

5.2 Программа сетевого анализа netstat

5.3 Использование программы tcpdump

5.4 Программа исследования топологии сети traceroute

6. Описание системы мультиплексирования TCP/IP трафика, запуск, мониторинг, контроль работы

6.1 Принцип работы системы

6.2 Листинги программ и их описание

6.2.1 Листинг программы "Демультиплексор"

6.2.2 Листинг программы "Мультиплексор"

6.2.3 Листинг программы "Передатчик"

6.3 Использование системы в сетях с малой вероятностью доступа к одному из каналов

6.4 Сравнение системы мультиплексирования с протоколом socks

6.5 Запуск и мониторинг системы

6.6 Листинги и описания tcp-сессий, полученных с помощью tcpdump

6.7 Детальный контроль маршрута прохождения трафика

6.8 Мультиплексирование с произвольными коэффициентамипо n каналам

7. Экономическое обоснование. Определение цены программы

7.1 Затраты на оплату труда, отчисления на социальное страхование

7.2 Расходы по содержанию и эксплуатации оборудования

7.3 Себестоимость устройства управления

8. Обеспечение безопасности при работе с видеодисплейными терминалами

8.1 Эргономические требования, предъявляемые квидеодисплейным терминалам

8.2 Использование жидкокристаллической матрицы, как дисплейного устройства вычислительной машины

9. Применение сигналов ГО для оповещения работников и служащих в ЧС

9.1 Основные задачи ГО

9.2 Способы оповещения и действия при угрозе нападения противника

9.3 Действия рабочих и служащих по сигналам ГО

9.4 Содержание речевой информации

Заключение

Список использованных источников

Введение

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

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

Наверно, никто сегодня не сможет с уверенностью назвать точную цифру суммарных потерь от компьютерных преступлений, связанных с несанкционированных доступом к информации. Подавляющее большинство таких преступлений происходит благодаря минимальным затратам со стороны злоумышленника, вследствие полного отсутствия средств защиты у жертвы. Известно, что элементарные средства защиты на порядок затрудняют сбор, и дальнейшее использование информации злоумышленником, но при этом, построение что надежная система защиты, близкой к идеальной, предполагает решение множества как финансовых, технических проблем, так и правовых аспектов, ведя общую политику обеспечения информационной безопасности. Это, относится к самому надежному на сегодняшний день средству защиты-шифрование криптографическими алгоритмами. Предлагаемое в данном дипломном проекте решение подразумевает, скорее, повышение стойкости информации при несанкционированном доступе к среде передачи, на основе имеющихся физических средств, с помощью проектирования и реализации необходимого программного обеспечения. Естественно, данный метод не может использоваться как альтернативный средствам криптографической защиты, а может, скорее, дополнять последний или использоваться в иных контекстах, не связанных с защитой информации. Характерной особенностью предложенной системы является то, что она, в отличие от шифрования, не предполагают введения информационной избыточности, не увеличивая тем самым себестоимость передачи информации, а является полностью привязанной к свойствам среды передачи и топологии сетевой структуры, полагаясь на наличие структурной избыточности, которая особенно свойственна для сети Internet. Так же следует отметить, что использование данного метода абсолютно свободно и легально, как с точки зрения используемых технологий, так и с точки зрения юридической законности, в отличие, например, от использования криптографического шифрования. Данная система может с успехом использоваться не только в Internet, но и в любых сетях использующих универсальный протокол пакетной коммутации передачи данных TCP/IP. Сети передачи данных железных дорог, благодаря соответствующей топологии резервирования основных каналов передачи параллельными маршрутами, так же идеально подходят для использования данной системы. В дипломе разработано основное программное обеспечение, отражены методы использования готовых средств для контроля работы системы, ее мониторинга. Дипломный проект выполнен в соответствии с СТП ОмИИТ-10-91, СТП ОмИИТ-11-91, СТП ОмИИТ-13-92, СТП ОмИИТ-14-93 /1,2/.

1. Основные понятия и принципы сетевого программного обеспечения

1.1 Архитектура клиент- сервер

Децентрализация архитектуры первых вычислительных систем стала возможной в связи с появлением персональных компьютеров, к которым мигрировала часть функций центральных ЭВМ. В результате появилась возможность создавать распределенные локальные и глобальные вычислительные системы, объединяющие персональные компьютеры и компьютеры, полностью предоставляющие свои ресурсы в общее пользование для других компьютеров сети. Компьютеры, предоставляющие те или иные общие ресурсы, были названы серверами, а компьютеры, использующие общие ресурсы, - клиентами. Соответственно архитектуру таких распределенных вычислительных систем стали называть архитектурой “клиент-сервер”. Далее термины “клиент” и “сервер” будут употребляться только в контексте программного обеспечения выполняющегося на каком-либо компьютере в сети (хосте).

Не смотря на данную терминалогию, в отношении клиента и сервера, не всегда очевидно, какую роль играет конкретная программа. Иногда программы являются равноправными участниками обмена информацией и нельзя однозначно утверждать, что одна программа обслуживает другую. Однако в случае с TCP/IP различие более четкое. Сервер прослушивает порт, чтобы обнаружить входящие TCP-соединения или UDP-датаграммы от одного или нескольких клиентов. С другой стороны, можно сказать, что клиент - это тот, кто начинает диалог первым. Существуют три типичных случая архитектуры клиент-сервер /4/, как показано на рис. 1.1. В первом случае клиент и сервер работают на одной машине (рис.l.la).

Типичные примеры архитектуры клиент-сервер.



Рис 1.1

На этапе разработки такое размещение клиента и сервера дает определенные преимущества, даже если в реальности они будут работать на разных машинах.

Во втором примере конфигурации (рис. 1.1б) клиент и сервер работают на разных машинах, но в пределах одной локальной сети.

В третьем примере клиент и сервер работают на разных компьютерах связанных глобальной сетью.

Этой сетью может быть Internet или корпоративная Intranet, но главное - приложения уже не находятся внутри одной локальной сети, так что на пути IP - датаграмм есть, по крайней мере, один маршрутизатор.

1.2 Семиуровневая модель ISO/OSI

Самый известный пример многоуровневой схемы сетевых протоколов - это эталонная модель открытого взаимодействия систем (Reference Model of Open Systems Interconnection), предложенная Международной организацией по стандартизации (ISO).

Поскольку в этой модели семь уровней (рис. 1.2), ее часто называют семиуровневой моделью OSI /3/.

Семиуровневая модель ISO/OSI

7	Прикладной уровень
6	Уровень представления
5	Сеансовый уровень
4	Транспортный уровень
3	Сетевой уровень
2	Канальный уровень
1	Физический уровень

Рис 1.2

Здесь, уровень N предоставляет сервис уровню N+1 и пользуется сервисами, предоставляемыми уровнем N-1. Кроме того, каждый уровень может взаимодействовать только со своими непосредственными соседями сверху и снизу. Это взаимодействие происходит посредством четко определенных интерфейсов между соседними уровнями.

Модель OSI имеет множество недостатков. Хотя, в конечном итоге, были созданы работающие реализации, протоколы OSI на сегодняшний день утратили актуальность. Основная проблема модели OSI - это сложность и неэффективность. Некоторые функции выполняются сразу на нескольких уровнях. Так, обнаружение и исправление ошибок происходит на большинстве уровней.

1.3 Cтек протоколов TCP/IP

Модель TCP/IP документирует дизайн семейства протоколов TCP/IP.

Можно сравнить две модели и посмотреть, как уровни TCP/IP отображаются на уровни модели OSI (рис.1.3).

Сравнение модели OSI и стека TCP/IP

Прикладной уровень
Уровень представления	Прикладной уровень
Сеансовый уровень
Транспортный уровень	Транспортный уровень
Сетевой уровень	Межсетевой уровень
Канальный уровень	Интерфейсный уровень
Физический уровень

Рис 1.3

Как видно из рис. 1.3, стек протоколов TCP/IP состоит из четырех уровней. На прикладном уровне решаются все задачи, свойственные прикладному уровню, уровню представления и сеансовому уровню модели OSI. Транспортный уровень аналогичен соответствующему уровню в OSI и занимается сквозной доставкой. На транспортном уровне определены протоколы TCP и UDP, на межсетевом - протоколы IP, ICMP и IGMP (Internet Group Management Protocol). Он соответствует сетевому уровню модели OSI.

Хотя сообщения протоколов ICMP и IGMP передаются в виде IP-датаграмм, они рассматриваются как неотъемлемая часть IP, а не как протоколы более высокого уровня.

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

На рис. 1.4 изображены два стека TCP/IP на компьютерах, между которыми расположено несколько маршрутизаторов.

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

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

Сквозная связь

Рис. 1.4

Однако, промежуточные системы могут изменять некоторые поля, например, время существования датаграммы (TTL - time to live) в IP-заголовке. Поэтому межсетевой уровень в пункте назначения может «видеть» не в точности то же сообщение, что межсетевой уровень, который его послал.

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

2. Классификация функций систем защиты информациии, обзор протоколов

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

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

2.1 Классификация систем защиты информации от несанкционированного доступа. Методы защиты

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

Все возможные способы несанкционированного доступа к информации, можно классифицировать по следующим признакам:

1) по принципу несанкционированного доступа:

-физический несанкционированный доступ;

-логический несанкционированный доступ.

Физический несанкционированный доступ может быть реализован одним из следующих способов:

- преодоление рубежей территориальной защиты и доступ к незащищенным информационным ресурсам;

- хищение документов или носителей информации;

- визуальный перехват информации, выводимой на экраны мониторов и принтеры, а также подслушивание;

- перехват электронных излучений.

Логический несанкционированный доступ предполагает логическое преодоление системы защиты ресурсов активной компьютерной сети. Учитывая, что подавляющее большенство угроз информации могут быть реализованны только в процессе функционирования вычислительной системы.

2) по положению источника несанкционированного доступа:

-несанкционированный доступ, источник которого расположен в локальной сети;

-несанкционированный доступ, источник которого расположен вне локальной сети.

3) по режиму выполнения несанкционированного доступа;

-при прямом участии человека;

-при косвенном участии человека, с помощью специальных средств.

4) по пути несанкционированного доступа:

-атаки, ориентированные на использование прямого стандартного пути доступа к компьютерным ресурсам;

-атаки, ориентированные на использование скрытого нестандартного пути доступа к компьютерным ресурсам.

5) по текущему месту расположения конечного объекта атаки:

-атаки на информацию, хранящуюся на внешних запоминающих устройствах;

-атаки на информацию, передаваемую по линиям связи;

-атаки на информацию, обрабатываемую в основной памяти компьютера.

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

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

Ниже приводятся основные, традиционные методы защиты инфомации от несанкционированного доступа/3/:

1) идентификация;

2) аутентификация;

3) разграничение доступа;

4) блокирование бесконтрольного доступа;

5) шифрование и контроль подлинности;

6) уничтожение остаточных данных;

7) изолирование участков сети передачи;

8) предупреждение пользователей перед выполнением опасных действий.

2.2 Протоколы защиты информации, ориентированные на разные уровни модели ISO/OSI

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

Для независимости от прикладных протоколов и приложений защищенные виртуальные сети формируются на одном из более низких уровней модели OSI -- канальном, сетевом или сеансовом. Канальному (второму) уровню соответствуют такие протоколы реализации, как РРТР, L2F и L2TP, межсетеевому (третьему) уровню -- IPSec, SKIP, а сеансовому (пятому) уровню -- SSL/TLS и SOCKS. Чем ниже уровень эталонной модели, на котором реализовывается защита, тем она прозрачнее для приложений и незаметнее для пользователей. Однако при снижении этого уровня уменьшается набор реализуемых услуг безопасности и становится сложнее организация управления. Чем выше защитный уровень в соответствии с моделью OSI, тем шире набор услуг безопасности, надежнее контроль доступа и проще конфигурирование системы защиты. Тем не менее в этом случае усиливается зависимость от используемых протоколов обмена и приложений.

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

2.2.1 Канальный уровень

Канальному уровню модели OSI соответствует также протокол туннелирования L2F (Layer-2 Forwarding), разработанный компанией Cisco Systems при поддержке компаний Shiva и Northern Telecom. В данном протоколе также не специфицируются конкретные методы аутентификации и шифрования. В отличие от протокола РРТР протокол L2F позволяет использовать для удаленного доступа к провайдеру Internet не только протокол РРР, но и другие протоколы, например, SLIP. При формировании защищенных каналов по глобальной сети провайдерам Internet не нужно осуществлять конфигурацию адресов и выполнять аутентификацию. Кроме того, для переносимости данных через защищенный туннель могут использоваться различные протоколы сетевого уровня, а не только IP, как в протоколе РРТР. Протокол L2F стал компонентом операционной системы IOS (Internetwork Operating System) компании Cisco и поддерживается во всех выпускаемых ею устройствах межсетевого взаимодействия и удаленного доступа.

Протоколы РРТР и L2F были представлены в организацию Internet Engineering Task Force (IETF) и в 1996 году соответствующие комитеты решили их объединить. Получившийся в результате протокол, включивший все лучшее из РРТР и L2F, был назван протоколом туннелирования второго уровня (Layer-2 Tunneling Protocol -- L2TP). Его поддерживают компании Cisco, Microsoft, 3Com, Ascend и многие другие производители. Как и предшествующие протоколы канального уровня, спецификация L2TP не описывает методы аутентификации и шифрования. Протокол L2TP является расширением РРР на канальном уровне и может поддерживать любые высокоуровневые протоколы.

Протоколы формирования защищенного туннеля на канальном уровне независимы от протоколов сетевого уровня модели OSI. Многопротокольность -- основное преимущество инкапсулирующих протоколов канального уровня.

Вместе с тем, формирование криптозащищенных туннелей между объединяемыми локальными сетями на основе протоколов канального уровня приводит к сложности конфигурирования и поддержки виртуальных каналов вязи. Туннели на основе РРР требуют, чтобы конечные точки поддерживали информацию о состоянии каждого канала (например, такую, как тайм-уты), и, следовательно, не обладают хорошей масштабируемостью при необходимости иметь несколько туннелей с общими конечными точками. Кроме того, протоколы формирования защищенных туннелей на канальном уровне не специфицируют конкретные методы шифрования, аутентификации, проверки целостности каждого передаваемого пакета, а также средств правления ключами.

2.2.2 Сетевой уровень

Спецификацией, где описаны стандартные методы для всех компонентов и функций защищенных виртуальных сетей, является протокол Internet Protocol Security (IPSec), соответствующий сетевому уровню модели OSI и входящий в состав новой версии протокола IP -- IPv6. Протокол IPSec иногда ще называют протоколом туннелирования третьего уровня (Layer-3 Tunneling). IPSес предусматривает стандартные методы аутентификации пользователей или компьютеров при инициации туннеля, стандартные способы шифрования конечными точками туннеля, формирования и проверки цифровой подписи, а также стандартные методы обмена и управления криптографическими ключами между конечными точками. Для функций аутентификации IPSec поддерживает цифровые сертификаты популярного стандарта Х.509.

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

Для управления криптографическими ключами на сетевом уровне модели OSI наиболее широкое распространение получили такие протоколы, как SKIP (Simple Key management for Internet Protocols) и ISAKMP (Internet Security Association and Key Management Protocol). SKIP проще в реализации, но он не поддерживает переговоров по поводу алгоритмов шифрования. Если получатель, использующий SKIP, не в состоянии расшифровать пакет, он уже не сможет согласовать метод шифрования с противоположной стороной. Протокол ISAKMP поддерживает такие переговоры и выбран в качестве обязательного протокола для управления ключами в IPSec для IPv6 Протокол ISAKMP является составной частью протокола IPSec.

2.2.3 Сеансовый уровень

Защищенные виртуальные каналы могут быть сформированы и на сеансовом уровне модели OSI. Для этого применяются так называемые "посредники каналов" (circuit proxy). Посредник функционирует над транспортным уровнем, шифрует и ретранслирует трафик из защищенной сети в общедоступную сеть Internet для каждого сокета в отдельности.

Для шифрования информации на сеансовом уровне наибольшую популярность получил протокол SSL/TLS (Secure Sockets Layer/ Transport Layer Security), разработанный компанией Netscape Communications. Этот протокол создает защищенный туннель между конечными точками виртуальной сети, обеспечивая взаимную аутентификацию абонентов, а также конфиденциальность, подлинность и целостность циркулирующих по туннелю данных. Ядром протокола SSL/TLS является технология комплексного использования асимметричных и симметричных криптосистем компании RSA Data Security. Для аутентификации взаимодействующих сторон и криптозащиты ключа симметричного шифрования используются цифровые сертификаты открытых ключей пользователей (клиента и сервера), заверенные цифровыми подписями специальных Сертификационных Центров. Поддерживаются цифровые сертификаты, соответствующие общепринятому стандарту Х.509.

С целью стандартизации процедуры взаимодействия клиент-серверных приложений TCP/IP через сервер-посредник (брандмауэр) комитет IETF утвердил протокол под названием SOCKS, и в настоящее время пятая версия данного протокола (SOCKS 5) применяется для стандартизованной реализации посредников каналов. SOCKS поддерживает приложения, требующие контроля над направлениями информационных потоков и настройки условий доступа в зависимости от атрибутов пользователя и/или информации.

В соответствии с SOCKS клиентский компьютер устанавливает аутентифицированный сеанс с сервером, исполняющим роль посредника (proxy). Использование этого посредника является единственным способом связи через брандмауэр. Посредник, в свою очередь, проводит любые операции, запрашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сеанса (сокета), он может осуществлять тщательный контроль, например, блокировать конкретные приложения пользователей, если они не имеют необходимых полномочий.

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

2.3 Протокол сеансового уровня SOCKS

Протокол SOCKS разработан в 1990 г. Дэвидом Кобласом для организации посредничества при взаимодействии между клиент-серверными приложениями на сеансовом уровне модели OSI. Изначально данный протокол разрабатывался только для перенаправления запросов к серверам со стороны клиентских приложений, а также возврата этим приложениям полученных ответов. Однако даже лишь перенаправление запросов и ответов между клиент-серверными приложениями уже позволяет реализовать функцию трансляции сетевых IP-адресов (Network Address Translation -- NAT). При замене для исходящих пакетов внутренних IP-адресов отправителей одним IP-адресом шлюза топология внутренней сети скрыта от внешних пользователей, что усложняет задачу несанкционированного доступа. Трансляция сетевых адресов, помимо повышения безопасности позволяет расширить внутреннее адресное пространство сети за счет возможности поддержки собственной системы адресации, не согласованной с адресацией во внешней сети.

На основе протокола SOCKS могут быть реализованы и любые другие функции посредничества по защите сетевого взаимодействия. Эффективность использования данного протокола для выполнения функций посредничества обеспечивается его ориентацией на сеансовый уровень модели OSI. По сравнению с посредниками прикладного уровня на сеансовом уровне достигаются более высокое быстродействие и независимость от высокоуровневых протоколов (HTTP, FТР, РОРЗ, SMTP, NNTP и др.). Кроме того, протокол SOCKS не привязан к протоколу IP, а также не зависит от операционных систем. Следует отменить, что если на основе протоколов канального и сетевого уровня защищенные виртуальные каналы формируются между разными парами взаимодействующих сторон, то на основе протокола SOCKS могут создаваться защищенные туннели для каждого приложения и сеанса в отдельности.

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

Обобщенная схема взаимодействия по протоколу SOCKS сводится к следующему:

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

2) SOCKS-клиент соединяется с SOCKS-сервером и передает ему запрос прикладного клиента;

3) SOCKS-сервер соединяется с запрошенным прикладным сервером;

4) прикладной клиент и прикладной сервер взаимодействуют друг с другом по цепочке соединений, в которой SOCKS-сервер просто, ретранслирует данные.

В реализации SOCKS-сервера, кроме трансляции IP-адресов, могут быть предусмотрены другие функции посредничества по защите сетевого взаимодействия. Однако в протоколе SOCKS такие функции не специфицируются.

Аутентификация пользователя, выполняемая SOCKS-сервером, может основываться на цифровых сертификатах в формате Х.509 или паролях. Максимальную функциональность по криптозащите обеспечит протокол SSL. Помимо аутентификации пользователей, трансляции IP-адресов и криптозащиты графика SOCKS-сервер может выполнять следующие функции:

1) разграничение доступа к ресурсам внутренней сети;

2) разграничение доступа к ресурсам внешней сети;

3) фильтрация потока сообщений, например, динамический поиск вирусов;

4) регистрация событий и реагирование на задаваемые события;

5) кэширование данных, запрашиваемых из внешней сети.

SOCKS-клиенты, выполняющие перехват запросов клиентских приложений и взаимодействие с SOCKS-сервером, могут быть изначально встроены в универсальные клиентские программы. К приложениям, имеющим встроенную поддержку протокола SOCKS, относятся популярные Web-навигаторы Netscape Navigator (Communicator) и Microsoft Internet Explorer. Существуют также специальные программы, называемые "соксификаторами", дополняющие клиентские приложения поддержкой протокола SOCKS. Если нет нарушений установленных правил безопасности, то работа SOCKS-клиента совершенно прозрачна для клиентских приложений и пользователей.

Таким образом, для формирования защищенных виртуальных сетей по протоколу SOCKS в точке сопряжения каждой локальной сети с Internet на компьютере-шлюзе устанавливается SOCKS-сервер, а на рабочих станциях в локальных сетях и на компьютерах удаленных пользователей устанавливаются SOCKS-клиенты (рис.2.1). SOCKS-сервер является ни чем иным, как межсетевым экраном, поддерживающим протокол SOCKS.

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

Схема сетевого взаимодействия по протоколу SOCKS



Рис.2.1

Помимо защиты локальной сети от несанкционированного доступа, на SOCKS-сервер может возлагаться контроль доступа пользователей этой локальной сети к открытым ресурсам Internet. Доступ является полностью авторизованным, так как идентифицируются и аутентифицируются конкретные пользователи, а не компьютеры, с которых они выходят в сеть. Правила доступа могут запрещать или разрешать соединения с конкретными ресурсами Internet в зависимости от полномочий конкретного сотрудника. Действие правил доступа может зависеть и от дрyгих параметров, например, от метода аутентификации или времени суток.

Для достижения наиболее высокой степени безопасности сетевого взаимодействия, серверы локальной сети, к которым разрешен доступ со стороны Internet, должны быть выделены в отдельный подсоединяемый к SOCKS-cерверу сегмент, образующий защищаемую открытую подсеть (см. локальную сеть слева на рис. 2.1). За счет трансляции сетевых адресов серверы и рабочие станции локальной сети, подсоединенной к Internet через SOCKS-сервер, могут не иметь зарегистрированных сетевых адресов и доменных имен. Разрешение адресов и имен производится SOCKS-сервером. При такой конфигурации пользователи защищенной виртуальной сети получают доступ ко всем серверам локальных сетей, входящим в состав виртуальной сети, так, как если бы эти серверы находились в одной локальной сети.

сетевой программный обеспечение

3. Сеансовый уровень стека tcp/ip, функционирование низлежащих протоколов, общие характеристики и принципы функционирования

3.1 Протоколы TCP и UDP, свойства, общие характеристики

Протокол управления передачей TCP (Transmission Control Protocol) предназначен для использования в качестве надежного средства при общении удаленных систем в локальных сетях с коммутацией пакетов, а также в системах, объединяющих такие сети /3/.

Протокол UDP (User Datagram Protocol), как и TCP расположен над IP, но обеспечивает негарантированную доставку пакетов и отсутствие логического соединения.

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

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

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

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

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

У типичного протокола, требующего наличия соединения, есть три фазы. Сначала устанавливается соединение между двумя приложениями. Затем происходит обмен данными. И, наконец, когда оба приложения завершили обмен данными, соединение разрывается.

Часто встречаются ситуации, когда для создания приложения использование протокола без организации логического соединения оправдано. Например, таким способом можно легко поддерживать связь одного хоста со многими и наоборот.

Поскольку TCP-пакеты (они называются сегментами) посылаются в составе IР-датаграмм, у TCP нет информации, дойдут ли они до адреса, не говоря о возможности искажения данных или о доставке в неправильном порядке. Чтобы обеспечить надежность, TCP добавляет к базовому IP-сервису три параметра. Во-первых, в ТСР-сегмент включена контрольная сумма содержащихся в нем данных. Во-вторых, TCP присваивает каждому байту порядковый номер. В-третьих, в TCP имеется механизм подтверждения и повторной передачи.

На каждом конце TCP-соединения поддерживается окно приема/4/, представляющее собой диапазон порядковых номеров байтов, который получатель готов принять от отправителя. Наименьшее значение, соответствующее левому краю окна, - это порядковый номер следующего ожидаемого байта. Наибольшее значение, соответствующее правому краю окна, - порядковый номер последнего байта, для которого у TCP есть место в буфере. Использование окна приема (вместо посылки только номера следующего ожидаемого байта) повышает надежность протокола за счет предоставления средств управления потоком. Механизм управления потоком предотвращает переполнение буфера TCP.

На приемном конце, помимо окна приема, TCP поддерживает также окно передачи, разделенное на две части. В одной из них расположены байты, которые уже отосланы, но еще не подтверждены, а в другой - байты, которые еще не отправлены.

TCP - надежный протокол, требующий установления логического соединения. С другой стороны, UDP предоставляет ненадежный сервис, не требующий соединения. Фактически UDP добавляет лишь два параметра к протоколу IP, поверх которого он построен. Во-первых, необязательную контрольную сумму для обнаружения искаженных данных. Во-вторых, UDP добавляет к IP понятие порта. С каждым TCP и UDP-сокетом ассоциирован номер порта. Приложение может явно указать этот номер путем обращения к системному вызову bind или поручить операционной системе выбор порта.

3.2 Производительность TCP

TCP - сложный протокол, обеспечивающий базовую службу доставки IP-датаграмм надежностью и управлением потоком.

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

Для обеспечения надежности TCP должен посылать подтверждения (АСК-сегменты) на каждый принятый пакет. Это несколько увеличивает объем обработки на обоих концах.

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

Как показано на рис. 3.1, клиент начинает процедуру установления соединения, посылая серверу сегмент SYN (синхронизация). В этом сегменте указывается порядковый номер, который клиент присвоит первому посланному байту, а также другие параметры соединения. В частности, максимальный размер сегмента (MSS), который клиент готов принять, и начальный размер окна приема. Сервер в ответ посылает свой сегмент SYN, который также содержит подтверждение АСК на сегмент SYN клиента. И, наконец, клиент отсылает АСК на сегмент SYN сервера. На этом процедура установления соединения завершается. Теперь клиент может послать свой первый сегмент данных.

Установление соединения

Рис. 3.1

Ha рис. 3.1 RTT (round-trip time) - это период кругового обращения, то есть время, необходимое пакету для прохождения с одного хоста на другой и обратно. Для установления соединения нужно полтора таких периода. При длительном соединении между клиентом и сервером (например, клиент и сервер обмениваются большим объемом данных) указанный период «размазывается» между всеми передачами данных, так что существенного влияния на производительность это не оказывает. Однако, если речь идет о простой транзакции, в течение которой клиент посылает запрос, получает ответ и разрывает соединение, то время инициализации составляет заметную часть от времени всей транзакции. Таким образом, следует ожидать, что UDP намного превосходит TCP по производительности именно тогда, когда приложение организует короткие сеансы связи. И, наоборот, TCР работает быстрее, когда соединение поддерживается в течении длительного времени при передаче больших объемов данных.

3.3 Сравнение TCP и UDP, обоснование выбора протокола

Протокол UDP может быть намного производительнее TCP в простых приложениях, где есть один запрос и один ответ. Очевидным кажется использовать в транзакционных задачах такого рода именно UDP, но протокол UDP ненадежен, поэтому эта обязанность лежит на приложении. Приложение, в случае использования UDP, должно позаботиться о тех датаграммах, которые теряются или искажаются при передаче.

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

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

4. Основные элементы построения сетевых приложений (API)

4.1 База элементов для построения клиента

На рис. 4.1 показаны функции, применяемые в любом клиенте.

Основные вызовы API для клиентов

Рис. 4.1

Адрес удаленного хоста задается с помощью структуры sockaddr_in, которая передается функции connect.

Первое, что необходимо сделать, - это получить сокет для логического соединения. Для этого предназначен системный вызов socket:

SOCKET socket( int domain, int type, int protocol );

Возвращаемое значение: дескриптор сокета в случае успеха; -1 (UNIX) или INVALID_SOCKET (Windows) - ошибка.

API сокетов не зависит от протокола и может поддерживать разные адресные домены. Параметр domain - это константа, указывающая, какой домен нужен сокету.

Чаще используются домены AF_INET (то есть Internet) и AF_LOCAL (или AF_UNIX). Домен AF_LOCAL применяется для межпроцессного взаимодействия (IPC) на одной и той же машине.

С помощью параметра type задается тип создаваемого сокета. Чаще встречаются следующие значения сокетов:

SOCK_STREAM - обеспечивают надежный дуплексный протокол на основе установления логического соединения. Если говорится о семействе протоколов TCP/IP, то это TCP;

SOCK_DGRAM - обеспечивают ненадежный сервис доставки датаграмм. В рамках TCP/ IP это будет протокол UDP;

SOCK_RAW -предоставляют доступ к некоторым датаграммам на уровне протокола IP. Они используются в особых случаях, например для просмотра всех ICMP-сообщений .

Параметр protocol показывает, какой протокол следует использовать с данным сокетом. В контексте TCP/IP он обычно неявно определяется типом сокета, поэтому в качестве значения задают 0. Иногда, например в случае простых (raw) сокетов, имеется несколько возможных протоколов, так что нужный необходимо задавать явно.

Для обеспечения соединения потребуется еще один вызов:

int connect; SOCKET s, const struct sockaddr *peer, int peer_len );

Возвращаемое значение: 0 - нормально, -1 (UNIX) или не 0 (Windows) -ошибка.

Параметр s - это дескриптор сокета, который вернул системный вызов socket. Параметр peer указывает на структуру, в которой хранится адрес удаленного хоста и некоторая дополнительная информация. Для домена AF_INET - это структура типа sockaddr_in. Параметр peer_len содержит размер структуры в байтах, на которую указывает peer.

После установления соединения можно передавать данные следующими вызовами:

int recv( SOCKET s, void *buf, size_t left, int flags );

int send( SOCKET s, const void *buf, size_t Jen, int Slags ) ;

Возвращаемое значение: число принятых или переданных байтов в случае успеха или -1 в случае ошибки.

Параметры s, huf и len означают то же, что и для вызовов read и write. Значение параметра flags в основном зависит от системы.

4.2 База элементов для построения Сервера

Сервер (рис.4.2) должен быть готов к установлению соединений с клиентами.

Основные вызовы API для сервера

Рис. 4.2

Для этого он обязан прослушивать известный ему порт с помощью системного вызова listen. Предварительно ему необходимо привязать адрес интерфейса и номер порта к прослушивающему сокету. Для этого предназначен вызов bind:

int bind( SOCKET s, const struct sockaddr,*name, int namelen );

Возвращаемое значение: 0 - нормально, -1 (UNIX) или socket_error (Windows) - ошибка.

Параметр s - это дескриптор прослушивающего сокета. С помощью параметров name и namelen передаются порт и сетевой интерфейс, которые нужно прослушивать. Обычно в качестве адреса задается константа INADDR_ANY. Это означает, что будет принято соединение, запрашиваемое по любому интерфейсу. namelen - длина структуры sockaddr_in.

После привязки локального адреса к сокету нужно перевести сокет в режим прослушивания входящих соединений с помощью системного вызова listen. Его единственная задача - пометить сокет как прослушивающий. Когда хосту поступает запрос на установление соединения, ядро ищет в списке прослушивающих сокетов тот, для которого адрес назначения и номер порта соответствуют указанным в запросе. Данный вызов имеет вид:

int listen( SOCKET s, int backlog );

Возвращаемое значение: 0 - нормально, -1 (UNIX) или SOCKET_ERROR (Windows) - ошибка.

Параметр s - это дескриптор сокета, который нужно перевести в режим прослушивания. Параметр backlog - это максимальное число ожидающих, но еще не принятых соединений. Следует отметить, что это не максимальное число одновременных соединений с данным портом, а лишь максимальное число частично установленных соединений, ожидающих в очереди, пока приложение их примет.

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

Вызов accept служит для приема соединения, ожидающего во входной очереди. После того как соединение принято, его можно использовать для передачи данных, например, с помощью вызовов recv и send. В случае успеха accept возвращает дескриптор нового сокета, по которому и будет происходить обмен данными.

int accept( SOCKET s, struct sockaddr *addr, int *addrlen );

Возвращаемое значение: 0- нормально, -1 (UNIX) или invalid_socket (Windows) - ошибка.

Параметр s - это дескриптор прослушивающего сокета. Как показано на рис. 4.2, accept возвращает адрес приложения на другом конце соединения в структуре sockaddr_in, на которую указывает параметр addr. Целому числу, на которое указывает параметр addrlen, ядро присваивает значение, равное длине этой структуры. Часто нет необходимости знать адрес клиентского приложения, поэтому в качестве addr и addrlen , будет передаваться NULL.

4.3 Завершение работы приложения и состояние TIME-WAIT

Состояние TIME-WAIT /4/ наступает в ходе разрыва TCP соединения. Для чего нужно обменяться четырьмя сегментами. На рис. 4.3 показано соединение между двумя приложениями, работающими на хостах 1 и 2.

Разрыв соединения

Рис.4.3

Приложение на хосте 1 закрывает свою сторону соединения, при этом TCP посылает сегмент FIN хосту 2. Хост 2 подтверждает FIN сегментом АСК и доставляет FIN приложению в виде признака конца файла EOF (предполагается, что у приложения есть незавершенная операция чтения). Позже приложение на хосте 2 закрывает свою сторону соединения, посылая FIN хосту 1, который отвечает сегментом АСК.

В этот момент хост 2 окончательно закрывает соединение и освобождает ресурсы. С точки зрения хоста 2, соединения больше не существует. Однако хост 1 не закрывает соединение, а переходит в состояние TIME-WAIT и остается в нем в течение двух максимальных продолжительностей существования сегмента (2MSL -maximum segment lifetime).

5. Описание и принципы действия основных инструментов отладки, мониторинга и управления

5.1 Система удаленного управления терминалом SSH

SSH (Secury shell) обеспечивает возможность удаленного выполнения команд и копирования файлов с аутентификацией клиента и сервера и шифрованием передаваемых данных (пароли также шифруются). Используемые порты: 22/tcp, 22/udp. SSH Представляет собой протоколы транспортного уровня, аутентификации и соединения (предполагается стандартизация IETF) и программные средства безопасного доступа к компьютерам по небезопасным каналам связи (telnet, X11, rsh, ftp). Аутентификация производится с использованием ассиметричного шифрования с открытым ключом (RSA/DSA). Обмен данными - симметричное шифрование (IDEA).

SSH так же позволяет использовать следующие методы проверки достоверности:

1) проверка достоверности на уровне самих машин, хостов;

2)проверка достоверности на уровне пользователя включая:

-RSA - аутентикацию;

-проверку достоверности посредством "public key".

3) шифрация данных любым из доступных методов используемых в SSH, по умолчанию - IDEA;

4) использование парольной фразы - passphrase;

5) совместная работа SSH с другими методами проверки безопасности, TIS, Kerberos, SSL, C2 и так далее, подробнее см. документацию SSH.

Клиент выступает в качестве рабочего места пользователя, на нем обязательно должны быть сгенерены "public key" и "private key", а со стороны удаленной машины, куда необходимо иметь безопасный вход, должен быть запущен демон SSHD, таким образом удаленная машина является сервером.