Разработка системы обнаружения атак веб-приложений на языке PHP

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

Выделенные преимущества и недостатки сетевых систем обнаружения атак приведены в таблице 1.2.

Таблица 1.2 - Преимущества и недостатки сетевых систем обнаружения атак

Преимущества	Недостатки
Контроль нескольких объектов одновременно	Могут влиять на производительность сети
Могут определять атаки, направленные на несколько объектов	Могут возникать проблемы с зашифрованными каналами
Не влияют на локальную производительность
Могут противостоять атакам, которые локально могу быть не видны

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

В общем виде выделяют два метода определения атак:

- статический;

- динамический.

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

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

- возможность анализировать произошедшие события только после их осуществления;

- анализ журналов может быть весьма трудозатратным из-за сложности информации, содержащейся в журналах или размера журнала;

- если злоумышленник получает доступ к системе, он может удалить все записи в журналах.

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

- невозможность анализировать данные, передаваемые методом POST;

- HTTP заголовки могут анализироваться лишь частично.

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

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

Различают следующие способы определения атак:

- сигнатурный способ;

- способ, основанный на выявлении аномалий в системе.

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

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

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

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

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

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

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

Существенным недостатком, который имеется у систем обнаружения атак, основанных на данном способе, является большое количество ложных срабатываний, а именно для случаев, когда мониторинг ресурсов не является стационарным и часто меняется, например, в случае веб-приложений. Если статистическая модели является слишком строгой и ограниченной, и система не может обобщать и учитывать изменения, то вполне вероятно, что такая система будет генерировать множество ложных срабатываний. Тем не менее, несколько продуктов, которые используют механизм обнаружение аномалий, уже существуют [25].

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

Таблица 1.3 - Преимущества и недостатки методов обнаружения атак

Способ обнаружения	Преимущества	Недостатки
Сигнатурный	Низкий уровень ложных срабатываний	Не может обнаруживать новые и неизвестные виды атак
	Нет необходимости в обучении системы (создание моделей, правил и т.д.)	Требует постоянного обновления баз сигнатур
	Оповещения тщательно типизированы и классифицированы
	Простота реализации
Основанный на аномалиях	Может обнаруживать новые и неизвестные виды атак	Высокое количество ложных срабатываний
	Система может самообучаться	Оповещения не типизированы и не классифицированы
		Сложность в реализации
		Требует время для обучения и создания модели

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

1.4 Анализ существующих СОА и предложение по разработке улучшенного решения

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

Из существующих систем одной из наиболее популярных систем обнаружения атак на веб-приложения является ModSecurity.

ModSecurity - система обнаружения атак с открытым исходным кодом для защиты веб-приложений. Данное ПО защищает от ряда атак, направленных на веб-приложения, позволяет осуществлять мониторинг HTTP трафика и проводить анализ событий в реальном режиме времени.

Существует два типовых варианта установки ModSecurity:

- установка модуля непосредственно на веб-сервер;

- установка в качестве обратного прокси-сервера (Reverse Proxy).

Коротко рассмотрим каждый вариант. В первом случае, который изображен на рисунке 1.4 ModSecurity перехватывает запросы к веб-серверу, на котором он установлен. HTTP запрос от клиента сначала обрабатывается ModSecurity. Модуль сравнивает запрос со своими правилами и, если запрос не блокируется, передает его на обработку веб-серверу. ModSecurity также может контролировать ответы веб-сервера, т.е. после формировании страницы ответ обрабатывается модулем и, в соответствии с правилами, блокирует или разрешает прохождение ответа.

Рисунок 1.4 - Пример установки СОА в качестве модуля для веб-сервера

В данном случае существует принципиальный недостаток, ModSecurity может быть установлен только на веб-сервер Apache. Данный факт существенно ограничивает его использование.

Установка Apache c модулем ModSecurity в качестве прокси позволяет перехватывать запросы клиентов к веб-серверам на любой платформе (IIS, Apache, WebSphere и т.д.). Пример представлен на рисунке 1.5. Принцип работы обратного прокси-сервера заключается в том, что сервер переадресует все запросы от клиентов к веб-серверу, и при получении ответа от веб-сервера перенаправляет его клиенту. Клиенты видят только внешний интерфейс прокси-сервера и не видят веб-серверов, расположенных за ним.

Рисунок 1.5 - Пример установки СОА в качестве обратного прокси-сервера

В данном варианте недостатками являются:

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

- введение единой точки отказа для одного или нескольких веб-серверов.

