Компьютерные сети

Прокси-серверы прикладного уровня и уровня соединений
Прокси-серверы могут выполнять свою посредническую миссию на разных уровнях.
ПРИМЕР-АНАЛОГИЯ -

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

Различают прокси-серверы прикладного уровня и уровня соединений.
Прокси-сервер прикладного уровня, как это следует из его названия, умеет «вклиниваться» в процедуру взаимодействия клиента и сервера по одному из прикладных протоколов, например тому же HTTP, HTTPS
>

SMTP/POP, FTP или telnet. Чтобы выступать в роли посредника на прикладном уровне, прокси-сервер должен «понимать» смысл команд, «знать» форматы и последовательность сообщений, которыми обмениваются клиент и сервер соответствующей службы. Это дает возможность прокси-серверу проводить анализ содержимого сообщений, делать заключения о подозрительном характере того или иного сеанса.

Прокси-сервер уровня соединений выполняет свою посредническую миссию на транспортном уровне, контролируя TCP-соединение. Очевидно, что работая на более низком уровне, прокси-сервер обладает гораздо меньшим «интеллектом» и имеет меньше возможностей для выявления и предупреждения атак. Однако он обладает одним очень важным преимуществом перед прокси-сервером прикладного уровня — универсальностью, то есть он может быть использован любыми приложениями, работающими по протоколу TCP (а в некоторых случаях и UDP).

Примером прокси-сервера данного типа является разработанный достаточно давно, но все еще широко применяемый сервер SOCKS (от SOCKetS).
В простейшей версии протокола SOCKS V4
84
клиент обменивается с прокси-сервером SOCKS двумя сообщениями: запросом клиента SOCKS-серверу и ответом SOCKS-сервера клиенту.
□ Запрос клиента SOCKS-серверу:
О поле 1 — номер версии SOCKS, 1 байт (для этой версии — 4);
G поле 2 — код команды, 1 байт (для установки соединения TCP/IP код равен 1);

О поле 3 — номер порта, 2 байта (TCP-порт запрашиваемого пользователем ресурсного сервера, например, для 21 для FTP);
О поле 4 — 1Р-адрес, 4 байта (IP-адрес ресурсного сервера);
О поле 5 — идентификатор пользователя (строка переменной длины, завершаемая байтом null).
SOCKS-сервер анализирует все полученные данные и на основании сконфигурированных для него правил определяет, предоставить или неу данному пользователю доступ к данному серверу. Результат SOCKS-сервер сообщает клиенту в виде ответа.

□ Ответ SOCKS-сервера клиенту:
О поле 1 — байт null;
О поле 2 — код ответа, 1 байт (применяются коды для следующих вариантов ответа: запрос разрешен, запрос отклонен или ошибочен, запрос не удался из-за проблем с идентификацией пользователя);
О несколько байтов, игнорируемых клиентом.
Если прокси-сервер сообщил в ответе, что запрос разрешен, то SOCKS-сервер начинает работать промежуточном звеном между клиентом и сервером (например, FTP), контролируя поток квитанции, которыми они обмениваются.

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

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

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

«Проксификация» приложения, изначально не рассчитанного на работу через проки-сервер, требует изменения исходного кода с последующей перекомпиляцией — очевидно, что такая работа не представляет сложностей для разработчиков данного приложения, но не всегда под силу обслуживающему персоналу сети. Задача последних заключается в приобретении готовых приложений, совместимых с используемым в сети прокси-сервером. Однако даже приобретение готового «проксифицированного» клиента не делает его готовым к работе — необходимо еще конфигурирование, в частности нужно сообщить клиенту адрес узла сети, на котором установлен соответствующий прокси-сервер.

Как можно было бы предположить, процедура «проксификации» значительно упрощается для прокси-сервера уровня соединений, в частности SOCKS-сервера. Для «проксификации» приложения в этом случае достаточно внести простейшие исправления в исходный текст, а затем выполнить его перекомпиляцию и связывание с библиотекой процедур SOCKS. Исправления сводятся к замене всех стандартных вызовов сетевых функций версиями этих функций из библиотеки SOCKS, в частности стандартный вызов 1 i sten () заменяется вызовом rl i sten(), вызов bi nd() — вызовом rbi nd(), вызов accept () — вызовом raccept().

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

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

Система обнаружения вторжений (Intrusion Detection System, IDS) — это программное или аппаратное средство, предназначенное для предупреждения, выявления и протоколирования некоторых типов сетевых атак.
В отличие от сетевых экранов и прокси-серверов, которые строят защиту сети исключительно на основе анализа сетевого трафика, системы обнаружения вторжений учитывают в своей работе различные подозрительные события, происходящие в системе.

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

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

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

□ подтверждение целостности поступающих по каналу сообщений, например, путем передачи одновременно с сообщением его дайджеста.
В зависимости от местарасположения программного обеспечения защищенного канала различает две схемы его образования:
□ схема с конечными узлами, взаимодействующими через публичную сеть (рис. 24.26, а)\
□ схема с оборудованием поставщика услуг публичной сети, расположенным на границе между частной и публичной сетями (рис. 24.26, б).

Рис. 24.26. Два подхода к образованию защищенного канала

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

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

Иерархия технологий защищенного канала
Защищенный канал можно построить с помощью системных средств, реализованных на разных уровнях модели OSI (рис. 24.27).
Уровнизащищаемыхпротоколов
Протоколызащищенногоканала
Свойства протоколов защищенного канала
Прикладнойуровень
S/MIME
Уровеньпредставления
SSL, TLS
Непрозрачностьппа пг\мплм/оимм иооооылмиллть
Сеансовыйуровень
' Д1т МрП1 ЮЖопИИ, НвЗаВИСИМиС! Ь "от транспортной инфраструктуры
Транспортныйуровень
Сетевойуровень
IPSec

