Методы и средства защиты компьютерной информации (стр. 2 )

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

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

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

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

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

Протокол с нестабильной структурой полей. Главной особенностью этого класса протоколов являются возникающие в работе функциональные поля со случайным набором параметров, зависящих от различных факторов (общего числа пользователей сети, ошибках выполнения и т. д). Границы субпротоколов обозначены неявно, содержит частые включения субструктуры TLV (Type – Length – Value). Фильтрация возможна при определении отдельных дополнительных условий (например, протокол OSCAR в ICQ-клиентах). Спецификации подобных протоколов закрыты или доступны не полностью, их содержание может быть заведомо некорректным или неактуальным. Межсетевой экран должен обладать возможностью автоматического редактирования прикладных правил на основе считывания отдельных полей и расчёта смещений данных в процессе работы приложения.

Протокол с языковой структурой описания – реализован на основе языка описания, представляет собой текстовые последовательности, размеры и смещения которых зависят от конкретной ситуации, происходящей как в самом приложении, так и в сети. Результаты фильтрации неоднозначны – удаление одного пакета может привести как к разрыву сессии, так и к продолжению работы в рамках уже существующей сессии с возможным искажением загружаемого контента (яркими представителями источников такого трафика являются JavaScript, Java-апплеты, ActiveX, различные приложения основанные на языке XML). Для фильтрации данной группы протоколов межсетевой экран должен быть оборудован механизмом контроля/восстановления протокольных сессий и пересборки пакетов.

Протокол с шифрованием данных – основан на полном или частичном шифровании, анализ данных затруднён для неопределённых источников трафика, но возможна фильтрация сертификатов в каждом индивидуальном случае (например, TLS, SSL, шифрованный Skype и BitTorrent). Экран должен быть оснащён модулями проверки сертификатов и расшифровки элементов.

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

1.2 Анализ прикладных протоколов

1.2.1 Традиционные протоколы прикладного уровня

1.2.1.1 HTTP

HTTP (HyperText Transfer Prоtocоl) – протокол обмена гипертекстовой информацией, протокол прикладного уровня стека TCP/IP. Его первая версия была разработана в 1991 году Тимом Бернерсом-Ли, как один из базовых элементов «мировой паутины» World Wide Web (WWW).

В 1996 году в RFC 1945 была определена версия HTTP 1.0, а в 1999 году вышла действующая на настоящий момент версия HTTP 1.1. Протокол этот достаточно сложен, его описание составляет почти 200 страниц, поэтому здесь мы касаемся лишь основных его особенностей с точки зрения возможной фильтрации.

В качестве транспортного протокола HTTP использует TCP и работает по стандартной схеме «клиент-сервер». Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта – 80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту. В версии HTTP 1.1 TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Протокол HTTP не сохраняет своего состояния, то есть не «помнит» предыдущих запросов и ответов (для этого могут использоваться дополнительные средства).

Таким образом, HTTP сообщения делятся на запросы клиента серверу и ответы сервера клиенту. Оба типа сообщений выглядят следующим образом: сначала идет начальная строка (start-line), затем один или несколько полей заголовка (называемых также просто "заголовки"), затем пустая строка, указывающая конец полей заголовка, а затем, возможно, тело сообщения.

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа.

Формат запросов и ответов различный.

HTTP запрос имеет следующий формат

Начальная строка

Заголовки запроса

Тело-Запроса

Начальная строка в запросе называется строкой запроса (Request-Line) и имеет формат <METHOD> <URI> <HTTP-VERSION> или <Метод><URI><Версия>.

Метод обозначает действие, которое следует применить к запрашиваемому объекту, метод может принимать следующие значения:

GET, HEAD, POST, PUT и др.

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

Пример

GET / HTTP/1.0 — простейший запрос. Запрашивается корневой файл из корневой директории web-сервера.

HEAD – аналогичен методу GET, за исключением того, что в ответе сервер не возвращает Тело-Ответа. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса.

POST – применяется главным образом для модификации имеющегося ресурса или передачи данных обрабатывающему их процессу. Тело запроса содержит данные. Метод POST может изменять содержимое ресурса, поэтому не может считаться безопасным методом. Метод применяется для передачи данных CGI-скриптам из HTML форм. Сами данные следуют в последующих строках запроса в виде параметров. Реальная функция, выполняемая методом POST, определяется сервером и обычно зависит от URI-Запроса.

PUT – запрашивает сервер о сохранении Тело-Запроса под URI, равным URI-Запроса. Если URI-Запроса ссылается на уже существующий ресурс, Тело-Запроса должно рассматриваться как модифицированная версия данного ресурса. Если ресурс, на который ссылается URI-Запроса не существует, и данный URI может рассматриваться как описание для нового ресурса, сервер может создать ресурс с данным URI.

Пример

PUT /path/filename. html HTTP/1.1 - такой вызов означает, что удаленный клиент хотел бы сохранить файл под именем /path/filename. html в дереве каталогов веб-сервера.

Фундаментальное различие между методами POST и PUT заключается в различном значении поля URI-Запроса. Для метода POST данный URI указывает ресурс, который будет управлять информацией, содержащейся в теле запроса, как неким придатком. Ресурс может быть обрабатывающим данные процессом, шлюзом в какой-нибудь другой протокол, или отдельным ресурсом, допускающим аннотации. В противоположность этому, URI для запроса PUT идентифицирует информацию, содержащуюся в Содержание-Запроса. Использующий запрос PUT точно знает какой URI он собирается использовать, и получатель запроса не должен пытаться применить этот запрос к какому-нибудь другому ресурсу.