Другим продуктом является система обнаружения атак openWAF - это распределенная система для защиты веб-приложений, выполненная в виде модуля для веб-сервера Apache и являющаяся открытым вариантом коммерческого продукта Hyperguard. Кроме Apache openWAF поддерживает еще несколько веб-серверов, таких как: Microsoft IIS (5-7), J2EE сервера, как Apache Tomcat, поддержка веб-сервера Lighttpd на данный момент находится в стадии бета-тестирования. Система имеет клиент-серверную модель, в которой Apache-модуль выступает в роли фильтрующего клиента, перенаправляющего все запросы на специальный сервер принятия решений. Серверов принятия решений может быть несколько, при этом они имеют общую конфигурацию и управляются централизованно. Управление производится через веб-интерфейс.

СОА openWAF можно использовать в двух различных режимах:

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

- в режиме обнаружения, когда openWAF просто осуществляет мониторинг веб-приложения всех попыток нападения, но не вмешивается в происходящие действия (пассивный режим).

Основным недостатком также является поддержка только ограниченного количества веб-серверов.

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

В данной системе также имеется ряд недостатков:

- поддержка только веб-сервера Apache;

- поддержка только ОС Linux;

- может требовать дополнительного оборудования и ресурсов.

При анализе существующих коммерческих решений, которые в основном представлены аппаратными средствами такими как: Cisco ScanSafe Web Security, Barracuda Web Application Firewall, а также коммерческим программным обеспечением, например, от компании Citrix - NetScaler VPX выделяется главный недостаток - это довольно высокие цены, превышающие в несколько десятков раз стоимость разработки самого веб-приложения.

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

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

- поддержка ограниченного количества веб-серверов и ОС;

- необходимость приобретать дополнительное оборудование;

- усложнение сетевой инфраструктуры;

- коммерческие решения являются дорогостоящими;

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

1.5 Выводы

По итогам данной главы можно сделать следующие выводы:

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

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

3. Системы обнаружения атак являются дополнительным элементом при построении системы, которая обеспечивает безопасность сети или компьютерной системы, а также дополнительным рубежом перед злоумышленниками. Рассмотрена классификация СОА, а также проведен анализ методов и способов обнаружения атак на веб-приложения с выявлением достоинств и недостатков.

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

2 Проектирование СИСТЕМЫ ОБНАРУЖЕНИЯ АТАК

ВЕБ-ПРИЛОЖЕНИЙ НА ЯЗЫКЕ PHP

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

