Посредники сеансового уровня

МЭ динамической фильтрации пакетов

МЭ динамической фильтрации пакетов (МЭ ДФ) позволяют модифицировать (корректировать) базу правил «на лету». Эта тех­нология изначально разрабатывалась для поддержки транспортно­го протокола UDP. Транспортный протокол UDP обычно использу­ется при небольших информационных запросах и ответах на прикладном уровне.

МЭ ДФ ассоциирует все UDP-пакеты с неким виртуальным соединением (напомним, что протокол UDP не определяет поня­тие соединения). Если МЭ обнаруживает ответный пакет, то уста­навливается виртуальное соединение, и пакету разрешается про­ходить через МЭ. Информация, ассоциированная с виртуальным соединением, обычно запоминается на короткий промежуток вре­мени, и если в этот промежуток времени не получен (обнаружен) ответный пакет, то виртуальное соединение разрывается (ликви­дируется).

МЭ ДФ имеют такие же преимущества и недостатки, как и первое поколение МЭ - МЭ ФП с одним исключением: дополни­тельно они не пропускают незапрашиваемые (согласно оценок вир­туального соединения) UDP-пакеты. МЭ пропускает первый па­кет UDP во внутреннюю сеть. Ответный пакет должен содержать соответствующий адрес назначения и номер порта.

МЭ ДФ можно использовать для поддержки ограниченного под­множества команд протокола ICMP. ICMP-протокол часто приме­няют для проверки сетевого соединения между двумя хостами путем обмена парой пакетов (ping). В этом случае МЭ может ре­шать различные задачи «видимости» внешних и внутренних хос­тов по некоторым правилам, что особо важно, поскольку протокол ICMP используется при реализации некоторых широко распрост­раненных атак.

Динамические фильтры, как МЭ, в настоящее время не исполь­зуют. Принципы, заложенные в ДФ, реализованы и значительно расширены в инспекторах состояний. По сравнению с инспектора­ми соединений в МЭ ДФ была предпринята попытка управлять взаимодействием хостов по протоколу UDP. Но, как будет показа­но ниже, инспекторы состояний при управлении UDP-трафиком ин­спектируют данные прикладного уровня, а МЭ ДФ использовали только адреса, транспортные порты и временные системы.

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

Наиболее известным примером посредника сеансового уровня является посредник SOCKS5. При запросе соединения с некото­рым узлом Интернет, SOCKS 5 проводит аутентификацию клиента и проверяет его права на доступ к запрашиваемому узлу по запра­шиваемому прикладному протоколу (на основании номера порта TCP/UDP). При успешной аутентификации пользователя SOCKS 5 устанавливает соединение с запрашиваемым узлом, что обеспе­чивает единую точку входа в сеть с обеих сторон сервера SOCKS 5. SOCKS5 позволяет передавать данные как в открытом виде, так и по защищенному протоколу, например SSL.

Недостатком использования посредника SOCKS5 является не­обходимость установки на каждое рабочее место клиентской час­ти SOCKS5, если, конечно, прикладные приложения сами не под­держивают работу через SOCKS5. Кроме того, нужно отметить, что поскольку клиентская часть SOCKS5 работает на основе пе­рехвата вызовов сетевого API ОС, то по ряду причин не все прило­жения будут поддерживать работу через SOCKS 5.

Одно из основных преимуществ SOCKS5 состоит в том, что он позволяет полноценно управлять доступом к различным ресурсам (адрес:порт) закрытой и общедоступной сетей на основе строгой аутентификации и при этом поддерживает транспортные протоко­лы TCP и UDP.

Дата добавления: 2014-01-07