Аттестация
При проведении работ со сведениями соответствующей степени конфиденциальности (секретности) системы информатизации должны (могут) быть аттестованы на соответствие требованиям безопасности информации.
Государственная система аттестации объектов информатизации устанавливает основные принципы, организационную структуру, порядок проведения аттестации, а также порядок контроля и надзора за эксплуатацией аттестованных объектов информатизации.
Система аттестации объектов информатизации по требованиям безопасности информации является составной частью единой государственной системы сертификации средств защиты информации и аттестации объектов информатизации по требованиям безопасности информации. Деятельность системы аттестации организуют уполномоченные федеральные органы по сертификации продукции и аттестации объектов информатизации по требованиям безопасности информации.
Под аттестацией объектов информатизации понимается комплекс организационно-технических мероприятий, в результате которых посредством специального документа -"Аттестата соответствия" подтверждается, что объект соответствует требованиям стандартов или иных нормативно-технических документов по безопасности информации, утвержденных Гостехкомиссией России. Наличие на объекте информатизации действующего "Аттестата соответствия" дает право обработки информации с определенным уровнем конфиденциальности и в указанный в "Аттестате соответствия" период времени.
Обязательной аттестации подлежат объекты информатики, предназначенные для обработки информации, составляющей государственную тайну, управления экологически опасными объектами, ведения секретных переговоров.
В остальных случаях аттестация носит добровольный характер (добровольная аттестация) и может осуществляться по инициативе заказчика или владельца объекта информатики.
При аттестации объекта информатизации подтверждается его соответствие требованиям по защите информации от несанкционированного доступа, в том числе от компьютерных вирусов, от утечки за счет побочных электромагнитных излучений и наводок при специальных воздействиях на объект (высокочастотное навязывание и облучение, электромагнитное и радиационное воздействие), от утечки или воздействия на нее за счет специальных устройств, встроенных в объекты информатизации.
Аттестация проводится уполномоченными органами по аттестации объектов информатизации. Органы по аттестации аккредитуются Гостехкомиссией России. Правила аккредитации определяются действующим в системе "Положением об аккредитации органов по аттестации объектов информатизации по требованиям безопасности информации". Каждый такой орган имеет лицензию Гостехкомиссии России на право выполнения работ в области защиты информации и Аттестат аккредитации. Виды работ, которые он может выполнять, указываются в области аккредитации, являющейся приложением к Аттестату аккредитации. В своей деятельности органы по аттестации руководствуются нормативно-методическими документами Гостехкомиссии России.
Аттестат соответствия утверждается руководителем органа по аттестации объектов информатизации, который и несет юридическую и финансовую ответственность за качество проведенных работ. Кроме того, органы по аттестации несут ответственность за обеспечение сохранности государственных и коммерческих секретов, а также за соблюдение авторских прав разработчиков аттестуемых объектов информатизации и их компонент.
Защита IP.
В 1994 году Совет по архитектуре Internet (Internet Architecture Board — IAB) опубликовал отчет, названный "Защита в рамках архитектуры Internet" (документ RFC 1636, "Security in the Internet Architecture"). Отчет отразил общее понимание того, что Internet нуждается в большей и лучшей защите, и определил области применения ключей в механизмах защиты. Среди прочего отмечалась необходимость защиты сетевой инфраструктуры от несанкционированного мониторинга и управления потоками данных, а также защиты сквозного обмена данными между пользователями с помощью средств аутентификации и шифрования.
Такие требования вполне оправданны. Подтверждением могут служить данные ежегодного отчета CERT (Computer Emergency Rresponse Team — группа компьютерной "скорой помощи") 1998 года, в котором сообщается более чем о 1300 зарегистрированных случаях нарушений защиты, повлиявших на работу почти 20000 узлов [CERT99]. К наиболее серьезным типам нарушений относятся фальсификация адресов IP (когда нарушители создают пакеты с ложными IP-адресами и используют приложения, предполагающие аутентификацию на основе адресов IP) и самые разные формы перехвата пакетов с данными (в результате чего нарушители получают передаваемую информацию, включая информацию аутентификации и содержимое баз данных). В ответ на эту угрозу IAB счел необходимым рассматривать аутентификацию и шифрование как обязательные средства защиты протокола IP следующего поколения (протокола IPv6). К счастью, эти средства можно применять как с действующим сейчас протоколом IPv4, так и с протоколом будущего IPv6. Это значит, что поставщики могут предлагать соответствующие возможности уже сейчас, и многие из них действительно делают это.
Области применения IPSec1
Протокол IPSec обеспечивает защиту обмена данными в локальных сетях, корпоративных и открытых глобальных сетях и в Internet. Примеры его применения включают следующее.
Защищенный доступ к филиалу организации через Internet. Компания может построить защищенную частную виртуальную сеть в рамках сети Internet или другой открытой глобальной сети. Это позволяет использовать каналы Internet и тем самым сократить расходы на создание и поддержку частной сети.
Защищенный удаленный доступ через Internet. Конечный пользователь, в системе которого предусмотрены протоколы защиты IP, может с помощью локального телефонного вызова обратиться к поставщику услуг Internet и получить защищенный доступ к сети компании. Это сокращает транспортные расходы служащих и надомных работников.
Внутрисетевое и межсетевое взаимодействие с партнерами. Средства IPSec могут обеспечить защищенную связь с другими организациями, гарантируя аутентификацию и конфиденциальность, а также предлагая механизм обмена ключами.
Усиление защиты электронных коммерческих операций. Даже если какие-то приложения Web и электронной коммерции имеют встроенные протоколы защиты данных, использование IPSec усиливает эту защиту.
Главной особенностью IPSec, позволяющей этому протоколу поддерживать самые разнообразные приложения, является возможность шифрования и/или аутентификации всего потока данных на уровне IP. Таким образом, защита может быть обеспечена любому распределенному приложению, включая приложения удаленной регистрации, приложения типа клиент-сервер, приложения электронной почты, передачи файлов, доступа к ресурсам Web и т.д.
На рис. 6.1 показан типичный сценарий использования IPSec. Некоторая организация поддерживает ряд локальных сетей, находящихся в разных местах. В рамках этих локальных сетей трафик IP не защищается. Для обмена данными через корпоративную или открытую внешнюю глобальную сеть используются протоколы IPSec. Эти протоколы применяются устройствами, размещенными по периметру сети (например, маршрутизаторами или брандмауэрами) и соединяющими локальные сети с внешним миром. Использующее IPSec сетевое устройство обычно шифрует и сжимает весь поток данных, отправляемый в глобальную сеть, и дешифрует и разворачивает данные, приходящие извне. Все выполняемые в этом случае операции не заметны для рабочих станций и серверов локаль нои сети, защищенный оомен данными возможен и с индивидуальными пользователями, использующими удаленный доступ к сети через глобальные сети. Чтобы обеспечить защиту, рабочие станции таких пользователей тоже должны использовать протоколы IPSec.
Система
Рис. 6.1. Защита на уровне IP
Преимущества IPSec
В [MARK97] перечислены следующие преимущества IPSec.
Если поддержку IPSec реализовать в брандмауэре или маршрутизаторе, это обеспечит надежную защиту всему потоку данных, идущему через границу локальной сети. При этом поток данных внутри локальной сети компании или рабочей группы не перегружается лишними операциями, связанными с защитой.
Средства IPSec в брандмауэре трудно обойти, если использование IP предполагается для всего потока данных, а брандмауэр является единственной точкой, связывающей сеть организации с Internet.
Средства IPSec размещаются ниже транспортного уровня (TCP, UDP), а поэтому оказываются незаметными для приложений. Нет необходимости менять программное обеспечение в системах пользователя или сервера, когда в брандмауэре или маршрутизаторе реализуется IPSec. Даже если IPSec реализуется в конечных системах, на программное обеспечение верхнего уровня, включая приложения, это не влияет.
Использование IPSec может быть незаметным для конечного пользователя. Нет необходимости объяснять пользователю механизмы защиты, выдавая ему соответствующие инструкции и требуя их вернуть, когда он покинет организацию.
• При необходимости IPSec может обеспечить защиту индивидуальным пользователям. Это может понадобиться для лиц, работающих вне территории предприятия, или при создании защищенной виртуальной подсети внутри организации для работы с особо важными приложениями.
Приложения маршрутизации
Кроме поддержки конечных пользователей и защиты систем и сетей предприятия, IPSec может участвовать в создании архитектуры маршрутизации при межсетевом взаимодействии. В [HUIT98] приводится следующий список примеров использования IPSec. Применение IPSec может гарантировать, что:
прибывающее извещение маршрутизатора (т.е. сообщение нового маршрутизатора, объявляющее о его присутствии в сети) действительно исходит от авторизованного маршрутизатора;
прибывающее извещение соседнего маршрутизатора (т.е. маршрутизатора, пытающегося установить отношения соседства с маршрутизатором из другого домена маршрутизации) действительно исходит от авторизованного маршрутизатора;
прибывающее сообщение переадресации исходит именно от того маршрутизатора, которому посылался исходный пакет;
прибывающее обновление маршрута не является фальсифицированным.
Если не использовать меры защиты, противник может разорвать связь или направить поток данных в обход по некоторому другому пути. Для защищенных связей между маршрутизаторами, определенных протоколом IPSec, должны поддерживаться протоколы маршрутизации типа OSPF (Open Shortest Path First — первоочередное открытие кратчайших маршрутов).
АРХИТЕКТУРА ЗАЩИТЫ НА УРОВНЕ IP
Спецификации IPSec довольно сложны. Чтобы получить общее представление об архитектуре IPSec, мы начнем с обсуждения документов, определяющих этот протокол. Затем мы исследуем сервисы IPSec и определим понятие защищенных связей.
Документы IPSec
Спецификации IPSec определяются целым рядом документов. Наиболее важными из них, опубликованными в ноябре 1998 года, являются документы RFC с номерами 2401, 2402, 2406 и 2408 (см. приложение 1 в конце книги):
RFC 2401 — обзор архитектуры защиты;
RFC 2402 — описание расширений аутентификации пакетов IPv4 и IPv6;
RFC 2406 — описание расширений шифрования пакетов IPv4 и IPv6;
RFC 2408 — спецификации средств управления ключами.
Поддержка этих возможностей обязательна для IPv6 и допустима, но не обязательна для IPv4. В обоих случаях средства защиты реализуются в виде заголов ков расширений, которые следуют за основным заголовком IP. Заголовок расширения аутентификации называют заголовком АН (Authentication Header — заголовок аутентификации), а заголовок расширения шифрования — заголовком ESP (Encapsulating Security Payioad header — заголовок защищенного полезного груза, или заголовок защищенного содержимого).
В дополнение к этим четырем документам Рабочая группа разработки протокола защиты IP (IP Security Protocol Working Group), созданная IETF, опубликовала еще ряд проектов стандартов. Все документы разделены на следующие семь групп (рис. 6.2).
Архитектура. Содержит описание общих принципов, требований защиты, а также определения и механизмы реализации технологии IPSec.
Защищенный полезный груз (ESP). Описание формата пакета и общих принципов использования ESP для шифрования пакетов и, если нужно, для аутентификации.
Заголовок аутентификации (АН). Описание формата пакета и общих принципов использования АН для аутентификации пакетов.
Алгоритм шифрования. Набор документов, определяющих использование различных алгоритмов шифрования для ESP.
Алгоритм аутентификации. Набор документов, определяющих использование различных алгоритмов аутентификации для АН и для опции аутентификации ESP.
Управление ключами. Документы, описывающие схемы управления ключами.
Область интерпретации (DOI — Domain of Interperetaion). Содержит значения, необходимые для соответствия одних документов другим. Это, в частности, идентификаторы проверенных алгоритмов шифрования и аутентификации, а также некоторые параметры, например, продолжительности жизненного цикла ключей.
Сервис IPSec
IPSec обеспечивает сервис защиты на уровне IP, позволяя системе выбрать необходимые протоколы защиты, определить алгоритм (алгоритмы) для соответствующего сервиса (сервисов) и задать значения любых криптографических ключей, требующихся для запрашиваемого сервиса. Для защиты используется два протокола: протокол аутентификации, указанный заголовком аутентификации АН, и комбинированный протокол шифрования/аутентификации, определенный форматом пакета для протокола ESP. В данном случае обеспечиваются следующие виды сервиса:
управление доступом;
целостность без установки соединений;
аутентификация источника данных;
отторжение воспроизведенных пакетов (форма целостности последовательностей);
конфиденциальность (шифрование);
ограниченная конфиденциальность транспортного потока.
Защищенные связи
Ключевым объектом в механизмах аутентификации и конфиденциальности IP является защищенная связь (Security Association). Связь представляет собой одностороннее отношение между отправителем и получателем, применяющим сервис защиты к транспортному потоку. Если требуется равноправное отношение для двустороннего защищенного обмена, необходимы две защищенные связи. Сервис защиты дает возможность для защищенной связи использовать либо АН, либо ESP, но никак не оба эти протокола одновременно.
Защищенная связь однозначно определяется следующими тремя параметрами.
Индекс параметров защиты. Строка битов, присваиваемая данной защищенной связи и имеющая только локальное значение. Индекс параметров защиты передается в заголовках АН и ESP, чтобы принимающая система имела возможность выбрать защищенную связь, в рамках которой должен обрабатываться принимаемый пакет.
Адрес IP пункта назначения. В настоящее время допускаются только однонаправленные адреса — это адрес пункта назначения защищенной связи, который может представлять систему конечного пользователя или сетевой объект типа брандмауэра или маршрутизатора.
Идентификатор протокола защиты. Этот идентификатор указывает, является ли данная связь защищенной связью АН или это защищенная связь ESP.
Таким образом, в любом пакете IP2 защищенная связь однозначно идентифицируется адресом пункта назначения, указанным в заголовке IPv4 или IPv6, и индексом параметров защиты во вложенном заголовке расширения (АН или ESP).
Параметры защищенной связи
В каждой реализации IPSec имеется номинальная3 таблица защищенных связей (Security Association Database), которая определяет параметры защищенных связей. Защищенная связь характеризуется следующими параметрами.
Счетчик порядкового номера. 32-битовое значение, используемое при генерировании значений поля порядкового номера в заголовках АН или ESP (требуется во всех реализациях).
Флаг переполнения счетчика порядкового номера. Флаг, указывающий на переполнение счетчика порядкового номера, должен генерировать регистрируемое событие и вести к прекращению дальнейшей передачи пакетов с применением этой защищенной связи (требуется во всех реализациях).
Окно защиты от воспроизведения. Используется для выявления воспроизведенных пакетов среди прибывающих пакетов АН или ESP, как описано ниже (требуется во всех реализациях).
Информация АН. Алгоритм аутентификации, ключи, параметры продолжительности жизни ключей и другие необходимые параметры, используемые в рамках АН (требуются в реализациях АН).
Информация ESP. Алгоритм шифрования и аутентификации, ключи, значения инициализации, параметры продолжительности жизни ключей и другие необходимые параметры, используемые в рамках ESP (требуются в реализациях ESP).
Продолжительность жизни данной защищенной связи. Интервал времени или значение счетчика байтов, по достижении которого защищенная связь должна быть заменена новой (с новым индексом параметров защиты) или завершена с указанием того, какое именно из этих событий должно произойти (требуется во всех реализациях).
Режим протокола IPSec. Туннельный, транспортный или задаваемый групповым символом (требуется во всех реализациях). Режимы описаны в этом разделе ниже.
Максимальная единица передачи (Maximum Transmission Unit — MTU) маршрута. Максимальная единица передачи (максимальный размер пакета, который может быть передан без фрагментации) для всех участков маршрута и переменные времени существования (требуются во всех реализациях).
Механизм управления ключами связывается с механизмами аутентификации и конфиденциальности только через индекс параметров защиты. Таким образом, аутентификация и конфиденциальность оказываются определенными независимо от конкретного механизма управления ключами.
Селекторы защищенной связи
IPSec обеспечивает пользователю значительную гибкость в выборе способа применения средств IPSec к трафику IP. Как мы вскоре убедимся, защищенные связи могут комбинироваться, чтобы предоставить пользователю желаемую конфигурацию. Кроме того, IPSec обеспечивает достаточную избирательность, различая трафик, подлежащий защите IPSec, и трафик, которому позволяется обойти IPSec, что достигается путем ассоциации части потока данных IP с имеющимися защищенными связями.
Средством, с помощью которого реализуется ассоциация потока IP с защищенными связями (или отсутствием таковой, если потоку данных позволено обойти IPSec), является номинальная база данных политики защиты (Security Policy Database — SPD). В наиболее простой своей форме база данных политики защиты представляет собой набор записей, каждая из которых определяет некоторое подмножество потока IP и указывает защищенную связь для этого подмножества потока. В более сложных средах может определяться несколько записей, потенциально соответствующих одной защищенной связи, или множество защищенных связей, ассоциируемых с одним элементом базы данных политики защиты. (Более подробную информацию по этому вопросу можно почерпнуть из соответствующих документов IPSec.)
Каждая запись базы данных политики защиты состоит из набора значений полей протокола IP и протоколов более высокого уровня — эти поля называются селекторами. Селекторы используются для фильтрации исходящего потока с целью его отображения в конкретную защищенную связь. Каждый отправляемый пакет IP обрабатывается следующим образом.
Сравниваются значения соответствующих полей пакета (селекторов) с полями базы данных политики защиты и в результате этого находится нужная запись базы данных политики защиты, в которой указано некоторое (возможно, нулевое) число защищенных связей.
Определяется защищенная связь и соответствующий индекс параметров защиты для данного пакета, если защита требуется.
Выполняются необходимые операции IPSec (т.е. обработка АН или ESP).
Запись базы данных политики защиты состоит из следующих селекторов.
Адрес IP пункта назначения. Это может быть один адрес IP, нумерованный список или диапазон адресов, либо группа адресов, задаваемая групповым символом (маской). Последние два варианта предназначены для указания нескольких систем-адресатов, использующих одну защищенную связь.
Адрес IP источника. Это может быть один адрес IP, нумерованный список или диапазон адресов, либо группа адресов, задаваемая групповым символом (маской). Последние два варианта обеспечивают возможность указать несколько систем-источников, использующих одну защищенную связь.
Идентификатор пользователя (UserlD). Идентификатор пользователя, получаемый от операционной системы. Это не поле в заголовке IP или заголовке протокола более высокого уровня, но оно доступно, когда IPSec выполняется в той же операционной системе, с которой работает пользователь.
Уровень (гриф) секретности данных. Предусмотрен для систем, обеспечивающих соответствующую защиту информационного потока (например, секретный или несекретный).
Протокол транспортного уровня. Соответствующая информация берется из протокола IPv4 и поля Next Header (следующий заголовок) IPv6. Это может быть конкретный номер протокола, список номеров протоколов или диапазон номеров протоколов.
Протокол IPSec (АН, или ESP, или АН/ESP). Если присутствует, то взят из протокола IPv4 или из поля Next Header (следующий заголовок) IPv6.
Порты источника и адресата. Это либо конкретные значения портов TCP или UDP, нумерованный список портов, либо порт, представленный групповым символом (wildcard).
Класс IPv6. Соответствующая информация берется из заголовка IPv6. Это может быть конкретное значение для класса IPv6 или значение, задаваемое групповым символом.
Метка потока IPv6. Соответствующая информация берется из заголовка IPv6. Это может быть конкретное значение для метки потока IPv6 или значение, задаваемое групповым символом.
Тип сервиса IPv4 (Type of Service — TOS). Соответствующая информация берется из заголовка IPv4. Это может быть конкретное значение для типа сервиса IPv4 или значение, задаваемое групповым символом.
Транспортный и туннельный режимы
Заголовки АН и ESP поддерживают два режима использования: транспортный и туннельный. Суть этих двух режимов лучше всего понять в контексте описаний заголовков АН и ESP, о которых пойдет речь соответственно в разделах 6.3 и 6.4. Здесь же мы ограничимся кратким определением этих режимов.
Транспортный режим
Транспортный режим обеспечивает защиту прежде всего для протоколов высшего уровня. Это значит, что защита транспортного режима распространяется на полезный груз пакета IP. Примерами могут быть сегменты TCP (Transmission Control Protocol — протокол управления передачей) или UDP (User Datagram Protocol — протокол передачи дейтаграмм пользователя), или же пакет ICMP (Internet Control Message Protocol — протокол управления сообщениями в сети Internet), размещающиеся в стеке протоколов хоста непосредственно над IP. Обычно транспортный режим обеспечивает сквозную связь двух узлов (например, клиента и сервера или двух рабочих станций). Когда система использует заголовки АН или ESP над IPv4, полезным грузом являются данные, обычно размещаемые сразу после заголовка IP. Для IPv6 полезным грузом являются данные, обычно следующие после заголовка IP и всех имеющихся заголовков расширений IPv6, за возможным исключением заголовка параметров адресата, который тоже может подлежать защите.
ESP в транспортном режиме шифрует и, если нужно, аутентифицирует полезный груз IP, но не заголовок IP. АН в транспортном режиме предполагает аутентификацию полезного груза IP и некоторых частей заголовка IP.
Туннельный режим
Туннельный режим обеспечивает защиту всего пакета IP. Чтобы выполнить эту задачу, после добавления к пакету IP полей АН или ESP весь пакет вместе с полями защиты рассматривается как полезный груз некоторого нового "внешнего" пакета IP с новым внешним заголовком IP. Весь оригинальный (внутренний) пакет при этом пересылается через "туннель" от одной точки сети IP к другой, и ни один из маршрутизаторов на пути не может проверить внутренний заголовок IP. Поскольку оригинальный пакет инкапсулирован в новый, больший пакет, этот новый пакет может иметь совершенно другие параметры источника и адресата, что, очевидно, усиливает защиту. Туннельный режим используется тогда, когда один или оба конца защищенной связи являются шлюзами защиты, например, брандмауэрами или маршрутизаторами, использующими IPSec. При использовании туннельного режима размещенные за брандмауэрами системы могут осуществлять защищенный обмен данными без применения IPSec. Незащищенные пакеты, генерируемые такими системами, передаются по туннелям, проложенным через внешние сети с помощью защищенных связей в туннельном режиме, устанавливаемых программным обеспечением IPSec брандмауэра или защищенного маршрутизатора на границе локальной сети.
Рассмотрим пример использования туннельного режима IPSec. Узел А сети генерирует пакет IP с адресом узла назначения В в другой сети. Этот пакет направляется от создавшего пакет узла к брандмауэру или защищенному маршрутизатору на границе сети А. Брандмауэр фильтрует все исходящие пакеты, что бы выяснить, нужно ли их защищать с помощью IPSec. Если направляющийся от А к В пакет требует применения средств IPSec, брандмауэр выполняет функции IPSec и инкапсулирует оригинальный пакет во внешний пакет IP. Адресок IP отправителя этого внешнего пакета IP будет данный брандмауэр, а адресом получателя может быть брандмауэр, формирующий границу локальной сети В. Теперь пакет направляется брандмауэру узла В, а промежуточные маршрутизаторы будут иметь дело только с внешним заголовком IP. В брандмауэре узла В внешний заголовок IP удаляется, а внутренний пакет доставляется узлу В.
ESP в туннельном режиме шифрует и, если нужно, аутентифицирует весь внутренний пакет IP, включая внутренний заголовок IP. АН в туннельном режиме аутентифицирует весь внутренний пакет IP и некоторые части внешнего заголовка IP.
Оперативно-диспетчерское управление защитой информации.
Защита Web.
Защита web-сервера
Собственно Web сервер - это программное обеспечение, осуществляющее взаимодействие по HTTP протоколу с браузерами: прием запросов, поиск указанных файлов и передача их содержимого, запуск CGI-приложений и передача клиенту результатов их выполнения.
Безопасность Web сервера представляет собой лишь небольшой компонент общей системы безопасности хоста Internet. Под словами "взлом сервера" чаще всего подразумевается замена или модификация страниц Web сервера - самое зрелищное проявление атаки на сервер, хотя на самом деле может оказаться лишь побочным продуктом захвата управления всем хостом.
В то же время существуют проблемы безопасности, характерные именно для Web серверов. Воспользовавшись ими, взломщик может получить стартовую площадку для дальнейшего проникновения в систему (поэтому по-прежнему остается в силе рекомендация вынести Web сервер, как и все другие службы, требующие внешнего доступа, на отдельную машину, по возможности изолированную от внутренней сети).
Наряду с обеспечением безопасности программной среды, важнейшим будет вопрос о разграничении доступа к объектам Web-сервиса. Для решения этого вопроса необходимо уяснить, что является объектом, как идентифицируются субъекты и какая модель управления доступом - принудительная или произвольная - применяется.
В Web-серверах объектами доступа выступают универсальные локаторы ресурсов (URL - Uniform (Universal) Resource Locator). За этими локаторами могут стоять различные сущности - HTML-файлы, CGI-процедуры и т.п. Как правило, субъекты доступа идентифицируются по IP-адресам и/или именам компьютеров и областей управления. Кроме того, может использоваться парольная аутентификация пользователей или более сложные схемы, основанные на криптографических технологиях.
В большинстве Web-серверов права разграничиваются с точностью до каталогов (директорий) с применением произвольного управления доступом. Могут предоставляться права на чтение HTML-файлов, выполнение CGI-процедур и т.д. Для раннего выявления попыток нелегального проникновения в Web-сервер важен регулярный анализ регистрационной информации. Разумеется, защита системы, на которой функционирует Web-сервер, должна следовать универсальным рекомендациям, главной из которых является максимальное упрощение. Все ненужные сервисы, файлы, устройства должны быть удалены. Число пользователей, имеющих прямой доступ к серверу, должно быть сведено к минимуму, а их привилегии - упорядочены в соответствии со служебными обязанностями.
Еще один общий принцип состоит в том, чтобы минимизировать объем информации о сервере, которую могут получить пользователи. Многие серверы в случае обращения по имени каталога и отсутствия файла index.HTML в нем, выдают HTML-вариант оглавления каталога. В этом оглавлении могут встретиться имена файлов с исходными текстами CGI-процедур или с иной конфиденциальной информацией. Такого рода "дополнительные возможности" целесообразно отключать, поскольку лишнее знание (злоумышленника) умножает печали (владельца сервера).
Web-сайты представляют собой мощный инструмент, позволяющий коммерческим, правительственным и общественным организациям, а также гражданам обмениваться информацией и вести дела в сети Интернет. По этой же причине они то и дело становятся мишенью злоумышленников...
Большинство организаций, маленьких или больших, уделяя много внимания оформлению своих сайтов, порой пренебрегают основами их безопасного существования. Недавние атаки на Web-сайты показали, что работоспособность серверов может быть нарушена даже в результате перегрузки одного или нескольких сервисов. В данной статье мы обсудим наиболее общие способы защиты, которые организации могут взять на вооружение для предотвращения атак на их серверы или смягчения их последствий.
Если большинство инцидентов вызывают лишь раздражение или неудобство, это не означает, что хакер не сможет причинить компании серьезного ущерба. Поэтому каждая организация должна принять меры по обеспечению безопасности своих ресурсов, оценив при этом уровень рисков и материальных затрат. Другими словами, каждая организация обязана сопоставить возможные потери с теми преимуществами, которые предоставляет возможность выхода в Интернет. В условиях ограниченных финансовых возможностей необходимо вкладывать средства в системы защиты наиболее уязвимых мест сети.
Можно выделить три уровня безопасности для сервера:
Минимальный уровень безопасности.
Модернизация имеющегося программного обеспечения и установка "заплаток".
Использование единых настроек (политик) для всех серверов.
Удаление лишних приложений.
Сопротивление вторжению.
Установка внешнего межсетевого экрана.
Удаленное администрирование систем безопасности.
Ограничения на использование скриптов.
Защита Web-серверов, используя фильтрацию пакетов.
Обучение персонала и разграничение прав доступа.
Использование решений, перечисленных в уровне 1.
Обнаружение атак и ослабление их воздействия.
Разделение привилегий.
Аппаратные системы защиты.
Внутренний межсетевой экран.
Сетевые системы обнаружения вторжений.
Системы обнаружения вторжений, размещаемые на серверах (хостах).
Использование решений, перечисленных в уровне 2.
Варианты обеспечения безопасности Web-серверов Можно выделить следующие, наиболее общие способы защиты Web-серверов:
удаление лишнего программного обеспечения (приложений);
обнаружение попыток нарушения защиты Web-серверов;
исправление изъянов в установленном программном обеспечении;
уменьшение последствий атак на сеть;
защита остальной части сети, в случае если Web-сервер был скомпрометирован.
Немало пользователей размещают серверы Web за брандмауэром во внутренней сети. Такая диспозиция обеспечивает простоту управления, но ценой безопасности. Кроме того, в этом случае работать с сервером защищенным образом становится намного труднее.
Еще один недостаток размещения сервера за брандмауэром состоит в том, что пользователи невольно начинают рассматривать сервер Web как обычный внутренний сервер. Такое отношение недопустимо: сервер Web нуждается в особом внимании, так как он открыт для доступа внешних пользователей, даже если эта открытость и ограничивается HTTP. Восприятие сервера Web как неотъемлемого элемента брандмауэра вырабатывает у администраторов именно такое отношение, какое требуется, - подозрительное до помешательства.
Другая стратегия состоит в размещении сервера Web по другую сторону брандмауэра (в данном случае под брандмауэром понимается шлюз приложений или брандмауэр с контекстной проверкой). Чаще всего между сервером Web и Internet по-прежнему располагается маршрутизатор, с помощью которого сервер Web можно защитить средствами фильтрации пакетов. Так что и в этом случае сервер Web не оказывается полностью беззащитным.
Достоинство такой конфигурации, безусловно, состоит в том, что, даже проникнув на сервер Web, злоумышленник все же остается по внешнюю сторону брандмауэра. При "атаке" на сервер брандмауэр ограничит доступ с сервера во внутрикорпоративную сеть.
С другой стороны, администрировать сервер Web становится намного труднее, поскольку доступ к нему оказывается в значительной мере затруднен - теперь между администратором и сервером Web находится брандмауэр. Кроме того, конфиденциальная информация оказывается как бы "за дверью" - за пределами внутренней сети. Допустим, сервер Web находился под охраной брандмауэра, и пользователи работали с ним, как с обычным сервером базы данных, и размещали на нем конфиденциальные данные, которые имеющие на то надлежащие права пользователи Web могли просматривать контролируемым образом. Теперь же сервер со всеми закрытыми данными надо вынести наружу.
Кому такое понравится? Смысл брандмауэров и состоит в том, чтобы защитить критически важные данные и внутреннюю сеть по периметру. Теперь эти данные оказываются "за оградой" и защищены только маршрутизатором. Стоит лишь кому-нибудь проникнуть на сервер - и все хранящиеся на нем сведения станут известны посторонним людям. Впрочем, следует отметить, что то же самое произойдет и в том случае, если удастся атака на защищенный брандмауэром сервер Web.
Выход может быть только один - критически важные данные не следует хранить на сервере Web. Лучше разместить их на внутреннем сервере базы данных. Тогда можно создать многоуровневую систему защиты на основе сценариев CGI или других механизмов сервера Web, с помощью которых он обрабатывает запросы от внешних пользователей и передает их на внутренний сервер базы данных. Внутренний сервер способен проверить полномочия подающего запрос и предоставить ему ограниченную выборку закрытых данных. В этом случае сервер Web действует как клиент базы данных, используя средства удаленной идентификации пользователей (имя и пароль, например) для получения доступа к определенной части базы данных.
Брандмауэр позволит серверу Web обратиться только к серверу базы данных, но ни к каким другим внутренним ресурсам. Если даже злоумышленник проникнет на открытый сервер Web, единственной лазейкой во внутреннюю сеть для него остается сервер базы данных, а он имеет собственную защиту.
Вместо того чтобы выставлять сервер Web на всеобщее обозрение под ненадежной защитой маршрутизатора, можно выбрать компромиссный вариант. Сервер Web можно расположить в экранированной подсети, или "демилитаризованной зоне", т. е. фактически брандмауэр будет обслуживать три сети. В результате брандмауэр будет защищать и сервер Web, и внутреннюю сеть.
В такой конфигурации брандмауэр пропускает из Internet на сервер только трафик HTTP (и, возможно, S/HTTP). Кроме того, он контролирует доступ сервера Web во внутреннюю сеть, ограничивая его внутренними серверами баз данных. В дополнение к этому, внутренним пользователям следует разрешить доступ к серверу Web для тестирования.
Несмотря на все достоинства, этот подход имеет свои "подводные камни". Как пользователи внутренней сети будут администрировать сервер Web? Он по-прежнему остается лакомым кусочком для злоумышленников и нуждается в очень тщательном администрировании. Если администраторы Web станут относиться к нему так же, как к внутреннему серверу, - жди неприятностей.
Общедоступные серверы Web нужно конфигурировать как неприступные хосты (форт-хосты): все ненужные службы программного обеспечения с них следует удалить. В идеале на сервере должно остаться только необходимое ПО, и ничего более. Так, систему UNIX вполне можно настроить как форт-хост: при этом она будет содержать менее 100 файлов, без учета документов и сценариев. Все прочее программное обеспечение следует удалить, а лучше вообще не устанавливать. Если удалять ненужное ПО не хочется, то по крайней мере необходимо блокировать те сетевые сервисы, которые не требуются серверу Web для выполнения его непосредственных функций.
Необходимо убедиться, что сервер Web допускает удаленное администрирование. Для безопасного удаленного администрирования рекомендуется использовать шифруемое соединение, организовать которое можно с помощью защищенного программного обеспечения telnet или Secure Shell (SSH). Еще один принцип форт-хоста - сокращение до минимума числа пользовательских бюджетов. В идеале их вообще не должно быть, за исключением бюджетов системного администратора и мастера Web. Чем меньше в системе пользователей, тем меньше вероятность того, что кто-то из них сделает ошибку и откроет лазейку для злоумышленников.
Еще большей защищенности можно добиться, исключив необходимость человеческого вмешательства и автоматизировав администрирование общедоступного сервера Web. Невозможно? Это и так, и не так. Систему следует настроить таким образом, чтобы администраторы Web работали с внутренними серверами Web. Все изменения, сделанные на внутреннем сервере, затем нужно перенести на внешний, общедоступный сервер Web. В принципе, это можно сделать с помощью протокола совместного использования файлов, таких как Microsoft Server Message Block или Unix Network File System. Однако подобные протоколы не гарантируют защиты, и пользоваться ими не следует.
Вместо этого рекомендуется воспользоваться программным обеспечением зеркального копирования: оно обновит общедоступный сервер Web и перенесет все изменения, проделанные на внутреннем сервере. Для этого ни пользовательских, ни административных бюджетов не требуется, так как программное обеспечение зеркального копирования может зарегистрироваться на общедоступном сервере Web как самостоятельный объект.
Одно из преимуществ данного подхода состоит в том, что вы получаете оперативную резервную копию открытого сервера Web. Кроме того, перед перенесением изменений их можно протестировать. В отношении внутреннего сервера Web не требуется принимать таких строгих мер защиты, как в отношении общедоступного сервера, поэтому администраторам Web будет немного проще получить к нему доступ. Нежелательно, однако, чтобы в систему было легко проникнуть изнутри. Ее по-прежнему требуется защитить от внутренних атак. Здесь можно воспользоваться программным обеспечением контроля версий для данных на сервере Web. Оно позволяет определить, кто производил изменения, и обеспечивает возможность отката.
Windows NT приобрела популярность в качестве платформы сервера Web (в особенности для сетей Intranet), но не по заслугам. Считается, что администрировать NT проще, чем серверы UNIX аналогичного масштаба, и это в определенной степени верно. Другие особенности серверов NT, такие как аутентификация доменов и возможности совместного использования файлов, также привлекают внимание администраторов к этой ОС. И все же, сколь бы весомыми ни были соображения в пользу выбора NT в качестве сервера Web, все они ничего не стоят по сравнению с недостатками защиты.
Большинство администраторов Web до сих пор даже не знают, каким собственно образом злоумышленники атакуют их серверы. Сообщество пользователей UNIX уже накопило достаточный опыт для противодействия нападениям и укрепления своих систем. У адептов Microsoft такого опыта пока нет.
Метод форт-хоста предполагает укрепление сервера посредством удаления ненужных пользовательских бюджетов и сервисов. В случае сервера Web на базе NT его функции лучше всего ограничить только функциями сервера Web. При активном использовании эти функции отнимают столько ресурсов, что отказ от обслуживания других пользователей или предоставления сервисов не окажется непроизводительным разбазариванием ресурсов.
Принцип форт-хоста предполагает также отказ от сетевых пользовательских бюджетов. Все бюджеты должны быть локальными: они предназначаются для администрирования Web. Решение об открытии сетевых бюджетов для администраторов Web на Web-сервере Intranet зависит исключительно от важности хранимой на нем информации.
На сервере NT в сети Intranet можно использовать фильтрацию пакетов. NT поддерживает простейшую фильтрацию пакетов, настроить которую можно посредством выбора закладки Protocols в апплете Network, в Control Panel.
Чем надежнее фильтрация пакетов, тем лучше защита. Например, сервер Web получает запросы через порт 80. Разрешив фильтру TCP пропускать только пакеты, адресованные этому порту, администратор тем самым запрещает использование всех других прикладных протоколов TCP/IP. Кроме того, он может, например, открыть порт 443 для протокола Secure Socket Layer (SSL). Теперь фильтр пакетов будет разрешать установку только соединений через порты 80 и 443. При этом исходящие соединения он никак не будет ограничивать.
Защита
web-приложений
Еще
некоторое время назад, когда для работы
в Web активно использовался HTML, защита
серверов сводилась к установке каскадов
пакетных фильтров. Ситуация изменилась
тогда, когда для построения ресурсов
активно стали использовать скрипты и
базы данных. Пакетный фильтр невосприимчив
к содержимому запроса, поэтому он
пропустит и запрос межсайтового
скриптинга и инжекции кода SQL. Решить
данную проблему могут брандмауэры для
web- приложений.
Н
есмотря
на активное использование приложений
в Web, их безопасности уделяется недостаточно
внимания. Вся система защиты сводится
к рассредоточению: внешний сервер,
сервер web-приложений, сервер базы данных,
— все они находятся в разных зонах.
Компоненты, используемые в разных зонах,
имеют укрепленную операционную систему
и хорошо сконфигурированы. В этом случае,
если злоумышленнику и получается
проникнуть на один из компонентов, то
ущерб ограничен этим компонентом, т.к.
между компонентами открыты исключительно
те порты, которые необходимы для
выполнения возложенной на них функции
(рис. 1). Но, как я и говорил, многоступенчатые
фильтры не принесут защиты от содержимого
запроса. В случае приложений, работающих
по технологии клиент-сервер, клиентская
часть устанавливается на пользовательскую
машину. При использовании web- приложений
часть приложения загружается на машину
пользователя, поэтому исследовать
исходный код может кто угодно, собственно,
сформировать необходимый запрос по
результату исследования может тоже кто
угодно. Web-приложения состоят из трех
частей: представления, логики и данных.
Уровень представления, получив запрос,
передает его на уровень логики, который
начинает обрабатывать запрос (возможно,
с привлечением уровня данных), после
чего передает результат снова на уровень
представления. На каждую из трех частей
атака может проводиться независимо.
Уровень данных представляет собой
хранилище информации и может опрашиваться
логическим уровнем (рис. 2). Любой
пользователь, в принципе, может запускать
скрипт со своими параметрами. Для этого
достаточно отправить на сервер специально
сформированный запрос. Приведу пример
такого запроса, в адресной строке пишется
следующее:
httр://www.sa-sec.org/test.php?id=23&format=html.
Файл
test.php выполняется на удаленном сервере
включая параметры справа от знака
вопроса. Если test.php представить в качестве
исполняемого файла для Windows (test.exe), то
результат оказался бы таким:
C:\
test.exe /id:23/fоrmat: html
Э
то
типичный межсайтовый скриптинг, о
котором, помнится, я уже писал на страницах
КГ. Защитой от такого рода атак может
быть хороший программинг под Web — для
этого разработчик должен хорошо проверить
имена и значения параметров. Конечно,
на практике до этого не доходит. Вдобавок
полностью игнорируются многочисленные
элементы: идентификационные маркеры
(Cookie), заголовок HTTP, информация о сеансе
в URL, скрытые поля в исходном тексте и
т.д. Поскольку протокол HTTP не содержит
никакой информации о статусе пользователя,
злоумышленник — в зависимости от
приложения — может, к примеру, путем
изменения маркера (Cookiе Poisoning, Cookie
Stealing) или информации о сеансе в URL получить
доступ к открытому сеансу другого
пользователя и тем самым к его данным
без имени и пароля. Изменение значений
скрытых полей в исходном тексте также
не представляет труда. Задачу упрощают
так называемые "посредники перехвата",
работающие на компьютере злоумышленника
и заметно упрощающие манипуляции с
перечисленными параметрами. Таким
образом, для разработки надежного
приложения программист должен исходить
из того, что злоумышленник в состоянии
манипулировать любыми значениями.
Дополнительно необходимо проверить
поля ввода на наличие специальных
символов и сценариев, поскольку они —
если достигнут сервера баз данных —
могут вызвать запуск специальных функций
или обеспечить доступ к оболочке через
внешнюю программу. Так, простая кавычка
(') в комбинации с командами SQL в поле
ввода способна привести к нежелательным
действиям с внутренней базой данных.
Еще одним возможным сценарием является
атака, когда некорректные данные
представлены в зашифрованной форме.
Если злоумышленник запускает сценарий
на стороне клиента (Cross-Site Scripting),
специальные символы будут интерпретированы
еще позже, когда их выведет, интерпретирует
и выполнит браузер ничего не подозревающего
пользователя. Для защиты от переполнения
буфера должна выполняться проверка
длины. Итак, программист должен, с одной
стороны, проверять, не манипулировал
ли злоумышленник параметрами, заданными
приложениями Web, а с другой — не содержат
ли поля ввода неразрешенных данных: к
примеру, инжекций SQL или команд, сценариев
для выполнения на стороне клиента или
переполнения буфера.
К
омпании
не должны полагаться на сторонних
разработчиков в том, что последние будут
использовать надежное программирование.
Большинство учитывают некоторые из
общих рекомендаций, и то весьма
поверхностно. Посему и приложения на
выходе не отвечают всем требованиям
безопасности. К тому же, надежное
программирование достаточно сложно,
а, следовательно, дорого. В любом случае
приложение должно адекватно обрабатывать
"мирные запросы". Это значит, что,
допустим, апостроф в имени пользователя
S'nams не должен распознаваться как попытка
провести инжекцию SQL (рис. 5). Поэтому
каждый раз значение поля следует
обрабатывать индивидуально. При покупке
готовых приложений компании должны
проводить обязательный аудит кода для
поиска и устранения потенциально опасных
мест, иначе это может вылиться в весьма
неприятное положение дел со всеми
вытекающими последствиями. Альтернативой
данному методу является использование
брандмауэров для web-приложений (Web
Application Firewall — WAF). Такого рода брандмауэр
устанавливается перед web-приложением
и предоставляет гораздо более расширенные
возможности, нежели обычные программные
брандмауэры для системы. Отличие от
классической технологии заключается
в том, что WAF интерпретирует защищаемые
приложения Web с их отдельными страницами,
полями ввода, значениями параметров и
маркерами Cookie. WAF в состоянии контролировать
все объекты, которые могут быть доступны
пользователям, вводимые URL, а также
параметры запросов GET и POST. Допускается
возможность только тех URL, которые могут
принадлежать тому или другому объекту.
Также брандмауэр не позволяет пользователям
запускать не относящиеся к ресурсу
объекты — например, логи или системные
журналы на сервере. Следует контролировать
отклики, т.к. в них может содержаться
описание ошибки — это описание может
содержать достаточно важную информацию.
Заголовок сервера, где в стандартной
конфигурации сервера Web указан тип
сервера (к примеру, сервер: Apache 2.0.54
(UNIX), mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev),
переписывается в отклике большинства
WAF, чтобы злоумышленник не мог получить
этих сведений таким простым
способом.
Возможны два подхода к
решениям обеспечения безопасности —
в соответствии с положительной и
отрицательной логикой безопасности. В
последнем случае определяется лишь то,
что запрещено — все остальное разрешено,
как, например, в антивирусном сканере.
WAF снабжаются заранее составленными
черными списками, содержащими схемы
распространенных типов атак. Тем самым
обеспечивается защита от многих известных
атак, базирующихся на этих схемах,
поэтому нет необходимости в знании и
конфигурировании всех параметров.
Чрезвычайно важная функция — исключение
отдельных полей ввода перед проверкой
для предотвращения неверных положительных
распознаваний. В некоторых приложениях
Web — к примеру, в техническом дискуссионном
форуме — при определенных обстоятельствах
может понадобиться разрешение возможности
ввода кодов HTML или сценариев. Положительная,
известная также как белый список, логика
предполагает определение того, что
можно — все остальное запрещено. Хотя
это и означает значительные издержки
на конфигурацию, но в результате
обеспечивается существенно более
последовательная защита, в том числе
от неизвестных типов атак. WAF должен
поддерживать комбинацию обоих типов
логики. И наиболее эффективен WAF тогда,
когда может соответствующим образом
интерпретировать приложение Web, т.е.
положительная логика преобладает.
Основой этого является создание свода
правил — так называемой политики.
Возможны два подхода: динамический и
статический. При динамическом администратор
определяет действительные страницы
входа и работу WAF в реальном времени.
Для каждой запрошенной пользователем
страницы содержащиеся в коде HTML ссылки
включая определенные в URI величины
добавляются в динамически создаваемое
правило. К сожалению, для более сложных
приложений, когда на стороне клиента
используется JavaScript, эту функцию часто
нельзя осмысленно применять, потому
что JavaScript позволяет генерировать на
клиенте вызываемый URL с передаваемыми
параметрами. Как следствие администратор
должен определять эти URL как исключение
— причем речь идет лишь об одном из
нескольких примеров, когда JavaScript на
клиенте в случае динамического варианта
вызывает проблемы. Поэтому наиболее
распространен статический вариант. При
статическом подходе администратор
создает правило до применения WAF. Этим
процессом можно управлять вручную или
автоматизировать при помощи определенных
инструментов. Например, WAF можно прозрачно
включить в поток данных для предварительного
протоколирования трафика. На основании
полученных данных администратор путем
ввода надежных IP-адресов или их диапазонов
и определения промежутка времени может
описать в политике все варианты
разрешенного доступа. Еще одним
инструментом является "крот"
(crawler). Он должен начиная с некоторой
стартовой страницы автоматически
отследить все ссылки и за короткое время
составить список всех URL включая поля
ввода, статичные значения пунктов
списка, селективные кнопки и перечни
выбора, на основании которых можно будет
сформировать политику. Важная функция
— анализ "кротом" JavaScript.
Д
ополнительно
должна быть предусмотрена возможность
определения пути навигации, по которому
может быть вызвана указанная страница.
Если, к примеру, задано, что страница
z.html должна быть достижимой лишь после
того, как пользователь запросил сначала
страницу x.html, а потом y.html, то WAF блокирует
запрос непосредственно к z.html. В этом
случае говорят о "потоках", для
которых определяются объекты отправителя
и получателя. Ряд производителей
предлагают собственный браузер для
тонкой настройки, который также
оказывается полезен при формировании
политики. Поскольку правило не должно
генерироваться динамически, статический
подход значительно более производителен.
Проверка того, было ли статическое
значение в запросе HTTP несанкционированно
изменено, для большинства WAF не представляет
проблемы. Однако при использовании
статического подхода WAF должны защищать
также от изменений динамических значений,
генерируемых на сервере. Это динамическое
значение, генерируемое приложением во
время выполнения, встречается, к примеру,
в URL или в скрытых полях. Злоумышленник
может просто изменить его и отправить
в следующем запросе HTTP приложению Web. В
результате, к примеру, товар будет
помещен в корзину покупателя по более
низкой цене (рис. 3). Другие приложения
для однозначной идентификации пользователя
применяют идентификаторы сеанса, которые
генерируются на сервере в качестве
динамических параметров. Если
злоумышленнику удается добраться до
идентификатора сеанса другого
пользователя, он получает доступ к
пользовательскому сеансу и тем самым
к его данным без знания имени пользователя
и пароля. Для защиты ландшафта ИТ можно
настроить WAF таким образом, чтобы он, к
примеру, удалял этот динамический
параметр из отклика.
Е
ще
одна важная задача WAF — проверка маркеров
Cookie. WAF должен предотвращать попадание
в приложение Web модифицированных
пользователем маркеров (Cookie Poisoning). Если
злоумышленнику удастся это сделать, не
исключено, что он, как и в предыдущем
примере с идентификатором сеанса,
попытается получить доступ к сеансу
другого пользователя. Одним из вариантов
проверки в WAF является помещение
зашифрованных и подписанных имен и
содержимого всех маркеров пользователя
в дополнительном сеансовом маркере,
который имеется только в памяти у
клиента. Если маркеры передаются
браузером приложению, как это происходит
в случае каждого запроса HTTP, WAF посредством
дополнительного сеансового маркера
распознает, изменил ли злоумышленник
один или несколько маркеров. К сожалению,
некоторые приложения меняют содержимое
маркеров и на стороне клиента. Поэтому
важно, чтобы маркеры таких приложений
могли исключаться перед проверкой.
Другой вариант — шифровать все маркеры
приложений. При этом, как описано выше,
отдельные маркеры могут перед шифрованием
исключаться. Когда приложение изменяет
на клиенте содержимое отдельного
маркера, оно должно быть представлено
открытым текстом. Большинство WAF работают
в качестве обратного посредника. Они
принимают от клиента запрос HTTP вместо
сервера Web или балансировщика нагрузки,
анализируют его соответствие политике
и организуют новое соединение HTTP,
наделенное собственным IP-адресом, с
сервером Web или балансировщиком нагрузки
(рис. 4).
Поэтому для регистрации
IP-адресов отправителя на сервере Web
необходимо, чтобы WAF мог передавать
дальше исходный IP-адрес клиента, к
примеру, в заголовке X-Forwarded-For-Header (XFF).
Терминирование SSL и аппаратное ускорение
шифрования и дешифрования включая
согласование ключа должно поддерживаться
в любом фильтре приложений, иначе анализу
оказываются доступны только незашифрованные
данные. Пассивный режим мониторинга,
когда запросы злоумышленника не
блокируют, а только отмечаются в отчетах,
полезен не только при вводе в эксплуатацию,
но и в случае высокочувствительных
приложений. Тем самым остается по крайней
мере возможность получения информации
обо всех атаках на приложение Web и сервер
Web без прерывания работы приложения.
Календарно-плановое руководство защитой информации.
Планирование защиты информации.