UML (англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML_моделей как интерпретируемого кода возможна кодогенерация.

2.1 Определение требований к разрабатываемой системе

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

Первым этапом проектирования является определение требований к разрабатываемой системе.

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

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

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

Модель требований, описываемую в UML, формируют два основных типа требований:

- функциональные требования - то, что система должна делать;

- нефункциональные требования - ограничение, накладываемое на систему.

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

- СОА должна быть кроссплатформенной;

- СОА должна поддерживать наибольшее число существующих веб-серверов;

- СОА должна быть простой в реализации и использовании;

- СОА должна обеспечивать достаточный уровень защиты;

- СОА должна обеспечить низкий уровень ложных срабатываний;

- СОА должна предоставить достаточно простую интеграцию с существующими системами (приложениями);

- СОА должна обеспечить полноценное рабочее состояние сразу после установки;

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

Нефункциональными требованиями являются:

- СОА должна быть разработана на языке PHP;

- СОА должна обеспечивать актуальность баз сигнатур.

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

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

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

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

- отношения - значимые отношения между актерами и прецедентами.

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

- администратор системы;

- пользователь.

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

- настройка параметров СОА;

- контроль состояния системы (мониторинг регистрируемых событий);

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

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

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

Выделяются следующие прецеденты, которые выполняет СОА при взаимодействии с пользователем:

- при вводе данных или параметров происходит формирование массива входящих данных;

- фильтрация входящих данных, используя поиск по сигнатурам;

- обнаружение совпадения с сигнатурой;

- преобразование данных в безопасный вид;

- регистрация события в СОА;

- отображение зарегистрированных событий в консоли управления;

- передача управления веб-приложению.

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



Рисунок 2.1 - Диаграмма прецедентов СОА

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

2.2 Проектирование архитектуры системы обнаружения атак

После завершения этапа определения требований к разрабатываемой системе следует этап проектирования архитектуры системы.

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

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

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

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

Обобщенная диаграмма деятельности системы обнаружения атак представлена на рисунке 2.2.

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



Рисунок 2.2 - Обобщенная диаграмма деятельности СОА

Общий алгоритм работы СОА на веб-приложения, представленный на рисунках 2.3-2.4, состоит из следующих этапов:

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

Этап 2. Формирования массива входных данных. Передача входных данных веб-приложению может осуществляться несколькими способами. Как было отмечено ранее, сетевое взаимодействие осуществляется посредством протокола HTTP, который имеет методы POST и GET. Им соответствуют глобальные массивы $_POST и $_GET языка PHP. Кроме того, для осуществления механизма Cookie существует массив $_COOKIE. На данном этапе происходит сбор входящих данных со всех глобальных массивов и формирование общего массива данных для удобства осуществления процесса обработки.

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



Рисунок 2.3 - Общий алгоритм работы СОА



Рисунок 2.4 - Общий алгоритм работы СОА (продолжение)

Этап 4. Обнаружено совпадение с сигнатурой. При обнаружении совпадения с сигнатурой происходит приведение значения совпавшего параметра, путем фильтрации, к безопасному виду. Это осуществляется с использование специальных PHP функций (strip_tags (string $str), mysql_real_escape_string (string $unescaped_string) и др.). Кроме этого информация об этом событии регистрируется в СОА для последующего анализа администратором системы.

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

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

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

1. Модуль логики СОА.

2. Модуль формирования отчета.

3. Модуль регистрации событий.

4. Модуль управления СОА.

Структурная схема взаимодействий модулей представлена на рисунке 2.5.

2.2.1 Модуль логики СОА

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

Регулярные выражения - это формальный язык поиска и осуществления манипуляций с подстроками в тексте, основанный на использовании метасимволов. Другими словами это строка-образец (шаблон), состоящая из символов и метасимволов и задающая правило поиска [29].

Рисунок 2.5 - Структурная схема СОА на веб-приложения

Потенциально опасные конструкции, описываемые с помощью языка регулярных выражений, являются сигнатурами. Механизм поиска совпадения основан на использовании специальной функции PHP - preg_match (string $pattern , string $subject, array $matches). Данная функция принимает три параметра, регулярное выражение (параметр $pattern), строку для поиска (параметр $subject) и массив, содержащий совпадения (параметр $matches).

Диаграмма деятельности модуля логики системы обнаружения атак изображена на рисунке 2.6.

Рисунок 2.6 - Диаграмма деятельности модуля логики СОА

2.2.2 Модуль формирования отчета

Модуль формирования отчета получает управление при возникновении совпадения сигнатуры с входными данными. При появлении совпадения создается специальный объект Event, который описывает возникшее событие. При создании объекта события в него передается информация о параметре, значении данного параметра и сигнатуре, с которой совпало значение параметра. Кроме того, в данном модуле существует некоторое хранилище (массив), в которое помещаются все события, возникающие при обработке модулем логики СОА входных данных. Таким образом, данный массив содержит отчет по всем возникшим событиям (совпадениям). Диаграмма деятельности данного модуля представлена на рисунке 2.7.

Рисунок 2.7 - Диаграмма деятельности модуля формирования отчета СОА

2.2.3 Модуль регистрации событий

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

Все современные веб-приложения используют базы данных для хранения информации. Для независимости от выбранной базы данных для веб-приложения работа модуля регистрации событий основана на использовании специального расширения - PDO.

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

Диаграмма деятельности данного модуля представлена на рисунке 2.8.

Рисунок 2.8 - Диаграмма деятельности модуля регистрации событий

В данном модуле происходит запись информации о каждом событии в таблицу с событиями. Эту таблицу использует модуль управления, для предоставления администратору системы информации о состоянии СОА.

2.2.4 Модуль управления СОА

Модуль управления системой обнаружения атак представляет собой консоль управления администратора, выполненную в виде веб-панели.

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

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

Диаграмма деятельности модуля управления системой обнаружения атак изображена на рисунке 2.9.

2.2.5 Анализ взаимодействия объектов СОА

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



Рисунок 2.9 - Диаграмма деятельности модуля управления СОА

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

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

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

Рисунок 2.10 - Диаграмма последовательности объектов СОА

В UML диаграмма последовательности имеет два измерения. Первое слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Крайним слева на диаграмме изображен объект, который является инициатором взаимодействия. Правее располагается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый очередностью или степенью активности объектов при взаимодействии друг с другом [30].

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

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

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

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

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

2.3 Выводы

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

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

2. Для описания архитектуры разрабатываемой системы, были изображены диаграмма деятельности и общий алгоритм работы СОА. Разрабатываемая СОА состоит из нескольких модулей, описание и диаграммы деятельности которых, также были приведены.

3. На заключительном этапе проектирования была разработана диаграмма последовательности объектов СОА, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Кроме того, был сделан вывод, что предлагаемая архитектура СОА соответствует предъявляемым требованиям и следующим этапом является реализация данной системы.

3 программная Реализация системы обнаружения атак

3.1 Спецификация

Таблица 3.1 -Документация

Обозначение	Наименование	Примечание
ОС	Общие сведения
ОП	Описание применения
РО	Руководство оператора
РСП	Руководство системного программиста
РП	Руководство программиста

Таблица 3.2 -Компоненты

Обозначение	Наименование	Примечание
МЛ	Модуль логики	Осуществляет анализ и фильтрацию входящих данных
МФО	Модуль формирования отчета	Производит процесс создания объекта зарегистрированного СОА события об атаке
МРС	Модуль регистрации событий	Получает сформированный отчет о событиях и загрузку данных о всех событиях в базу данных
МУ	Модуль управления	Предназначен для администрирования СОА

3.2 Описание программы

1. Общие сведения. Наименование разработанной системы обнаружение атак веб-приложений: WebIDS.

Системные требования системы обнаружения атак представлены в таблице 3.3. Указанные системные требования не включают требования, предъявляемые для работы веб-приложения.

Таблица 3.3 - Системные требования СОА

Рекомендуемые системные требования
Процессор	2,2 ГГц
Оперативная память	2 Гб
Объем свободного места ЖД	5 Мб
Операционная система	кроссплатформеноe
Интерпретатор PHP	5.3.x
СУБД	MySQL 5.5.x

Данная система обнаружения атак веб-приложений разработана на языке PHP.

2. Функциональное назначение. Разработанная система обнаружения атак предназначена для защиты веб-приложения от проведения реальных атак.

3. Вызов и загрузка. Данная система обнаружения атак является встраиваемой, и ее работа осуществляется параллельно с работой веб-приложения. Входными точками является методы GET и POST протокола HTTP, а также HTTP Cookie.

4. Входные и выходные данные. Входные данные поступаем на обработку системой обнаружения атак посредством методов GET и POST протокола HTTP, а также HTTP Cookie в соответствующие глобальные массивы языка PHP. В начале работы СОА осуществляет формирование общего массива, которые содержит данные со всех глобальных массив. После окончания анализа входных данных СОА передает управление веб-приложению для обработки его логикой.

3.3 Описание применения

1. Назначение программы. Разработанная система обнаружения атак предназначена для защиты веб-приложения от проведения реальных атак. СОА обеспечивает фильтрацию входных данных и приводит их в безопасный вид для обработки веб-приложением. Данная система осуществляет контроль входящих данных передаваемых веб-приложению и производит мониторинг только событий происходящих с веб-приложением.

2. Условия применения. Для работы разработанной системы обнаружения атак необходимо наличие веб-сервера, интерпретатора PHP (5.3.x), СУБД.

3.4 Руководство оператора

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

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

1.2. Модуль формирования отчета - данный модуль производит процесс создания объекта зарегистрированного СОА события о потенциальной попытке совершить атаку. Сформированный объект события помещается в массив, который формирует общий отчет, который затем передается в Модуль регистрации событий.

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

1.4. Модуль управления СОА - это консоль управления представляющая собой панель с веб-интерфейсом. Данный модуль предназначен для администраторов и позволяет производить мониторинг зарегистрированных событий, настройку СОА, добавление новых сигнатур.

2. Выполнение программы. Для получения доступа в Модуль управления СОА необходимо перейти по адресу «название веб-сайта/путь/до/СОА/panel.php». При этом будет предложено пройти процесс авторизации. Окно входа в панель представлено на рисунке 3.1.

Рисунок 3.1 - Окно входа в Модуль управления СОА

При создании таблицы пользователей, в процессе подготовки к работе СОА, был установлен пользователь по умолчанию с идентификационные данными: имя пользователя: administrator, пароль: administrator. Требуется сразу изменить пароль данного пользователя на пароль повышенной сложности, включающий алфавитно-цифровые символы, специальные символы и имеющий длину не менее 8 символов.

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



Рисунок 3.2 - Отображение зарегистрированных СОА событий

В представленной таблице отображается следующая информация:

- параметр веб-приложения, которому передавались потенциально вредоносные данные;

- значение, которое передавало параметру, т.е. вредоносные конструкции, которые отправлял злоумышленник;

- IP-адрес, с которого были произведены попытки произвести атаку на веб-приложение;

- дата зарегистрированного события, содержащая число и время.

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



Рисунок 3.3 - Форма добавления новой сигнатуры в СОА

При добавление новой сигнатуры необходимо указать:

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

- краткое описание данной сигнатуры;

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

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

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

3.5 Руководство программиста

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

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

1.1. необходимо отредактировать конфигурационные данные в файле конфигурации config.ini. Данный файл располагается в «путь/до/ /СОА/IDS/Config». В данном файле необходимо указать такие параметры как: полный путь до СОА, путь до файлы сигнатур signatures.xml, кроме того необходимо указать параметры подключения к базе данных.

1.2. необходимо создать таблицы в существующей базе данных установленного веб-приложения либо создать отдельную базу в соответствии с указанными параметрами в файле конфигурации, а также загрузить файл tables.sql, который находится в «путь/до/ СОА/IDS/Config», который создать необходимые таблицы (intrusions,users).

1.3. в корне каталога СОА имеется файл webids.php, который необходимо перенести в корен каталога веб-приложения при этом его необходимо отредактировать, указав полный путь до каталога СОА.

1.4. необходимо отредактировать файл .htaccess, который располагается в корне дистрибутива СОА. В нем необходимо указать полный путь до файла webids.php. Данный файл содержит параметр auto_prepend_file, который указывает php интерпретатору путь до файла, который будет обрабатываться раньше всех остальных, это необходимо чтобы СОА обрабатывала входящие данные раньше веб-приложения, тем самым, обеспечивая безопасность данных.

1.5. на каталог /tmp, который расположен в каталоге СОА необходимо установить права 775.

Если все настройки указаны верно, то система обнаружения атак готова к работе. Доступ к консоли управления можно получить по следующему адресу «название веб-сайта/путь/до/СОА/panel.php».

2. Приложение к руководству. Диаграмма классов разработанной системы обнаружения атак представлена на рисунке 3.4.



Рисунок 3.4 - Диаграмма классов СОА

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

Снимок экрана документации изображен на рисунке 3.5.

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



Рисунок 3.5 - Отображение документации созданной с помощью phpDocumentor

3.6 Выводы

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

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

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

4 БЕЗОПАСНОСТЬ И ЭКОЛОГИЧНОСТЬ ПРОЕКТА

4.1 Анализ вредных и опасных производственных факторов, действующих на оператора ЭВМ

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

Рассмотрим опасные и вредные факторы, возникающие при эксплуатации разработанной системы. Поскольку она является программным обеспечением, которое работает и с использованием персональной ЭВМ (ПЭВМ), то анализ необходимо проводить применительно к рабочему месту оператора ПЭВМ. Работа оператора ПЭВМ относится к категории работ, связанных с опасными и вредными условиями труда. В процессе труда на оператора ПЭВМ оказывают действие следующие опасные и вредные производственные факторы, в соответствии с [7]:

1) физические:

