Обеспечение безопасности технологий создания активного содержимого

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

Активное содержание на стороне клиента относится к интерактивным элементам, обрабатываемым web-браузером. Активное содержание может представлять серьезную угрозу для конечного пользователя. Например, оно может выполняться на машине клиента без явного разрешения пользователя. Существуют различные технологии создания активного содержимого. Некоторые наиболее популярные примеры включают ActiveX, Java, VBScript и JavaScript. Организации, рассматривающие разработку активного содержимого на стороне клиента, должны тщательно изучить риски для своих пользователей, так как использование активного содержания часто требует от пользователя понижения установок безопасности в своем web-браузере.

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

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

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

Опубликование информации на web-сайтах

Политика опубликования в web должна содержать следующие элементы:

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

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

Публичный web-сайт обычно не содержит следующую информацию:

классифицированные записи;внутренние правила и процедуры для персонала;чувствительную или частную информацию;

персональную информацию о служащих организации:

домашние адреса и номера телефонов;номера различных социальных карточек;детальный биографический материал;фамилии руководства.

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

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

Для гарантирования согласованного подхода организация должна создать формальную политику и описать процесс определения того, какая информация публикуется на web-сервере. Во многих организациях за это отвечает офицер информационной службы (Chief Information Officer — CIO). Такой процесс должен включать следующие шаги.

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

Областью web-содержимого, про которую часто забывают, является информация, находящаяся в исходном коде HTML-страницы. Она может быть просмотрена из web-браузера использованием опции меню view source code. Разработчики часто не придают значения содержимому исходного кода их HTML страниц, даже если этот код содержит чувствительную информацию. Он может, например, содержать указатели на контактную информацию и показывать части структуры директории web-сервера. Атакующие могут проанализировать не только очевидное содержимое web-сайта, но также и исходный код; следовательно, web-администраторы должны проверять создаваемые HTML страницы своего web-сервера.

Список действий для обеспечения безопасности web-содержимого

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

Классифицированные записи.Внутренние правила и процедуры персонала.Чувствительная или частная информация.Персональная информация о сотрудниках.Номера телефонов, e-mail адреса или списки руководства.Расписание сотрудников и их местоположение.Чувствительная информация, относящаяся к домашней безопасности.Инвестиционные записи.Финансовые записи.Процедуры обеспечения физической и информационной безопасности.Информация о сети организации и информационной инфраструктуре.Информация о физических уязвимостях безопасности.Планы, карты, диаграммы строений.Материалы с грифом копирайта без письменного разрешения собственника.Политика безопасности, перечисляющая типы мер безопасности в той степени, в которой это может быть полезно атакующему.

Установить документированную формальную политику и процесс принятия решения об опубликовании web-содержимого.

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

Обсудить возможность использования частной информации пользователей.

Опубликовать политику, касающуюся использования частной информации.Запретить сбор персональных идентификационных данных без явного разрешения пользователя.Запретить использование persistent cookies.Использовать сессионные cookies, явно указав это в политике, касающейся частной информации.

Обсуждение безопасности активного содержимого на стороне клиента.

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

Обсуждение безопасности активного содержимого на стороне сервера.

Упростить код для обеспечения его легкого понимания.Ограничить доступ к файлам либо по чтению, либо по записи.

Ограничить или исключить взаимодействие с другими программами (например, такими, как sendmail).

Не требовать выполнения с привилегиями suid.

Использовать полные имена путей (т.е. не полагаться на переменную path). Не иметь директорий с одновременно установленными привилегиями по записи и выполнению.Разместить все выполняемые файлы в отдельных директориях.

Запретить SSI или запретить функцию выполнения в них. Проверять корректности всего ввода пользователя.Динамически созданные страницы не должны содержать опасных метасимволов.Кодировка набора символов должна быть явно указана на каждой странице.Просканировать пользовательские данные относительно наличия последовательностей байтов, означающих специальные символы для данной схемы кодирования.Проверить cookies относительно наличия любых специальных символов.Использовать механизм шифрования трафика для паролей, введенных через формы.Для web-приложений, которые имеют ограничения, связанные с именами пользователей и паролями, проследить, чтобы ни одна web-страница не была доступна без прохождения соответствующего процесса аутентификации.Удалить все примеры скриптов.Не использовать никаких скриптов или выполняемого кода третьих фирм без проверки исходного кода.

Уязвимости технологий активного содержимого на стороне клиента

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

Java – полнофункциональный, объектно-ориентированный язык программирования, который компилируется в платформонезависимый байт-код, выполняемый интерпретатором, называемым Java Virtual Machine (JVM). Результирующий байт-код может быть выполнен в том месте, где он был скомпилирован, или передан на другую поддерживающую Java платформу (например, передан с помощью HTML-страницы как апплет). Java используется для добавления функциональности в web-сайтах. Многие сервисы, предлагаемые популярными web-сайтами, требуют от пользователя иметь поддерживающий Java браузер. Когда web-браузер видит ссылки на Java-код, он загружает код и затем выполняет его, используя встроенную JVM.

Разработчики Java в большинстве случаев успешно решают проблемы безопасности. Язык программирования Java и окружение времени выполнения обеспечивают безопасность первоначально с помощью строгой типизации, при которой программа может выполнять определенные операции только для определенных типов объектов. Java придерживается так называемой модели безопасности sandbox, использующей изолирование памяти и методов доступа, а также поддержку нескольких независимых доменов выполнений.
Код Java, такой, как web-апплет, заключается в sandbox, который разработан для предотвращения выполнения неавторизованных операций, например, просмотр или изменение файлов в файловой системе клиента и использование сетевых соединений в обход защиты файлов.

Тем не менее, апплеты хоста представляют угрозы для безопасности, даже если выполняются внутри sandbox. Апплеты хоста могут использовать различными способами не предназначенные для этого системные ресурсы или могут заставить пользователя выполнить различные нежелательные действия. Примеры нежелательных действий апплетов на хосте включают DoS-атаки, подделку e-mail адресов, вторжение в частную жизнь (например, экспорт идентификации e-mail адреса и информации о платформе) и инсталлирование люков (backdoors) в систему. Так как модель безопасности Java является более сложной, пользователю может быть трудно понять ее и управлять ею. Такая ситуация может увеличить риск.

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

Теоретически ограничение языка скрипта границами web-браузера должно обеспечивать относительно безопасное окружение. На практике это выполняется не во всех случаях. Многие основанные на браузерах атаки используют скриптовый язык в сочетании с конкретной уязвимостью безопасности. Основной источник проблем двойной: существование изъянов в реализации в выполняемом окружении и скрытое связывание браузера с соответствующей функциональностью, такой, как клиент e-mail.


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

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

Рассмотрим риск ActiveX в сравнении с другими популярными технологиями активного содержимого на стороне клиента.

Сравнение риска различных технологий на стороне клиентаТехнология на стороне клиентаСтепень риска

JavaScript и VBScript	Низкая
Java-апплеты	Средняя
Управление ActiveX	Высокая

Подобные внедрения включают посылку списка истории URL на удаленный сайт и использование e-mail адреса пользователя для подделки почты. Возрастающее использование HTML и других языков разметки в качестве содержимого электронной почты и в сервисах push-технологий может открыть новые бреши для внедрения ошибок с использованием встроенных скриптов.

Visual Basic Script (VBScript) – язык программирования, разработанный Microsoft для создания скриптов, которые могут быть встроены в web-страницы, просматриваемые с помощью браузера IE. Netscape Navigator, однако, не поддерживает VBScript. Подобно JavaScript, VBScript является интерпретируемым языком, который дает возможность обрабатывать скрипты на стороне клиента. VBScript, который является подмножеством широко используемого Microsoft языка программирования Visual Basic, работает под управлением Microsoft ActiveX. Язык подобен JavaScript и имеет аналогичные риски.

ActiveX – это множество технологий от Microsoft, которые предоставляют инструментальные средства для связывания desktop-приложений с web. Управления ActiveX являются переиспользуемыми программными компонентными объектами, которые могут быть присоединены к e-mail или быть загруженными с web-сайта. Управления ActiveX также могут быть заранее инсталлированы на Windows-платформе. Web-страницы включают управления ActiveX, используя скриптовый язык или с помощью HTML-тега OBJECT.

Модель безопасности ActiveX значительно отличается от модели sandbox Java. Модель Java ограничивает апплет множеством безопасных действий. В противоположность этому, ActiveX не имеет ограничений на то, что он может делать. Вместо этого управляющие элементы ActiveX имеют цифровую подпись своего автора в соответствии с технологией, называемой Authenticcode. Цифровые подписи проверяются, используя сертификаты, выпущенные доверенными сертификационными центрами. Сертификационный центр должен гарантировать, что никакого опасного кода не будет сознательно распространено. Технология Authenticcode гарантирует, что управления ActiveX не могут быть распространены анонимно и что модификация управления может быть определена.

Уязвимости технологий создания содержимого на стороне сервера

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

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

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

Генераторы содержимого на стороне сервера могут создать уязвимости на сервере следующим образом:

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

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

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

Уязвимость может потенциально воздействовать на весь web-сервер. Хотя чаще всего подобное происходит в CGI-приложениях, другие интерфейсы и технологии разработки серверных приложений также имеют изъяны. CGI, как наиболее ранний и часто используемый стандарт, приобрел большее значение за последние годы, но то же множество уязвимостей существует при использовании аналогичных технологий web-разработки на стороне сервера.

Common Gateway Interface (CGI) – CGI-скрипты определяют механизм, используемый для взаимодействия web-сайтов с базами данных и другими приложениями на стороне сервера. Существуют различные методы обработки информации на стороне сервера, такие, как Microsoft ASP для IIS-сервера, Java-сервлеты и РНР, поддерживаемые большинством web-платформ, включая Apache и IIS. Перечислим основные требования, которым должна удовлетворять лежащая в основе ОС:

файловая система хоста должна обеспечивать безопасность для CGI-программ;web-сервер должен обеспечивать ограничения доступа к CGI-программам с точностью до директории;возможности безопасного программирования на Perl больше, чем у других языков (например, С, С++, shell).

