Сетевая инфраструктура играет весьма важную роль в обеспечении безопасности web-сервера. В большинстве конфигураций сетевая инфраструктура является первой линией обороны между Интернетом и web-сервером. Хотя на создание той или иной сетевой инфраструктуры влияют многие факторы, отличные от проблем, связанных с безопасностью (такие как цена, производительность и надежность), мы в основном будем рассматривать проблемы, относящиеся к безопасности.
Сеть, которая разрабатывалась без учета требований обеспечения безопасности web-сервера, может иметь серьезные уязвимости для его безопасности. Частота, изощренность и разнообразие web-атак, осуществляемых сегодня, говорят о том, что безопасность web должна обеспечиваться с помощью многоуровневых и распределенных механизмов обороны (так называемая "оборона вглубь"). Обсудим сетевые компоненты, которые могут поддерживать и защищать web-серверы с целью соответствующего усиления безопасности.
Топология сети
Существует много вариантов создания топологии сети, и безопасность может быть не главным фактором при принятии решений. Топология сети является первым и во многих аспектах наиболее критичным сетевым решением, которое воздействует на безопасность web-сервера. Она важна по нескольким причинам. Топология сети определяет, какая сетевая инфраструктура может быть использована для защиты web-сервера. Например, если web-сервер расположен позади firewall’а организации, то firewall может использоваться для контроля входящего и исходящего трафика во внутреннюю сеть и web-сервер. Топология сети также определяет, какие участки сети окажутся уязвимыми, если web-сервер будет скомпрометирован. Например, если web-сервер размещен во внутренней производственной сети, то внутренняя сеть может быть подвергнута атаке со стороны скомпрометированного web-сервера. Организация может принять решение не размещать web-сервер в своей сети, а разместить его в сторонней организации.
Иногда принимается решение о размещении публичных web-серверов во внутренних производственных сетях, где расположены их внутренние серверы и рабочие станции пользователей. Такое расположение не рекомендуется, потому что при этом существует неоправданный риск компрометации внутренней сети. Принципиально слабым местом такой конфигурации является то, что web-серверы часто являются целью атакующих. Если удастся скомпрометировать web-сервер, атакующие окажутся во внутренней сети и могут легко скомпрометировать внутренние хосты.
Также не рекомендуется располагать web-сервер перед firewall’ом организации или роутером, который осуществляет IP-фильтрацию. При таком типе конфигурации сеть может обеспечивать меньшую, чем необходимо, защиту web-сервера. Вся безопасность зависит только от самого web-сервера, который представляет собой единственную точку падения. Даже если при такой топологии и задействовать существенные меры обеспечения безопасности, все равно ОС, на которой выполняется web-сервер, должна быть достаточно укрепленной (все ненужные и небезопасные сервисы запрещены) и полностью применены необходимые patches безопасности, а 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-сервера в третьей организации (например, в Internet Service Provider – ISP). В этом случае web-сервер не размещается в сети организации. ISP имеет выделенную сеть, обслуживающую много web-серверов (для многих организаций), которые выполняются в одной сети.
Преимущества хостинга во внешней организации с точки зрения безопасности:
DoS-атаки, направленные на web-сервер, не воздействуют на сеть предприятия.
Компрометация web-сервера не представляет непосредственной угрозы внутренней сети предприятия.
Внешняя организация может лучше разбираться в безопасности и лучше защитит web-сервер.
Сеть может быть оптимизирована исключительно для поддержки и защиты web-серверов.
Недостатки хостинга во внешней организации с точки зрения безопасности:
Требуется доверие к третьей стороне в отношении содержимого web-сервера.
Трудно удаленно администрировать web-сервер или удаленно изменять содержимое web-сервера.
Может быть предоставлен меньший контроль за безопасностью web-сервера.
На web-сервер могут влиять атаки, направленные на другие web-сервера, которые размещены в той же самой сети.
Внешний хостинг предпочтительней для небольших организаций, которые не могут позволить себе иметь необходимых экспертов для поддержки web-сервера. Это возможно также для больших организаций, которые не хотят поддерживать свой собственный web-сервер, но неприемлемо для организаций, которые хотят иметь жесткий контроль за web-сервером.
Сетевые элементы
После того как web-сервер размещен в сети, следует сконфигурировать элементы сетевой инфраструктуры для поддержки и защиты web-сервера. Элементами сетевой инфраструктуры, которые влияют на безопасность web-сервера, являются firewall’ы, роутеры, системы обнаружения проникновения и сетевые коммутаторы (switch). Каждый из них играет важную роль для защиты web-сервера при обеспечении многоуровневой обороны. К сожалению, при обеспечении безопасности web-сервера не существует универсального решения. Единичный firewall или IDS не может обеспечить адекватную защиту публичного 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’а и лежащей в основе ОС.
Системы обнаружения проникновения (IDS)
IDS является приложением, которое просматривает системные и сетевые ресурсы и анализирует различные виды деятельности, а также, используя информацию, полученную из этих источников, уведомляет сетевого администратора и/или соответствующий персонал, отвечающий за безопасность, о возможном проникновении или попытки взлома. Два основных типами IDS: host-based и network-based.
Сетевые коммутаторы и концентраторы
Сетевые коммутаторы являются устройствами, которые обеспечивают соединение между двумя или более хостами, расположенными в одном сетевом сегменте. Они аналогичны концентраторам (hub) в том, что обслуживают коммуникации между хостами, но, в отличие от концентраторов, коммутаторы более "интеллектуальны" и посылают пакеты только тому хосту, для которого эти пакеты предназначены. Тем самым коммутаторы изолируют хосты в сетевом сегменте друг от друга. Такая изоляция может иметь преимущества в уменьшении воздействия DoS-атаки на другие хосты в сети.
При использовании коммутаторов труднее просматривать взаимодействия между различными хостами в данном сегменте сети. Это преимущество особенно важно, когда web-сервер расположен в сегменте сети, в котором также расположены и другие хосты. Например, если используется концентратор и web-сервер скомпрометирован, атакующий может иметь возможность подсмотреть взаимодействие других хостов, что может привести к компрометации этих хостов или информации, которую они посылают по сети. E-mail серверы часто расположены вместе с web-серверами и в конфигурации по умолчанию принимают незашифрованные пароли. В таком случае компрометация web-сервера приводит к компрометации почтового сервера, независимо от того, используется коммутатор или нет. Коммутатор предотвращает или, по крайней мере, затрудняет для атакующего перехват паролей почтового сервера с использованием скомпрометированного web-сервера, если эти серверы расположены на разных хостах.
Многие коммутаторы имеют специфические настройки безопасности, которые еще больше усиливают безопасность сети, затрудняя "разрушение" коммутатора. Некоторые примеры включают возможность минимизировать риск от атак на протокол ARP.
Список действий для обеспечения безопасности сетевой инфраструктуры
Расположение сети.
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-сервера. Запись соответствующих данных и последующий просмотр и анализ этих логов — это важная деятельность. Просмотр логов 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-сервер поддерживает возможность расширения программ, скриптов или plug-ins, web-администратор должен иметь возможность определить специфичные данные логов, которые должны записываться в соответствии с функционированием этих возможностей. Если разработаны специальные программы, скрипты или plug-ins, рекомендуется, чтобы был определен и реализован согласованный и легко понимаемый подход к созданию логов, основанный на механизмах создания логов и предоставляемый ОС и web-сервером. Информация в логах, связанная с программами, скриптами и plug-ins, может быть добавлена к обычной информации, хранящейся в логах web-сервера.
Возможные параметры логов
Логи, созданные со следующими параметрами, можно считать оптимальными для первоначального использования:
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-сервера поддерживает такую возможность).
Просмотр и хранение лог-файлов
Просмотр лог-файлов может быть трудоемким и занимать много времени. Лог-файлы являются реагирующей мерой безопасности; они информируют о событиях, которые уже произошли. Соответственно, они часто бывают полезны для поддержки других доказательств, таких как аномальный сетевой трафик, обнаруженный IDS. Логи web-сервера должны также просматриваться для обнаружения атак. Частота просмотра зависит от следующих факторов:
трафик, получаемый сервером;
общий уровень угроз (федеральное правительство и крупные коммерческие организации намного больше подвержены атакам, чем сайты других фирм и, таким образом, должны просматривать свои логи более часто);
специфические угрозы (могут возникать угрозы, специфичные для определенного времени, что требует более частого анализа лог-файла);
уязвимость web-сервера;
значимость (ценность) данных и сервисов, предоставляемых web-сервером.
Для облегчения анализа логов разработаны специальные автоматизированные средства.
Кроме того, обычно бывает необходим более глубокий и более продолжительный анализ логов. Так как типичная web-атака может включать сотни web-запросов, атакующий может попытаться замаскировать атаку увеличением интервала между запросами. В этом случае просмотр одних ежедневных или еженедельных логов может не показать общей тенденции. Однако, когда тенденция анализируется в течение недели, месяца или квартала, многие атаки на один и тот же хост могут быть легко обнаружены.
Лог-файлы должны быть защищены для гарантирования того, что атакующий, который скомпрометировал web-сервер, не может изменить лог-файлы, чтобы скрыть свои действия. Хотя шифрование и может использоваться для защиты лог-файлов, лучшим решением является хранение лог-файлов на отдельном от web-сервера хосте. Он часто называется лог- или syslog-хостом.
Необходимо регулярно создавать back up и архивы лог-файлов. Периодическое архивирование лог-файлов существенно по нескольким причинам. Оно может быть важно с точки зрения законодательных действий или использоваться при возникновении различных проблем, связанных с web-сервером. Периодичность архивации лог-файлов зависит от нескольких факторов, включающих следующие:
законодательные требования;
организационные требования;
размер логов (который напрямую зависит от трафика сайта и параметров создания логов );
значимость (ценность) данных web-сервера и сервисов;
уровень угроз.
Автоматизированные инструментальные средства анализа лог-файлов
Большинство web-серверов имеют большой трафик, и лог-файлы быстро становятся огромными. Для облегчения работы web-администратора необходимо использовать одно или более автоматизированное средство анализа лог-файлов. Эти средства анализируют записи в лог-файле и идентифицируют подозрительную или необычную деятельность.
Доступно большое количество коммерческих и свободно распространяемых средств, обеспечивающих регулярный анализ Transfer Log. Большинство выполняется для Common или Combined Log Format.
Такие средства могут идентифицировать IP-адреса, которые являются источником большого числа соединений или большого объема трафика.
Средства Error Log определяют не только ошибки, которые могут существовать в конкретном web-содержимом (такие как отсутствующие файлы), но также попытки доступа к несуществующим URL. Эти попытки могут указывать на следующее:
зондирование на наличие определенных уязвимостей, которые могут быть использованы позднее для осуществления атаки;
сбор информации;
интерес к конкретному содержимому, такому как базы данных.
Автоматизированный анализатор лог-файла должен как можно быстрее сообщить о любых подозрительных событиях в лог-файле web-администратору.
Процедуры создания backup web-сервера
Одна из наиболее важных функций администратора web-сервера — поддержка целостности данных на web-сервере. Это жизненно важно, потому что web-сервер часто является наиболее незащищенным сервером в сети организации и, таким образом, часто наиболее чувствительным к враждебным действиям и возможным падениям ПО и аппаратуры. Существуют два принципиальных компонента для выполнения backup’а данных для web-сервера: регулярный backup данных и всей системы и поддержка защищенной, аутентичной, отдельно хранящейся копии содержимого 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’а.
Поддержка тестового web-сервера
Большинство организаций поддерживают тестовый или развиваемый web-сервер. Идеально, чтобы данный сервер имел аппаратуру и ПО, идентичную основному web-серверу, и был размещен во внутреннем сегменте сети (Интранет), где он может быть полностью защищен обороной периметра. Хотя цена поддержки дополнительного web-сервера может быть значительной, наличие тестового сервера часто обеспечивает значительные преимущества.
Обеспечивается платформа для тестирования новых patches до применения их к производственному web-серверу.
Обеспечивается платформа для разработки и тестирования нового содержимого и новых приложений.
ПО, которое является необходимым для разработки и тестирования, но может представлять собой неприемлемый риск безопасности, если оно развернуто на производственном сервере, может быть установлено на тестовый сервер (например, компиляторы, инструментальные средства администрирования, ПО удаленного доступа).
Замечание: тестовый web-сервер должен быть отделен от сервера, который содержит аутентичную копию содержимого производственного web-сервера.
Поддержка аутентичной копии web-содержимого
Следует поддерживать аутентичную (проверенную, доверяемую) копию web-содержимого на хосте, который не доступен из Интернета. Это дополняет, но не заменяет соответствующую политику backup’а. Например, в отношении статических web-сайтов это должна быть простая копия web-сайта на устройстве только для чтения (CD-R). Аутентичная копия web-сайта должна поддерживаться на безопасном хосте. Такой хост обычно расположен позади firewall’а во внутренней сети, а не в DMZ. Цель создания аутентичной копии состоит в том, чтобы предоставить способы восстановления информации на web-сайте, если он был скомпрометирован в результате случайных или преднамеренных действий. Аутентичная копия web-сайта позволяет быстро восстановить изуродованный web-сайт.
Для успешного выполнения данной цели должны быть выполнены следующие требования:
Защита аутентичной копии от неавторизованного доступа. Следует:
использовать устройства, которые допускают только однократную запись (подходит для относительно статичных web-сайтов);
размещать хост с аутентичной копией позади firewall’а и гарантировать, что к хосту не существует доступа извне;
минимизировать количество пользователей, которые имеют доступ к хосту;
управлять доступом пользователей максимально точным способом;
обеспечить строгую аутентификацию пользователей;
развернуть соответствующие процедуры создания логов и мониторинга;
предусмотреть дополнительные аутентичные копии в различных физических местах для обеспечения большей защиты.
Установить соответствующие процедуры обновления аутентичных копий:
выполнять обновление аутентичной копии первым (любое тестирование кода должно выполняться перед обновлением аутентичной копии);
установить политику и процедуры, определяющие, кто может выполнять обновление, когда может выполняться обновление и т.п.
Установить процесс копирования аутентичной копии на производственный web-сервер:
данные могут передаваться с использованием физически безопасной среды (например, шифрование и/или устройства только однократной записи, такие как CD-R);
использовать безопасный протокол (например, SSH) для передач по сети.
Включить процедуры восстановления с аутентичной копии в организационные процедуры реакции на инцидент.
Восстановление при компрометации безопасности
Большинство организаций при определенных обстоятельствах сталкиваются с успешной компрометацией одного или более хостов в своей сети. Первый шаг при восстановлении состоит в создании и документировании требуемых политик и процедур в ответ на успешное вторжение до осуществления самого вторжения. Ответные процедуры должны очерчивать действия, которые требуются в ответ на успешную компрометацию web-сайта, и соответствующую последовательность этих действий (последовательность может быть критически важной). Эти процедуры должны содержаться в политике безопасности организации.
Web-администраторы должны выполнить следующие шаги при определении успешной компрометации:
Сообщить об инциденте.
Просмотреть политику безопасности организации.
Изолировать скомпрометированную систему(ы) и выполнить шаги по сохранению следов атаки, чтобы могли быть собраны дополнительные доказательства.
Исследовать другие "аналогичные" хосты (в том же самом диапазоне адресов, имеющие те же или аналогичные пароли, разделяющие отношение доверия и имеющие ту же ОС и приложения) для определения того, не скомпрометировал ли атакующий и другие системы.
Просмотреть соответствующее законодательство.
Проанализировать проникновение, включая:
модификации, сделанные в ПО и конфигурациях;
модификации, сделанные в данных;
инструментальные средства или данные, оставленные нарушителем;
данные из системных логов, определение проникновения и файлы логов firewall.
Выполнить восстановление системы.
Существуют две возможности:
инсталлировать чистые ОС, приложения, необходимые patches и содержимое web-сервера;
восстановить из backup’а (данное действие может быть более рискованным, так как backup мог быть сделан после компрометации и восстановление компрометированного backup может позволить атакующему в дальнейшем получить доступ к системе).
Запретить сервисы, не являющиеся необходимыми.
Применить все patches.
Изменить все пароли (даже на нескомпрометированных хостах).
Переконфигурировать элементы сетевой безопасности (например, firewall, роутер, IDS) для обеспечения дополнительной защиты и оповещения.
Заново присоединить систему к сети.
Протестировать систему для гарантирования безопасности.
Выполнить мониторинг системы и сети, чтобы убедиться, что атакующий снова не сможет получить доступ к системе или сети.
Все документировать.
Системные администраторы должны рассмотреть следующие параметры при принятии решения о том, следует ли переинсталлировать ОС на скомпрометированной системе или же достаточно восстановить все из backup’а:
Уровень доступа, который получил нарушитель (например, root, user, guest, system).
Тип атакующего (внутренней или внешний).
Цель компрометации (например, изуродовать web-страницу, получить незаконный доступ к репозиторию ПО, платформе для выполнения других атак).
Метод компрометации системы.
Действия атакующего в течение и после компрометации (например, просмотр логов, отчетов об обнаружении проникновения).
Продолжительность компрометации.
Распространение компрометации на сеть (например, количество скомпрометированных хостов).
Результаты консультаций с адвокатами.
Более низкий уровень доступа, полученный нарушителем, и большие знания web-администратора о действиях нарушителя уменьшают риск, существующий при восстановлении из backup’а и выполнении patch для устранения уязвимостей. Если о действиях нарушителя известно мало, то нужно переустановить все ПО на хосте.
Тестирование безопасности web-серверов
Периодическое тестирование безопасности web-сервера является весьма существенным. Без периодического тестирования не может быть уверенности, что текущие меры защиты работают или что patch безопасности, примененные web-администратором, функционирует так, как объявлено. Хотя существуют различные технологии тестирования безопасности, наиболее общей является сканирование уязвимостей. Сканирование уязвимостей помогает web-администратору идентифицировать уязвимости и выполнить проверки эффективности существующих мер безопасности. Также используется тестирование проникновения, хотя и менее часто и обычно только как часть общего тестирования безопасности сети организации.
Сканирование уязвимостей
Сканеры уязвимостей – это автоматические инструментальные средства, которые используются для идентификации уязвимостей и неправильной конфигурации хостов. Многие сканеры уязвимостей также предоставляют информацию о мерах по смягчению обнаруженных уязвимостей.
Сканеры уязвимостей пытаются идентифицировать уязвимости в сканируемом хосте. Сканеры уязвимостей могут помочь в идентификации устарелых версий ПО, отсутствующих patches или обновлений системы и проанализировать на соответствие или отклонение от политики безопасности организации. Для выполнения этого сканеры идентифицируют ОС и основные приложения ПО, выполняющиеся на хосте, и ищут соответствие с известными уязвимостями. Сканеры имеют большие базы данных уязвимостей для идентификации проблем, связанных с наиболее широко используемыми ОС и приложениями.
Тем не менее сканеры уязвимостей имеют некоторые важные слабые места. Обычно они идентифицируют только внешние уязвимости и не могут определить общий уровень риска сканируемого web-сервера. Хотя сам процесс сканирования и высоко автоматизирован, сканеры уязвимостей имеют большой процент ложных позитивностей (отчет об уязвимостях, которых не существует). Это означает, что тот, кто проверяет безопасность web-сервера, должен сам интерпретировать результат. Более того, сканеры уязвимостей не могут идентифицировать уязвимости в коде или приложении заказчика.
Для сканеров уязвимостей периодически должно выполняться обновление базы данных, чтобы они могли распознавать самые последние уязвимости. Перед запуском любого сканера web-администраторы должны инсталлировать самые последние обновления базы данных уязвимостей. Некоторые базы данных изменяются более регулярно, чем другие (выпуск обновлений часто должен быть важным фактором при выборе сканера уязвимостей).
Сканеры уязвимостей часто лучше подходят для определения наличия известных уязвимостей, чем неизвестных. Все производители стремятся поддерживать высокую скорость работы своих сканеров (большее количество обнаруживаемых уязвимостей требует большего количества тестов). Следовательно, сканеры уязвимостей плохо применимы для не очень популярных web-серверов, ОС и не применимы для анализа кода приложений заказчиков.
Сканеры уязвимостей предоставляют следующие возможности:
Идентификация активных хостов в сети.
Идентификация активных сервисов (портов) на хостах и указание, какие из них являются уязвимыми.
Идентификация вредоносных приложений и баннеров.
Идентификация ОС.
Идентификация уязвимостей, связанных с обнаруженными ОС и приложениями.
Тестирование согласованности с политиками безопасности.
Следует использовать сканеры уязвимостей для проверки того, что на ОС и приложениях web-сервера установлены последние обновления, относящиеся к безопасности, и последние версии ОС. Сканирование уязвимостей может приводить к разрыву других сетевых операций, занимая всю полосу пропускания и замедляя время ответа. Часто сканер уязвимостей запускается всякий раз, когда получает новая база данных уязвимостей.
Следует также предусмотреть возможность использования более одного сканера уязвимостей. Как уже обсуждалось, ни один сканер не может определить все известные уязвимости, но применение двух сканеров обычно увеличивает количество обнаруживаемых уязвимостей.
Тестирование проникновения
Тестирование проникновения есть тестирование безопасности, при котором тестировщик пытается обойти систему безопасности. Цель состоит в определении методов получения доступа к системе, используя общие инструментальные средства и технологии, разработанные хакерами. Такое тестирование особенно рекомендуется для сложных или критичных систем.
Как минимум такое тестирование может замедлить время ответа в сети. Более того, целевой системе может быть нанесен определенный ущерб при тестировании проникновения. Хотя этот риск и невелик при использовании квалифицированных тестировщиков, его никогда нельзя полностью исключать.
Тестирование проникновения имеет следующие преимущества:
Тестирование сети производится теми же методами и инструментальными средствами, какие используют хакеры.
Осуществляется проверка наличия уязвимостей.
Осуществляется не только проверка внешних уязвимостей, но и проводится демонстрация того, как эти уязвимости могут быть использованы для получения большего доступа.
Демонстрируется, что уязвимости являются не чисто теоретическими.
Показывается реальная ситуация с безопасностью.
Имеется определенный элемент социальной инженерии.
Удаленное администрирование web-сервера
Администраторы web-сервера должны тщательно рассмотреть, существует ли необходимость удаленного администрирования и/или модификации содержимого web-сервера. Большинство безопасных конфигураций запрещает любое удаленное администрирование или модификации содержимого, хотя это может и не являться необходимым абсолютно для всех организаций. Риск от необходимости удаленного администрирования или модификации содержимого зависит от размещения web-сервера в сети. Например, если web-сервер расположен внешне относительно firewall’а или фильтрующего роутера, то никакого удаленного администрирования или модификации содержимого не должно выполняться. Удаленное администрирование или модификация содержимого могут выполняться относительно безопасно из внутренней сети, когда web-сервер расположен позади firewall’а. Удаленное администрирование или модификация содержимого не должны допускаться с хоста, расположенного вне сети организации.
Если необходимо удаленное администрирование или модификация содержимого на web-сервере, то для обеспечения безопасности должно быть гарантировано следующее:
Используется механизм сильной аутентификации (например, криптография с открытым ключом, двухфакторная аутентификация или аналогичные по силе механизмы).
Существует ограничение на хосты, которые могут быть использованы для удаленного администрирования или модификации содержимого на web-сервере.
Ограничение по IP-адресу (не по имени хоста).
Ограничение для хостов, находящихся во внутренней сети.
Используются безопасные протоколы (например, SSH, TLS/SSL), а не протоколы, не обеспечивающие конфиденциальность, целостность и аутентификацию (Telnet, FTP, HTTP, NFS). От протоколов требуется, чтобы они обеспечивали шифрование как паролей, так и данных.
Реализация концепции минимальных привилегий для удаленного администрирования и модификации содержимого (например, минимизировать права доступа для аккаунтов удаленного администрирования и модификации).
Изменены все аккаунты по умолчанию или пароли для утилит или приложений удаленного администрирования.
Не монтируется никаких файлов, разделяемых во внутренней сети, к 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-сервером.
Сетевая инфраструктура играет весьма важную роль в обеспечении безопасности web-сервера. В большинстве конфигураций сетевая инфраструктура является первой линией обороны между Интернетом и web-сервером. Хотя на создание той или иной сетевой инфраструктуры влияют многие факторы, отличные от проблем, связанных с безопасностью (такие как цена, производительность и надежность), мы в основном будем рассматривать проблемы, относящиеся к безопасности.
Сеть, которая разрабатывалась без учета требований обеспечения безопасности web-сервера, может иметь серьезные уязвимости для его безопасности. Частота, изощренность и разнообразие web-атак, осуществляемых сегодня, говорят о том, что безопасность web должна обеспечиваться с помощью многоуровневых и распределенных механизмов обороны (так называемая "оборона вглубь"). Обсудим сетевые компоненты, которые могут поддерживать и защищать web-серверы с целью соответствующего усиления безопасности.
Топология сети
Существует много вариантов создания топологии сети, и безопасность может быть не главным фактором при принятии решений. Топология сети является первым и во многих аспектах наиболее критичным сетевым решением, которое воздействует на безопасность web-сервера. Она важна по нескольким причинам. Топология сети определяет, какая сетевая инфраструктура может быть использована для защиты web-сервера. Например, если web-сервер расположен позади firewall’а организации, то firewall может использоваться для контроля входящего и исходящего трафика во внутреннюю сеть и web-сервер. Топология сети также определяет, какие участки сети окажутся уязвимыми, если web-сервер будет скомпрометирован. Например, если web-сервер размещен во внутренней производственной сети, то внутренняя сеть может быть подвергнута атаке со стороны скомпрометированного web-сервера. Организация может принять решение не размещать web-сервер в своей сети, а разместить его в сторонней организации.
Иногда принимается решение о размещении публичных web-серверов во внутренних производственных сетях, где расположены их внутренние серверы и рабочие станции пользователей. Такое расположение не рекомендуется, потому что при этом существует неоправданный риск компрометации внутренней сети. Принципиально слабым местом такой конфигурации является то, что web-серверы часто являются целью атакующих. Если удастся скомпрометировать web-сервер, атакующие окажутся во внутренней сети и могут легко скомпрометировать внутренние хосты.
Также не рекомендуется располагать web-сервер перед firewall’ом организации или роутером, который осуществляет IP-фильтрацию. При таком типе конфигурации сеть может обеспечивать меньшую, чем необходимо, защиту web-сервера. Вся безопасность зависит только от самого web-сервера, который представляет собой единственную точку падения. Даже если при такой топологии и задействовать существенные меры обеспечения безопасности, все равно ОС, на которой выполняется web-сервер, должна быть достаточно укрепленной (все ненужные и небезопасные сервисы запрещены) и полностью применены необходимые patches безопасности, а 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-сервера в третьей организации (например, в Internet Service Provider – ISP). В этом случае web-сервер не размещается в сети организации. ISP имеет выделенную сеть, обслуживающую много web-серверов (для многих организаций), которые выполняются в одной сети.
Преимущества хостинга во внешней организации с точки зрения безопасности:
DoS-атаки, направленные на web-сервер, не воздействуют на сеть предприятия.
Компрометация web-сервера не представляет непосредственной угрозы внутренней сети предприятия.
Внешняя организация может лучше разбираться в безопасности и лучше защитит web-сервер.
Сеть может быть оптимизирована исключительно для поддержки и защиты web-серверов.
Недостатки хостинга во внешней организации с точки зрения безопасности:
Требуется доверие к третьей стороне в отношении содержимого web-сервера.
Трудно удаленно администрировать web-сервер или удаленно изменять содержимое web-сервера.
Может быть предоставлен меньший контроль за безопасностью web-сервера.
На web-сервер могут влиять атаки, направленные на другие web-сервера, которые размещены в той же самой сети.
Внешний хостинг предпочтительней для небольших организаций, которые не могут позволить себе иметь необходимых экспертов для поддержки web-сервера. Это возможно также для больших организаций, которые не хотят поддерживать свой собственный web-сервер, но неприемлемо для организаций, которые хотят иметь жесткий контроль за web-сервером.
Сетевые элементы
После того как web-сервер размещен в сети, следует сконфигурировать элементы сетевой инфраструктуры для поддержки и защиты web-сервера. Элементами сетевой инфраструктуры, которые влияют на безопасность web-сервера, являются firewall’ы, роутеры, системы обнаружения проникновения и сетевые коммутаторы (switch). Каждый из них играет важную роль для защиты web-сервера при обеспечении многоуровневой обороны. К сожалению, при обеспечении безопасности web-сервера не существует универсального решения. Единичный firewall или IDS не может обеспечить адекватную защиту публичного 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’а и лежащей в основе ОС.
Системы обнаружения проникновения (IDS)
IDS является приложением, которое просматривает системные и сетевые ресурсы и анализирует различные виды деятельности, а также, используя информацию, полученную из этих источников, уведомляет сетевого администратора и/или соответствующий персонал, отвечающий за безопасность, о возможном проникновении или попытки взлома. Два основных типами IDS: host-based и network-based.
Сетевые коммутаторы и концентраторы
Сетевые коммутаторы являются устройствами, которые обеспечивают соединение между двумя или более хостами, расположенными в одном сетевом сегменте. Они аналогичны концентраторам (hub) в том, что обслуживают коммуникации между хостами, но, в отличие от концентраторов, коммутаторы более "интеллектуальны" и посылают пакеты только тому хосту, для которого эти пакеты предназначены. Тем самым коммутаторы изолируют хосты в сетевом сегменте друг от друга. Такая изоляция может иметь преимущества в уменьшении воздействия DoS-атаки на другие хосты в сети.
При использовании коммутаторов труднее просматривать взаимодействия между различными хостами в данном сегменте сети. Это преимущество особенно важно, когда web-сервер расположен в сегменте сети, в котором также расположены и другие хосты. Например, если используется концентратор и web-сервер скомпрометирован, атакующий может иметь возможность подсмотреть взаимодействие других хостов, что может привести к компрометации этих хостов или информации, которую они посылают по сети. E-mail серверы часто расположены вместе с web-серверами и в конфигурации по умолчанию принимают незашифрованные пароли. В таком случае компрометация web-сервера приводит к компрометации почтового сервера, независимо от того, используется коммутатор или нет. Коммутатор предотвращает или, по крайней мере, затрудняет для атакующего перехват паролей почтового сервера с использованием скомпрометированного web-сервера, если эти серверы расположены на разных хостах.
Многие коммутаторы имеют специфические настройки безопасности, которые еще больше усиливают безопасность сети, затрудняя "разрушение" коммутатора. Некоторые примеры включают возможность минимизировать риск от атак на протокол ARP.
Список действий для обеспечения безопасности сетевой инфраструктуры
Расположение сети.
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-сервера. Запись соответствующих данных и последующий просмотр и анализ этих логов — это важная деятельность. Просмотр логов 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-сервер поддерживает возможность расширения программ, скриптов или plug-ins, web-администратор должен иметь возможность определить специфичные данные логов, которые должны записываться в соответствии с функционированием этих возможностей. Если разработаны специальные программы, скрипты или plug-ins, рекомендуется, чтобы был определен и реализован согласованный и легко понимаемый подход к созданию логов, основанный на механизмах создания логов и предоставляемый ОС и web-сервером. Информация в логах, связанная с программами, скриптами и plug-ins, может быть добавлена к обычной информации, хранящейся в логах web-сервера.
Возможные параметры логов
Логи, созданные со следующими параметрами, можно считать оптимальными для первоначального использования:
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-сервера поддерживает такую возможность).
Просмотр и хранение лог-файлов
Просмотр лог-файлов может быть трудоемким и занимать много времени. Лог-файлы являются реагирующей мерой безопасности; они информируют о событиях, которые уже произошли. Соответственно, они часто бывают полезны для поддержки других доказательств, таких как аномальный сетевой трафик, обнаруженный IDS. Логи web-сервера должны также просматриваться для обнаружения атак. Частота просмотра зависит от следующих факторов:
трафик, получаемый сервером;
общий уровень угроз (федеральное правительство и крупные коммерческие организации намного больше подвержены атакам, чем сайты других фирм и, таким образом, должны просматривать свои логи более часто);
специфические угрозы (могут возникать угрозы, специфичные для определенного времени, что требует более частого анализа лог-файла);
уязвимость web-сервера;
значимость (ценность) данных и сервисов, предоставляемых web-сервером.
Для облегчения анализа логов разработаны специальные автоматизированные средства.
Кроме того, обычно бывает необходим более глубокий и более продолжительный анализ логов. Так как типичная web-атака может включать сотни web-запросов, атакующий может попытаться замаскировать атаку увеличением интервала между запросами. В этом случае просмотр одних ежедневных или еженедельных логов может не показать общей тенденции. Однако, когда тенденция анализируется в течение недели, месяца или квартала, многие атаки на один и тот же хост могут быть легко обнаружены.
Лог-файлы должны быть защищены для гарантирования того, что атакующий, который скомпрометировал web-сервер, не может изменить лог-файлы, чтобы скрыть свои действия. Хотя шифрование и может использоваться для защиты лог-файлов, лучшим решением является хранение лог-файлов на отдельном от web-сервера хосте. Он часто называется лог- или syslog-хостом.
Необходимо регулярно создавать back up и архивы лог-файлов. Периодическое архивирование лог-файлов существенно по нескольким причинам. Оно может быть важно с точки зрения законодательных действий или использоваться при возникновении различных проблем, связанных с web-сервером. Периодичность архивации лог-файлов зависит от нескольких факторов, включающих следующие:
законодательные требования;
организационные требования;
размер логов (который напрямую зависит от трафика сайта и параметров создания логов );
значимость (ценность) данных web-сервера и сервисов;
уровень угроз.
Автоматизированные инструментальные средства анализа лог-файлов
Большинство web-серверов имеют большой трафик, и лог-файлы быстро становятся огромными. Для облегчения работы web-администратора необходимо использовать одно или более автоматизированное средство анализа лог-файлов. Эти средства анализируют записи в лог-файле и идентифицируют подозрительную или необычную деятельность.
Доступно большое количество коммерческих и свободно распространяемых средств, обеспечивающих регулярный анализ Transfer Log. Большинство выполняется для Common или Combined Log Format.
Такие средства могут идентифицировать IP-адреса, которые являются источником большого числа соединений или большого объема трафика.
Средства Error Log определяют не только ошибки, которые могут существовать в конкретном web-содержимом (такие как отсутствующие файлы), но также попытки доступа к несуществующим URL. Эти попытки могут указывать на следующее:
зондирование на наличие определенных уязвимостей, которые могут быть использованы позднее для осуществления атаки;
сбор информации;
интерес к конкретному содержимому, такому как базы данных.
Автоматизированный анализатор лог-файла должен как можно быстрее сообщить о любых подозрительных событиях в лог-файле web-администратору.
Процедуры создания backup web-сервера
Одна из наиболее важных функций администратора web-сервера — поддержка целостности данных на web-сервере. Это жизненно важно, потому что web-сервер часто является наиболее незащищенным сервером в сети организации и, таким образом, часто наиболее чувствительным к враждебным действиям и возможным падениям ПО и аппаратуры. Существуют два принципиальных компонента для выполнения backup’а данных для web-сервера: регулярный backup данных и всей системы и поддержка защищенной, аутентичной, отдельно хранящейся копии содержимого 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’а.
Поддержка тестового web-сервера
Большинство организаций поддерживают тестовый или развиваемый web-сервер. Идеально, чтобы данный сервер имел аппаратуру и ПО, идентичную основному web-серверу, и был размещен во внутреннем сегменте сети (Интранет), где он может быть полностью защищен обороной периметра. Хотя цена поддержки дополнительного web-сервера может быть значительной, наличие тестового сервера часто обеспечивает значительные преимущества.
Обеспечивается платформа для тестирования новых patches до применения их к производственному web-серверу.
Обеспечивается платформа для разработки и тестирования нового содержимого и новых приложений.
ПО, которое является необходимым для разработки и тестирования, но может представлять собой неприемлемый риск безопасности, если оно развернуто на производственном сервере, может быть установлено на тестовый сервер (например, компиляторы, инструментальные средства администрирования, ПО удаленного доступа).
Замечание: тестовый web-сервер должен быть отделен от сервера, который содержит аутентичную копию содержимого производственного web-сервера.
Поддержка аутентичной копии web-содержимого
Следует поддерживать аутентичную (проверенную, доверяемую) копию web-содержимого на хосте, который не доступен из Интернета. Это дополняет, но не заменяет соответствующую политику backup’а. Например, в отношении статических web-сайтов это должна быть простая копия web-сайта на устройстве только для чтения (CD-R). Аутентичная копия web-сайта должна поддерживаться на безопасном хосте. Такой хост обычно расположен позади firewall’а во внутренней сети, а не в DMZ. Цель создания аутентичной копии состоит в том, чтобы предоставить способы восстановления информации на web-сайте, если он был скомпрометирован в результате случайных или преднамеренных действий. Аутентичная копия web-сайта позволяет быстро восстановить изуродованный web-сайт.
Для успешного выполнения данной цели должны быть выполнены следующие требования:
Защита аутентичной копии от неавторизованного доступа. Следует:
использовать устройства, которые допускают только однократную запись (подходит для относительно статичных web-сайтов);
размещать хост с аутентичной копией позади firewall’а и гарантировать, что к хосту не существует доступа извне;
минимизировать количество пользователей, которые имеют доступ к хосту;
управлять доступом пользователей максимально точным способом;
обеспечить строгую аутентификацию пользователей;
развернуть соответствующие процедуры создания логов и мониторинга;
предусмотреть дополнительные аутентичные копии в различных физических местах для обеспечения большей защиты.
Установить соответствующие процедуры обновления аутентичных копий:
выполнять обновление аутентичной копии первым (любое тестирование кода должно выполняться перед обновлением аутентичной копии);
установить политику и процедуры, определяющие, кто может выполнять обновление, когда может выполняться обновление и т.п.
Установить процесс копирования аутентичной копии на производственный web-сервер:
данные могут передаваться с использованием физически безопасной среды (например, шифрование и/или устройства только однократной записи, такие как CD-R);
использовать безопасный протокол (например, SSH) для передач по сети.
Включить процедуры восстановления с аутентичной копии в организационные процедуры реакции на инцидент.
Восстановление при компрометации безопасности
Большинство организаций при определенных обстоятельствах сталкиваются с успешной компрометацией одного или более хостов в своей сети. Первый шаг при восстановлении состоит в создании и документировании требуемых политик и процедур в ответ на успешное вторжение до осуществления самого вторжения. Ответные процедуры должны очерчивать действия, которые требуются в ответ на успешную компрометацию web-сайта, и соответствующую последовательность этих действий (последовательность может быть критически важной). Эти процедуры должны содержаться в политике безопасности организации.
Web-администраторы должны выполнить следующие шаги при определении успешной компрометации:
Сообщить об инциденте.
Просмотреть политику безопасности организации.
Изолировать скомпрометированную систему(ы) и выполнить шаги по сохранению следов атаки, чтобы могли быть собраны дополнительные доказательства.
Исследовать другие "аналогичные" хосты (в том же самом диапазоне адресов, имеющие те же или аналогичные пароли, разделяющие отношение доверия и имеющие ту же ОС и приложения) для определения того, не скомпрометировал ли атакующий и другие системы.
Просмотреть соответствующее законодательство.
Проанализировать проникновение, включая:
модификации, сделанные в ПО и конфигурациях;
модификации, сделанные в данных;
инструментальные средства или данные, оставленные нарушителем;
данные из системных логов, определение проникновения и файлы логов firewall.
Выполнить восстановление системы.
Существуют две возможности:
инсталлировать чистые ОС, приложения, необходимые patches и содержимое web-сервера;
восстановить из backup’а (данное действие может быть более рискованным, так как backup мог быть сделан после компрометации и восстановление компрометированного backup может позволить атакующему в дальнейшем получить доступ к системе).
Запретить сервисы, не являющиеся необходимыми.
Применить все patches.
Изменить все пароли (даже на нескомпрометированных хостах).
Переконфигурировать элементы сетевой безопасности (например, firewall, роутер, IDS) для обеспечения дополнительной защиты и оповещения.
Заново присоединить систему к сети.
Протестировать систему для гарантирования безопасности.
Выполнить мониторинг системы и сети, чтобы убедиться, что атакующий снова не сможет получить доступ к системе или сети.
Все документировать.
Системные администраторы должны рассмотреть следующие параметры при принятии решения о том, следует ли переинсталлировать ОС на скомпрометированной системе или же достаточно восстановить все из backup’а:
Уровень доступа, который получил нарушитель (например, root, user, guest, system).
Тип атакующего (внутренней или внешний).
Цель компрометации (например, изуродовать web-страницу, получить незаконный доступ к репозиторию ПО, платформе для выполнения других атак).
Метод компрометации системы.
Действия атакующего в течение и после компрометации (например, просмотр логов, отчетов об обнаружении проникновения).
Продолжительность компрометации.
Распространение компрометации на сеть (например, количество скомпрометированных хостов).
Результаты консультаций с адвокатами.
Более низкий уровень доступа, полученный нарушителем, и большие знания web-администратора о действиях нарушителя уменьшают риск, существующий при восстановлении из backup’а и выполнении patch для устранения уязвимостей. Если о действиях нарушителя известно мало, то нужно переустановить все ПО на хосте.
Тестирование безопасности web-серверов
Периодическое тестирование безопасности web-сервера является весьма существенным. Без периодического тестирования не может быть уверенности, что текущие меры защиты работают или что patch безопасности, примененные web-администратором, функционирует так, как объявлено. Хотя существуют различные технологии тестирования безопасности, наиболее общей является сканирование уязвимостей. Сканирование уязвимостей помогает web-администратору идентифицировать уязвимости и выполнить проверки эффективности существующих мер безопасности. Также используется тестирование проникновения, хотя и менее часто и обычно только как часть общего тестирования безопасности сети организации.
Сканирование уязвимостей
Сканеры уязвимостей – это автоматические инструментальные средства, которые используются для идентификации уязвимостей и неправильной конфигурации хостов. Многие сканеры уязвимостей также предоставляют информацию о мерах по смягчению обнаруженных уязвимостей.
Сканеры уязвимостей пытаются идентифицировать уязвимости в сканируемом хосте. Сканеры уязвимостей могут помочь в идентификации устарелых версий ПО, отсутствующих patches или обновлений системы и проанализировать на соответствие или отклонение от политики безопасности организации. Для выполнения этого сканеры идентифицируют ОС и основные приложения ПО, выполняющиеся на хосте, и ищут соответствие с известными уязвимостями. Сканеры имеют большие базы данных уязвимостей для идентификации проблем, связанных с наиболее широко используемыми ОС и приложениями.
Тем не менее сканеры уязвимостей имеют некоторые важные слабые места. Обычно они идентифицируют только внешние уязвимости и не могут определить общий уровень риска сканируемого web-сервера. Хотя сам процесс сканирования и высоко автоматизирован, сканеры уязвимостей имеют большой процент ложных позитивностей (отчет об уязвимостях, которых не существует). Это означает, что тот, кто проверяет безопасность web-сервера, должен сам интерпретировать результат. Более того, сканеры уязвимостей не могут идентифицировать уязвимости в коде или приложении заказчика.
Для сканеров уязвимостей периодически должно выполняться обновление базы данных, чтобы они могли распознавать самые последние уязвимости. Перед запуском любого сканера web-администраторы должны инсталлировать самые последние обновления базы данных уязвимостей. Некоторые базы данных изменяются более регулярно, чем другие (выпуск обновлений часто должен быть важным фактором при выборе сканера уязвимостей).
Сканеры уязвимостей часто лучше подходят для определения наличия известных уязвимостей, чем неизвестных. Все производители стремятся поддерживать высокую скорость работы своих сканеров (большее количество обнаруживаемых уязвимостей требует большего количества тестов). Следовательно, сканеры уязвимостей плохо применимы для не очень популярных web-серверов, ОС и не применимы для анализа кода приложений заказчиков.
Сканеры уязвимостей предоставляют следующие возможности:
Идентификация активных хостов в сети.
Идентификация активных сервисов (портов) на хостах и указание, какие из них являются уязвимыми.
Идентификация вредоносных приложений и баннеров.
Идентификация ОС.
Идентификация уязвимостей, связанных с обнаруженными ОС и приложениями.
Тестирование согласованности с политиками безопасности.
Следует использовать сканеры уязвимостей для проверки того, что на ОС и приложениях web-сервера установлены последние обновления, относящиеся к безопасности, и последние версии ОС. Сканирование уязвимостей может приводить к разрыву других сетевых операций, занимая всю полосу пропускания и замедляя время ответа. Часто сканер уязвимостей запускается всякий раз, когда получает новая база данных уязвимостей.
Следует также предусмотреть возможность использования более одного сканера уязвимостей. Как уже обсуждалось, ни один сканер не может определить все известные уязвимости, но применение двух сканеров обычно увеличивает количество обнаруживаемых уязвимостей.
Тестирование проникновения
Тестирование проникновения есть тестирование безопасности, при котором тестировщик пытается обойти систему безопасности. Цель состоит в определении методов получения доступа к системе, используя общие инструментальные средства и технологии, разработанные хакерами. Такое тестирование особенно рекомендуется для сложных или критичных систем.
Как минимум такое тестирование может замедлить время ответа в сети. Более того, целевой системе может быть нанесен определенный ущерб при тестировании проникновения. Хотя этот риск и невелик при использовании квалифицированных тестировщиков, его никогда нельзя полностью исключать.
Тестирование проникновения имеет следующие преимущества:
Тестирование сети производится теми же методами и инструментальными средствами, какие используют хакеры.
Осуществляется проверка наличия уязвимостей.
Осуществляется не только проверка внешних уязвимостей, но и проводится демонстрация того, как эти уязвимости могут быть использованы для получения большего доступа.
Демонстрируется, что уязвимости являются не чисто теоретическими.
Показывается реальная ситуация с безопасностью.
Имеется определенный элемент социальной инженерии.
Удаленное администрирование web-сервера
Администраторы web-сервера должны тщательно рассмотреть, существует ли необходимость удаленного администрирования и/или модификации содержимого web-сервера. Большинство безопасных конфигураций запрещает любое удаленное администрирование или модификации содержимого, хотя это может и не являться необходимым абсолютно для всех организаций. Риск от необходимости удаленного администрирования или модификации содержимого зависит от размещения web-сервера в сети. Например, если web-сервер расположен внешне относительно firewall’а или фильтрующего роутера, то никакого удаленного администрирования или модификации содержимого не должно выполняться. Удаленное администрирование или модификация содержимого могут выполняться относительно безопасно из внутренней сети, когда web-сервер расположен позади firewall’а. Удаленное администрирование или модификация содержимого не должны допускаться с хоста, расположенного вне сети организации.
Если необходимо удаленное администрирование или модификация содержимого на web-сервере, то для обеспечения безопасности должно быть гарантировано следующее:
Используется механизм сильной аутентификации (например, криптография с открытым ключом, двухфакторная аутентификация или аналогичные по силе механизмы).
Существует ограничение на хосты, которые могут быть использованы для удаленного администрирования или модификации содержимого на web-сервере.
Ограничение по IP-адресу (не по имени хоста).
Ограничение для хостов, находящихся во внутренней сети.
Используются безопасные протоколы (например, SSH, TLS/SSL), а не протоколы, не обеспечивающие конфиденциальность, целостность и аутентификацию (Telnet, FTP, HTTP, NFS). От протоколов требуется, чтобы они обеспечивали шифрование как паролей, так и данных.
Реализация концепции минимальных привилегий для удаленного администрирования и модификации содержимого (например, минимизировать права доступа для аккаунтов удаленного администрирования и модификации).
Изменены все аккаунты по умолчанию или пароли для утилит или приложений удаленного администрирования.
Не монтируется никаких файлов, разделяемых во внутренней сети, к 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-сервером.
