Учебник для вузов в. Олифер Н. Олифер Компьютерные Принципы, технологии, протоколы
 Скачать 22.28 Mb.
|
|
883 могут также фильтровать почтовые сообщения по типу пересылаемого файла (например, запретить получение сообщений формата MP3) и по их контенту. К разным пользователям могут применяться разные правила фильтрации, поэтому часто на прокси-серверы воз лагается задача аутентификации пользователей. Рис. 24.25. Варианты расположения прокси-серверов: а — на сетевом экране, б — на узле внутренней сети Если после всесторонней оценки запроса от приложения прокси-сервер констатирует, что запрос удовлетворяет условиям прохождения дальше во внешнюю сеть, то он выполняет по поручению приложения, но от своего имени процедуру соединения с сервером, затребо ванным данным приложением. В некоторых случаях прокси-сервер может изменять запрос клиента. Например, если в него встроена функция трансляции сетевых адресов (см. раздел «Трансляция сетевых адресов» в главе 18), он может подменять в пакете запроса IP-адреса и/или номера TCP- и UDP- 884 Глава 24. Сетевая безопасность портов отправителя. Таким способом прокси-сервер лишает злоумышленника возможности сканировать внутреннюю сеть для получения информации об адресах узлов и структуре сети. Единственный адрес в таком случае, который может узнать злоумышленник, — это адрес компьютера, на котором выполняется программа прокси-сервера. Поэтому многие атаки, построенные на знании злоумышленником адресов узлов внутренней сети, стано вятся нереализуемыми. Прокси-сервер, выступая посредником между клиентом и сервером, взаимодействующими между собой по совершенно определенному протоколу, не может не учитывать специфику этого протокола. Так, для каждого из протоколов HTTP, HTTPS, SMTP/POP, FTP, telnet существует особый прокси-сервер, ориентированный на использование соответствующими приложениями: веб-браузером, электронной почтой, FTP-клиентом, клиентом telnet. Каж дый из этих посредников принимает и обрабатывает пакеты только того типа приложений, для обслуживания которого он был создан. ПРИМЕЧАНИЕ-------------------------------------------------------------------------------------------------- Обычно несколько разных прокси-серверов объединяю т в один программный продукт. Посмотрим, как учитывает специфику протокола прокси-сервер, ориентированный на веб-службу. Этот тип прокси-сервера может, например, выполнить собственными силами запрос веб-клиента, не отсылая его к соответствующему веб-серверу. Работая транзитным узлом при передаче сообщений между браузерами и веб-серверами Интернета, прокси- сервер не только передает клиентам запрашиваемые веб-страницы, но и сохраняет их в своей кэш-памяти на диске. В соответствии с алгоритмом кэширования, на диске прокси- сервера оседают наиболее часто используемые веб-страницы. При получении запросов к веб-серверам прокси-сервер, прежде всего, проверяет, есть ли запрошенная страница в его кэше. Если есть, то она немедленно передается клиенту, а если нет, то прокси-сервер обыч ным образом делает запрос от имени своего доверителя. Прокси-сервер веб-службы может осуществлять административный контроль проходящего через него контента, в частности ограничивать доступ клиента к сайтам, имеющим IP-адреса или DNS-имена из «черных списков». Более того, он может фильтровать сообщения на основе ключевых слов. Прокси-серверы прикладного уровня и уровня соединений Прокси-серверы могут выполнять свою посредническую миссию на разных уровнях. ПРИМЕР-АНАЛОГИЯ ---------------------------------------------------------------------------------------- Рассмотрим пример, иллю стрирую щ ий идею посредничества разного уровня. Д ля покупки акций инвестор (в нашем случае аналог клиентской части приложения) может прибегнуть к посредническим услугам брокера или 1рейдера. Брокер, точно следуя указаниям инвестора, покупает для него опреде ленное количество акций определенного типа по определенной цене. Трейдер — это посредник более высокого уровня, которому инвестор поручает самостоятельно принимать реш ения о необходимых покупках, учиты вая различные факторы, например состояние рынка. Различают прокси-серверы прикладного уровня и уровня соединений. Прокси-сервер прикладного уровня, как это следует из его названия, умеет «вклинивать ся» в процедуру взаимодействия клиента и сервера по одному из прикладных протоколов, Прокси-серверы 885 например тому же HTTP, HTTPS> SMTP/POP, FTP или telnet. Чтобы выступать в роли посредника на прикладном уровне, прокси-сервер должен «понимать» смысл команд, «знать» форматы и последовательность сообщений, которыми обмениваются клиент и сер вер соответствующей службы. Это дает возможность прокси-серверу проводить анализ содержимого сообщений, делать заключения о подозрительном характере того или иного сеанса. Прокси-сервер уровня соединений выполняет свою посредническую миссию на транс портном уровне, контролируя TCP-соединение. Очевидно, что работая на более низком уровне, прокси-сервер обладает гораздо меньшим «интеллектом» и имеет меньше возмож ностей для выявления и предупреждения атак. Однако он обладает одним очень важным преимуществом перед прокси-сервером прикладного уровня — универсальностью, то есть он может быть использован любыми приложениями, работающими по протоколу TCP (а в некоторых случаях и UDP). Примером прокси-сервера данного типа является разработанный достаточно давно, но все еще широко применяемый сервер SOCKS (от SOCKetS). В простейшей версии протокола SOCKS V41 клиент обменивается с прокси-сервером SOCKS двумя сообщениями: запросом клиента SOCKS-серверу и ответом SOCKS-сервера клиенту. □ Запрос клиента SOCKS-серверу: О поле 1 — номер версии SOCKS, 1 байт (для этой версии — 4); G поле 2 — код команды, 1 байт (для установки соединения T C P/IP код равен 1); О поле 3 — номер порта, 2 байта (TCP-порт запрашиваемого пользователем ресурсного сервера, например, для 21 для FTP); О поле 4 — 1Р-адрес, 4 байта (IP -адрес ресурсного сервера); О поле 5 — идентификатор пользователя (строка переменной длины, завершаемая байтом null). SOCKS-сервер анализирует все полученные данные и на основании сконфигурирован ных для него правил определяет, предоставить или неу данному пользователю доступ к данному серверу. Результат SOCKS-сервер сообщает клиенту в виде ответа. □ Ответ SOCKS-сервера клиенту: О поле 1 — байт null; О поле 2 — код ответа, 1 байт (применяются коды для следующих вариантов ответа: запрос разрешен, запрос отклонен или ошибочен, запрос не удался из-за проблем с идентификацией пользователя); О несколько байтов, игнорируемых клиентом. Если прокси-сервер сообщил в ответе, что запрос разрешен, то SOCKS-сервер начинает работать промежуточном звеном между клиентом и сервером (например, FTP), контро лируя поток квитанции, которыми они обмениваются. 1 Более поздняя версия протокола SO CK S V5 расш иряет возможности версии SO CK S V4, добавляя поддержку UDP, доменных имен, адресов IPv6 и процедур аутентификации пользователей. 886 Глава 24. Сетевая безопасность «Проксификация» приложений Заметим, что не каждое приложение, построенное в архитектуре клиент-сервер, непре менно должно работать через прокси-сервер, а также не каждое из них имеет возможность работать через прокси-сервер. Список приложений (точнее их клиентских частей), которые должны передавать свои запросы во внешнюю сеть исключительно через прокси-сервер, определяется администра тором. А чтобы эти приложения имели возможности для такого режима выполнения, их программы должны быть соответствующим образом написаны. Точнее приложения должны быть оснащены средствами, которые распознавали бы запросы к внешним серверам и перед отправкой преобразовывали эти запросы так, чтобы все они попадали на соответствующий прокси-сервер, а не передавались в соответствии со стан дартным протоколом прямо на сервер-адресат. Эти средства должны также поддерживать протокол обмена сообщениями приложения-клиента с прокси-сервером. В последние годы в большинстве приложений, ориентированных на работу через Интернет, предусмотрена встроенная поддержка прокси-сервера. Такой поддержкой, например, оснащены все веб браузеры и все клиенты электронной почты, которыми мы сейчас пользуемся. «Проксификация» приложения, изначально не рассчитанного на работу через проки- сервер, требует изменения исходного кода с последующей перекомпиляцией — очевидно, что такая работа не представляет сложностей для разработчиков данного приложения, но не всегда под силу обслуживающему персоналу сети. Задача последних заключается в при обретении готовых приложений, совместимых с используемым в сети прокси-сервером. Однако даже приобретение готового «проксифицированного» клиента не делает его гото вым к работе — необходимо еще конфигурирование, в частности нужно сообщить клиенту адрес узла сети, на котором установлен соответствующий прокси-сервер. Как можно было бы предположить, процедура «проксификации» значительно упрощается для прокси-сервера уровня соединений, в частности SOCKS-сервера. Для «проксифика ции» приложения в этом случае достаточно внести простейшие исправления в исходный текст, а затем выполнить его перекомпиляцию и связывание с библиотекой процедур SOCKS. Исправления сводятся к замене всех стандартных вызовов сетевых функций версиями этих функций из библиотеки SOCKS, в частности стандартный вызов 1 і s t e n ( ) заменяется вызовом rl і s t e n ( ), вызов bi nd( ) — вызовом rbi nd( ), вызов a c c e p t () — вы зовом r a c c e p t ( ). Имеется еще один подход к «проксификации» — встраивание поддержки прокси-сервера в операционную систему. В этом случае приложения могут оставаться в полном «неведении» о существовании в сети прокси-сервера, за них все необходимые действия выполнит ОС. Помимо основных функций, многие прокси-серверы способны обнаруживать вирусы еще до того, как они попали во внутреннюю сеть. К другим полезным (для администрации и службы безопасности) вспомогательным функциям прокси-сервера относится сбор статистических данных о доступе пользователей в Интернет: когда и какие сайты посещал тот или иной пользователь, сколько времени продолжалось каждое посещение. Протоколы защищенного канала. IPsec 887 Системы обнаружения вторжений Система обнаружения вторжений (Intrusion Detection System, IDS) — это программное или аппаратное средство, предназначенное для предупреждения, выявления и протоколирования некоторых типов сетевых атак. В отличие от сетевых экранов и прокси-серверов, которые строят защиту сети исключи тельно на основе анализа сетевого трафика, системы обнаружения вторжений учитывают в своей работе различные подозрительные события, происходящие в системе. Существуют ситуации, когда сетевой экран оказывается проницаемым для злоумышлен ника, например, когда атака идет через туннель VPN из взломанной сети или инициатором атаки является пользователь внутренней сети и т. п. И дело здесь не в плохой конфигура ции межсетевого экрана, а в самом принципе его работы. Экран, несмотря на то что облада ет памятью и анализирует последовательность событий, конфигурируется на блокирование трафика с заранее предсказуемыми признаками, например по ІР-адресам или протоколам. Так что факт взлома внешней сети, с которой у него был установлен защищенный канал и которая до сих пор вела себя вполне корректно, в правилах экрана отразить нельзя. Точно так же, как и неожиданную попытку легального внутреннего пользователя скопировать файл с паролями или повысить уровень своих привилегий. Подобные подозрительные действия может обнаружить только система со встроенными агентами во многих точках сети, причем она должна следить не только за трафиком, но и за обращениями к критически важным ресурсам операционных систем отдельных компьютеров, а также иметь инфор мацию о перечне подозрительных действий (сигнатур атак) пользователей. Таковой и яв ляется система обнаружения вторжений. Она не дублирует действия межсетевого экрана, а дополняет их, производя, кроме того, автоматический анализ всех журналов событий, имеющихся у сетевых устройств и средств защиты, чтобы попытаться найти следы атаки, если ее не удалось зафиксировать в реальном времени. Протоколы защищенного канала. IPsec Известно, что задачу защиты данных можно разделить на две подзадачи: защиту данных внутри компьютера и защиту данных в процессе их передачи от одного компьютера в дру гой. Для обеспечения безопасности данных при их передаче по публичным сетям исполь зуются различные технологии защищенного канала. Технология защищенного канала обеспечивает защиту трафика между двумя точками в откры той транспортной сети, например в Интернете. Защищенный канал подразумевает выполнение трех основных функций: □ взаимная аутентификация абонентов при установлений соединения, которая может быть выполнена, например, путем обмена паролями; □ защита передававмцх'По каналу сообщений от несанкционированного доступа, например, путем шифрования; □ подтверждение целостности поступающих по каналу сообщений, например, путем передачи одновременно с сообщением его дайджеста. 888 Глава 24. Сетевая безопасность В зависимости от местарасположения программного обеспечения защищенного канала различает две схемы его образования: □ схема с конечными узлами, взаимодействующими через публичную сеть (рис. 24.26, а)\ □ схема с оборудованием поставщика услуг публичной сети, расположенным на границе между частной и публичной сетями (рис. 24.26, б). В первом случае защищенный канал образуется программными средствами, установлен ными на двух удаленных компьютерах, принадлежащих двум разным локальным сетям одного предприятия и связанных между собой через публичную сеть. Преимуществом этого подхода является полная защищенность канала вдоль всего пути следования, а также возможность использования любых протоколов создания защищенных каналов, лишь бы на конечных точках канала поддерживался один и тот же протокол. Недостатки заключаются в избыточности и децентрализованности решения. Избыточность состоит в том, что вряд ли стоит создавать защищенный канал на всем пути следования данных: уязвимыми для злоумышленников обычно являются сети с коммутацией пакетов, а не каналы телефонной сети или выделенные каналы, через которые локальные сети подклю чены к территориальной сети. Поэтому защиту каналов доступа к публичной сети можно считать избыточной. Децентрализация заключается в том, что для каждого компьютера, которому требуется предоставить услуги защищенного канала, необходимо отдельно уста навливать, конфигурировать и администрировать программные средства защиты данных. Подключение каждого нбвого компьютера к защищенному каналу требует выполнять эти трудоемкие операций заново. Во втором случае клиенты и серверы не участвуют в создании защищенного канала — он прокладывается только внутри публичной сети с коммутацией пакетов, например внутри Интернета. Так, канал может быть проложен между сервером удаленного доступа по ставщика услуг публичной сети и пограничным маршрутизатором корпоративной сети. Это хорошо масштабируемое решение, управляемое централизовано администраторами Протоколы защищенного канала. IPsec 889 как корпоративной сети, так и cefn поставщика услуг. Для компьютеров корпоративной сети канал прозрачен — программное обеспечение этих конечных узлов остается без из менений. Такой гибкий подход позволяет легко образовывать новые каналы защищенного взаимодействия между компьютерами независимо от места их расположения. Реализация этого подхода сложнее — нужен стандартный протокол образования защищенного канала, требуется установка у всех поставщиков услуг программного обеспечения, поддерживаю щего такой протокол, необходима поддержка протокола производителями пограничного коммуникационного оборудования. Однако вариант, когда все заботы по поддержанию защищенного канала берет на себя поставщик услуг публичной сети, оставляет сомне ния в надежности защиты: во-первых, незащищенными оказываются каналы доступа к публичной сети, во-вторых, потребитель услуг чувствует себя в полной зависимости от надежности поставщика услуг. Иерархия технологий защищенного канала Защищенный канал можно построить с помощью системных средств, реализованных на разных уровнях модели OSI (рис. 24.27). Уровни защищаемых протоколов Протоколы защищенного канала Свойства протоколов защищенного канала Прикладной уровень S/MIME Уровень представления SSL, TLS Непрозрачность п п а п п м п л м / й и м м и й о о в м л м и л л т и Сеансовый уровень " д л я n p n j іи ж о и и и , п е о а в и и іг ім и и і ь - от транспортной инфраструктуры Транспортный уровень Сетевой уровень IPSec Прозрачность для приложений, АТ тґ\0илплптилі4 Канальный уровень РРТР З а В И С И М О С Т Ь О Т Т р а Н С П О р Т Н О И инфраструктуры Физический уровень Рис. 24.27. Протоколы, формирующие защищенный канал на разных уровнях модели OSI Если защита данных осуществляется средствами верхних уровней (прикладного, представ ления или сеансового), то такой способ защиты не зависит от технологий транспортировки данных (IP или IPX, Ethernet или ATM), что можно считать несомненным достоинством. В то же время приложения при этом становятся зависимыми от конкретного протокола защищенного канала, так как в них должны быть встроены явные вызовы функций этого протокола. Защищенный канал, реализованный на самом высоком (прикладном) уровне, защищает только вполне определенную сетевую службу, например файловую, гипертекстовую или почтовую. Так, протокол S/М ІМ Е защищает исключительно сообщения электронной почты. При таком подходе для каждой службы необходимо разрабатывать собственную защищенную версию протокола. |