Прозрачность для приложений,OODM^MIIAATL АТ ТЬОиЛПЛПтиЛЫ
Канальныйуровень
РРТР
ЗаВИСИМОСТЬ ОТ ТраНСПОрТНОИинфраструктуры
Физическийуровень
Рис. 24.27. Протоколы, формирующие защищенный канал на разных уровнях модели OSI

Если защита данных осуществляется средствами верхних уровней (прикладного, представления или сеансового), то такой способ защиты не зависит от технологий транспортировки данных (IP или IPX, Ethernet или ATM), что можно считать несомненным достоинством. В то же время приложения при этом становятся зависимыми от конкретного протокола защищенного канала, так как в них должны быть встроены явные вызовы функций этого протокола.

Защищенный канал, реализованный на самом высоком (прикладном) уровне, защищает только вполне определенную сетевую службу, например файловую, гипертекстовую или почтовую. Так, протокол S/MIME защищает исключительно сообщения электронной почты. При таком подходе для каждой службы необходимо разрабатывать собственную защищенную версию протокола.
Популярный протокол SSL
85
(Secure Socket Layer — слой защищенных сокетов) работает на уровне

представления и создает защищенный канал, используя следующие технологии безопасности:
□ взаимная аутентификация приложений на обоих концах защищенного канала выполняется путем обмена сертификатами (стандарт Х.509);
□ для контроля целостности передаваемых данных используются дайджесты;
□ секретность обеспечивается шифрацией со средствами симметричных ключей сеанса.

Протокол SSL разработан компанией Netscape Communications для защиты данных, передаваемых между веб-сервером и веб-браузером, но он может быть использован и любыми другими приложениями. Работа протокола защищенного канала на уровне представления делает его более универсальным средством, чем протокол безопасности прикладного уровня. Однако для того чтобы приложение смогло воспользоваться протоколом уровня представления, в него по-прежнему приходится вносить исправления, хотя и не столь существенные, как в случае протокола прикладного уровня. Модификация приложения в данном случае сводится к встраиванию явных обращений к API соответствующего протокола безопасности.

Средства защищенного канала становятся прозрачными для приложений в тех случаях, когда безопасность обеспечивается на сетевом и канальном уровнях. Однако здесь мы сталкиваемся с другой проблемой — зависимостью сервиса защищенного канала от протокола нижнего уровня. Например, протокол РРТР, не являясь протоколом канального уровня, защищает кадры протокола РРР канального уровня, упаковывая их в IP-пакеты. При этом не имеет никакого значения, пакет какого протокола, в свою очередь, упакован в данном РРР-кадре: IP, IPX, SNA или NetBIOS. С одной стороны, это делает сервис РРТР достаточно универсальным, так как клиент сервиса защищенного канала может задействовать любые протоколы в своей сети. С другой стороны, такая схема предъявляет жесткие требования к типу протокола канального уровня, используемому на участке доступа клиента к защищенному каналу — для протокола РРТР таким протоколом может быть только РРР. Хотя протокол РРР очень распространен в линиях доступа, сегодня конкуренцию ему составляют протоколы Gigabit Ethernet и Fast Ethernet, которые все чаще работают не только в локальных, но и глобальных сетях.

Работающий на сетевом уровне протокол IPSec является компромиссным вариантом. С одной стороны, он прозрачен для приложений, с другой — может Сработать практически во всех сетях, так как основан на широко распространенном протоколе IP и использует любую технологию канального уровня (РРР, Ethernet, ATM и т. д.).
Распределение функций между протоколами IPSec

Протокол IPSec называют в стандартах Интернета системой. Действительно, IPSec — это согласованный набор открытие стандартов, имеющий сегодня вполне очерченное ядро, которое в то же время может быть достаточно просто дополнено новыми функциями и протоколами.
Ядро IPSec составляют три протокола:
□ АН (Authentication Header — заголовок аутентификации) — гарантирует целостность и аутентичность данных;

□ ESP (Encapsulating Security Payload — инкапсуляция зашифрованных данных) — шифрует передаваемые данные, обеспечивая конфиденциальность, может также поддерживать аутентификацию и целостность данных;
□ IKE (Internet Key Exchange — обмен ключами Интернета) — решает вспомогательную задачу автоматического предоставления конечным точкам защищенного канала секретных ключей, необходимых для работы протоколов аутентификации и шифрования данных.

Как видно из краткого описания функций, возможности протоколов АН и ESP частично перекрываются (рис. 24.28). В то время как АН отвечает только за обеспечение целостности и аутентификации данных, ESP может шифровать данные и, кроме того, выполнять функции протокола АН (хотя, как увидим позднее, аутентификация и целостность обеспечиваются им в несколько урезанном виде). ESP может поддерживать функции шифрования и аутентификации/целостности в любых комбинациях, то есть либо всю группу функций, либо только аутентификацию/целостность, либо только шифрование.

Выполняемые функции
Протокол
Обеспечение целостности
АН
ESP
Обеспечение аутентичности
Обеспечение конфиденциальности (шифрование)
Распределение секретных ключей
IKE
Рис. 24.28. Распределение функций между протоколами IPSec

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

Безопасная ассоциация
Для того чтобы протоколы АН и ESP могли выполнять свою работу по защите передаваемых данных, протокол IKE устанавливает между двумя конечными точками логическое соединение (рис. 24.29), которое в стандартах IPSec носит название безопасной ассоциации (Security Association, SA).
Рис. 24.29. Безопасная ассоциация

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

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

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