- пониженное содержание отрицательных аэроионов в воздухе рабочей зоны (ро- < 550);

- пониженная влажность воздуха рабочей зоны (менее 40 %);

- пониженная подвижность воздуха рабочей зоны (менее 0,1 м/с);

- повышенный уровень статического электричества (более 80 кВ/м);

- повышенный уровень температуры (выше 25 C).

2) психофизиологические:

- напряжение зрения;

- напряжение внимания;

- интеллектуальные нагрузки;

- эмоциональные нагрузки;

- длительные статические нагрузки;

- монотонность труда;

- большой объем информации обрабатываемой в единицу времени;

- нерациональная организация рабочего места.

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

- содержание отрицательных аэроионов в воздухе рабочей зоны 600 < ро- <= 50000;

- влажность воздуха рабочей зоны 40-60 %;

- подвижность воздуха рабочей зоны 0,1 м/с;

- уровень статического электричества 60 кВ/м;

- уровень температуры 23 -25 C.

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

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

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

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

Как правило, для помещений с персональными ЭВМ используются бытовые кондиционеры (БК), установленные в окнах и подающие обработанный наружный воздух непосредственно в помещение. Пример представлен на рисунке 4.1. Встроенные системы управления кондиционерами обеспечивают их работу в режимах, определяемых температурой и влажностью воздуха в помещении.

Рисунок 4.1 - Воздухообмен в помещении с персональной ЭВМ