Server Side Includes (SSI) – ограниченный скриптовый язык на стороне сервера, поддерживаемый большинством web-серверов. SSI предоставляет множество динамических возможностей, например, включение текущего момента времени или даты последней модификации HTML файла, и является альтернативой использованию CGI-программ для выполнения определенных функций. Когда браузер запрашивает документ со специальным типом файла, таким, как .shtml, это говорит о том, что сервер должен обработать его перед тем, как послать клиенту (web-браузеру). Команды SSI встроены в HTML комментарии (к примеру, <!--#include file="standard.html"-->). Сервер читает файл и ищет HTML комментарии, содержащие встроенные команды SSI.


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

Тем не менее, существуют определенные гарантии от переполнения буфера.

Java Servlets – сервлеты, основанные на технологии Java и являющиеся Java-программами на стороне сервера. Web-сервер первым делом определяет, требует ли запрос пользователя динамически создаваемую сервлетом информацию. Если так, web-сервер может создать экземпляр объекта сервлета, соответствующий запросу, и вызвать его для получения необходимых результатов. Web-сервер обычно сам управляет жизненным циклом своих сервлетов. Следуя возможности портирования Java и обеспечивая общий прикладной программный интерфейс, объекты сервлета могут выполняться в любом окружении сервера. Сервлеты используют объектно-ориентированное окружение на web-сервере, которое является гибким и расширяемым. Более того, недоверяемые объекты сервлета могут выполняться в безопасной области, динамически создавая информацию, которая будет передаваться из безопасной области в оставшееся окружение сервера.

Основные особенности, которые следует учитывать при использовании Java сервлетов:



хорошая интеграция с возможностями обеспечения безопасности ОС и аутентификацией web-сервера для обеспечения строгой безопасности;

возможности безопасного программирования:



возможности безопасности языка Java;

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



PHP (Hypertext Preprocessor) – скриптовый язык, используемый для создания динамических web-страниц. Синтаксис РНР аналогичен С, Java и Perl, при этом код РНР встроен в HTML страницы для выполнения на стороне сервера.


Например, в большинстве форм возможны только такие категории данных, как буквы a-z, A-Z и цифры 0-9. Имена устройств, например, AUX, COM, LPT, NUL и PRN должны также отфильтровываться из входных данных;

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

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

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

cookies должны быть проанализированы относительно наличия любых специальных символов. Любые специальные символы должны быть отфильтрованы; следует использовать шифрование для паролей, вводимых с помощью форм;

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

При рассмотрении генератора содержимого на стороне сервера важно просмотреть различные базы данных уязвимостей (такие как ICAT метабаза, http://icat.nist.gov) для определения возможного риска использования различных технологий.


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

Уязвимость может потенциально воздействовать на весь web-сервер. Хотя чаще всего подобное происходит в CGI-приложениях, другие интерфейсы и технологии разработки серверных приложений также имеют изъяны. CGI, как наиболее ранний и часто используемый стандарт, приобрел большее значение за последние годы, но то же множество уязвимостей существует при использовании аналогичных технологий web-разработки на стороне сервера.

Common Gateway Interface (CGI) – CGI-скрипты определяют механизм, используемый для взаимодействия web-сайтов с базами данных и другими приложениями на стороне сервера. Существуют различные методы обработки информации на стороне сервера, такие, как Microsoft ASP для IIS-сервера, Java-сервлеты и РНР, поддерживаемые большинством web-платформ, включая Apache и IIS. Перечислим основные требования, которым должна удовлетворять лежащая в основе ОС:

файловая система хоста должна обеспечивать безопасность для CGI-программ;web-сервер должен обеспечивать ограничения доступа к CGI-программам с точностью до директории;возможности безопасного программирования на Perl больше, чем у других языков (например, С, С++, shell).

Server Side Includes (SSI) – ограниченный скриптовый язык на стороне сервера, поддерживаемый большинством web-серверов. SSI предоставляет множество динамических возможностей, например, включение текущего момента времени или даты последней модификации HTML файла, и является альтернативой использованию CGI-программ для выполнения определенных функций. Когда браузер запрашивает документ со специальным типом файла, таким, как .shtml, это говорит о том, что сервер должен обработать его перед тем, как послать клиенту (web-браузеру). Команды SSI встроены в HTML комментарии (к примеру, <!--#include file="standard.html"-->). Сервер читает файл и ищет HTML комментарии, содержащие встроенные команды SSI.


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

Тем не менее, существуют определенные гарантии от переполнения буфера.

Java Servlets – сервлеты, основанные на технологии Java и являющиеся Java-программами на стороне сервера. Web-сервер первым делом определяет, требует ли запрос пользователя динамически создаваемую сервлетом информацию. Если так, web-сервер может создать экземпляр объекта сервлета, соответствующий запросу, и вызвать его для получения необходимых результатов. Web-сервер обычно сам управляет жизненным циклом своих сервлетов. Следуя возможности портирования Java и обеспечивая общий прикладной программный интерфейс, объекты сервлета могут выполняться в любом окружении сервера. Сервлеты используют объектно-ориентированное окружение на web-сервере, которое является гибким и расширяемым. Более того, недоверяемые объекты сервлета могут выполняться в безопасной области, динамически создавая информацию, которая будет передаваться из безопасной области в оставшееся окружение сервера.

Основные особенности, которые следует учитывать при использовании Java сервлетов:



хорошая интеграция с возможностями обеспечения безопасности ОС и аутентификацией web-сервера для обеспечения строгой безопасности;

возможности безопасного программирования:



возможности безопасности языка Java;

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



PHP (Hypertext Preprocessor) – скриптовый язык, используемый для создания динамических web-страниц. Синтаксис РНР аналогичен С, Java и Perl, при этом код РНР встроен в HTML страницы для выполнения на стороне сервера.


Например, в большинстве форм возможны только такие категории данных, как буквы a-z, A-Z и цифры 0-9. Имена устройств, например, AUX, COM, LPT, NUL и PRN должны также отфильтровываться из входных данных;

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

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

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

cookies должны быть проанализированы относительно наличия любых специальных символов. Любые специальные символы должны быть отфильтрованы; следует использовать шифрование для паролей, вводимых с помощью форм;

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

При рассмотрении генератора содержимого на стороне сервера важно просмотреть различные базы данных уязвимостей (такие как ICAT метабаза, http://icat.nist.gov) для определения возможного риска использования различных технологий.

URLs и cookies

URLs являются технологией адресации в Интернете. Существует несколько проблем безопасности, связанных с URLs. Так как URLs посылаются в открытом виде, любые данные, которые хранятся внутри них, могут быть легко скомпрометированы. Например, URLs записываются во многие места, включая логи web-браузера (например, история браузера), логи прокси-сервера и логи НТТР referrer. Тем самым хранить чувствительные данные, такие, как имена пользователей и пароли или указатели на ресурсы сервера, в URL не следует. Безопасность через неясность не является хорошей практикой.

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

e-mail адреса;картинки, используемые в качестве ссылок на другие серверы;непосредственные ссылки на другие серверы;конкретные текстовые выражения (например, userid, password, root, administrator), спрятанные в виде значения формы.

Cookie – есть небольшой блок информации, которая может быть записана на жесткий диск пользователя, когда он посещает web-сайт. Цель cookies состоит в том, чтобы позволить серверу распознать конкретный браузер и, в конечном счете, пользователя при повторном посещении данного сервера. В сущности, они добавляют состояние в НТТР-протоколе, в котором состояние отсутствует. К сожалению, cookies обычно посылаются в явном виде и хранятся в явном виде на хосте пользователя, тем самым, они уязвимы для компрометации. Существуют уязвимости, например, в некоторых версиях IE, которые позволяют нарушителю удаленно собрать все cookies без оповещения об этом самого пользователя. Следовательно, cookies никогда не должны содержать данные, которые могут быть использованы непосредственно атакующим (например, аутентификационная информация, такая, как имя пользователя, пароль).

Существует два типа cookies.

Cookies, которые являются причиной большинства проблем, называются постоянные (persistent) cookies. Эти cookies могут использоваться для отслеживания деятельности пользователя в течение всего времени и на различных web-сайтах. Наиболее общее использование постоянных cookies состоит в сохранении соответствия информации о пользователях между сессиями. Часто запрещается использование постоянных cookies на публично доступных web-сайтах.

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

Атаки Cross Site Scripting

Атаки Cross Site Scripting (XSS) возникают тогда, когда атакующий вставляет HTML и/или JavaScript код в web-страницы и затем данный код выполняется на компьютерах других пользователей. Обычно это достигается добавлением HTML в те места, где он не должен быть. Результатом успешной XSS-атаки может стать получение атакующим cookie сессии и затем получение полного доступа к приложению от имени другого пользователя.

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

SecFilter "<script" SecFilter "<.+>"

Первый фильтр защищает только от вставления JavaScript c тегом <script>. Второй фильтр – более общий и запрещает любой HTML-код в параметрах.

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

<Location /xxx.php> SecFilterInheritance Off SecFilterSelective :ARGS | !ARG_body" "<.+>" </Location>

Данный фрагмент кода будет разрешать HTML только в теле указанного параметра.

Атаки переполнения буфера

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

SecFilterByteRange 32 126

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

Атаки SQL / база данных

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

Фильтры должны быть примерно следующими:

SecFilter "delete[[:space:]]+from" SecFilter "insert [[:space:]]+into" SecFilter "select.+from"

Эти фильтры могут защитить от большинства атак, относящихся к SQL.

Аутентификация, основанная на IP-адресе

Простейшим механизмом аутентификации, который поддерживается большинством web-серверов, является аутентификация по IP-адресу. Управление доступом основано на IP-адресе и/или имени хоста. Хотя это легко реализовать для небольших групп пользователей, аутентификация на основе адреса может быть громоздкой для web-сайтов, которые имеют большое число потенциальных пользователей (т.е. большинство публичных web-серверов). Такая аутентификация чувствительна к некоторым типам атак, включая подделку IP-адреса (IP-spoofing) и атаки на DNS. Данный тип аутентификации должен применяться только тогда, когда требуется минимальная безопасность, в противном случае она должна использоваться совместно с более сильными методами аутентификации.

Basic-аутентификация

Технология Basic-аутентификации использует определенную структуру директорий содержимого web-сервера. Все файлы в некоторой директории должны иметь одни и те же привилегии доступа. Пользователь, выполняющий запрос, предоставляет свою идентификацию и пароль для доступа к файлам в данной директории. Каждый производитель ПО web-сервера определяет свой собственный синтаксис для использования механизма Basic-аутентификации.

С точки зрения безопасности, основной недостаток данной технологии состоит в том, что пароль передается в явном виде без шифрования. Любой, кто имеет доступ к сетевому трафику, может извлечь пароль при сетевом просматривании. Более того, все web-содержимое передается в незашифрованном виде и, тем самым, также может быть перехвачено, что нарушает конфиденциальность. Этот недостаток может быть ликвидирован с использованием Basic-аутентификации совместно с SSL/TLS. Basic-аутентификация поддерживается стандартными web-браузерами. Она используется также для защиты информации от вредоносных bots.

Cookies

ModSecurity обеспечивает полную поддержку cookies. По умолчанию cookies обрабатываются как формат версии 0. Однако версия 1 cookies (как определено в RFC 2965) также поддерживается. Для того чтобы включить поддержку cookie версии 1, надо использовать следующую директиву:

SecFilterCookieFormat 1

По умолчанию ModSecurity не пытается нормализовать имена и значения cookies. Однако, так как некоторые приложения и платформы (например, РНР) выполняют декодирование содержимого cookie, можно выбрать применение нормализации к cookies. Это делается следующим образом:

SecFilterNormalizeCookies On

Действия (Actions)

Существует несколько типов действий.

Первичное действие принимает решение, продолжать обработку запроса или нет. Может существовать только одно первичное действие. Если указано в параметре несколько первичных действий, будет выполняться последнее действие. Первичными действиями являются deny, pass и redirect.

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

Действия потока (flow) могут изменить последовательность правил, заставляя переходить на другое правило или пропуская одно или несколько правил. Действиями потока являются chain и skip.

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

Действия для правила

Можно также указать действия для каждого фильтра. В обеих директивах фильтрования (SecFilter и SecFilterSelective) может быть указано множество действий в качестве дополнительного параметра. Действия, указанные для правила, объединяются с действиями, указанными в директиве SecFilterSignatureAction (значением по умолчанию является log, deny, status:403). Объединение происходит по следующим правилам:

Разрешается только одно первичное действие для каждого списка правил. Первичное действие для правила перекрывает первичное действие в списке по умолчанию;

Действия, указанные в конфигурации для правила, перекрывают эквивалентные действия в списке действий по умолчанию;

Когда задан ограниченный режим (см SecFilterActionsRestricted), только действия над метаданными могут появиться в списке действий для каждого правила;

Правила могут объединяться во время конфигурирования (предпочтительней и понятней) или во время выполнения.

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

SecFilterDefaultAction log, deny, status:500 SecFilter 000

# Warning rules SecFilterSignatureAction log, pass SecFilter 111 id:1 SecFilter 222 id:2

# Error rules SecFilterSignatureAction log, pass, status:403 SecFilter 333 id:3 SecFilter 444 id:4

При использовании совместно с директивой SecFilterActionsRestricted данная директива позволяет с легкостью включать в конфигурацию набор правил стороннего разработчика.

Замечание. Значение директивы SecFilterSignatureAction не наследуется в дочерних контекстах.

Digest-аутентификация

Так как в Basic-аутентификации существуют определенные недостатки, в версии 1.1 протокола НТТР была введена Digest-аутентификация. Она использует для "опознания" пользователя механизм запроса / ответа (challenge / response), когда пользователю посылается nonce (случайное значение), который предназначен для использования вместе с ID и паролем. В данном случае информация, вводимая пользователем, соединяется вместе с переданным nonce и запрошенным URL, и вычисляется криптографический хэш, который затем посылается в качестве ответа.

Так как пароль пользователя не посылается в явном виде, он не может быть подсмотрен в сети. Nonce может быть сконструирован из информации о текущей дате и времени, поэтому replay-атаки также невозможны. Следовательно, Digest-аутентификация является более безопасной, чем Basic-аутентификация. К сожалению, все данные посылаются в явном виде (не шифруются), что является уязвимым для перехвата и изменения. Это ограничение можно обойти, используя Digest-аутентификацию вместе с SSL/TLS. Подобно Basic-аутентификации, Digest-аутентификация используется для защиты информации от вредоносных bots.

Динамическое управление ModSecurity

Возможно разрешать или запрещать функционирование ModSecurity для конкретного запроса. Это выполняется с помощью переменной окружения MODSEC_ENABLE совместно с директивами SetEnvIf и SetEnvIfNoCase. Если MODSEC_ENABLE не установлена, то считается, что будет использоваться SecFilterEngine. Если MODSEC_ENABLE установлена, то значение SecFilterEngine игнорируется. Значения MODSEC_ENABLE являются теми же самыми, что и для директивы SecFilterEngine: On, Off или DynamicOnly.

Reject requests with status 403

SecFilterEngine On # Reject requests with status 403 SecFilterDefaultAction "deny, log, status:403" # Some defaults SecFilterScanPOST On SecFilterCheckURLEncoding On SecFilterCheckUnicodeEncoding Off # Accept almost all byte values SecFilterForceByteRange 1 255 SecUploadDir /tmp SecUploadKeepFiles Off # Only accept request encoding we know how to handle # we exclude GET requests from this because some (automated) # client supply # "text/html" as Content-Type SecFilterSelective REQUEST_METHOD "!^(GET | HEAD) $" chain SecFilterSelective HTTP_Content-Type \ "!(^applicatin/x-www-form-urlencoded$ | ^multipart/form-data;)" # Do not accept GET or HEAD requests with bodies SecFilterSelective REQUEST_METHOD "^(GET | HEAD)$" chain SecFilterSelective HTTP_Content-Length "!^$" # Require Content-Length to be provided with every POST request SecFilterSelective REQUEST_METHOD "^POST$" chain SecFilterSelective HTTP_Content-Length "^$" # Don’t accept transfer encodings we know we don’t handle SecFilterSelective HTTP_Transfer-Encoding "!^$"

Пример 11.1.

Закрыть окно

Хранение загруженных файлов

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

SecUploadKeepFiles On

Каталог, в котором хранятся файлы, определяется с помощью директивы SecUploadDir.

Исходящая фильтрация

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

SecFilterScanOutput On

После этого следует просто добавлять фильтры, используя специальную переменную OUTPUT:

SecFilterSelective OUTPUT "credit card numbers"

В следующем примере перехватывается исходящее сообщение об ошибке РНР в теле ответа и заменяется ответ с ошибкой.

SecFilterSelective OUTPUT "Fatal error:" deny,status:500 ErrorDocument 500 /php-fatal-error.html

Следует заметить, что хотя и можно перемешивать выходные и входные фильтры, они не выполняются одновременно. Входные фильтры выполняются перед тем, как запрос будет обработан Apache, в то время как выходные — после того, как Apache завершит обработку запроса.

Действия skipnext и chain не работают с выходными фильтрами.

Выходная фильтрация используется только для выхода в виде plain-текста и HTML. Применение регулярных выражений к бинарным данным (например, к изображениям) сильно загрузит сервер. По умолчанию ModSecurity сканирует выходные данные в ответах, в которых не указан Content Type или Content Type есть text/plan или text/html. Это можно изменить, используя директиву SecFilterOutputMimeTypes:

SecFilterOutputMimeTypes "(null) text/html text/plain"

В данной конфигурации ModSecurity будет применять выходные фильтры к файлам в виде plain-текста, HTML-файлам и файлам, чей MIME-тип не указан.

При использовании буферизации ModSecurity держит всю страницу в памяти, независимо от размера страницы.

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

Использовать Content-Type, который не просматривается. По причинам, связанным с производительностью, невозможно просматривать все типы содержимого; Некоторым способом перекодировать выходные данные. Даже простейшее перекодирование может обмануть мониторинг.

Поддерживается выходная переменная – OUTPUT_STATUS. Данная переменная определяет код статуса в ответе.

Исключение фильтрования аргументов

Для фильтрования можно указать инверсию некоторой переменной. Например:

SecFilterSelective "ARGS | !ARG_param" KEYWORD

Будет осуществляться поиск всех аргументов, за исключением названного параметра.

Кодирование запросов и ответов, использующих chunk

Протокол НТТР поддерживает метод передачи запроса, при котором размер содержимого заранее не известен. В этом случае тело запроса доставляется с использованием chunk’ов. Следовательно, должно существовать кодирование именованных chunk’ов. ModSecurity в настоящее время не поддерживает анализ запросов, состоящих из chunk’ов; когда запрос разбивается на chunk’и, тело запроса игнорируется. Насколько известно, браузеры не посылают разбитых на chunk’и запросов. Хотя Apache поддерживает данное представление для некоторых операций, большинство модулей (например, модуль РНР с Apache 1.3.x) его не поддерживает.

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

SecFilterSelective HTTP_Transfer-Encoding "!^$"

Это не влияет на возможность посылать ответы, использующие разбиение на куски.

Конфигурирование

Директивы конфигурирования ModSecurity непосредственно добавляются в конфигурационный файл (обычно httpd.conf). Если заранее не известно, включен ли данный модуль, директивы следует заключить в тег <IfModule>. Это позволит Apache игнорировать конфигурационные директивы, когда модуль не активен.

<IfModule mod_security.c> # mod_security configuration directives # ѕ </IfModule>

Так как Apache допускает, чтобы конфигурационные данные были расположены более чем в одном файле, существует возможность сгруппировать конфигурационные директивы в один файл (например, modsecurity.conf) и включить его в httpd.conf с помощью директивы Include.

Include conf/modsecurity.conf

Наследование фильтра

Фильтры, определенные в родительских каталогах, обычно наследуются во вложенных контекстах Apache. Такое поведение приемлемо (и требуется) в большинстве случаев, но не всегда. Иногда необходимо ослабить проверки для некоторой части сайта. Используя SecFilterInheritance директиву

SecFilterInheritance Off

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

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

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

SecFilterImport – импорт единственного правила из родительского контекста. Данная директива применяется, когда в дочернем контексте надо начать заново задавать правила, а из родительского – импортировать только выбранные правила.

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

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

Замечание. Если ID требуемого правила ссылается на правило, которое является частью цепочки, директивы импорта и удаления воздействуют на всю цепочку, а не только на правило, на которое указывает ID.

Пример 1. Правила из родительского контекста не наследуются, но одно правило импортируется.

SecFilter XXX id:1001 SecFilter YYY id:1002 SecFilter ZZZ id:1003 <Location /subcontext/> SecFilterInheritance Off SecFilterImport 1003 </Location>

Пример 2. Правила из родительского контекста наследуются, при этом два правила удаляются.

SecFilter XXX id:1001 SecFilter YYY id:1002 SecFilter ZZZ id:1003 <Location /subcontext/> SecFilterRemove 1001 1002 </Location>

Замечание. Web-сервер Apache поддерживает много различных типов контекстов (например, <Directory>, <Location>, <Files>). Последовательность, в которой контексты соединяются, важна. Не следует смешивать наследование и контексты разного типа. В любом случае следует тщательно протестировать конфигурацию, чтобы быть уверенным, что все работает так, как ожидается.

Наследование фильтра в многопользовательских окружениях

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

Замечание. Если нет полного доверия пользователям (например, в случае web-хостинга), то никогда не следует разрешать им доступ к ModSecurity. Возможность .htaccess используется для децентрализованного администрирования. Но это не означает, что ее следует использовать в ситуациях, в которых пользователи могут захотеть разрушить конфигурацию. В этом случае надо полностью выключить возможность .htaccess, скомпилировав ModSecurity с опцией –DDISABLE_HTACCESS_CONFIG.

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

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

SecFilterInheritanceMandatory On Рассмотрим, что произойдет в следующей ситуации: SecFilter XXX id:1001 SecFilterInheritabceMandatory On <Location /subcontext/> SecFilterInheritance Off SecFilter YYY id:1002 SecFilter ZZZ id:1003, mandatory </Location>

<Location /subcontext/another/> SecFilterRemove 1001 1002 1003 SecFilter QQQ id:1004 </Location>

Так как наследование правил является обязательным в основном контексте, /subcontext/ контекст будет наследовать правило 1001, несмотря на попытку его отключить (используя SecFilterInheritance Off). В данном подконтексте первым будет выполняться правило 1001, далее правила 1002 и 1003.

Обязательное правило 1001 из основного контекста будет также распространяться на контекст /subcontext/another/, несмотря на попытку удалить его. Это также выполняется для правила 1003, которое было сделано обязательным для наследования, используя действие mandatory. Директива SecFilterRemove 1001 1002 1003 будет, однако, успешно удалять правило 1002, потому что наследование не является обязательным в /subcontext/. Следовательно, в данном контексте первыми будут выполняться правила 1001 и 1003, следующим будет правило 1004.

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

Настройка отключения динамической буферизации

Существует возможность настройки отключения сканирования содержимого POST-запросов для отдельного запроса. Если определена переменная окружения MODSEC_NOPOSTBUFFERING для ModSecurity, то буферизация содержимого POST не выполняется. Например, для выключения буферизации загрузок (upload) файлов следует использовать следующее:

SetEnvIfNoCase Content-Type \ "^multipart/form-data;" "MODSEC_NOPOSTBUFFERING=Do not buffer file uploads"

Значение, связанное с переменной MODSEC_NOPOSTBUFFERING, будет записано в логи отладки.

Неявная проверка корректности

Неявная проверка корректности запроса (если она сконфигурирована), выполняется только в начале обработки запроса. Эта проверка состоит из проверок строки запроса и заголовков.

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

Нормализация пути

Фильтры не применяются к исходным данным запроса – первым делом выполняется их нормализация. Это делается потому, что атакующий может применить различные технологии скрытия определенной последовательности символов, чтобы избежать обнаружения атаки. Например, можно установить фильтр, который определяет выполнение команд shell:

SecFilter /bin/sh

Но атакующий может использовать строку /bin/./sh (которая приведет к тем же самым действиям), чтобы обойти фильтр. ModSecurity автоматически применяет следующие преобразования:

в Windows преобразует \ в /;понижает /./ до /;понижает // до /;декодирует символы URL.

Можно также установить или запретить проверку представления URL, а также разрешать использовать только байты из некоторого диапазона

Ограничение памяти, используемой для загрузки

В Apache 2.х можно определить количество памяти, которое может быть использовано для обработки multipart/form-data запросов. Если запрос больше, чем доступная память, то может использоваться временный файл. Значением по умолчанию является 60 Kб но данный лимит может быть изменен с помощью директивы SecUploadInMemoryLimit:

SecUploadInMemoryLimit 125000

Ограничения в списке действий для каждого правила

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

SecFilterSignatureAction log, deny, status:403 SecFilterActionsRestricted On Include conf/third-party-rules.conf

Единственными действиями, которые разрешены в конфигурации для каждого правила при включении ограниченного режима, являются правила метаданных id, msg, rev и severity. Другие правила игнорируются.

Перемещение по директории

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

SecFilter "\.\./"

Поддержка загрузки (upload) файла

ModSecurity имеет возможность перехватывать файлы, загружаемые с помощью POST-запросов и multipart/form-data кодирования или с помощью PUT-запросов.

Подход mod_security

В ModSecurity добавлена специальная директива, которая позволяет успешно выполнить chroot.

SecChrootDir /chroot/apache

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

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

Понятие регулярных выражений

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

Замечание. В Apache 1.x и Apache 2.x используются различные инструментальные средства для регулярных выражений. В Apache 2.x обработка регулярных выражений совместима с Perl. В Apache 1.x обработка регулярных выражений совместима с POSIX.

В регулярных выражениях используются специальные символы. Приведем краткую семантику некоторых из них:

СимволОписание

.	Соответствует любому символу
(…)	Группирует последовательность элементов
+	Соответствует образцу один или более раз
*	Соответствует образцу нуль или более раз
?	Соответствует образцу нуль или один раз
^	Соответствует началу строки
$	Соответствует образцу в конце строки
! (перед первым символом)	Инвертирует выражение

Правила (Rules)

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

Предотвращать null byte атаки

Атаки null byte пытаются обмануть ПО, написанное на C/C++, заставляя его считать, что строка заканчивается раньше, чем это есть на самом деле. Данный тип атак обычно предотвращается с помощью фильтра SecFilterByteRange. Если не отфильтровать null byte, то это может повлиять на последующую фильтрацию. Например:

SecFilter hidden

Но при этом слово hidden не будет определено в случае такого запроса:

GET /one/two/three?p=visible%00hidden HTTP/1.0

Пример SSL/TLS-сессии

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

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

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

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

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

Теперь Рукопожатие SSL/TLS завершено и начинается SSL/TLS-сессия. Клиент и сервер используют ключи сессии для шифрования и дешифрования, а также для проверки целостности посылаемых друг другу данных.

Простая фильтрация

Самая простейшая форма фильтрации выглядит следующим образом:

SecFilter KEYWORD [ACTION]

Для каждого простого фильтра ModSecurity ищет KEYWORD в запросе. Поиск ведется очень широко; он применяется к строке запроса, которая выглядит некоторым аналогичным образом: GET /index.php?parameter= value HTTP/1.0. В случае POST-запросов тело запроса также будет просматриваться.

Первое, что следует отметить: KEYWORD – это не простой текст. Это регулярное выражение.

Проверка диапазона байтов

Часто следует проверять, что запрос состоит из количества байтов, принадлежащих определенному диапазону. Это может быть полезно для того, чтобы избежать атак переполнения стека (так как они обычно содержат "случайные" биты). Например, для того, чтобы разрешить запрос, состоящий из значений байтов от 32 до 126 (включительно), следует использовать директиву:

SecFilterForceByteRange 32 126

Значениями диапазона по умолчанию являются 0 и 255, т.е. все значения байтов разрешены.

Замечание. Данная директива не проверяет содержимое POST-запросы при использовании представления multipart/form-data. Если это делать, то невозможно будет загружать бинарные файлы. Однако, после того, как параметры извлечены из такого запроса, оставшаяся часть проверяется на корректность диапазона.

Проверка файлов

Можно выполнять внешний скрипт для проверки файла перед тем, как разрешить ему проходить через web-сервер к приложению. Директива SecUploadApproveScript делает доступной данную функцию:

SecUploadApproveScript /full/path/to/the/script.sh

Скрипт получает один параметр из командной строки – полный путь к файлу, который должен быть загружен. После того как скрипт выполнит его обработку, он должен записать ответ в стандартный вывод. Если первый символ ответа есть "1", то файл принимается. В противном случае ответ отвергается. Скрипт может использовать остаток строки для записи более информативного сообщения об ошибке. Данное сообщение будет храниться в логах отладки.

Проверка корректности представления Unicode

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

SecFilterCheckUnicodeEncoding On

Это предполагает представление в UTF-8 и проверяет следующие три типа ошибок.

Недостаточно байтов. UTF-8 поддерживает кодирование из двух, трех, четырех, пяти и шести байтов. ModSecurity определяет случаи, когда один или более байтов пропущены.

Несуществующее кодирование. Атакующие могут использовать несуществующее кодирование, чтобы попытаться обмануть Unicode декодировщики.

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

Проверка корректности представления URL

Специальные символы могут быть закодированы злоумышленником перед тем, как они будут вставлены в URL. Любой символ может быть заменен с использованием комбинации из трех символов: %XY, где XY представляют собой шестнадцатеричный код символа. В шестнадцатеричных числах разрешены только буквы от А до F, но атакующие иногда используют другие буквы, чтобы запутать алгоритм декодирования. ModSecurity выполняет декодирование с помощью следующего правила:

SecFilterCheckURLEncoding On

Замечание. Данная директива не проверяет содержимого POST-запросы при использовании представления multipart/form-data. Это не является обязательным, потому что в этом случае не используется URL.

Проверка параметров

Проверка того, что параметр является целым в диапазоне от 0 до 99999, выполняется с помощью следующего фильтра:

SecFilterSelective ARG_parameter "!^[0-9]{1,5}$"

Рекомендуемая конфигурация

Ниже приведена рекомендуемая минимальная конфигурация.

Пример 11.1.

(html, txt)

Решение общих проблем безопасности

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

Схемы шифрования SSL/TLS

Протокол SSL/TLS поддерживает использование различных криптографических алгоритмов для таких операций, как аутентификация сервера и клиента и установление ключей сессии.

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

Требуемая безопасность:

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

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

Сканирование POST-запросов

Сканирование содержимого тела запроса (т.е. содержимое POST-запросов) по умолчанию выключено. Для выполнения сканирования содержимого POST-запросов необходимо указать:

SecFilterScanPOST On

ModSecurity поддерживает два типа кодирования тела запроса:

application/x-www-form-urlencoded – используется для пересылки данных формы;

multipart/form-data – используется для пересылки файлов.

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

SecFilterSelective HTTP_Content-Type \ "! (^$ | ^application/x-www-form-urlencoded$ | ^multipart/form-data;)"

Скрытие идентификации сервера

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

Для изменения идентификации web-сервера можно найти его имя (например, "Apache") в исходном коде, заменить его и перекомпилировать сервер. Тот же самый результат можно получить, используя директиву SecServerSignature:

SecServerSignature "Microsoft-IIS/5.0"

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

Слабые места SSL/TLS

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

SSL/TLS также уязвим для атаки "man-in-the-middle" при отсутствии аутентификации сервера или использовании им самоподписанного сертификата. В случае анонимного сервера общий секрет вырабатывается по алгоритму Диффи-Хеллмана, который уязвим для атак "man-in-the-middle". Аналогичная ситуация возникает, когда пользователь принимает сертификат сервера без проверки его действительности вручную или при отсутствии в браузере открытого ключа выпустившего сертификат СА.

При этом атакующий устанавливает одно множество ключей сессии для использования с настоящим сервером, и другое множество ключей – для использования с клиентом. Это позволяет атакующему не только читать все данные, которые передаются между клиентом и сервером, но и изменять данные без обнаружения этого. Следовательно, очень важно для пользователей понимать опасность данного типа атаки и проверять действительность сертификата, прежде, чем полагаться на безопасность SSL/TLS сессии. Данная угроза может быть понижена, если клиент доверяет сертификатам, выпущенным доверенными CAs, или самоподписанные сертификаты получены с использованием некоторых внешних механизмов. Предоставление самоподписанного сертификата может означать, что происходит атака "man-in-the-middle". Последние версии браузеров выполняют некоторые проверки автоматически, но на это нельзя полагаться во всех случаях.

Список действий для технологий аутентификации и шифрования

Технологии web-аутентификации и шифрования.

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

Для web-ресурсов, которые требуют минимальной защиты, но для которых не существует четко определенной аудитории, сконфигурировать Basic или Digest (лучше) аутентификацию.

Для web-ресурсов, которые требуют защиты от вредоносных bots, следует сконфигурировать Basic или (лучше) Digest аутентификацию.

Для web-ресурсов, которые требуют максимальной защиты, сконфигурировать SSL/TLS.

Конфигурирование SSL/TLS.

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

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

Для конфигураций, которые требуют среднего уровня аутентификации клиента, следует сконфигурировать аутентификацию сервера по SSL/TLS, а запрос имени пользователя и пароля — по Basic-аутентификации или с использованием тега <form> в HTML-странице.

Для конфигураций, которые требуют высокого уровня аутентификации клиента, сконфигурировать сервер для запроса сертификатов клиента по SSL/TLS. Сконфигурировать проверку целостности файла, содержащего сертификат web-сервера.

Если используется только SSL/TLS на web-сервере, то проверить, что доступ через 80 порт запрещен.

Если основной трафик к web-серверу будет получаться по протоколу SSL/TLS, то гарантировать, что на web-сервере используются соответствующие механизмы ведения логов и определения проникновения, потому что сетевой мониторинг не эффективен для зашифрованных сессий SSL/TLS.

Список действий по умолчанию

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

SecFilterDefaultAction "deny, log, status:404"

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

Замечание. Если указан нефатальный список действий по умолчанию (список, который не вызовет ситуацию, при которой запрос может быть отвергнут, например, log, pass), то такой список действий будет игнорироваться на фазе инициализации. Фаза инициализации предназначена для того, чтобы получить информацию о запросе. Разрешение нефатальных действий будет приводить к тому, что некоторые части запроса могут быть пропущены. Поскольку данная информация требуется для внутренней обработки, такие действия не могут быть разрешены. Если ModSecurity должен выполняться в "detect-only" режиме, необходимо запретить все неявные проверки корректности (проверку корректности представления URL, проверку корректности представления Unicode, проверку корректности формата cookie и ограничение диапазона байтов).

Замечание. Некоторые действия не могут появиться в списке по умолчанию такие как: id, rev, skipnext, chain.

Способы задания действий

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

SecFilterDefaultAction "deny, log, status:500"

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

SecFilterDefaultAction "deny, log, status:’Hello, World!’"

Замечание. Если указано по умолчанию нефатальное действие (такое как log, pass), то оно будет игнорироваться при инициализации. Фаза инициализации разработана для получения информации о запросе, не допуская, чтобы не фатальные действия приводили к тому, чтобы некоторая часть запроса пропускалась при обработке в ModSecurity. Следовательно, если ModSecurity должен функционировать в режиме "detect-only", следует запретить все неявные проверки корректности (проверка представления URL, Unicode, формат cookie, диапазон байтов).

Замечание. Действия над метаданными (id, rev, msg, severity) и действия, которые управляют последовательностью правил (skip/skipnext, chain), не могут появиться в директиве SecFilterDefaultAction.

SSL/TLS

Протоколы SSL и TLS обеспечивают аутентификацию сервера и клиента и шифрование соединений. SSL был впервые введен компанией Netscape Communication в 1994 году и дважды пересматривался (последней версией SSL является версия 3). В 1996 году IETF основало рабочую группу TLS, чтобы определить протокол SSL в качестве стандарта Интернета. Протокол TLS версии 1.0 специфицирован в RFC 2246 в 1999 году и основывается на SSL версии 3. Можно считать, что SSL версии 3 и TLS версии 1 идентичны, поэтому они будут обсуждаться вместе. Протоколы TCP/IP управляют транспортом и роутингом данных в Интернете. Протоколы прикладного уровня, такие как НТТР, LDAP, IMAP, выполняются поверх TCP. SSL/TLS расположен между протоколом ТСР и протоколами прикладного уровня.

Стандартный подход

ModSecurity включает поддержку изоляции файловой системы Apache или выполнение chroot. После того как операция chroot выполнена, приложение не может иметь доступа вне указанной директории.

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

Требования к аутентификации и шифрованию

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

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

Требования к реализации SSL/TLS

Цифровые подписи необходимы для выполнения протокола SSL/TLS. Сертификаты могут быть выпущены третьей доверенной стороной (СА) или быть самоподписанными. Организационные требования определяют используемый подход.

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

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

Когда СА выпускает сертификаты, он гарантирует идентификацию организации и web-сервера. В самоподписанном сертификате web-сервер сам "гарантирует" свою идентификацию.

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

После того как сертификат получен от СА или самовыпущен, необходимо сконфигурировать SSL/TLS. Некоторые шаги, которые являются общими для всех web-серверов:

сконфигурировать SSL/TLS для использования только криптографических алгоритмов, обеспечивающих требуемый уровень безопасности; – указать расположение сертификата сервера и других параметров, требуемых для SSL/TLS;

сконфигурировать сервер, чтобы он слушал определенный порт (по умолчанию 443). В большинстве случаев сервер не предполагает использования SSL/TLS по умолчанию, данный порт должен быть закрыт по причинам безопасности. Необходимо сконфигурировать всю сетевую инфраструктуру для поддержки SSL/TLS трафика;

сконфигурировать сервер для защиты необходимых ресурсов (директорий и файлов), используя SSL/TLS. При этом эти ресурсы будут доступны только по URL, начинающихся с https://.

Включение фильтрации

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

SecFilterEngine On

Возможные значения параметров:

On – анализировать каждый запрос;

Off – не делать ничего;

DynamicOnly – анализировать только запросы страниц, создаваемых динамически во время выполнения. Это предотвращает использование времени ЦП на проверку запросов для статических файлов.

Возможности SSL/TLS

SSL/TLS обеспечивает следующие возможности.

Аутентификация сервера – SSL/TLS позволяет web-клиенту убедиться в идентификации сервера. Поддерживающие SSL/TLS клиенты могут использовать стандартные технологии криптографии с открытым ключом для проверки имени сервера и открытого ключа, содержащихся в действительном сертификате, выпущенном СА, который перечислен в списке доверенных САs. Эта проверка может быть важна, если, например, пользователь посылает номер кредитной карты по сети и хочет иметь подтверждение идентификации получающего сервера.

Аутентификация клиента – SSL/TLS позволяет web-серверу запрашивать идентификацию пользователя, используя ту же технологию, которая использовалась при аутентификации сервера. Поддерживающее SSL/TLS ПО web-сервера может убедиться, что сертификат клиента действительный и выпущен СА, перечисленном в списке доверенных САs. Это подтверждение может быть важным, если сервер, например, является банком и посылает конфиденциальную финансовую информацию потребителям, и при этом он хочет иметь подтверждение идентификации получателя.

Шифрование и целостность соединения – SSL/TLS может шифровать и обеспечивать целостность информации, передаваемой между клиентом и сервером. При выборе соответствующего алгоритма шифрования SSL/TLS обеспечивает высокую степень конфиденциальности. Также обеспечивается целостность данных.

Встроенные действия

pass

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

SecFilter KEYWORD "log, pass"

allow

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

SecFilterSelective REMOTE_ADDR "^192\.168\.2\.99$" allow

deny

Прерывает обработку запроса, который соответствует фильтру. Если не используется действие status, ModSecurity возвращает код ошибки HTTP 500. Если запрос запрещен, заголовок mod_security_action будет добавлен в список заголовков запроса. Данный заголовок будет содержать используемый код статуса.

status

Использует указанный код статуса НТТР при прерывании запроса. Пример:

SecFilter KEYWORD "deny, status:404"

Будет возвращать ответ "Page not found" при соответствии фильтру. Директива Apache ErrorDocument будет использована, если она присутствует в конфигурации. Следовательно, если имеется заранее определенная страница для сообщения об ошибке для данного статуса, она будет выполняться, и ее выходные значения будут показаны пользователю.

redirect

При соответствии фильтру происходит перенаправление запроса пользователя на данный URL. Например:

SecFilter KEYWORD "redirect:http://www.modseciruty.org"

Данная конфигурационная директива всегда перекрывает код статуса НТТР или ключевое слово deny.

proxy

При соответствии фильтру запрос попускается через внутренний реверсный прокси.

SecFilter KEYWORD "proxy:http://www.example.ru"

Для выполнения данного действия должен быть инсталлирован mod_proxy.

exec

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

SecFilter KEYWORD "exec:/home/my/report-attack.pl"

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

На каждый фильтр можно иметь только один выполняемый бинарный файл. Выполнение будет добавлять заголовок mod_security-executed в список заголовков запроса.

Замечание. Выполняемый скрипт должен что-либо записать в stdout. Если он этого не делает, то ModSeciruty предполагает, что скрипт не работает.

log

При соответствии фильтру информация заносится в error log Apache.

nolog

Не заносится ничего в лог при соответствии фильтру.

skipnext

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

SecFilterSelective ARG_p value1 skipnext:2 SecFilterSelective ARG_p value2 SecFilterSelective ARG_p value3

chain

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

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

SecFilterSelective ARG_username admin chain SecFilterSelective REMOTE_ADDR "!^YOUR_IP_ADDRESS_HERE$"

Для первого правила выполняется соответствие только тогда, когда существует параметр username, и его значение есть admin. Только при этом будет выполняться второе правило, которое проверяет соответствие удаленного адреса в запросе с указанным IP-адресом.


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

pause

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

auditlog

Занесение информации о транзакции в лог аудита.

noauditlog

Информация о транзакции не заносится в лог аудита.

id, rev, msg, severity

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



id – уникальный ID правила.

rev – пересмотр правила; если опущено, то предполагается 1; всякий раз, когда правило изменяется, значение пересмотра должно быть увеличено.

msg – текстовое сообщение, которое появляется в логах ошибок.

severity – целое значение или имя, как определено syslog. Могут использоваться следующие уровни: 2 (большая строгость), 3 (средняя строгость), 4 (маленькая строгость) и 5 (нормальная, но важная). Уровни 0-1 и 5-7 могут применяться только конечными пользователями для своих целей.



0 EMERGENCY – система не используется.

1 ALERT – действие должно быть выполнено немедленно.

2 CRITICAL – критичные условия.

3 ERROR – ошибочные условия.

4 WARNING – предупреждающие условия.

5 NOTICE – нормальные, но важные условия.

6 INFO – информационное.

7 DEBUG – сообщение отладочного уровня.



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

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

mandatory

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

Замечание. Действие может применяться только для отдельного правила или в начале цепочке.

SecFilter 111 mandatory

Или

SecFilter 111 mandatory, chain SecFilter 222

setenv, setnote

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

Указание имени и значения:

SecFilter KEYWORD setenv:name=value

Указание только имени, значение предполагается равным "1":

SecFilter KEYWORD setenv:name

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

SecFilter KEYWORD setenv:!name

Он также может называться прикладным

ModSecurity является инструментом определения и предотвращения проникновений для web-приложений. Он также может называться прикладным web firewall’ом. Данный модуль встроен в web-сервер Apache.
Основные возможности модуля:

Фильтрация запросов: входящие запросы анализируются перед тем, как они будут обработаны web-сервером или другими модулями.
Использование технологии предотвращения обхода проверок: все параметры нормализуются перед тем, как модуль анализирует входные параметры, для того чтобы не допустить возможность обхода проверок.
Фильтрация запросов с учетом семантики НТТР-протокола: может выполняться очень специфичная и точная фильтрация. Например, модуль может просматривать отдельные параметры или значения поименованных cookies.
Анализ содержимого POST: модуль может анализировать содержимое, передаваемое с использованием метода POST.
Аудит логов: полная детализация каждого запроса (включая POST) может быть занесена в лог для последующего анализа.
Фильтрация сжатого содержимого: модуль анализирует запросы после того, как была выполнена декомпрессия.
ModSecurity может использоваться не только для обнаружения, но и для предотвращения атак.

Выбор местоположения для загружаемых файлов

ModSecurity всегда загружает файлы во временный каталог. Это можно изменить, используя директиву SecUploadDir:

SecUploadDir /tmp

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

Выборочное фильтрование

SecFilterSelective LOCATION KEYWORD [ACTION]

Позволяет точнее указать условия поиска. KEYWORD и ACTION аналогичны SecFilter. Параметр LOCATION состоит из набора идентификаторов, разделенных вертикальной чертой.

SecFilterSelective "REMOTE_ADDR | REMOTE_HOST" KEYWORD

Модуль применяет регулярное выражение только к IP-адресу клиента или имени хоста. Список возможных идентификаторов включает все CGI-переменные и некоторые другие.

REMOTE_ADDRREMOTE_HOSTREMOTE_USERREMOTE_IDENTREQUEST_METHODSCRIPT_FILENAMEPATH_INFOQUERY_STRINGAUTH_TYPEDOCUMENT_ROOTSERVER_ADMINSERVER_ADDRSERVER_PORTSERVER_PROTOCOLSERVER_SOFTWARETIME_YEARTIME_MONTIME_DAYTIME_HOURTIME_MINTIME_SECTIME_WDAYTIMEAPI_VERSIONTHE_REQUESTREQUEST_URIREQUEST_FILENAMEIS_SUBREQ

Существует несколько специальных идентификаторов:

POST_PAYLOAD – фильтр тела POST-запросаARGS – аргументы фильтра, то же самое, что и QUERY_STRING | POST_PAYLOADARGS_NAMES – только имена переменных и параметровARGS_VALUES – только значения переменных и параметровCOOKIES_NAMES – только имена cookieCOOKIE_VALUES – только значения cookieSCRIPT_UIDSCRIPT_GIDSCRIPT_USERNAMESCRIPT_GROUPNAMESCRIPT_MODEARGS_COUNTCOOKIES_COUNTHEADERSHEADERS_COUNTHEADERS_NAMESHEADERS_VALUESFILES_COUNTFIELS_NAMESFILES_SIZES

Существуют и более специальные идентификаторы:

HTTP_header – запрос поиска заголовкаENV_variable – поиск переменной окруженияARG_variable – поиск переменной / параметра запросаCOOKIE_name – поиск cookie с данным именемFILE_NAME_variable – поиск имени файлаFILE_SIZE_variable – поиск размера загружаемого файла

В Apache 2 существует ограниченное число переменных, специфичных для вывода (только когда доступна буферизация вывода).

OUTPUT – все тело ответаOUTPUT_STATUS – код статуса ответа

Выполнение команд ОС

Web-приложениям иногда требуется выполнять команды ОС. Это может позволить атакующему выполнить произвольные команды. Фильтр должен быть подобен следующему:

SecFilterSelective ARGS "bin/"

Это может предотвратить попытки выполнить бинарные файлы, расположенные в различных папках.

Взаимодействие ModSecurity c пакетным фильтром

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

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

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

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

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

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

Взаимодействие с другими демонами

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

Заголовки запроса, добавляемые mod_security

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

Список добавляемых заголовков следующий:

mod_security-executed – вместе с путем к выполняемому файлу.

mod_security-action – вместе с возвращаемым кодом статуса.

mod_security-message – сообщение, касающееся обнаруженной проблемы; то же самое сообщение добавляется в лог ошибок.

Загрузка файлов

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

SecFilterSelective HTTP_CONTENT_TYPE multipart/form-data <Location /upload.php> SecFilterInheritance Off </Location>

Занесение в лог тела запроса

ModSecurity экспортирует тело запроса с помощью mod_security-body. Это можно использовать для создания логов.

LogFormat "%h %l %u %t \" %r \" %>s %{mod_security-body}n

Замечание. Если запрос является multipart/request-data типом (например, загрузка файла), реальное тело запроса будет заменено эмулированным содержимым application/x-www-form-urlencoded.

Межсетевое экранирование

Автоматизированные инструментальные средства анализа лог-файлов

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

Доступно большое количество коммерческих и свободно распространяемых средств, обеспечивающих регулярный анализ Transfer Log. Большинство выполняется для Common или Combined Log Format.

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

Средства Error Log определяют не только ошибки, которые могут существовать в конкретном web-содержимом (такие как отсутствующие файлы), но также попытки доступа к несуществующим URL. Эти попытки могут указывать на следующее:

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

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

Демилитаризованная зона

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

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

Рис. 12.1.  Базовая DMZ

Данный тип DMZ имеет минимальную стоимость. Это подходит для небольших организаций при наличии минимальной угрозы. Основное слабое место такого подхода состоит в том, что, хотя роутер и имеет возможность защитить от большинства сетевых атак, он не "понимает" протокол НТТР и, следовательно, не может защитить от атак прикладного уровня, нацеленных на web-сервер. Лучший подход состоит в добавлении второго firewall’а между Интернетом и DMZ. Так будет создана лучшая защита DMZ. Пример данного типа реализации показан на рис. 12.2.

Рис. 12.2.  DMZ с двумя firewall’ами

Эта DMZ с двумя firewall’ами обеспечивает лучшую защиту по сравнению с базовой DMZ, так как выделенные firewall’ы могут иметь более сложные и сильные наборы правил безопасности. Кроме того, выделенный firewall часто имеет возможность анализировать входящий и исходящий НТТР-трафик, он может определить атаки прикладного уровня, направленные на web-сервер, и защитить от них.
Однако, данный тип DMZ может иметь некоторые проблемы с эффективностью выполнения.

Для организаций, которым требуется безопасность уровня DMZ с двумя firewall’ами, но которые не имеют финансовых возможностей для покупки двух firewall’ов, существует возможность, называемая service leg DMZ. В такой конфигурации firewall создается с тремя (или более) сетевыми интерфейсами. Один сетевой интерфейс соединяется с пограничным роутером, другой — с внутренней сетью и третий — с DMZ.

Рис. 12.3.  DMZ с firewall’ом с тремя интерфейсами

Данная конфигурация имеет определенные недостатки. В конфигурации DMZ, которая обсуждалась выше, DoS-атака, направленная на web-сервер, обычно задевает только сам web-сервер. В service leg конфигурации firewall принимает удар любой DoS-атаки, потому что он должен проверить весь сетевой трафик до того, как трафик достигнет web-сервера (либо любого другого ресурса в DMZ или во внутренней сети). Необходимость такой обработки может сильно загрузить firewall и замедлить весь трафик, включая тот, что предназначен для внутренней сети.

Преимущества создания DMZ с точки зрения безопасности:



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

Сетевая конфигурация DMZ может быть оптимизирована для поддержки и защиты web-сервера.

Недостатки DMZ с точки зрения безопасности.

DoS-атаки, направленные на web-сервер, могут воздействовать на внутреннюю сеть.

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

Дополнительные требования для создания логов

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

Хостинг во внешней организации

Многие организации предпочитают хостинг своего web-сервера в третьей организации (например, в Internet Service Provider – ISP). В этом случае web-сервер не размещается в сети организации. ISP имеет выделенную сеть, обслуживающую много web-серверов (для многих организаций), которые выполняются в одной сети.

Преимущества хостинга во внешней организации с точки зрения безопасности:

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

Недостатки хостинга во внешней организации с точки зрения безопасности:

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

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

Основные возможности создания логов

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

Transfer Log – каждая пересылка представлена в виде одной записи, которая описывает основную информацию, относящуюся к пересылке.

Error Log – каждая ошибка представлена в виде одной записи, включая объяснение причины возникновения данного сообщения об ошибке.

Agent Log – содержит информацию о ПО пользовательского клиента, которое использовалось для доступа к содержимому web.

Referrer Log – собирает информацию, относящуюся к НТТР-доступу. Это включает URL страницы, содержащей ссылку (link), по которой ПО клиента следовало для получения доступа к web-странице.

Большинство web-серверов поддерживают Transfer Log, и это обычно считается наиболее важным. Для записей Transfer Log доступно несколько форматов логов. Обычно информация представлена в виде плоского ASCII-текста без специальных разграничений различных полей.

Common Log Format – данный формат хранит следующую информацию, относящуюся к одной пересылке (Transfer Log) в указанном порядке:

Удаленный хост.Идентификация удаленного пользователя в соответствии с RFC 1413.Аутентифицированный пользователь в соответствии с базовой схемой аутентификации.Дата.Запрошенный URL.Статус запроса.Количество реально переданных байтов.

Комбинированный Log Format – данный формат содержит те же самые поля, которые были перечислены выше. Он также предоставляет информацию, обычно хранящуюся в Agent Log и Referrer Log, вместе с реально переданными данными. Хранение такой информации в консолидированном формате логов может способствовать более эффективному администрированию.

Расширенный Log Format – данный формат предоставляет способ описать все элементы, которые должны быть собраны в лог-файле. Первые две строки лог-файла содержат версию и хранимые поля:

#Version: 1.0 #Field: date time c-ip sc-bytes time-taken cs-version 2005-08-01 02:10:57 192.0.0.2 6340 3 HTTP/1.0

Данный пример включает в себя дату, время, исходный адрес, число переданных байт, время, затраченное на передачу, и версию НТТР.

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

Поддержка аутентичной копии web-содержимого

Следует поддерживать аутентичную (проверенную, доверяемую) копию web-содержимого на хосте, который не доступен из Интернета. Это дополняет, но не заменяет соответствующую политику backup’а. Например, в отношении статических web-сайтов это должна быть простая копия web-сайта на устройстве только для чтения (CD-R). Аутентичная копия web-сайта должна поддерживаться на безопасном хосте. Такой хост обычно расположен позади firewall’а во внутренней сети, а не в DMZ. Цель создания аутентичной копии состоит в том, чтобы предоставить способы восстановления информации на web-сайте, если он был скомпрометирован в результате случайных или преднамеренных действий. Аутентичная копия web-сайта позволяет быстро восстановить изуродованный web-сайт.

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

Защита аутентичной копии от неавторизованного доступа. Следует:

использовать устройства, которые допускают только однократную запись (подходит для относительно статичных web-сайтов);размещать хост с аутентичной копией позади firewall’а и гарантировать, что к хосту не существует доступа извне;минимизировать количество пользователей, которые имеют доступ к хосту;управлять доступом пользователей максимально точным способом;обеспечить строгую аутентификацию пользователей;развернуть соответствующие процедуры создания логов и мониторинга;предусмотреть дополнительные аутентичные копии в различных физических местах для обеспечения большей защиты.

Установить соответствующие процедуры обновления аутентичных копий:

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

Установить процесс копирования аутентичной копии на производственный web-сервер:

данные могут передаваться с использованием физически безопасной среды (например, шифрование и/или устройства только однократной записи, такие как CD-R);использовать безопасный протокол (например, SSH) для передач по сети.

Включить процедуры восстановления с аутентичной копии в организационные процедуры реакции на инцидент.

Поддержка тестового web-сервера

Большинство организаций поддерживают тестовый или развиваемый web-сервер. Идеально, чтобы данный сервер имел аппаратуру и ПО, идентичную основному web-серверу, и был размещен во внутреннем сегменте сети (Интранет), где он может быть полностью защищен обороной периметра. Хотя цена поддержки дополнительного web-сервера может быть значительной, наличие тестового сервера часто обеспечивает значительные преимущества.

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

Замечание: тестовый web-сервер должен быть отделен от сервера, который содержит аутентичную копию содержимого производственного web-сервера.

Политики и стратегии выполнения backup’а web-сервера

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

Все организации должны иметь политику выполнения backup’а данных web-сервера. На содержание этой политики могут повлиять следующие факторы:

требования законодательства:

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

требования бизнеса:

контрактные;общепринятая практика;критичность данных для организации.

руководства и политики, принятые в организации.

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

Цель политики выполнения backup’а web-сервера.Что влияет на политику выполнения backup’а web-сервера.Какие web-серверы охватывает политика backup’а.Определение ключевых элементов, особенно касающихся законодательных и технических сторон.Описание детальных требований в контексте законов, требований бизнеса и организации.Частота выполнения backup’а.

Процедуры, гарантирующие, что данные корректно сохранены и защищены:

Зашифрованная пересылка.Зашифрованное хранение.Механизмы физической защиты.

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

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

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

Процедуры создания backup web-сервера

Одна из наиболее важных функций администратора web-сервера — поддержка целостности данных на web-сервере. Это жизненно важно, потому что web-сервер часто является наиболее незащищенным сервером в сети организации и, таким образом, часто наиболее чувствительным к враждебным действиям и возможным падениям ПО и аппаратуры. Существуют два принципиальных компонента для выполнения backup’а данных для web-сервера: регулярный backup данных и всей системы и поддержка защищенной, аутентичной, отдельно хранящейся копии содержимого web-сервера.

Просмотр и хранение лог-файлов

Просмотр лог-файлов может быть трудоемким и занимать много времени. Лог-файлы являются реагирующей мерой безопасности; они информируют о событиях, которые уже произошли. Соответственно, они часто бывают полезны для поддержки других доказательств, таких как аномальный сетевой трафик, обнаруженный IDS. Логи web-сервера должны также просматриваться для обнаружения атак. Частота просмотра зависит от следующих факторов:

трафик, получаемый сервером;

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

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

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

Лог-файлы должны быть защищены для гарантирования того, что атакующий, который скомпрометировал web-сервер, не может изменить лог-файлы, чтобы скрыть свои действия. Хотя шифрование и может использоваться для защиты лог-файлов, лучшим решением является хранение лог-файлов на отдельном от web-сервера хосте. Он часто называется лог- или syslog-хостом.

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

законодательные требования;организационные требования;

размер логов (который напрямую зависит от трафика сайта и параметров создания логов); значимость (ценность) данных web-сервера и сервисов;уровень угроз.

Роутер и firewall

Firewall’ы (или роутеры, функционирующие как firewall’ы) являются устройствами или системами, которые контролируют поток сетевого трафика между сетями. Они защищают web-серверы от уязвимостей, существующих в семействе протоколов TCP/IP. Они также помогают уменьшить проблемы безопасности, связанные с небезопасными приложениями и ОС. Существует несколько типов firewall’ов: роутеры, которые могут обеспечивать управление доступом на уровне IP-пакетов; statefull firewalls’ы которые могут также контролировать доступ, основываясь не только на содержимом IP, но также и на содержимом заголовков протоколов ТСР и UDP; и наиболее мощные firewall’ы, которые могут распознавать и фильтровать web-содержимое.

Существует ошибочное мнение, что firewall’ы (или роутеры, функционирующие как firewall’ы) могут избавить от всех рисков и защитить от неправильной конфигурации web-сервера или плохо разработанной топологии сети. К сожалению, этого не происходит. Firewall’ы сами являются уязвимыми с точки зрения неправильной конфигурации, иногда уязвимы с точки зрения ПО. Кроме того, web-серверы уязвимы для многих атак, даже когда они расположены позади безопасного правильно сконфигурированного firewall’а. Например, firewall, который защищает web-сервер, должен блокировать любой доступ к web-серверу из Интернета, за исключением НТТР (обычно ТСР порт 80) и/или HTTPS (обычно ТСР порт 443). Тем не менее при такой конфигурации многие приложения web-сервера уязвимы для атак через 80 порт. Тем самым, firewall можно считать первой линией обороны web-сервера. Однако, чтобы быть действительно в безопасности, организация должна применять "оборону вглубь". Более важно, чтобы организация старалась поддерживать все системы безопасным образом и не зависела исключительно от firewall’ов (или любого другого единственного компонента), которые должны остановить атаку.

Для того чтобы более успешно защищать web-сервер с использованием firewall’а, следует гарантировать, что существует возможность сконфигурировать следующее:

управление всем трафиком между Интернетом и web-сервером;блокирование всего входящего трафика в web-серверу, за исключением 80 порта и/или 443 порта;блокирование всего входящего трафика с внутренних IP-адресов (предотвращение атак IP-spoofing);блокирование соединений клиента от web-сервера к Интернету и внутренней сети организации (это поможет уменьшить воздействие некоторых червей, таких как Code Red);блокирование (совместно с системой обнаружения проникновения) IP-адресов или подсетей, которые по отчетам IDS являются атакующими;уведомление сетевого администратора или соответствующего персонала о подозрительной активности (по e-mail или используя сетевую ловушку);обеспечение фильтрации содержимого;защиту от DoS-атак;определение атак, связанных с запросами конкретных URL;

создание логов критичных событий, включая следующие детали:

время и дата;IP-адрес интерфейса;название события, специфичное для производителя;стандартное событие атаки (если существует);IP-адреса источника и получателя;номера портов источника и получателя;сетевой протокол, используемый для атаки.

возможность своевременного получения patches для ПО firewall’а и лежащей в основе ОС.

Сетевые элементы

После того как web-сервер размещен в сети, следует сконфигурировать элементы сетевой инфраструктуры для поддержки и защиты web-сервера. Элементами сетевой инфраструктуры, которые влияют на безопасность web-сервера, являются firewall’ы, роутеры, системы обнаружения проникновения и сетевые коммутаторы (switch). Каждый из них играет важную роль для защиты web-сервера при обеспечении многоуровневой обороны. К сожалению, при обеспечении безопасности web-сервера не существует универсального решения. Единичный firewall или IDS не может обеспечить адекватную защиту публичного web-сервера от всех угроз и атак.

Сетевые коммутаторы и концентраторы

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

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

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

Системы обнаружения проникновения (IDS)

IDS является приложением, которое просматривает системные и сетевые ресурсы и анализирует различные виды деятельности, а также, используя информацию, полученную из этих источников, уведомляет сетевого администратора и/или соответствующий персонал, отвечающий за безопасность, о возможном проникновении или попытки взлома. Два основных типами IDS: host-based и network-based.

Сканирование уязвимостей

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

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

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

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

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

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

Идентификация активных хостов в сети.Идентификация активных сервисов (портов) на хостах и указание, какие из них являются уязвимыми.Идентификация вредоносных приложений и баннеров.Идентификация ОС.Идентификация уязвимостей, связанных с обнаруженными ОС и приложениями.Тестирование согласованности с политиками безопасности.

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

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

Создание логов

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

Логи web-сервера обеспечивают следующее:

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

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

Список действий для безопасного администрирования web-сервера

Создание логов.

Использовать Combined Log Format для хранения Transfer Log или вручную сконфигурировать информацию, описанную в Combined Log Format, чтобы стандартизовать формат Transfer Log.Если Combined Log Format недоступен, то использовать Referrer Log или Agent Log.Установить разные имена лог-файлов для разных виртуальных web-сайтов, которые могут быть реализованы как часть одного физического web-сервера.Использовать Remote User Identity, как описано в RFC 1413.Хранить логи на отдельном (syslog) хосте.Архивировать логи в соответствии с организационными требованиями.Просматривать логи ежедневно или еженедельно (при существовании требования более длительного их хранения).Использовать автоматизированные средства анализа лог-файла.

Выполнение backup’ов web-сервера.

Создать политику выполнения backup’а web-сервера.

Выполнять backup web-сервера инкрементально ежедневно или еженедельно.

Выполнять полный backup web-сервера еженедельно или ежемесячно. Периодически архивировать backup’ы.Поддерживать аутентичную копию web-сайта(ов).

Восстановление после компрометации.

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

Тестирование безопасности.

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

Удаленное администрирование и модификация содержимого.

Использовать сильный механизм аутентификации.

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

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

Не допускать удаленное администрирование из Интернета через firewall. Не иметь никаких разделяемых файлов из внутренней сети с web-сервером.

© 2003-2007 INTUIT.ru. Все права защищены.

Список действий для обеспечения безопасности сетевой инфраструктуры

Расположение сети.

Web-сервер располагается в DMZ или внешне по отношению к организации, и соответствующим образом защищается firewall.

DMZ не следует располагать на третьем (или более) интерфейсе firewall’а.

Конфигурация firewall’а.

Web-сервер защищается firewall’ом.Web-сервер, если он в большей степени подвержен атакам или является достаточно уязвимым, защищается firewall’ом прикладного уровня.Firewall контролирует весь трафик между интернетом и web-сервером.Firewall блокирует весь входящий трафик к web-серверу, за исключением ТСР порта, предназначенного для НТТР (80), и/или порта, предназначенного для НТТРS, который использует SSL/TLS (443).Firewall блокирует (совместно с IDS) IP-адреса или подсети, о которых IDS сообщает, что с них выполняется атака.Firewall уведомляет сетевого или web-администратора о подозрительной активности.Firewall обеспечивает фильтрацию содержимого.Firewall конфигурируется для защиты от атак на сервисы.Firewall определяет неправильно сформатированные или известные атаки, связанные с запросом конкретных URL.Firewall заносит в лог критичные события.Firewall и лежащая в основе ОС устанавливаются в максимальный уровень безопасности.

Использование IDS.

Host-based IDS применяются для web-серверов, которые используют SSL/TLS.IDS конфигурируется для просмотра сетевого трафика до любого firewall’а или фильтрующего роутера (network-based).IDS конфигурируется для просмотра сетевого трафика к web-серверу и от web-сервера после firewall’а.IDS блокирует (совместно с firewall) IP-адреса или подсети, с которых выполняется атака.IDS уведомляет сетевого или web-администратора об атаках.IDS конфигурируется для определения сканирования портов.IDS конфигурируется для определения DoS-атак.IDS конфигурируется для определения неправильно сформатированных URL-запросов.IDS конфигурируется для создания логов событий.IDS часто обновляется для получения новых сигнатур атак.IDS конфигурируется для просмотра сетевых ресурсов, доступных web-серверу (host-based).

Использование сетевых коммутаторов и концентраторов.

Сетевые коммутаторы используются в сети web-сервера для защиты от сетевого просматривания.Сетевые коммутаторы конфигурируются в режим максимальной безопасности для защиты от ARP-атак.Сетевые коммутаторы конфигурируются таким образом, чтобы посылать весь трафик в сетевом сегменте к IDS-хосту (network-based).

Тестирование безопасности web-серверов

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

Тестирование проникновения

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

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

Тестирование проникновения имеет следующие преимущества:

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

Топология сети

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

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

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

Удаленное администрирование web-сервера

Администраторы web-сервера должны тщательно рассмотреть, существует ли необходимость удаленного администрирования и/или модификации содержимого web-сервера. Большинство безопасных конфигураций запрещает любое удаленное администрирование или модификации содержимого, хотя это может и не являться необходимым абсолютно для всех организаций. Риск от необходимости удаленного администрирования или модификации содержимого зависит от размещения web-сервера в сети. Например, если web-сервер расположен внешне относительно firewall’а или фильтрующего роутера, то никакого удаленного администрирования или модификации содержимого не должно выполняться. Удаленное администрирование или модификация содержимого могут выполняться относительно безопасно из внутренней сети, когда web-сервер расположен позади firewall’а. Удаленное администрирование или модификация содержимого не должны допускаться с хоста, расположенного вне сети организации.

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

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

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

Ограничение по IP-адресу (не по имени хоста).Ограничение для хостов, находящихся во внутренней сети.

Используются безопасные протоколы (например, SSH, TLS/SSL), а не протоколы, не обеспечивающие конфиденциальность, целостность и аутентификацию (Telnet, FTP, HTTP, NFS). От протоколов требуется, чтобы они обеспечивали шифрование как паролей, так и данных.

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

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

Восстановление при компрометации безопасности

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

Web-администраторы должны выполнить следующие шаги при определении успешной компрометации:

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

Проанализировать проникновение, включая:

модификации, сделанные в ПО и конфигурациях;модификации, сделанные в данных;инструментальные средства или данные, оставленные нарушителем;данные из системных логов, определение проникновения и файлы логов firewall.

Выполнить восстановление системы.

Существуют две возможности:

инсталлировать чистые ОС, приложения, необходимые patches и содержимое web-сервера;восстановить из backup’а (данное действие может быть более рискованным, так как backup мог быть сделан после компрометации и восстановление компрометированного backup может позволить атакующему в дальнейшем получить доступ к системе).

Запретить сервисы, не являющиеся необходимыми.Применить все patches.Изменить все пароли (даже на нескомпрометированных хостах).Переконфигурировать элементы сетевой безопасности (например, firewall, роутер, IDS) для обеспечения дополнительной защиты и оповещения.

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

Системные администраторы должны рассмотреть следующие параметры при принятии решения о том, следует ли переинсталлировать ОС на скомпрометированной системе или же достаточно восстановить все из backup’а:

Уровень доступа, который получил нарушитель (например, root, user, guest, system).Тип атакующего (внутренней или внешний).Цель компрометации (например, изуродовать web-страницу, получить незаконный доступ к репозиторию ПО, платформе для выполнения других атак).Метод компрометации системы.Действия атакующего в течение и после компрометации (например, просмотр логов, отчетов об обнаружении проникновения).Продолжительность компрометации.Распространение компрометации на сеть (например, количество скомпрометированных хостов).Результаты консультаций с адвокатами.

Более низкий уровень доступа, полученный нарушителем, и большие знания web-администратора о действиях нарушителя уменьшают риск, существующий при восстановлении из backup’а и выполнении patch для устранения уязвимостей. Если о действиях нарушителя известно мало, то нужно переустановить все ПО на хосте.

Возможные параметры логов

Логи, созданные со следующими параметрами, можно считать оптимальными для первоначального использования:

Combined Log Format для хранения Transfer Log, или вручную сконфигурировать информацию, описываемую Combined Log Format, в стандартном формате для Transfer Log.Создание Referrer Log или Agent Log, если Combined Log Format недоступен.Установить различные имена лог-файлов для различных виртуальных web-сайтов, которые реализованы как часть одного физического web-сервера.Использовать идентификацию удаленного пользователя, как специфицировано в RFC 1413.Предусмотреть выполнение процедур или механизмов, которые бы гарантировали, что лог-файлы не переполняют жесткий диск.

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

---

---