Введение
В самом общем виде web можно разделить на два основных компонента: web-серверы — они являются приложениями, которые формируют информацию, доступную по протоколу НТТР, и web-браузеры (клиенты) — они используются для доступа и показа информации, хранящейся на web-серверах. В основном будем рассматривать проблемы безопасности, касающиеся web-серверов.
К сожалению, web-серверы часто являются целями атак. Вследствие этого важно гарантировать безопасность web-серверов, а также сетевой инфраструктуры, которая их поддерживает. Угрозы безопасности, специфичные для web-серверов в общем случае можно разделить на следующие категории:
Враждебно настроенные пользователи интернета могут использовать ошибки ПО в web-серверах лежащей в основе ОС или в программах, создающих динамические web-страницы, для получения неавторизованного доступа к web-серверу.
Результатом этого может быть получение доступа к файлам или каталогам, которые не предназначены для открытого доступа, либо выполнение привилегированных команд и/или установка ПО на web-сервер.
Информация на web-сервере может быть преднамеренно изменена с враждебными целями. Наиболее общим примером такой угрозы является подмена содержимого web-сайта.
Denial of service (DoS) атаки могут быть направлены на web-сервер что приведет к отказу в доступе законным пользователям.
Чувствительная информация, передаваемая в открытом виде между web-сервером и браузером, может быть перехвачена.
Пользователи могут получить неавторизованный доступ к ресурсам, расположенным где-то еще в локальной сети организации, используя успешную атаку на web-сервер.
Возможно осуществление атаки на другие сети и серверы, причем будет использован скомпрометированный web-сервер, скрыта настоящая идентификация и, иногда, ответственность за последствия возложена на администратора web-сервера, с которого выполняется атака.
Сервер может быть использован в качестве незаконной точки распространения ПО, инструментальных средств атаки, при этом на администратора сервера может быть возложена ответственность за последствия атаки.
Рассмотрим проблемы, связанные с безопасностью при инсталлировании, конфигурировании и сопровождении web-серверов. Перечислим кратко основные вопросы:
Безопасное инсталлирование и конфигурирование лежащей в основе ОС.
Безопасное инсталлирование и конфигурирование ПО web-сервера.
Развертывание соответствующих сетевых механизмов защиты:
Firewall’ы;
Intrusion detection systems (IDS);
DNS.
Поддержка безопасной конфигурации, со своевременным применением соответствующих patches и upgrades, тестированием безопасности, просмотром логов и выполнение backup’ов как данных, так и ОС.
Обеспечение защиты информации, исходя из ее семантики.
Здесь нужно придерживаться следующих принципов.
Следует реализовать соответствующую практику управления безопасностью и контроль за функционированием системы.
Соответствующая практика управления является критичной для функционирования и поддержки безопасного web-сервера. Необходимо определить требования к развертыванию, документированию и реализации политик, стандартов, процедур и руководств, которые гарантируют конфиденциальность, целостность и доступность информационных ресурсов.
Для гарантирования безопасности web-сервера и поддержки сетевой инфраструктуры должны быть рассмотрены и реализованы следующие основные моменты:
Политика безопасности информационной системы организации.
Принципы управления и контроля конфигурации и ее изменений.
Анализ риска и определенные подходы к управлению риском.
Стандартные конфигурации ПО, которые удовлетворяют политике безопасности информационной системы.
Необходимый объем знаний и тренинги, обеспечивающие требуемый объем знаний.
Способы восстановления после внезапных сбоев.
Соответствующая сертификация и аккредитация.
Следует гарантировать, что ОС, на которой выполняется web-сервер, развернута, сконфигурирована и управляется в соответствии с требованиями безопасности.
Первым шагом в обеспечении безопасности web-сервера является безопасность лежащей в основе ОС. Большинство доступных web-серверов выполняются на ОС общего назначения. Многих проблем безопасности можно избежать, если ОС, лежащая в основе web-сервера, сконфигурирована соответствующим образом. Конфигурации по умолчанию для аппаратуры и ПО обычно устанавливаются производителями, при этом, как правило, делается упор на использование возможностей, функциональностей исходного ПО, а также на простоту использования возможностей, связанных с безопасностью. Также следует понимать, что производители не знают требований безопасности каждой организации, поэтому web-администратор должен сконфигурировать новые серверы в соответствии с требованиями безопасности и переконфигурировать их каждый раз при изменении этих требований. Обеспечение безопасности ОС как минимум должна включать следующие шаги:
выполнение patch’ей и upgrade’ов ОС;
удаление или запрещение ненужных сервисов и приложений;
конфигурирование управления ресурсами;
тестирование безопасности ОС.
Следует гарантировать, что ПО web-сервера развернуто, сконфигурировано и управляется в соответствии с требованиями безопасности, определенными в организации.
Во многих аспектах инсталляция и конфигурирование безопасности ПО web-сервера аналогично процессу инсталляции и конфигурирования ОС. Главным принципом, как и раньше, является инсталляция минимального числа требуемых сервисов web-сервера и удаление всех известных уязвимостей с помощью patche’ей и upgrade’ов. Если инсталляционная программа устанавливает какие-то ненужные приложения, сервисы или скрипты, они должны быть удалены немедленно после завершения процесса установки. Обеспечение безопасности web-сервера как минимум должно включать следующие шаги:
выполнение patch’ей и upgrade’ов ПО web-сервера – удаление или запрещение ненужных сервисов, приложений и примеров содержимого;
конфигурирование аутентификации пользователей web-сервера ;
конфигурирование управления ресурсами web-сервера ;
тестирование безопасности приложения web-сервера и конкретного содержимого web-сервера.
Следует предпринять шаги для гарантирования того, что на web-сайте публикуется только корректное содержимое.
Должна существовать четкая политика в определении того, какой тип информации является открытым, к какой информации следует ограничить доступ и какая информация не должна публиковаться в публично доступном репозитории.
Следует гарантировать защиту web-содержимого от неавторизованного доступа или модификации.
Должна существовать определенная политика, гарантирующая невозможность модификации без выполнения авторизации. Требуется обеспечить гарантию целостности, даже если информация не является конфиденциальной. Необходимо защищать содержимое web посредством выполнения соответствующего управления ресурсами web-сервера. Некоторые примеры управления ресурсами включают:
инсталлирование только необходимых сервисов;
инсталлирование web-содержимого на выделенном жестком диске или в выделенном разделе;
возможность выполнять запись (uploads) только в директории, которые не являются читаемыми из web-сервера, а доступны по некоторому другому протоколу (например, ftp);
определение единственной директории для всех скриптов или программ, которые выполняются для создания web-содержимого и являются внешними по отношению к web-серверу ;
запрещение использования жестких или символических ссылок в файловой системе ОС, на которой выполняется web-сервер ;
создание матрицы доступа к web-содержимому, которая определяет, какие папки и файлы внутри директории web-сервера имеют ограничения по доступу;
запрет просмотра директории в файловой системе;
использование аутентификации пользователей с помощью цифровых подписей и других криптографических механизмов;
использование систем обнаружения проникновений, основанных на хосте и /или проверки целостности файлов, для обнаружения проникновения и проверки целостности web-содержимого.
Следует использовать активное содержимое только после тщательного взвешивания получаемых при этом преимуществ в сравнении с увеличением рисков.
Вначале большинство web-сайтов представляли собой статическую информацию, расположенную на сервере, обычно в форме текстовых документов, имеющих соответствующую разметку (HTML). В дальнейшем вводились различные интерактивные элементы. К сожалению, эти интерактивные элементы вносят новые уязвимости, так как они предполагают пересылку определенного рода информации как от web-сервера к клиенту для выполнения на стороне клиента, так и от клиента к web-серверу для обработки информации на стороне сервера. Различные технологии создания активного содержимого имеют различные уязвимости, которые должны быть оценены в сравнении с получаемыми преимуществами.
Следует использовать аутентификацию, основанную на криптографических технологиях, для обеспечения соответствующей защиты чувствительных данных.
Публичные web-серверы обычно поддерживают широкий спектр технологий идентификации и аутентификации пользователей и определения различных привилегий для доступа к информации. Некоторые из этих технологий основаны на криптографических функциях, которые могут обеспечивать тот или иной тип зашифрованного канала между клиентом web-браузера и web-сервером. Web-серверы могут быть сконфигурированы для использования различных криптографических алгоритмов, обеспечивающих различные уровни безопасности.
Без наличия аутентификации пользователей нет возможности обеспечить разграничение доступа к чувствительной информации. Без наличия сильных механизмов аутентификации вся информация, которая расположена в web-пространстве сервера, может стать доступной любому. Кроме того, без процесса аутентификации сервера пользователи не имеют возможности определить, что сервер является требуемым, а не поддельным, созданным враждебно настроенным участником для перехвата конфиденциальной информации о пользователе.
Следует обеспечивать безопасность сетевой инфраструктуры для защиты web-серверов.
Сетевая инфраструктура, в которой функционирует web-сервер, играет важную роль в обеспечении безопасности web-сервера. Во многом сетевая инфраструктура является первой линией обороны web-сервера. Однако только тщательное проектирование сети не является достаточным для защиты web-сервера. Частота и варианты web-атак, совершаемых сегодня, говорят о том, что безопасность web-серверов может быть обеспечена только с использованием различных и расположенных на разных уровнях механизмов обороны (так называемая "оборона вглубь").
Следует гарантировать постоянное функционирование системы обеспечения безопасности.
Поддержание безопасного функционирования web-сервера требует постоянных усилий и наличия достаточного количества ресурсов. Поддержание безопасности web-сервера обычно включает следующие шаги:
своевременное применение patch’ей и upgrade’ов;
конфигурирование, защита и анализ лог файлов;
частое выполнение back up’а критической информации;
поддержка защищенных копий web-содержимого;
определение процедур восстановления при компрометации и следование им при обнаружении проникновения;
периодическое тестирование безопасности.
Рассмотрим общие принципы, которые применимы ко всем системам.
Причины уязвимости web-сервера
Основные проблемы, связанные с безопасностью функционирования публично доступного web-сайта, возникают по следующим причинам:
Неправильная конфигурация или другое некорректное действие над web-сервером, которое может привести к раскрытию или изменению информации.
Уязвимости ПО web-сервера, которые могут допускать, например, чтобы атакующий компрометировал безопасность сервера или других хостов в сети.
Неадекватные механизмы защиты web-сервера, предусмотренные в его окружении.
ПО на стороне сервера (скрипты, JSP, ASP и т.п.), которое содержит ошибки, позволяющие атакующим компрометировать безопасность web-сервера.
Планирование развертывания web-сервера
При планировании развертывания web-сервера следует рассмотреть следующие пункты:
Определить цели web-сервера ;
Какие категории информации будут храниться в web-сервере.
Какие категории информации будут обрабатываться или передаваться через web-сервер.
Каковы требования безопасности для данной информации.
Существует ли информация, которая получена с другого сервера или хранится на другом сервере (например, backend база данных, почтовый сервер, прокси-сервер).
Какие еще сервисы предоставляет web-сервер (должен ли web-сервер выполняться на выделенном хосте).
Каковы требования безопасности для этих дополнительных сервисов.
Определить сетевые сервисы, которые будет предоставлять web-сервер, и используемые при этом протоколы:
НТТР, НТТРS, SOAP и т.п. – протоколы взаимодействия с клиентами.
ODBC, JDBC, LDAP, LDAPS, NFS и т.п. – протоколы взаимодействия с backend-системами.
Определить все необходимое ПО, которое требуется для поддержки функционирования web-сервера ;
Определить категории пользователей web-сервера и всех backend-систем;
Определить способы аутентификации пользователей и web-сервера и способы защиты аутентификационных данных;
Определить, как будет предоставляться соответствующий доступ к информационным ресурсам.
Безопасность лежащей в основе ОС
Первым шагом в обеспечении безопасности web-сервера является безопасность лежащей в его основе ОС. Большинство общедоступных web-серверов функционируют на ОС общего назначения. Многих проблем безопасности можно избежать, если ОС соответствующим образом сконфигурирована. Конфигурации по умолчанию аппаратуры и ПО обычно поставляются производителями с упором на возможности безопасного функционирования и возможности легкого расширения. Так как производители не знают потребности безопасности каждой организации, каждый web-администратор должен сконфигурировать новые серверы в соответствии с требованиями безопасности своей организации.
Данная технология в различных ОС может сильно отличаться. Также могут существовать некоторые автоматизированные инструментальные средства для настройки ОС с точки зрения безопасности.
Выбор приложения web-сервера может определяться выбором ОС. Однако по возможности web-администраторы должны выбрать ОС, которая обеспечивает следующее:
возможность ограничить деятельность административного уровня или уровня root только авторизованными пользователями;
возможность управлять доступом к данным на сервере;
возможность запретить сетевые сервисы, не являющиеся необходимыми, которые встроены в ПО ОС или сервера;
возможность управления доступом к различным формам выполнимых программ, таких как CGI-скрипты и plug-ins, на стороне сервера;
возможность записывать в лог соответствующую деятельность сервера для определения проникновения и попыток проникновения.
Безопасное инсталлирование и конфигурирование ОС
Применение Patch и Upgrade ОС
После того как ОС инсталлирована, следует применить все patches и upgrades для удаления известных уязвимостей. Все ОС, реализованные сегодня, имеют известные уязвимости, которые должны быть удалены перед использованием ОС в качестве хоста web-сервера. Для адекватного определения и корректирования этих уязвимостей web-администратор должен:
идентифицировать уязвимости и применить patches;
смягчить уязвимости, для которых пока patches еще не доступны, не протестированы или не установлены;
проводить регулярное инсталлирование fixes (часто называемых patches, hotfixes, service packs или updates).
Удаление или запрещение ненужных сервисов и приложений
Идеально, чтобы web-сервер был выделенным и использовался только для этой цели. Многие ОС сконфигурированы по умолчанию для предоставления более широкого круга сервисов и приложений, чем требуется web-серверу ; следовательно, web-администратор должен сконфигурировать ОС, удалив или запретив сервисы, не являющиеся необходимыми. Приведем некоторые примеры сервисов, которые обычно должны быть запрещены:
NetBIOS, если не требуется.
NFS, если не требуется.
FTP.
Berkley "r" сервисы (например, rlogin, rsh, rcp).
Тelnet.
NIS.
SMTP.
Компиляторы.
Инструментальные средства разработки ПО, за исключением того случая, когда HTML страницы создаются каким-либо интерпретатором, например, Perl. В этом случае должен быть оставлен только используемый интерпретатор.
Удаление ненужных сервисов и приложений является предпочтительным, чем просто запрещение с помощью конфигурационных установок, потому что атакующий может попытаться изменить установки и активизировать запрещенные сервисы, что нельзя сделать при полном удалении.
Удаление или запрещение ненужных сервисов усиливает безопасность web-сервера по следующим причинам:
ненужные сервисы не могут быть скомпрометированы и использованы для атаки на хост или для повреждения сервисов web-сервера. Каждый имеющийся в наличии сервис увеличивает риск компрометации хоста, потому что каждый сервис потенциально открывает вход для доступа атакующего;
обычно различные сервисы могут администрировать разные люди. Следует изолировать сервисы таким образом, чтобы каждый хост имел одного администратора при минимально возможных конфликтах между администраторами. Наличие одного администратора, отвечающего за хост, приводит к лучшему распределению обязанностей;
хост может быть лучше сконфигурирован для удовлетворения требований конкретного сервиса. Различные сервисы могут требовать наличия различной аппаратуры и конфигураций ПО, которые приводят к возникновению уязвимостей или ограничениям сервиса;
при уменьшении числа сервисов уменьшается и количество логов и записей лога, благодаря чему обнаружение некорректного поведения становится легче.
При конфигурировании ОС следует применять принцип "запретить все, за исключением того, что явно разрешено" — это означает запретить и по возможности удалить все сервисы и приложения и затем выборочно разрешить те, которые требуются web-серверу. Также нужно по возможности установить минимальную конфигурацию ОС, которая требуется для приложения web-сервера. Если система инсталляции ОС предоставляет опцию "минимальная инсталляция", то нужно выбрать ее, потому что это минимизирует усилия, требуемые для удаления ненужных сервисов. Многие скрипты или программы типа uninstall не выполняют полного удаления всех компонент сервиса; следовательно, всегда лучше по возможности избегать инсталлирования ненужных сервисов.
Необходимые web-серверу сервисы зависят от функций, которые должен обеспечивать сервер. Эти сервисы могут включать протоколы баз данных для доступа к базе данных, протоколы передачи файлов и сервисы удаленного администрирования. Каждый из этих сервисов, даже если он необходим, увеличивает риск для сервера. Когда риски перекрывают преимущества, следует рассмотреть необходимость наличия каждого сервиса.
Конфигурирование аутентификации пользователя в ОС
Авторизованных пользователей, которые могут конфигурировать систему и запускать различные сервисы, обычно очень мало. Однако пользователей, которые могут иметь доступ к публичному web-серверу, может быть как неограниченное количество, так и некоторое ограниченное подмножество Интернет-сообщества. Для обеспечения политики безопасности web-администратор должен сконфигурировать систему для аутентификации пользователей, которым разрешен вход, требуя предоставления доказательства своей идентификации. Даже если web-сервер разрешает неаутентифицированный доступ к большинству сервисов, администрирование и другие типы специализированного доступа должны быть ограничены определенными персонами или ролями.
Конфигурирование компьютера для аутентификации обычно включает конфигурирование ОС, firmware и приложений на сервере, таких как ПО, которое реализует сетевой сервис. В специальных случаях для сайтов с высоким риском или хранящих важные данные можно также применять аппаратуру для аутентификации, например, токены или устройства с одноразовыми паролями. Использование аутентификационных механизмов, в которых аутентификационная информация является переиспользуемой (например, пароли) и передается в явном виде по сети, не рекомендуется, потому что информация может быть перехвачена и задействована атакующим для подделки под аутентифицированного пользователя.
Для гарантии того, что соответствующая аутентификация пользователя выполняется, необходимо выполнить следующие шаги.
Удалить или запретить неиспользуемые аккаунты и группы, созданные по умолчанию. Конфигурация ОС по умолчанию часто включает аккаунт guest (как с паролем, так и без), аккаунты уровня администратора или root, связанные с локальными и сетевыми сервисами. Имена и пароли этих аккаунтов хорошо известны. Удаление или запрещение ненужных аккаунтов предотвращает их использование для проникновения, включая аккаунты guest, на компьютерах, содержащих чувствительную информацию. Если существует требование оставить аккаунт или группу guest, следует ограничить их доступ и изменить пароль в соответствии с политикой для паролей в организации. Для аккаунтов по умолчанию, которые необходимо оставить, следует изменить имена (где возможно, особенно для аккаунтов уровня администратора или root) и пароли в соответствии с политикой для паролей. Следует помнить, что имена аккаунтов и пароли по умолчанию хорошо известны злоумышленникам.
Запретить неинтерактивные аккаунты. Запретить аккаунты (и связанные с ними пароли), которые должны существовать, но не требуют интерактивного входа. Для Unix-систем запретить входной shell или предоставить входной shell с функциональностью NULL ( /bin/false ).
Создать группы пользователей. Привязать пользователей к соответствующим группам и назначать права группам. Данный подход предпочтительнее, чем назначать права индивидуальным пользователям.
Создать аккаунты пользователей. Определить, кто авторизован использовать каждый компьютер и его сервисы. Создать только необходимые аккаунты. Не допускать использования разделяемых аккаунтов.
Проверить политику для паролей в организации. Установить пароли аккаунтов соответствующим образом. Данная политика должна рассматривать следующее:
длина – минимальная длина паролей;
сложность – требуемые символы. Требуемые пароли содержат буквы как верхнего, так и нижнего регистров и, по крайней мере, один неалфавитный символ;
срок использования – как долго можно не изменять пароль. Требовать от пользователей периодически изменять пароли. Пароль уровня администратора или root должен изменяться каждые 30–120 дней. Пароль пользователя также должен периодически изменяться. Этот период определяется длиной и сложностью пароля в сочетании с чувствительностью защищаемой им информации;
переиспользуемость – может ли пароль переиспользоваться. Некоторые пользователи пытаются обойти требование устаревания пароля, изменяя пароль на тот, который они уже использовали до этого. Нужно по возможности гарантировать, что пользователь не может изменить пароль простым добавлением "предполагаемых" символов к своему исходному паролю. Например, исходный пароль был "mysecret", а измененный – "mysecret1" или "1mysecret";
авторство – кому разрешено изменять или переустанавливать пароли и какого типа доказательство требуется перед началом любых изменений.
Сконфигурировать компьютеры для запрещения входа после небольшого числа неудачных попыток. Следует помнить, что может быть относительно легко для неавторизованного пользователя получить доступ к компьютеру, используя автоматические программные средства, которые перебирают все пароли. Чтобы ОС не предоставляла такую возможность, ее следует сконфигурировать таким образом, когда она будет запрещать вход после трех неудачных попыток. Обычно аккаунт блокируется на определенное время (например, 30 минут) или до тех пор, пока пользователь с соответствующими полномочиями не активирует его.
Это пример ситуации, когда от web-администратора требуется принятие решения о балансе между безопасностью и удобством. Реализация данной возможности может помочь предотвратить некоторые типы атак, но может также позволить злоумышленнику выполнить неудачные попытки входа для недопущения доступа пользователя, т.е. выполнить DoS-атаку для конкретного пользователя.
Неудачные попытки сетевого входа не должны запрещать вход с консоли пользователя и тем более администратора. Заметим также, что все неудачные попытки по сети или с консоли должны регистрироваться. Также, если удаленное администрирование не предусмотрено, следует запретить возможность входа по сети аккаунтам уровня администратора или root.
Инсталлировать и сконфигурировать другие механизмы безопасности для усиления аутентификации. Если информация на web-сервере требует этого – рассмотреть использование других аутентификационных механизмов, таких как токены, сертификаты клиента и сервера или системы одноразовых паролей. Хотя они могут быть более дорогими и трудными в реализации, это, возможно, оправдается в некоторых случаях. Когда используются подобные механизмы аутентификации и устройства, политика организации должна быть пересмотрена и в ней отражен наилучший способ их применения.
Создавать и распространять отчеты об использовании аккаунтов пользователей. Для того чтобы гарантировать, что все неиспользуемые аккаунты удаляются своевременно, важно установить в организации систему, которая создает отчеты о пользовательских аккаунтах, включающие информацию, необходимую для определения того, должен ли аккаунт оставаться активным. Эти отчеты должны распространяться соответствующим пользователям и управляющему персоналу для определения индивидуумов, которым более не требуется иметь аккаунт.
Как отмечалось ранее, нарушитель, используя сетевые сниферы, может легко перехватить переиспользуемые пароли, передаваемые по сети в явном виде. Вместо этого следует использовать менее уязвимые технологии аутентификации и шифрования, такие как SSH и SSL/TLS.
Управление ресурсами на уровне ОС
Многие ОС имеют возможность указать конкретные привилегии доступа для файлов, директорий, устройств и других коммуникационных ресурсов. Тщательно продумывая управление доступом, web-администратор может уменьшить преднамеренные и непреднамеренные бреши в безопасности. Например, запрет доступа по чтению к файлам и директориям помогает обеспечить конфиденциальность информации, тогда как запрет доступа по записи помогает обеспечить целостность информации. Разрешая выполнение большинства инструментальных средств системного уровня только системным администратором, можно предотвратить внесение пользователями изменений в конфигурацию, которые понижают безопасность системы. Такое ограничение может также уменьшить возможность атакующего использовать эти инструментальные средства для атаки как на данную систему, так и на другие системы в сети. Так как управление ресурсами ОС тесно связано с управлением ресурсами web-сервера, данная проблема будет рассмотрена далее в деталях.
Альтернативные платформы для web-сервера
Часто web-серверы выполняются на ОС общего назначения. В то же время существуют примеры, когда используется одна из альтернатив, обсуждаемых ниже. Хотя данные средства являются относительно новыми для web-серверов, они основаны на надежных технологиях и, возможно, скоро найдут широкое применение для использования в качестве окружения web-сервера.
Trusted ОС
Trusted ОС ( TOS являются модифицированными с учетом требований безопасности или специально усиленные ОС, которые включают дополнительные механизмы безопасности, отсутствующие в ОС общего назначения. Они уже изначально создавались с использованием мандатного управления доступом. TOS обеспечивают безопасную политику управления, четко определенное множество привилегий доступа, расширяемые возможности создания логов и аудита. Большинство TOS подвергались независимой проверке для гарантии того, что они соответствуют множеству требований, указанных в их документации.
TOS обычно используются в приложениях, где безопасность очень важна. TOS могут безопасно управлять всеми аспектами своего окружения, включая сетевые ресурсы, пользователей, процессы, память и т.п. Более конкретно, TOS имеют возможность ограничить доступ к системным ресурсам таким способом, в который нельзя вмешаться или скомпрометировать.
Использование TOS обычно приводит к созданию очень безопасного web-сервера, однако существуют определенные трудности при их использовании. Основной недостаток состоит в том, что администрирование TOS требует хорошего знания каждой защищенной подсистемы. Тем не менее, даже при таких ограничениях, организации, которые имеют большие требования к безопасности, должны рассмотреть возможность использования TOS для поддержки web-серверов.
Должны быть рассмотрены следующие вопросы при определении того, какую платформу использовать для web:
какая ОС лежит в основе и насколько проанализирована ее безопасность;
имеет ли организация опыт администрирования TOS – какова дополнительная цена покупки и поддержки TOS по сравнению с ее преимуществами;
совместима ли TOS с существующими в организации web-приложениями и скриптами.
Использование Appliances для web-сервера
Относительно недавние разработки в области web-серверов привели к появлению так называемых web Appliances. Web Appliances является комбинацией ПО и аппаратуры, которая разработана, чтобы быть "plug-and-play" web-сервером. Эти Appliances используют упрощенную ОС, которая оптимизирована для поддержки web-сервера. Упрощенная ОС обеспечивает безопасность, минимизируя возможности, сервисы и опции, которые не являются необходимыми для web-приложений. ПО web-сервера в таких системах часто заранее инсталлировано и заранее сконфигурировано с точки зрения безопасности.
Такие системы часто имеют преимущества, относящиеся к наличию дополнительной безопасности. Выполнение часто улучшается, так как система (ОС, ПО web-сервера и аппаратура) разработана и собрана специально для выполнения web-сервера. Цена на них зачастую ниже, так как аппаратура и ПО не требуют специальной настройки для web-сервера. Такие системы могут быть отличным решением для малых и средних организаций, которые не могут себе позволить иметь web-администратора на полную ставку.
Самым большим недостатком таких систем является то, что они не подходят для больших сложных и многоуровневых web-сайтов. Они могут также не подойти организациям, которым требуется более одного сервера, если только организация не захочет покупать web Appliances от одного производителя, так как такая простота делает трудным конфигурирование вместе web Appliances от разных производителей. Web Appliances доступны от основных производителей аппаратуры и от различных специализированных производителей web Appliances.
Некоторые вопросы, которые следует рассматривать при принятии решения о покупки web Appliances:
какая ОС лежит в основе и как она протестирована с точки зрения безопасности;
как web Appliance само протестировано с точки зрения безопасности. (Заметим, что конфигурационные опции web Appliances являются ограниченными, таким образом, web Appliance обычно бывает безопасным только при инсталляции по умолчанию);
какова разнородность инфраструктуры web-сервера организации. (Различные торговые марки web Appliances, как правило, не очень хорошо работают вместе);
имеется ли возможность какого-либо расширения web Appliances. (Организация, которая предполагает быстрый рост, может не захотеть ограничивать себя web Appliance).
Специально усиленные (pre-hardened) ОС и web-серверы
Сегодня распространяется всё возрастающее число специально усиленных ОС и пакетов web-сервера. Эти пакеты включают ОС и ПО web-сервера, которые модифицированы и заранее сконфигурированы для обеспечения большой безопасности. Некоторые из этих пакетов содержат и аппаратную платформу, другие являются ПО, которое состоит только из ОС и ПО web-сервера. Эти дистрибутивы обычно основаны на специально усиленной и/или модифицированной ОС общего назначения (например, Linux, Unix и, реже, Windows), которая специально разработана для поддержки безопасного web-сервера. Приложение web-сервера также часто основано на усиленном и/или модифицированном обычном ПО web-сервера например, Apache или IIS). Эти пакеты зачастую включают большее число опций безопасности и разработаны для более легкого конфигурирования с помощью заранее cкомпилированных скриптов и GUIs. Хотя все пакеты различны, они обычно обеспечивают какие-либо из следующих возможностей:
безопасная начальная конфигурация обеспечена по умолчанию;
наличие усиленной ОС и/или TOS – наличие усиленного ПО web-сервера ;
расширяемые возможности аудита;
наличие разного рода оберток (wrappers) для приложений;
наличие возможностей сетевых wrappers и/или host-based firewall;
host-based IDS;
упрощенное администрирование безопасности (например, меню, GUIs).
Эти типы систем должны быть рассмотрены организацией, которая понимает важность угроз и/или имеет важные данные на web-сайтах (например, правительственные организации, банки и т.п.). Такие пакеты доступны от некоторых основных производителей аппаратуры и ПО, а также от некоторых специализированных производителей.
Некоторые вопросы, которые следует рассмотреть при приобретении усиленного web Appliance.
Какая ОС лежит в основе и как она протестирована относительно безопасности.
Как само ПО web-сервер протестировано относительно безопасности.
Насколько трудно его администрировать.
Совместимо ли усиленное ПО web-сервер с существующими в организации web-приложениями и скриптами.
Тестирование безопасности операционной системы
Периодическое тестирование безопасности ОС является важным способом идентифицировать уязвимости и гарантировать, что существующие меры обеспечения безопасности эффективны. Наиболее популярными методами тестирования ОС являются сканирование уязвимостей и тестирование проникновения. Обычно используют автоматизированные сканеры уязвимостей для сканирования уязвимостей приложения, сети или ОС на хосте или группе хостов в сети. Тестирование проникновения является процессом тестирования, разработанным для проверки возможности компрометации сети, при этом используются инструментальные средства и методики атакующего. Это итеративный процесс тестирования, который идентифицирует наиболее слабые области сети и использует их для получения доступа к оставшейся сети. Результатом обычно является компрометация безопасности всей сети. Сканирование уязвимостей должно проводиться периодически, по крайней мере, раз в неделю или в месяц. Тестирование проникновения должно быть минимум ежегодным. Так как обе эти технологии тестирования применяются также для тестирования приложений web-сервера, далее они будут обсуждаться более детально.
Список действий для обеспечения безопасности ОС, на которой выполняется web-сервер
Составление плана конфигурации и развертывания web-сервера.
Определить функции web-сервера.
Определить категории информации, которая будет храниться, обрабатываться и передаваться web-сервером.
Определить требования безопасности для данной информации.
Определить способы опубликования информации на web-сервере.
Определить необходимость иметь выделенный хост для web-сервера.
Определить пользователей и категории пользователей web-сервера и определить привилегии каждой категории пользователей.
Определить методы аутентификации пользователей на web-сервере.
Выбор подходящей ОС для web-сервера.
Максимальная защищенность от уязвимостей.
Возможность ограничить деятельность уровня администратора или root только аутентифицированными и авторизованными пользователями.
Возможность запретить доступ к информации на сервере всем, кроме явно указанных пользователей.
Возможность сделать недоступными ненужные сетевые сервисы, которые могли быть встроены в ОС или ПО сервера.
Возможность управления доступом к различным программам, связанным с web-сервером, таким как CGI-скрипты и plug-ins сервера в случае web-сервера.
Применение patch’ей и upgrade’ов ОС.
Определить и инсталлировать все необходимые patches и upgrades для ОС.
Определить и инсталлировать все необходимые patches и upgrades для приложений и сервисов, включенных в ОС.
Удаление или запрещение ненужных сервисов и приложений.
Конфигурирование аутентификации пользователей в ОС.
Удалить или запретить ненужные аккаунты и группы, существующие по умолчанию.
Запретить неинтерактивные аккаунты.
Создать группы пользователей для данного экземпляра ОС.
Создать аккаунты пользователей для данного экземпляра ОС.
Проверить политику пароля в организации и установить соответствующие пароли аккаунтов (длина, сложность).
Сконфигурировать ОС для запрещения входа после небольшого числа неудачных попыток.
Инсталлировать и сконфигурировать другие механизмы безопасности для усиления аутентификации.
Тестирование безопасности ОС.
Протестировать ОС после начальной инсталляции для определения уязвимостей.
Проводить частое тестирование ОС для определения новых уязвимостей.
Безопасное инсталлирование и конфигурирование web-сервера
После того как ОС инсталлирована и сделана безопасной, следует инсталлировать выбранное ПО web-сервера. Перед началом данного процесса следует прочитать документацию производителя и понять, какие опции доступны при инсталляции. Также следует посетить web-сайт производителя или web-сайт базы данных уязвимостей, такой как ICAT метабаза (http://icat.nist.gov), для определения всех известных уязвимостей и соответствующих patches, которые должны быть инсталлированы или сконфигурированы как часть процесса установки. Только после завершения этих предварительных шагов следует начать инсталляцию. Будем обсуждать только общие процедуры инсталляции и конфигурирования.
Безопасное инсталлирование web-сервера
Во многих аспектах безопасное инсталлирование и конфигурирование приложения web-сервера аналогично инсталляции и конфигурированию ОС. Основной принцип состоит в том, чтобы инсталлировать минимальное количество требуемых сервисов web-сервера и исключить все известные уязвимости с помощью patches или upgrades. Если программа инсталляции устанавливает какие-то ненужные приложения, сервисы или скрипты, они должны быть немедленно удалены после завершения процесса. При инсталляции web-сервера должны быть выполнены следующие шаги:
Инсталлировать ПО сервера на выделенный хост.
Инсталлировать минимально требуемые сервисы Интернета.
Применить все patches или upgrades для корректировки известных уязвимостей.
Создать выделенный физический диск или логический раздел (отдельный от ОС и приложения сервера) для содержимого web.
Удалить или запретить все web-сервисы, инсталлированные приложением web-сервера, но не требуемые (например, gopher, FTP и удаленное администрирование).
Из корневой директории приложения web-сервера удалить все файлы, которые не являются частью web-сайта.
Удалить всю документацию, а также примеры скриптов и выполняемого кода.
Выполнить разного рода образцы безопасности или "hardening" скрипты, усиливающие безопасность web-сервера.
Переконфигурировать баннер НТТР-сервиса (и других сервисов, если они используются), чтобы он не сообщал о типе и версии web-сервера и ОС. Это может быть выполнено в IIS использованием свободного Microsoft IIS Lockdown Tool и в Apache посредством "ServerTokens" директивы.
Конфигурирование управления доступом
Большинство ОС для web-серверов предоставляют возможность указать конкретные привилегии доступа для файлов, устройств и других вычислительных ресурсов на данном хосте. Следует понимать, что любая информация, к которой может быть осуществлен доступ из каталогов, принадлежащих web-серверу потенциально может стать доступной всем пользователям, имеющим доступ к публичному web-сайту. Обычно ПО web-сервера обеспечивает дополнительное управление доступом к файлам, устройствам и ресурсам. В случае, если разрешения доступа к ресурсам могут быть установлены как на уровне ОС, так и на уровне приложения web-сервера, важно, чтобы они были идентичны друг другу, в противном случае возможна ситуация, когда пользователям предоставлен либо очень большой, либо очень маленький доступ. Web-администраторы должны рассмотреть, какое конфигурирование доступа к хранимой в публичном web-сервере информации является наилучшим со следующих точек зрения:
ограничение доступа ПО web-сервера к подмножеству вычислительных ресурсов средствами управления доступом ОС;
ограничение доступа пользователей посредством дополнительного управления доступом, обеспечиваемым web-сервером, когда требуются более детальные уровни управления доступом.
Соответствующая установка управления доступом может помочь предотвратить раскрытие чувствительной информации, которая не предназначена для публичного распространения. Дополнительно управление доступом может быть использовано для ограничения использования ресурсов в случае DoS-атаки на публичный web-сайт.
Обычно файлами, доступ к которым должен контролироваться, являются следующие:
ПО и конфигурационные файлы приложения.
Файлы, непосредственно использующиеся механизмами безопасности:
файлы хэшей паролей и другие файлы, используемые при аутентификации;
файлы, которые содержат авторизационную информацию, используемую при управлении доступом;
криптографический материал ключа, используемый в сервисах конфиденциальности, целостности и невозможности отказа.
Логи сервера и файлы системного аудита.
Системное ПО и его конфигурационные файлы.
Разграничение доступа для ПО web-сервера
Первый шаг в конфигурировании управления доступа состоит в гарантировании того, что web-сервер выполняется только от имени пользователя и группы, которые специально созданы для этого и имеют очень ограниченные права доступа. Таким образом, должны быть введены специальные идентификаторы пользователя и группы, используемые исключительно ПО web-сервера. Новый пользователь и новая группа должны быть уникальными и независимыми от всех остальных пользователей и групп. Это необходимо для реализации управления доступом, описанного далее. Хотя сервер может начинать выполняться как root (Unix) или system/administrator (Windows NT/2000/XP) для привязки к ТСР-порту 80 и/или 443 (используемому для предоставления НТТР и НТТРS-сервисов соответственно), не следует допускать, чтобы сервер продолжал выполняться на данном уровне доступа.
Дополнительно следует использовать возможности ОС для ограничения доступа к файлам, доступным процессам web-сервера. Эти процессы должны иметь доступ только по чтению к тем файлам, которые необходимы для выполнения сервиса, и не должны иметь доступа к остальным файлам, таким как файлы лога сервера. Следует использовать управление доступом на уровне ОС для обеспечения следующего:
процессы web-сервера должны быть сконфигурированы для выполнения от имени пользователя с очень ограниченным множеством привилегий (т.е. не выполняться как root, администратор или эквивалентные пользователи);
к файлам содержимого web-сайтов процессы web-сервера должны иметь доступ по чтению, но не по записи;
процессы web-сервера не должны иметь возможность записи в директории, в которых хранится публичное содержимое web-сайтов;
только процессы, авторизованные как администратор web-сервера, могут писать в файлы web-содержимого;
приложение web-сервера может писать в файлы логов web-сервера, но лог-файлы не могут читаться приложением web-сервера. Только процессы уровня root/system/administrator могут читать лог-файлы web-сервера ;
временные файлы, создаваемые приложением web-сервера, например, те, которые возникают при формировании динамических web-страниц, должны быть расположены в специальной и соответствующим образом защищенной поддиректории;
доступ к любым временным файлам, созданным приложением web-сервера, ограничен процессами, которые создали эти файлы.
Также необходимо гарантировать, что приложение web-сервера не может хранить файлы вне специального подкаталога, выделенного для публичного web-содержимого. Это может быть задано посредством конфигурации в ПО сервера или может контролироваться ОС. Следует гарантировать, что к директориям и файлам вне специального поддерева директорий не может быть обращений, даже если пользователи знают имена этих файлов.
Для уменьшения воздействия основных типов DoS-атак нужно сконфигурировать web-сервер с ограниченным количеством ресурсов ОС, которые он может использовать. Чаще всего необходимо совершить следующие действия:
инсталлировать содержимое web на отдельном жестком диске или логическом разделе от ОС и web-приложения;
если допустимы загрузки (uploads) на web-сервер, установить ограничение на объем дискового пространства, которое выделяется для этой цели;
если допустимы загрузки (uploads) на web-сервер, эти файлы не должны быть сразу же читаемы web-сервером и, тем самым, видимы пользователям по протоколу НТТР. Они должны быть читаемы web-сервером только после некоторого автоматизированного или ручного процесса просмотра. Это предотвращает от использования web-сервера для передачи пиратского ПО, инструментальных средств атак, порнографии и т.п.;
гарантировать, что лог-файлы хранятся в соответствующем месте, в котором они не смогут исчерпать ресурсы файловой системы.
Эти действия в некоторой степени защитят от атак, которые попытаются заполнить файловую систему информацией, что может вызвать крах системы. Они могут также защитить против атак, которые пытаются заполнить RAM память ненужными процессами для замедления или краха системы, тем самым ограничив доступность сервиса. Информация в логах, созданных ОС, может помочь распознать такие атаки.
Дополнительно часто бывает необходимо сконфигурировать таймауты и другие способы управления для дальнейшего уменьшения влияния основных DoS-атак. Один из типов DoS-атаки состоит в том, чтобы одновременно устанавливать сетевые соединения сверх максимально допустимого, чтобы никакой новый законный пользователь не мог получить доступ. Когда таймауты установлены на сетевые соединения (время, после которого неактивное соединение сбрасывается) в минимально допустимое ограничение, существующие соединения будут завершаться по таймауту так быстро, как только возможно, создавая возможность устанавливать новые соединения законным пользователям. Данная мера только смягчает DoS-атаку, но не уничтожает ее.
Если максимальное число открытых соединений (или соединений, которые являются полуоткрытыми, – это означает, что первая часть ТСР-рукопожатия завершилась успешно) установить в наименьшее число, атакующий может легко израсходовать доступные соединения ложными запросами (часто называемыми SYN flood). Установка в максимум данного числа может смягчить эффект такой атаки, но ценой расходования дополнительных ресурсов. Заметим, что это является проблемой только тех web-серверов, которые не защищены firewall’ом, останавливающим SYN flood атаки. Большинство современных firewall’ов защищают web-сервер от SYN flood атаки, прерывая ее прежде, чем она достигнет web-сервера.
Управление доступом к директории содержимого web-сервера
Не следует использовать ссылки, aliases или shortcuts из дерева директории содержимого web на директории или файлы, расположенные где-то еще на хосте или сетевой файловой системе. Лучше всего запретить возможность ПО web-сервера следовать по ссылкам и aliases. Как указывалось раньше, лог-файлы и конфигурационные файлы web-сервера должны размещаться вне дерева директории, которое определено для публичного содержимого web.
Для ограничения доступа к дереву директории содержимого web требуется выполнить следующие шаги:
выделить отдельный жесткий диск или логический раздел для web-содержимого и использовать поддиректории на данном жестком диске или логическом разделе исключительно для файлов содержимого web-сервера, включая графику, но исключая скрипты и другие программы;
определить отдельную директорию исключительно для всех внешних по отношению к ПО web-сервера скриптов или программ, выполняющихся как часть содержимого web (например, CGI, ASP, PHP);
запретить выполнение скриптов, которые не находятся под исключительным контролем административных аккаунтов. Данное действие выполняется созданием доступа и управлением им к отдельной директории, предназначенной для хранения авторизованных скриптов;
запретить использование жестких и символических ссылок;
определить матрицу доступа к содержимому web. Определить, какие папки и файлы внутри содержимого web-сервера имеют ограничения и какие являются доступными (и кому).
Большинство производителей ПО web-сервера предоставляют директивы или команды, которые позволяют web-администратору ограничить доступ пользователя к файлам содержимого web-сервера. Например, ПО web-сервера Apache предоставляет директиву Limit, которая позволяет web-администратору указать, какие возможности доступа (такие как New, Delete, Connect, Head и Get ) связаны с каждым файлом web-содержимого. Директива Require в Apache позволяет web-администратору ограничивать доступ к содержимому аутентифицированными пользователями или группами.
Многие директивы или команды могут быть перекрыты на уровне директории. Но при этом следует помнить, что удобство, состоящее в возможности делать локальные исключения из глобальной политики, может привести к появлению дыры в безопасности, появившейся в отдельной поддиректории, которая контролируется другим пользователем. Web-администратор должен запретить для поддиректорий возможность перекрывать директивы безопасности верхнего уровня, если это не является абсолютно необходимым.
В большинстве случаев подобные директивы web-сервера должны быть запрещены. НТТР определяет, что URL, заканчивающийся символом слеша, должен трактоваться как запрос на перечисление файлов в указанной директории. Web-сервер должен запрещать отвечать на такие запросы, даже если возможно публичное чтение всех файлов директории. Такие запросы часто указывают на попытку разместить информацию способами, отличными от тех, которые допускает web-администратор. Пользователи могут пытаться это делать, если у них возникают трудности в навигации по сайту или если ссылки в web-страницах обрываются. Нарушитель может пытаться это сделать, чтобы разместить информацию, скрытую интерфейсом сайта. Web-администраторы должны исследовать запросы данного типа, найденные в лог-файлах web-сервера.
Управление влиянием web Bots
Web bots (что тоже самое, что и агенты или spiders) есть прикладное ПО, используемое для сбора, анализа и индексирования web-содержимого. Web bots используются многими организациями в разных целях. Некоторые примеры:
Scooter, Slurp и Googlebot анализируют, индексируют и записывают web-сайты для поисковых систем, таких как AltaVista и Google;
ArchitextSpider собирает статистику Интернета;
Hyperlink validators используются для автоматической проверки корректности гиперссылок на другие сайты;
EmailSiphon и Cherry Picker являются bots, специально разработанными для поиска на web-сайтах e-mail адресов для добавления в e-mail списки ("спам"). Это пример bot, который имеет негативное воздействие на web-сайты или их пользователей.
Bots имеют негативные последствия, потому что:
web-серверы часто содержат директории, которые не должны индексироваться;
организации могут не хотеть, чтобы часть их сайта появлялась в поисковых системах;
web-серверы часто содержат временные страницы, которые не должны индексироваться;
bots часто содержат ошибки или не всегда имеют хорошие намерения и могут нанести вред частыми запросами, создавая DoS-атаку для законных пользователей.
В принципе, существует способ для web-администратора повлиять на поведение большинства bots на своем web-сайте. Была создана серия соглашений, называемая Robots Exclusion Standard (REP). Хотя REP не является официальным стандартом Интернета, он поддерживается большинством хорошо написанных и имеющих благие цели bots, включая те, которые используются в большинстве поисковых систем.
Web-администраторы, которые хотят ограничить деятельность bots на своих web-серверах, должны создать тестовый файл, называемый robots.txt. Файл должен всегда иметь данное имя и располагаться в корневой директории web-сервера. Кроме того, допускается только один такой файл на весь web-сайт. Заметим, что файл robots.txt является стандартом, который на добровольной основе должен поддерживаться программистами bots. Не существует обязательного требования использовать его. Таким образом, вредоносные bots, такие как EmailSiphon и Cherry Picker, игнорируют данный файл.
Robots.txt является простым тестовым файлом, который содержит определенные ключевые слова и спецификации файла. Каждая строка файла либо является пустой, либо состоит из единственного ключевого слова и относящейся к нему информации. Ключевые слова используются для того, чтобы сказать роботам, какую часть web-сайта следует исключить из их анализа.
Допустимы следующие ключевые слова:
User-agent – имя робота или spider. Web-администратор может указать более одного имени агента, при этом действие будет применяться к каждому указанному bot. Запись нечувствительна к регистру (слово "googlebot" – то же самое, что и "GoogleBot", "GOOGLEBOT"). "*" указывает, что это запись по умолчанию, которая используется, если никакого соответствия не найдено. Например, если указать "GoogleBot", то "*" будет применяться к любому другому роботу, за исключением GoogleBot.
Disallow – говорит bots, какие разделы web-сайта следует исключить. Например, /images информирует bots, что не следует открывать или индексировать любые файлы в директории images и любых ее поддиректориях. Таким образом, директория /images/special также не будет индексироваться указанными в user-agent bots.
Заметим, что /do будет соответствовать любой директории, начинающейся с "/do" (например, /do, /document, /docs и т.п.), в то время как /do/ соответствует только директории, называемой "/do/".
Web-администратор может также указать конкретные файлы. Например, он может указать /mydata/help.html для предотвращения доступа только к одному файлу.
Значение "/" указывает, что ничего на web-сайте не разрешено для доступа указанных в user-agent bots.
Должна существовать по крайней мере одна запись на каждый user-agent.
Существует много способов использовать файл robots.txt. Несколько простых примеров:
запретить всем (учитывающим это) bots доступ в указанные директории:
User-agent: *
Disallow: /images/
Disallow: /banners/
Disallow: /Forms/
Disallow: /Dictionary/
запретить всем (учитывающим это) bots доступ ко всему web-сайту:
User-agent: *
Disallow: /
запретить конкретному bot анализировать конкретную web-страницу:
User-agent: GoogleBot
Disallow: tempindex.html
Заметим, что файл robots.txt доступен всем. Следовательно, web-администратор не должен указывать имена чувствительных файлов или папок. Если они должны быть исключены, то лучше использовать защищенные паролем страницы, которые не могут быть доступны bots. Защита паролем является более надежным способом для исключения не придерживающихся правил bots. Более подробная информация будет приведена при описании методов аутентификации.
Использование программ проверки целостности файлов
Программа проверки целостности файла является приложением, которое вычисляет и хранит криптографическую контрольную сумму каждого защищаемого файла и поддерживает базу данных контрольных сумм файлов. Это позволяет системному администратору легко распознать изменения, в частности, неавторизованные, сделанные в критичных файлах. Контрольные суммы должны перевычисляться регулярно для сравнения текущего значения с хранимым значением, что позволит определить любые модификации файла. Возможность проверки целостности файлов часто включается в системы обнаружения проникновений для хоста, но такая проверка может быть доступна и в виде отдельной программы.
Хотя программа проверки целостности и является полезным инструментальным средством, которое не требует большого участия человека, для гарантии эффективности она должна использоваться продуманно.
При создании первого варианта базы данных файлом проверки целостности требуется гарантия, что система находится в безопасном состоянии. В противном случае могут быть созданы криптографические хэши скомпрометированной системы, и тем самым создастся ложное чувство безопасности у тестирующего.
База данных контрольных сумм должна храниться off-line, чтобы атакующий не мог скомпрометировать систему и модифицировать базу данных с целью спрятать следы атаки.
Программа проверки целостности файлов может также создавать ложные позитивные предупреждения. Каждое изменение файла и каждый системный patch изменяет файл и, следовательно, требуется изменить базу данных контрольных сумм. Таким образом, держать базу данных актуальной может быть непросто.
Однако, даже если программа проверки целостности выполняется только один раз (при первой инсталляции системы), она может быть полезна для определения того, какие файлы были модифицированы в случае предполагаемой компрометации. Наконец, атакующий может так модифицировать файл, что использование 32-битной циклической контрольной суммы (Cyclic Redundancy Check – CRC) не определит модификацию. Следовательно, рекомендуются более сильные алгоритмы подсчета контрольных сумм для гарантирования целостности данных.
Программы проверки целостности должны выполняться ночью для проверки некоторой файловой системы, которая могла быть скомпрометирована. Если программа проверки целостности определит неавторизованные модификации системных файлов, должна быть рассмотрена возможность инцидента, связанного с безопасностью, и осуществлены соответствующие процедуры, согласно установленной политики безопасности.
Список действий для безопасного инсталлирования и конфигурирования web-сервера
Безопасное инсталлирование web-сервера.
Инсталлировать ПО сервера на выделенный хост.
Инсталлировать минимально требуемые сервисы Интернета.
Применить все patches и upgrades для устранения известных уязвимостей.
Создать выделенный физический диск или логический раздел (отдельно от ОС и приложения сервера) для web-содержимого.
Удалить или запретить все сервисы, инсталлированные приложением web-сервера, но в данном случае не требуемые (например, gopher, FTP и удаленное администрирование).
Удалить все примеры страниц, скриптов и выполняемого кода.
Удалить с сервера всю документацию производителя.
Протестировать сервер, применив различные образцы безопасности или скрипты взлома.
Переконфигурировать баннер НТТР-сервиса (и баннеры других сервисов, если требуется), чтобы он не сообщал о типе и версии web-сервера и ОС.
Конфигурирование управления доступом web-сервера со стороны ОС.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы процессы web-сервера могли только читать файлы web-содержимого, но не могли записывать в них.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы процессы web-сервера не могли записывать в директории, в которых расположено содержимое web.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы только процессы, авторизованные для администрирования web-сервера, могли записывать в файлы содержимого web.
– Сконфигурировать доступ к файлам со стороны ОС так, чтобы web-приложение могло писать в лог-файлы web-сервера, но лог-файлы не могли быть читаемы приложением web-сервера.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы временные файлы, создаваемые приложением web-сервера, были расположены только в указанной и соответствующим образом защищенной поддиректории.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы доступ к любым временным файлам, созданным приложением web-сервера, был ограничен только процессами, которые создали эти файлы.
Инсталлировать web-содержимое на отдельном жестком диске или логическом разделе, отличном от ОС и web-приложения.
Сконфигурировать доступ к файлам со стороны ОС так, что если допустима загрузка на web-сервер, то должно существовать ограничение на пространство жесткого диска или логического раздела, которое выделено для этих целей.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы лог-файлы имели соответствующий максимальный размер.
Конфигурирование безопасной директории web-содержимого.
Выделить отдельный жесткий диск или логический раздел для web-содержимого и установить соответствующие поддиректории исключительно для файлов содержимого web-сервера, включая графику, но исключая скрипты и другие программы.
Определить отдельную директорию исключительно для всех внешних по отношению к ПО web-сервера скриптов или программ, выполняющихся как часть содержимого web-сервера например, CGI, ASP и т.п.).
Запретить выполнение скриптов, которые не находятся под управлением административных аккаунтов. Данное действие выполняется созданием доступа и управлением им к отдельной директории, которая предназначена для авторизованных скриптов.
Создать группы и пользователей для web-сервера.
Запретить использование жестких и символических ссылок (аналог shortcuts в Windows).
Определить полную матрицу доступа к web-содержимому. Определить, какие папки и файлы внутри документов web-сервера имеют ограничения и какие являются доступными (и кому).
Проверить политику паролей в организации и установить соответствующие критерии паролей (длина, сложность).
Использовать при необходимости файл robots.txt.
Использование программ проверки целостности.
Инсталлировать проверку целостности для защиты конфигурационных файлов web-сервера.
Пересчитывать контрольные суммы при изменении содержимого файлов.
Хранить контрольные суммы в защищенном от записи носителе.
Регулярно сравнивать контрольные суммы критичных файлов с эталонными значениями.
Введение
В самом общем виде web можно разделить на два основных компонента: web-серверы — они являются приложениями, которые формируют информацию, доступную по протоколу НТТР, и web-браузеры (клиенты) — они используются для доступа и показа информации, хранящейся на web-серверах. В основном будем рассматривать проблемы безопасности, касающиеся web-серверов.
К сожалению, web-серверы часто являются целями атак. Вследствие этого важно гарантировать безопасность web-серверов, а также сетевой инфраструктуры, которая их поддерживает. Угрозы безопасности, специфичные для web-серверов в общем случае можно разделить на следующие категории:
Враждебно настроенные пользователи интернета могут использовать ошибки ПО в web-серверах лежащей в основе ОС или в программах, создающих динамические web-страницы, для получения неавторизованного доступа к web-серверу.
Результатом этого может быть получение доступа к файлам или каталогам, которые не предназначены для открытого доступа, либо выполнение привилегированных команд и/или установка ПО на web-сервер.
Информация на web-сервере может быть преднамеренно изменена с враждебными целями. Наиболее общим примером такой угрозы является подмена содержимого web-сайта.
Denial of service (DoS) атаки могут быть направлены на web-сервер что приведет к отказу в доступе законным пользователям.
Чувствительная информация, передаваемая в открытом виде между web-сервером и браузером, может быть перехвачена.
Пользователи могут получить неавторизованный доступ к ресурсам, расположенным где-то еще в локальной сети организации, используя успешную атаку на web-сервер.
Возможно осуществление атаки на другие сети и серверы, причем будет использован скомпрометированный web-сервер, скрыта настоящая идентификация и, иногда, ответственность за последствия возложена на администратора web-сервера, с которого выполняется атака.
Сервер может быть использован в качестве незаконной точки распространения ПО, инструментальных средств атаки, при этом на администратора сервера может быть возложена ответственность за последствия атаки.
Рассмотрим проблемы, связанные с безопасностью при инсталлировании, конфигурировании и сопровождении web-серверов. Перечислим кратко основные вопросы:
Безопасное инсталлирование и конфигурирование лежащей в основе ОС.
Безопасное инсталлирование и конфигурирование ПО web-сервера.
Развертывание соответствующих сетевых механизмов защиты:
Firewall’ы;
Intrusion detection systems (IDS);
DNS.
Поддержка безопасной конфигурации, со своевременным применением соответствующих patches и upgrades, тестированием безопасности, просмотром логов и выполнение backup’ов как данных, так и ОС.
Обеспечение защиты информации, исходя из ее семантики.
Здесь нужно придерживаться следующих принципов.
Следует реализовать соответствующую практику управления безопасностью и контроль за функционированием системы.
Соответствующая практика управления является критичной для функционирования и поддержки безопасного web-сервера. Необходимо определить требования к развертыванию, документированию и реализации политик, стандартов, процедур и руководств, которые гарантируют конфиденциальность, целостность и доступность информационных ресурсов.
Для гарантирования безопасности web-сервера и поддержки сетевой инфраструктуры должны быть рассмотрены и реализованы следующие основные моменты:
Политика безопасности информационной системы организации.
Принципы управления и контроля конфигурации и ее изменений.
Анализ риска и определенные подходы к управлению риском.
Стандартные конфигурации ПО, которые удовлетворяют политике безопасности информационной системы.
Необходимый объем знаний и тренинги, обеспечивающие требуемый объем знаний.
Способы восстановления после внезапных сбоев.
Соответствующая сертификация и аккредитация.
Следует гарантировать, что ОС, на которой выполняется web-сервер, развернута, сконфигурирована и управляется в соответствии с требованиями безопасности.
Первым шагом в обеспечении безопасности web-сервера является безопасность лежащей в основе ОС. Большинство доступных web-серверов выполняются на ОС общего назначения. Многих проблем безопасности можно избежать, если ОС, лежащая в основе web-сервера, сконфигурирована соответствующим образом. Конфигурации по умолчанию для аппаратуры и ПО обычно устанавливаются производителями, при этом, как правило, делается упор на использование возможностей, функциональностей исходного ПО, а также на простоту использования возможностей, связанных с безопасностью. Также следует понимать, что производители не знают требований безопасности каждой организации, поэтому web-администратор должен сконфигурировать новые серверы в соответствии с требованиями безопасности и переконфигурировать их каждый раз при изменении этих требований. Обеспечение безопасности ОС как минимум должна включать следующие шаги:
выполнение patch’ей и upgrade’ов ОС;
удаление или запрещение ненужных сервисов и приложений;
конфигурирование управления ресурсами;
тестирование безопасности ОС.
Следует гарантировать, что ПО web-сервера развернуто, сконфигурировано и управляется в соответствии с требованиями безопасности, определенными в организации.
Во многих аспектах инсталляция и конфигурирование безопасности ПО web-сервера аналогично процессу инсталляции и конфигурирования ОС. Главным принципом, как и раньше, является инсталляция минимального числа требуемых сервисов web-сервера и удаление всех известных уязвимостей с помощью patche’ей и upgrade’ов. Если инсталляционная программа устанавливает какие-то ненужные приложения, сервисы или скрипты, они должны быть удалены немедленно после завершения процесса установки. Обеспечение безопасности web-сервера как минимум должно включать следующие шаги:
выполнение patch’ей и upgrade’ов ПО web-сервера – удаление или запрещение ненужных сервисов, приложений и примеров содержимого;
конфигурирование аутентификации пользователей web-сервера ;
конфигурирование управления ресурсами web-сервера ;
тестирование безопасности приложения web-сервера и конкретного содержимого web-сервера.
Следует предпринять шаги для гарантирования того, что на web-сайте публикуется только корректное содержимое.
Должна существовать четкая политика в определении того, какой тип информации является открытым, к какой информации следует ограничить доступ и какая информация не должна публиковаться в публично доступном репозитории.
Следует гарантировать защиту web-содержимого от неавторизованного доступа или модификации.
Должна существовать определенная политика, гарантирующая невозможность модификации без выполнения авторизации. Требуется обеспечить гарантию целостности, даже если информация не является конфиденциальной. Необходимо защищать содержимое web посредством выполнения соответствующего управления ресурсами web-сервера. Некоторые примеры управления ресурсами включают:
инсталлирование только необходимых сервисов;
инсталлирование web-содержимого на выделенном жестком диске или в выделенном разделе;
возможность выполнять запись (uploads) только в директории, которые не являются читаемыми из web-сервера, а доступны по некоторому другому протоколу (например, ftp);
определение единственной директории для всех скриптов или программ, которые выполняются для создания web-содержимого и являются внешними по отношению к web-серверу ;
запрещение использования жестких или символических ссылок в файловой системе ОС, на которой выполняется web-сервер ;
создание матрицы доступа к web-содержимому, которая определяет, какие папки и файлы внутри директории web-сервера имеют ограничения по доступу;
запрет просмотра директории в файловой системе;
использование аутентификации пользователей с помощью цифровых подписей и других криптографических механизмов;
использование систем обнаружения проникновений, основанных на хосте и /или проверки целостности файлов, для обнаружения проникновения и проверки целостности web-содержимого.
Следует использовать активное содержимое только после тщательного взвешивания получаемых при этом преимуществ в сравнении с увеличением рисков.
Вначале большинство web-сайтов представляли собой статическую информацию, расположенную на сервере, обычно в форме текстовых документов, имеющих соответствующую разметку (HTML). В дальнейшем вводились различные интерактивные элементы. К сожалению, эти интерактивные элементы вносят новые уязвимости, так как они предполагают пересылку определенного рода информации как от web-сервера к клиенту для выполнения на стороне клиента, так и от клиента к web-серверу для обработки информации на стороне сервера. Различные технологии создания активного содержимого имеют различные уязвимости, которые должны быть оценены в сравнении с получаемыми преимуществами.
Следует использовать аутентификацию, основанную на криптографических технологиях, для обеспечения соответствующей защиты чувствительных данных.
Публичные web-серверы обычно поддерживают широкий спектр технологий идентификации и аутентификации пользователей и определения различных привилегий для доступа к информации. Некоторые из этих технологий основаны на криптографических функциях, которые могут обеспечивать тот или иной тип зашифрованного канала между клиентом web-браузера и web-сервером. Web-серверы могут быть сконфигурированы для использования различных криптографических алгоритмов, обеспечивающих различные уровни безопасности.
Без наличия аутентификации пользователей нет возможности обеспечить разграничение доступа к чувствительной информации. Без наличия сильных механизмов аутентификации вся информация, которая расположена в web-пространстве сервера, может стать доступной любому. Кроме того, без процесса аутентификации сервера пользователи не имеют возможности определить, что сервер является требуемым, а не поддельным, созданным враждебно настроенным участником для перехвата конфиденциальной информации о пользователе.
Следует обеспечивать безопасность сетевой инфраструктуры для защиты web-серверов.
Сетевая инфраструктура, в которой функционирует web-сервер, играет важную роль в обеспечении безопасности web-сервера. Во многом сетевая инфраструктура является первой линией обороны web-сервера. Однако только тщательное проектирование сети не является достаточным для защиты web-сервера. Частота и варианты web-атак, совершаемых сегодня, говорят о том, что безопасность web-серверов может быть обеспечена только с использованием различных и расположенных на разных уровнях механизмов обороны (так называемая "оборона вглубь").
Следует гарантировать постоянное функционирование системы обеспечения безопасности.
Поддержание безопасного функционирования web-сервера требует постоянных усилий и наличия достаточного количества ресурсов. Поддержание безопасности web-сервера обычно включает следующие шаги:
своевременное применение patch’ей и upgrade’ов;
конфигурирование, защита и анализ лог файлов;
частое выполнение back up’а критической информации;
поддержка защищенных копий web-содержимого;
определение процедур восстановления при компрометации и следование им при обнаружении проникновения;
периодическое тестирование безопасности.
Рассмотрим общие принципы, которые применимы ко всем системам.
Причины уязвимости web-сервера
Основные проблемы, связанные с безопасностью функционирования публично доступного web-сайта, возникают по следующим причинам:
Неправильная конфигурация или другое некорректное действие над web-сервером, которое может привести к раскрытию или изменению информации.
Уязвимости ПО web-сервера, которые могут допускать, например, чтобы атакующий компрометировал безопасность сервера или других хостов в сети.
Неадекватные механизмы защиты web-сервера, предусмотренные в его окружении.
ПО на стороне сервера (скрипты, JSP, ASP и т.п.), которое содержит ошибки, позволяющие атакующим компрометировать безопасность web-сервера.
Планирование развертывания web-сервера
При планировании развертывания web-сервера следует рассмотреть следующие пункты:
Определить цели web-сервера ;
Какие категории информации будут храниться в web-сервере.
Какие категории информации будут обрабатываться или передаваться через web-сервер.
Каковы требования безопасности для данной информации.
Существует ли информация, которая получена с другого сервера или хранится на другом сервере (например, backend база данных, почтовый сервер, прокси-сервер).
Какие еще сервисы предоставляет web-сервер (должен ли web-сервер выполняться на выделенном хосте).
Каковы требования безопасности для этих дополнительных сервисов.
Определить сетевые сервисы, которые будет предоставлять web-сервер, и используемые при этом протоколы:
НТТР, НТТРS, SOAP и т.п. – протоколы взаимодействия с клиентами.
ODBC, JDBC, LDAP, LDAPS, NFS и т.п. – протоколы взаимодействия с backend-системами.
Определить все необходимое ПО, которое требуется для поддержки функционирования web-сервера ;
Определить категории пользователей web-сервера и всех backend-систем;
Определить способы аутентификации пользователей и web-сервера и способы защиты аутентификационных данных;
Определить, как будет предоставляться соответствующий доступ к информационным ресурсам.
Безопасность лежащей в основе ОС
Первым шагом в обеспечении безопасности web-сервера является безопасность лежащей в его основе ОС. Большинство общедоступных web-серверов функционируют на ОС общего назначения. Многих проблем безопасности можно избежать, если ОС соответствующим образом сконфигурирована. Конфигурации по умолчанию аппаратуры и ПО обычно поставляются производителями с упором на возможности безопасного функционирования и возможности легкого расширения. Так как производители не знают потребности безопасности каждой организации, каждый web-администратор должен сконфигурировать новые серверы в соответствии с требованиями безопасности своей организации.
Данная технология в различных ОС может сильно отличаться. Также могут существовать некоторые автоматизированные инструментальные средства для настройки ОС с точки зрения безопасности.
Выбор приложения web-сервера может определяться выбором ОС. Однако по возможности web-администраторы должны выбрать ОС, которая обеспечивает следующее:
возможность ограничить деятельность административного уровня или уровня root только авторизованными пользователями;
возможность управлять доступом к данным на сервере;
возможность запретить сетевые сервисы, не являющиеся необходимыми, которые встроены в ПО ОС или сервера;
возможность управления доступом к различным формам выполнимых программ, таких как CGI-скрипты и plug-ins, на стороне сервера;
возможность записывать в лог соответствующую деятельность сервера для определения проникновения и попыток проникновения.
Безопасное инсталлирование и конфигурирование ОС
Применение Patch и Upgrade ОС
После того как ОС инсталлирована, следует применить все patches и upgrades для удаления известных уязвимостей. Все ОС, реализованные сегодня, имеют известные уязвимости, которые должны быть удалены перед использованием ОС в качестве хоста web-сервера. Для адекватного определения и корректирования этих уязвимостей web-администратор должен:
идентифицировать уязвимости и применить patches;
смягчить уязвимости, для которых пока patches еще не доступны, не протестированы или не установлены;
проводить регулярное инсталлирование fixes (часто называемых patches, hotfixes, service packs или updates).
Удаление или запрещение ненужных сервисов и приложений
Идеально, чтобы web-сервер был выделенным и использовался только для этой цели. Многие ОС сконфигурированы по умолчанию для предоставления более широкого круга сервисов и приложений, чем требуется web-серверу ; следовательно, web-администратор должен сконфигурировать ОС, удалив или запретив сервисы, не являющиеся необходимыми. Приведем некоторые примеры сервисов, которые обычно должны быть запрещены:
NetBIOS, если не требуется.
NFS, если не требуется.
FTP.
Berkley "r" сервисы (например, rlogin, rsh, rcp).
Тelnet.
NIS.
SMTP.
Компиляторы.
Инструментальные средства разработки ПО, за исключением того случая, когда HTML страницы создаются каким-либо интерпретатором, например, Perl. В этом случае должен быть оставлен только используемый интерпретатор.
Удаление ненужных сервисов и приложений является предпочтительным, чем просто запрещение с помощью конфигурационных установок, потому что атакующий может попытаться изменить установки и активизировать запрещенные сервисы, что нельзя сделать при полном удалении.
Удаление или запрещение ненужных сервисов усиливает безопасность web-сервера по следующим причинам:
ненужные сервисы не могут быть скомпрометированы и использованы для атаки на хост или для повреждения сервисов web-сервера. Каждый имеющийся в наличии сервис увеличивает риск компрометации хоста, потому что каждый сервис потенциально открывает вход для доступа атакующего;
обычно различные сервисы могут администрировать разные люди. Следует изолировать сервисы таким образом, чтобы каждый хост имел одного администратора при минимально возможных конфликтах между администраторами. Наличие одного администратора, отвечающего за хост, приводит к лучшему распределению обязанностей;
хост может быть лучше сконфигурирован для удовлетворения требований конкретного сервиса. Различные сервисы могут требовать наличия различной аппаратуры и конфигураций ПО, которые приводят к возникновению уязвимостей или ограничениям сервиса;
при уменьшении числа сервисов уменьшается и количество логов и записей лога, благодаря чему обнаружение некорректного поведения становится легче.
При конфигурировании ОС следует применять принцип "запретить все, за исключением того, что явно разрешено" — это означает запретить и по возможности удалить все сервисы и приложения и затем выборочно разрешить те, которые требуются web-серверу. Также нужно по возможности установить минимальную конфигурацию ОС, которая требуется для приложения web-сервера. Если система инсталляции ОС предоставляет опцию "минимальная инсталляция", то нужно выбрать ее, потому что это минимизирует усилия, требуемые для удаления ненужных сервисов. Многие скрипты или программы типа uninstall не выполняют полного удаления всех компонент сервиса; следовательно, всегда лучше по возможности избегать инсталлирования ненужных сервисов.
Необходимые web-серверу сервисы зависят от функций, которые должен обеспечивать сервер. Эти сервисы могут включать протоколы баз данных для доступа к базе данных, протоколы передачи файлов и сервисы удаленного администрирования. Каждый из этих сервисов, даже если он необходим, увеличивает риск для сервера. Когда риски перекрывают преимущества, следует рассмотреть необходимость наличия каждого сервиса.
Конфигурирование аутентификации пользователя в ОС
Авторизованных пользователей, которые могут конфигурировать систему и запускать различные сервисы, обычно очень мало. Однако пользователей, которые могут иметь доступ к публичному web-серверу, может быть как неограниченное количество, так и некоторое ограниченное подмножество Интернет-сообщества. Для обеспечения политики безопасности web-администратор должен сконфигурировать систему для аутентификации пользователей, которым разрешен вход, требуя предоставления доказательства своей идентификации. Даже если web-сервер разрешает неаутентифицированный доступ к большинству сервисов, администрирование и другие типы специализированного доступа должны быть ограничены определенными персонами или ролями.
Конфигурирование компьютера для аутентификации обычно включает конфигурирование ОС, firmware и приложений на сервере, таких как ПО, которое реализует сетевой сервис. В специальных случаях для сайтов с высоким риском или хранящих важные данные можно также применять аппаратуру для аутентификации, например, токены или устройства с одноразовыми паролями. Использование аутентификационных механизмов, в которых аутентификационная информация является переиспользуемой (например, пароли) и передается в явном виде по сети, не рекомендуется, потому что информация может быть перехвачена и задействована атакующим для подделки под аутентифицированного пользователя.
Для гарантии того, что соответствующая аутентификация пользователя выполняется, необходимо выполнить следующие шаги.
Удалить или запретить неиспользуемые аккаунты и группы, созданные по умолчанию. Конфигурация ОС по умолчанию часто включает аккаунт guest (как с паролем, так и без), аккаунты уровня администратора или root, связанные с локальными и сетевыми сервисами. Имена и пароли этих аккаунтов хорошо известны. Удаление или запрещение ненужных аккаунтов предотвращает их использование для проникновения, включая аккаунты guest, на компьютерах, содержащих чувствительную информацию. Если существует требование оставить аккаунт или группу guest, следует ограничить их доступ и изменить пароль в соответствии с политикой для паролей в организации. Для аккаунтов по умолчанию, которые необходимо оставить, следует изменить имена (где возможно, особенно для аккаунтов уровня администратора или root) и пароли в соответствии с политикой для паролей. Следует помнить, что имена аккаунтов и пароли по умолчанию хорошо известны злоумышленникам.
Запретить неинтерактивные аккаунты. Запретить аккаунты (и связанные с ними пароли), которые должны существовать, но не требуют интерактивного входа. Для Unix-систем запретить входной shell или предоставить входной shell с функциональностью NULL ( /bin/false ).
Создать группы пользователей. Привязать пользователей к соответствующим группам и назначать права группам. Данный подход предпочтительнее, чем назначать права индивидуальным пользователям.
Создать аккаунты пользователей. Определить, кто авторизован использовать каждый компьютер и его сервисы. Создать только необходимые аккаунты. Не допускать использования разделяемых аккаунтов.
Проверить политику для паролей в организации. Установить пароли аккаунтов соответствующим образом. Данная политика должна рассматривать следующее:
длина – минимальная длина паролей;
сложность – требуемые символы. Требуемые пароли содержат буквы как верхнего, так и нижнего регистров и, по крайней мере, один неалфавитный символ;
срок использования – как долго можно не изменять пароль. Требовать от пользователей периодически изменять пароли. Пароль уровня администратора или root должен изменяться каждые 30–120 дней. Пароль пользователя также должен периодически изменяться. Этот период определяется длиной и сложностью пароля в сочетании с чувствительностью защищаемой им информации;
переиспользуемость – может ли пароль переиспользоваться. Некоторые пользователи пытаются обойти требование устаревания пароля, изменяя пароль на тот, который они уже использовали до этого. Нужно по возможности гарантировать, что пользователь не может изменить пароль простым добавлением "предполагаемых" символов к своему исходному паролю. Например, исходный пароль был "mysecret", а измененный – "mysecret1" или "1mysecret";
авторство – кому разрешено изменять или переустанавливать пароли и какого типа доказательство требуется перед началом любых изменений.
Сконфигурировать компьютеры для запрещения входа после небольшого числа неудачных попыток. Следует помнить, что может быть относительно легко для неавторизованного пользователя получить доступ к компьютеру, используя автоматические программные средства, которые перебирают все пароли. Чтобы ОС не предоставляла такую возможность, ее следует сконфигурировать таким образом, когда она будет запрещать вход после трех неудачных попыток. Обычно аккаунт блокируется на определенное время (например, 30 минут) или до тех пор, пока пользователь с соответствующими полномочиями не активирует его.
Это пример ситуации, когда от web-администратора требуется принятие решения о балансе между безопасностью и удобством. Реализация данной возможности может помочь предотвратить некоторые типы атак, но может также позволить злоумышленнику выполнить неудачные попытки входа для недопущения доступа пользователя, т.е. выполнить DoS-атаку для конкретного пользователя.
Неудачные попытки сетевого входа не должны запрещать вход с консоли пользователя и тем более администратора. Заметим также, что все неудачные попытки по сети или с консоли должны регистрироваться. Также, если удаленное администрирование не предусмотрено, следует запретить возможность входа по сети аккаунтам уровня администратора или root.
Инсталлировать и сконфигурировать другие механизмы безопасности для усиления аутентификации. Если информация на web-сервере требует этого – рассмотреть использование других аутентификационных механизмов, таких как токены, сертификаты клиента и сервера или системы одноразовых паролей. Хотя они могут быть более дорогими и трудными в реализации, это, возможно, оправдается в некоторых случаях. Когда используются подобные механизмы аутентификации и устройства, политика организации должна быть пересмотрена и в ней отражен наилучший способ их применения.
Создавать и распространять отчеты об использовании аккаунтов пользователей. Для того чтобы гарантировать, что все неиспользуемые аккаунты удаляются своевременно, важно установить в организации систему, которая создает отчеты о пользовательских аккаунтах, включающие информацию, необходимую для определения того, должен ли аккаунт оставаться активным. Эти отчеты должны распространяться соответствующим пользователям и управляющему персоналу для определения индивидуумов, которым более не требуется иметь аккаунт.
Как отмечалось ранее, нарушитель, используя сетевые сниферы, может легко перехватить переиспользуемые пароли, передаваемые по сети в явном виде. Вместо этого следует использовать менее уязвимые технологии аутентификации и шифрования, такие как SSH и SSL/TLS.
Управление ресурсами на уровне ОС
Многие ОС имеют возможность указать конкретные привилегии доступа для файлов, директорий, устройств и других коммуникационных ресурсов. Тщательно продумывая управление доступом, web-администратор может уменьшить преднамеренные и непреднамеренные бреши в безопасности. Например, запрет доступа по чтению к файлам и директориям помогает обеспечить конфиденциальность информации, тогда как запрет доступа по записи помогает обеспечить целостность информации. Разрешая выполнение большинства инструментальных средств системного уровня только системным администратором, можно предотвратить внесение пользователями изменений в конфигурацию, которые понижают безопасность системы. Такое ограничение может также уменьшить возможность атакующего использовать эти инструментальные средства для атаки как на данную систему, так и на другие системы в сети. Так как управление ресурсами ОС тесно связано с управлением ресурсами web-сервера, данная проблема будет рассмотрена далее в деталях.
Альтернативные платформы для web-сервера
Часто web-серверы выполняются на ОС общего назначения. В то же время существуют примеры, когда используется одна из альтернатив, обсуждаемых ниже. Хотя данные средства являются относительно новыми для web-серверов, они основаны на надежных технологиях и, возможно, скоро найдут широкое применение для использования в качестве окружения web-сервера.
Trusted ОС
Trusted ОС ( TOS являются модифицированными с учетом требований безопасности или специально усиленные ОС, которые включают дополнительные механизмы безопасности, отсутствующие в ОС общего назначения. Они уже изначально создавались с использованием мандатного управления доступом. TOS обеспечивают безопасную политику управления, четко определенное множество привилегий доступа, расширяемые возможности создания логов и аудита. Большинство TOS подвергались независимой проверке для гарантии того, что они соответствуют множеству требований, указанных в их документации.
TOS обычно используются в приложениях, где безопасность очень важна. TOS могут безопасно управлять всеми аспектами своего окружения, включая сетевые ресурсы, пользователей, процессы, память и т.п. Более конкретно, TOS имеют возможность ограничить доступ к системным ресурсам таким способом, в который нельзя вмешаться или скомпрометировать.
Использование TOS обычно приводит к созданию очень безопасного web-сервера, однако существуют определенные трудности при их использовании. Основной недостаток состоит в том, что администрирование TOS требует хорошего знания каждой защищенной подсистемы. Тем не менее, даже при таких ограничениях, организации, которые имеют большие требования к безопасности, должны рассмотреть возможность использования TOS для поддержки web-серверов.
Должны быть рассмотрены следующие вопросы при определении того, какую платформу использовать для web:
какая ОС лежит в основе и насколько проанализирована ее безопасность;
имеет ли организация опыт администрирования TOS – какова дополнительная цена покупки и поддержки TOS по сравнению с ее преимуществами;
совместима ли TOS с существующими в организации web-приложениями и скриптами.
Использование Appliances для web-сервера
Относительно недавние разработки в области web-серверов привели к появлению так называемых web Appliances. Web Appliances является комбинацией ПО и аппаратуры, которая разработана, чтобы быть "plug-and-play" web-сервером. Эти Appliances используют упрощенную ОС, которая оптимизирована для поддержки web-сервера. Упрощенная ОС обеспечивает безопасность, минимизируя возможности, сервисы и опции, которые не являются необходимыми для web-приложений. ПО web-сервера в таких системах часто заранее инсталлировано и заранее сконфигурировано с точки зрения безопасности.
Такие системы часто имеют преимущества, относящиеся к наличию дополнительной безопасности. Выполнение часто улучшается, так как система (ОС, ПО web-сервера и аппаратура) разработана и собрана специально для выполнения web-сервера. Цена на них зачастую ниже, так как аппаратура и ПО не требуют специальной настройки для web-сервера. Такие системы могут быть отличным решением для малых и средних организаций, которые не могут себе позволить иметь web-администратора на полную ставку.
Самым большим недостатком таких систем является то, что они не подходят для больших сложных и многоуровневых web-сайтов. Они могут также не подойти организациям, которым требуется более одного сервера, если только организация не захочет покупать web Appliances от одного производителя, так как такая простота делает трудным конфигурирование вместе web Appliances от разных производителей. Web Appliances доступны от основных производителей аппаратуры и от различных специализированных производителей web Appliances.
Некоторые вопросы, которые следует рассматривать при принятии решения о покупки web Appliances:
какая ОС лежит в основе и как она протестирована с точки зрения безопасности;
как web Appliance само протестировано с точки зрения безопасности. (Заметим, что конфигурационные опции web Appliances являются ограниченными, таким образом, web Appliance обычно бывает безопасным только при инсталляции по умолчанию);
какова разнородность инфраструктуры web-сервера организации. (Различные торговые марки web Appliances, как правило, не очень хорошо работают вместе);
имеется ли возможность какого-либо расширения web Appliances. (Организация, которая предполагает быстрый рост, может не захотеть ограничивать себя web Appliance).
Специально усиленные (pre-hardened) ОС и web-серверы
Сегодня распространяется всё возрастающее число специально усиленных ОС и пакетов web-сервера. Эти пакеты включают ОС и ПО web-сервера, которые модифицированы и заранее сконфигурированы для обеспечения большой безопасности. Некоторые из этих пакетов содержат и аппаратную платформу, другие являются ПО, которое состоит только из ОС и ПО web-сервера. Эти дистрибутивы обычно основаны на специально усиленной и/или модифицированной ОС общего назначения (например, Linux, Unix и, реже, Windows), которая специально разработана для поддержки безопасного web-сервера. Приложение web-сервера также часто основано на усиленном и/или модифицированном обычном ПО web-сервера например, Apache или IIS). Эти пакеты зачастую включают большее число опций безопасности и разработаны для более легкого конфигурирования с помощью заранее cкомпилированных скриптов и GUIs. Хотя все пакеты различны, они обычно обеспечивают какие-либо из следующих возможностей:
безопасная начальная конфигурация обеспечена по умолчанию;
наличие усиленной ОС и/или TOS – наличие усиленного ПО web-сервера ;
расширяемые возможности аудита;
наличие разного рода оберток (wrappers) для приложений;
наличие возможностей сетевых wrappers и/или host-based firewall;
host-based IDS;
упрощенное администрирование безопасности (например, меню, GUIs).
Эти типы систем должны быть рассмотрены организацией, которая понимает важность угроз и/или имеет важные данные на web-сайтах (например, правительственные организации, банки и т.п.). Такие пакеты доступны от некоторых основных производителей аппаратуры и ПО, а также от некоторых специализированных производителей.
Некоторые вопросы, которые следует рассмотреть при приобретении усиленного web Appliance.
Какая ОС лежит в основе и как она протестирована относительно безопасности.
Как само ПО web-сервер протестировано относительно безопасности.
Насколько трудно его администрировать.
Совместимо ли усиленное ПО web-сервер с существующими в организации web-приложениями и скриптами.
Тестирование безопасности операционной системы
Периодическое тестирование безопасности ОС является важным способом идентифицировать уязвимости и гарантировать, что существующие меры обеспечения безопасности эффективны. Наиболее популярными методами тестирования ОС являются сканирование уязвимостей и тестирование проникновения. Обычно используют автоматизированные сканеры уязвимостей для сканирования уязвимостей приложения, сети или ОС на хосте или группе хостов в сети. Тестирование проникновения является процессом тестирования, разработанным для проверки возможности компрометации сети, при этом используются инструментальные средства и методики атакующего. Это итеративный процесс тестирования, который идентифицирует наиболее слабые области сети и использует их для получения доступа к оставшейся сети. Результатом обычно является компрометация безопасности всей сети. Сканирование уязвимостей должно проводиться периодически, по крайней мере, раз в неделю или в месяц. Тестирование проникновения должно быть минимум ежегодным. Так как обе эти технологии тестирования применяются также для тестирования приложений web-сервера, далее они будут обсуждаться более детально.
Список действий для обеспечения безопасности ОС, на которой выполняется web-сервер
Составление плана конфигурации и развертывания web-сервера.
Определить функции web-сервера.
Определить категории информации, которая будет храниться, обрабатываться и передаваться web-сервером.
Определить требования безопасности для данной информации.
Определить способы опубликования информации на web-сервере.
Определить необходимость иметь выделенный хост для web-сервера.
Определить пользователей и категории пользователей web-сервера и определить привилегии каждой категории пользователей.
Определить методы аутентификации пользователей на web-сервере.
Выбор подходящей ОС для web-сервера.
Максимальная защищенность от уязвимостей.
Возможность ограничить деятельность уровня администратора или root только аутентифицированными и авторизованными пользователями.
Возможность запретить доступ к информации на сервере всем, кроме явно указанных пользователей.
Возможность сделать недоступными ненужные сетевые сервисы, которые могли быть встроены в ОС или ПО сервера.
Возможность управления доступом к различным программам, связанным с web-сервером, таким как CGI-скрипты и plug-ins сервера в случае web-сервера.
Применение patch’ей и upgrade’ов ОС.
Определить и инсталлировать все необходимые patches и upgrades для ОС.
Определить и инсталлировать все необходимые patches и upgrades для приложений и сервисов, включенных в ОС.
Удаление или запрещение ненужных сервисов и приложений.
Конфигурирование аутентификации пользователей в ОС.
Удалить или запретить ненужные аккаунты и группы, существующие по умолчанию.
Запретить неинтерактивные аккаунты.
Создать группы пользователей для данного экземпляра ОС.
Создать аккаунты пользователей для данного экземпляра ОС.
Проверить политику пароля в организации и установить соответствующие пароли аккаунтов (длина, сложность).
Сконфигурировать ОС для запрещения входа после небольшого числа неудачных попыток.
Инсталлировать и сконфигурировать другие механизмы безопасности для усиления аутентификации.
Тестирование безопасности ОС.
Протестировать ОС после начальной инсталляции для определения уязвимостей.
Проводить частое тестирование ОС для определения новых уязвимостей.
Безопасное инсталлирование и конфигурирование web-сервера
После того как ОС инсталлирована и сделана безопасной, следует инсталлировать выбранное ПО web-сервера. Перед началом данного процесса следует прочитать документацию производителя и понять, какие опции доступны при инсталляции. Также следует посетить web-сайт производителя или web-сайт базы данных уязвимостей, такой как ICAT метабаза (http://icat.nist.gov), для определения всех известных уязвимостей и соответствующих patches, которые должны быть инсталлированы или сконфигурированы как часть процесса установки. Только после завершения этих предварительных шагов следует начать инсталляцию. Будем обсуждать только общие процедуры инсталляции и конфигурирования.
Безопасное инсталлирование web-сервера
Во многих аспектах безопасное инсталлирование и конфигурирование приложения web-сервера аналогично инсталляции и конфигурированию ОС. Основной принцип состоит в том, чтобы инсталлировать минимальное количество требуемых сервисов web-сервера и исключить все известные уязвимости с помощью patches или upgrades. Если программа инсталляции устанавливает какие-то ненужные приложения, сервисы или скрипты, они должны быть немедленно удалены после завершения процесса. При инсталляции web-сервера должны быть выполнены следующие шаги:
Инсталлировать ПО сервера на выделенный хост.
Инсталлировать минимально требуемые сервисы Интернета.
Применить все patches или upgrades для корректировки известных уязвимостей.
Создать выделенный физический диск или логический раздел (отдельный от ОС и приложения сервера) для содержимого web.
Удалить или запретить все web-сервисы, инсталлированные приложением web-сервера, но не требуемые (например, gopher, FTP и удаленное администрирование).
Из корневой директории приложения web-сервера удалить все файлы, которые не являются частью web-сайта.
Удалить всю документацию, а также примеры скриптов и выполняемого кода.
Выполнить разного рода образцы безопасности или "hardening" скрипты, усиливающие безопасность web-сервера.
Переконфигурировать баннер НТТР-сервиса (и других сервисов, если они используются), чтобы он не сообщал о типе и версии web-сервера и ОС. Это может быть выполнено в IIS использованием свободного Microsoft IIS Lockdown Tool и в Apache посредством "ServerTokens" директивы.
Конфигурирование управления доступом
Большинство ОС для web-серверов предоставляют возможность указать конкретные привилегии доступа для файлов, устройств и других вычислительных ресурсов на данном хосте. Следует понимать, что любая информация, к которой может быть осуществлен доступ из каталогов, принадлежащих web-серверу потенциально может стать доступной всем пользователям, имеющим доступ к публичному web-сайту. Обычно ПО web-сервера обеспечивает дополнительное управление доступом к файлам, устройствам и ресурсам. В случае, если разрешения доступа к ресурсам могут быть установлены как на уровне ОС, так и на уровне приложения web-сервера, важно, чтобы они были идентичны друг другу, в противном случае возможна ситуация, когда пользователям предоставлен либо очень большой, либо очень маленький доступ. Web-администраторы должны рассмотреть, какое конфигурирование доступа к хранимой в публичном web-сервере информации является наилучшим со следующих точек зрения:
ограничение доступа ПО web-сервера к подмножеству вычислительных ресурсов средствами управления доступом ОС;
ограничение доступа пользователей посредством дополнительного управления доступом, обеспечиваемым web-сервером, когда требуются более детальные уровни управления доступом.
Соответствующая установка управления доступом может помочь предотвратить раскрытие чувствительной информации, которая не предназначена для публичного распространения. Дополнительно управление доступом может быть использовано для ограничения использования ресурсов в случае DoS-атаки на публичный web-сайт.
Обычно файлами, доступ к которым должен контролироваться, являются следующие:
ПО и конфигурационные файлы приложения.
Файлы, непосредственно использующиеся механизмами безопасности:
файлы хэшей паролей и другие файлы, используемые при аутентификации;
файлы, которые содержат авторизационную информацию, используемую при управлении доступом;
криптографический материал ключа, используемый в сервисах конфиденциальности, целостности и невозможности отказа.
Логи сервера и файлы системного аудита.
Системное ПО и его конфигурационные файлы.
Разграничение доступа для ПО web-сервера
Первый шаг в конфигурировании управления доступа состоит в гарантировании того, что web-сервер выполняется только от имени пользователя и группы, которые специально созданы для этого и имеют очень ограниченные права доступа. Таким образом, должны быть введены специальные идентификаторы пользователя и группы, используемые исключительно ПО web-сервера. Новый пользователь и новая группа должны быть уникальными и независимыми от всех остальных пользователей и групп. Это необходимо для реализации управления доступом, описанного далее. Хотя сервер может начинать выполняться как root (Unix) или system/administrator (Windows NT/2000/XP) для привязки к ТСР-порту 80 и/или 443 (используемому для предоставления НТТР и НТТРS-сервисов соответственно), не следует допускать, чтобы сервер продолжал выполняться на данном уровне доступа.
Дополнительно следует использовать возможности ОС для ограничения доступа к файлам, доступным процессам web-сервера. Эти процессы должны иметь доступ только по чтению к тем файлам, которые необходимы для выполнения сервиса, и не должны иметь доступа к остальным файлам, таким как файлы лога сервера. Следует использовать управление доступом на уровне ОС для обеспечения следующего:
процессы web-сервера должны быть сконфигурированы для выполнения от имени пользователя с очень ограниченным множеством привилегий (т.е. не выполняться как root, администратор или эквивалентные пользователи);
к файлам содержимого web-сайтов процессы web-сервера должны иметь доступ по чтению, но не по записи;
процессы web-сервера не должны иметь возможность записи в директории, в которых хранится публичное содержимое web-сайтов;
только процессы, авторизованные как администратор web-сервера, могут писать в файлы web-содержимого;
приложение web-сервера может писать в файлы логов web-сервера, но лог-файлы не могут читаться приложением web-сервера. Только процессы уровня root/system/administrator могут читать лог-файлы web-сервера ;
временные файлы, создаваемые приложением web-сервера, например, те, которые возникают при формировании динамических web-страниц, должны быть расположены в специальной и соответствующим образом защищенной поддиректории;
доступ к любым временным файлам, созданным приложением web-сервера, ограничен процессами, которые создали эти файлы.
Также необходимо гарантировать, что приложение web-сервера не может хранить файлы вне специального подкаталога, выделенного для публичного web-содержимого. Это может быть задано посредством конфигурации в ПО сервера или может контролироваться ОС. Следует гарантировать, что к директориям и файлам вне специального поддерева директорий не может быть обращений, даже если пользователи знают имена этих файлов.
Для уменьшения воздействия основных типов DoS-атак нужно сконфигурировать web-сервер с ограниченным количеством ресурсов ОС, которые он может использовать. Чаще всего необходимо совершить следующие действия:
инсталлировать содержимое web на отдельном жестком диске или логическом разделе от ОС и web-приложения;
если допустимы загрузки (uploads) на web-сервер, установить ограничение на объем дискового пространства, которое выделяется для этой цели;
если допустимы загрузки (uploads) на web-сервер, эти файлы не должны быть сразу же читаемы web-сервером и, тем самым, видимы пользователям по протоколу НТТР. Они должны быть читаемы web-сервером только после некоторого автоматизированного или ручного процесса просмотра. Это предотвращает от использования web-сервера для передачи пиратского ПО, инструментальных средств атак, порнографии и т.п.;
гарантировать, что лог-файлы хранятся в соответствующем месте, в котором они не смогут исчерпать ресурсы файловой системы.
Эти действия в некоторой степени защитят от атак, которые попытаются заполнить файловую систему информацией, что может вызвать крах системы. Они могут также защитить против атак, которые пытаются заполнить RAM память ненужными процессами для замедления или краха системы, тем самым ограничив доступность сервиса. Информация в логах, созданных ОС, может помочь распознать такие атаки.
Дополнительно часто бывает необходимо сконфигурировать таймауты и другие способы управления для дальнейшего уменьшения влияния основных DoS-атак. Один из типов DoS-атаки состоит в том, чтобы одновременно устанавливать сетевые соединения сверх максимально допустимого, чтобы никакой новый законный пользователь не мог получить доступ. Когда таймауты установлены на сетевые соединения (время, после которого неактивное соединение сбрасывается) в минимально допустимое ограничение, существующие соединения будут завершаться по таймауту так быстро, как только возможно, создавая возможность устанавливать новые соединения законным пользователям. Данная мера только смягчает DoS-атаку, но не уничтожает ее.
Если максимальное число открытых соединений (или соединений, которые являются полуоткрытыми, – это означает, что первая часть ТСР-рукопожатия завершилась успешно) установить в наименьшее число, атакующий может легко израсходовать доступные соединения ложными запросами (часто называемыми SYN flood). Установка в максимум данного числа может смягчить эффект такой атаки, но ценой расходования дополнительных ресурсов. Заметим, что это является проблемой только тех web-серверов, которые не защищены firewall’ом, останавливающим SYN flood атаки. Большинство современных firewall’ов защищают web-сервер от SYN flood атаки, прерывая ее прежде, чем она достигнет web-сервера.
Управление доступом к директории содержимого web-сервера
Не следует использовать ссылки, aliases или shortcuts из дерева директории содержимого web на директории или файлы, расположенные где-то еще на хосте или сетевой файловой системе. Лучше всего запретить возможность ПО web-сервера следовать по ссылкам и aliases. Как указывалось раньше, лог-файлы и конфигурационные файлы web-сервера должны размещаться вне дерева директории, которое определено для публичного содержимого web.
Для ограничения доступа к дереву директории содержимого web требуется выполнить следующие шаги:
выделить отдельный жесткий диск или логический раздел для web-содержимого и использовать поддиректории на данном жестком диске или логическом разделе исключительно для файлов содержимого web-сервера, включая графику, но исключая скрипты и другие программы;
определить отдельную директорию исключительно для всех внешних по отношению к ПО web-сервера скриптов или программ, выполняющихся как часть содержимого web (например, CGI, ASP, PHP);
запретить выполнение скриптов, которые не находятся под исключительным контролем административных аккаунтов. Данное действие выполняется созданием доступа и управлением им к отдельной директории, предназначенной для хранения авторизованных скриптов;
запретить использование жестких и символических ссылок;
определить матрицу доступа к содержимому web. Определить, какие папки и файлы внутри содержимого web-сервера имеют ограничения и какие являются доступными (и кому).
Большинство производителей ПО web-сервера предоставляют директивы или команды, которые позволяют web-администратору ограничить доступ пользователя к файлам содержимого web-сервера. Например, ПО web-сервера Apache предоставляет директиву Limit, которая позволяет web-администратору указать, какие возможности доступа (такие как New, Delete, Connect, Head и Get ) связаны с каждым файлом web-содержимого. Директива Require в Apache позволяет web-администратору ограничивать доступ к содержимому аутентифицированными пользователями или группами.
Многие директивы или команды могут быть перекрыты на уровне директории. Но при этом следует помнить, что удобство, состоящее в возможности делать локальные исключения из глобальной политики, может привести к появлению дыры в безопасности, появившейся в отдельной поддиректории, которая контролируется другим пользователем. Web-администратор должен запретить для поддиректорий возможность перекрывать директивы безопасности верхнего уровня, если это не является абсолютно необходимым.
В большинстве случаев подобные директивы web-сервера должны быть запрещены. НТТР определяет, что URL, заканчивающийся символом слеша, должен трактоваться как запрос на перечисление файлов в указанной директории. Web-сервер должен запрещать отвечать на такие запросы, даже если возможно публичное чтение всех файлов директории. Такие запросы часто указывают на попытку разместить информацию способами, отличными от тех, которые допускает web-администратор. Пользователи могут пытаться это делать, если у них возникают трудности в навигации по сайту или если ссылки в web-страницах обрываются. Нарушитель может пытаться это сделать, чтобы разместить информацию, скрытую интерфейсом сайта. Web-администраторы должны исследовать запросы данного типа, найденные в лог-файлах web-сервера.
Управление влиянием web Bots
Web bots (что тоже самое, что и агенты или spiders) есть прикладное ПО, используемое для сбора, анализа и индексирования web-содержимого. Web bots используются многими организациями в разных целях. Некоторые примеры:
Scooter, Slurp и Googlebot анализируют, индексируют и записывают web-сайты для поисковых систем, таких как AltaVista и Google;
ArchitextSpider собирает статистику Интернета;
Hyperlink validators используются для автоматической проверки корректности гиперссылок на другие сайты;
EmailSiphon и Cherry Picker являются bots, специально разработанными для поиска на web-сайтах e-mail адресов для добавления в e-mail списки ("спам"). Это пример bot, который имеет негативное воздействие на web-сайты или их пользователей.
Bots имеют негативные последствия, потому что:
web-серверы часто содержат директории, которые не должны индексироваться;
организации могут не хотеть, чтобы часть их сайта появлялась в поисковых системах;
web-серверы часто содержат временные страницы, которые не должны индексироваться;
bots часто содержат ошибки или не всегда имеют хорошие намерения и могут нанести вред частыми запросами, создавая DoS-атаку для законных пользователей.
В принципе, существует способ для web-администратора повлиять на поведение большинства bots на своем web-сайте. Была создана серия соглашений, называемая Robots Exclusion Standard (REP). Хотя REP не является официальным стандартом Интернета, он поддерживается большинством хорошо написанных и имеющих благие цели bots, включая те, которые используются в большинстве поисковых систем.
Web-администраторы, которые хотят ограничить деятельность bots на своих web-серверах, должны создать тестовый файл, называемый robots.txt. Файл должен всегда иметь данное имя и располагаться в корневой директории web-сервера. Кроме того, допускается только один такой файл на весь web-сайт. Заметим, что файл robots.txt является стандартом, который на добровольной основе должен поддерживаться программистами bots. Не существует обязательного требования использовать его. Таким образом, вредоносные bots, такие как EmailSiphon и Cherry Picker, игнорируют данный файл.
Robots.txt является простым тестовым файлом, который содержит определенные ключевые слова и спецификации файла. Каждая строка файла либо является пустой, либо состоит из единственного ключевого слова и относящейся к нему информации. Ключевые слова используются для того, чтобы сказать роботам, какую часть web-сайта следует исключить из их анализа.
Допустимы следующие ключевые слова:
User-agent – имя робота или spider. Web-администратор может указать более одного имени агента, при этом действие будет применяться к каждому указанному bot. Запись нечувствительна к регистру (слово "googlebot" – то же самое, что и "GoogleBot", "GOOGLEBOT"). "*" указывает, что это запись по умолчанию, которая используется, если никакого соответствия не найдено. Например, если указать "GoogleBot", то "*" будет применяться к любому другому роботу, за исключением GoogleBot.
Disallow – говорит bots, какие разделы web-сайта следует исключить. Например, /images информирует bots, что не следует открывать или индексировать любые файлы в директории images и любых ее поддиректориях. Таким образом, директория /images/special также не будет индексироваться указанными в user-agent bots.
Заметим, что /do будет соответствовать любой директории, начинающейся с "/do" (например, /do, /document, /docs и т.п.), в то время как /do/ соответствует только директории, называемой "/do/".
Web-администратор может также указать конкретные файлы. Например, он может указать /mydata/help.html для предотвращения доступа только к одному файлу.
Значение "/" указывает, что ничего на web-сайте не разрешено для доступа указанных в user-agent bots.
Должна существовать по крайней мере одна запись на каждый user-agent.
Существует много способов использовать файл robots.txt. Несколько простых примеров:
запретить всем (учитывающим это) bots доступ в указанные директории:
User-agent: *
Disallow: /images/
Disallow: /banners/
Disallow: /Forms/
Disallow: /Dictionary/
запретить всем (учитывающим это) bots доступ ко всему web-сайту:
User-agent: *
Disallow: /
запретить конкретному bot анализировать конкретную web-страницу:
User-agent: GoogleBot
Disallow: tempindex.html
Заметим, что файл robots.txt доступен всем. Следовательно, web-администратор не должен указывать имена чувствительных файлов или папок. Если они должны быть исключены, то лучше использовать защищенные паролем страницы, которые не могут быть доступны bots. Защита паролем является более надежным способом для исключения не придерживающихся правил bots. Более подробная информация будет приведена при описании методов аутентификации.
Использование программ проверки целостности файлов
Программа проверки целостности файла является приложением, которое вычисляет и хранит криптографическую контрольную сумму каждого защищаемого файла и поддерживает базу данных контрольных сумм файлов. Это позволяет системному администратору легко распознать изменения, в частности, неавторизованные, сделанные в критичных файлах. Контрольные суммы должны перевычисляться регулярно для сравнения текущего значения с хранимым значением, что позволит определить любые модификации файла. Возможность проверки целостности файлов часто включается в системы обнаружения проникновений для хоста, но такая проверка может быть доступна и в виде отдельной программы.
Хотя программа проверки целостности и является полезным инструментальным средством, которое не требует большого участия человека, для гарантии эффективности она должна использоваться продуманно.
При создании первого варианта базы данных файлом проверки целостности требуется гарантия, что система находится в безопасном состоянии. В противном случае могут быть созданы криптографические хэши скомпрометированной системы, и тем самым создастся ложное чувство безопасности у тестирующего.
База данных контрольных сумм должна храниться off-line, чтобы атакующий не мог скомпрометировать систему и модифицировать базу данных с целью спрятать следы атаки.
Программа проверки целостности файлов может также создавать ложные позитивные предупреждения. Каждое изменение файла и каждый системный patch изменяет файл и, следовательно, требуется изменить базу данных контрольных сумм. Таким образом, держать базу данных актуальной может быть непросто.
Однако, даже если программа проверки целостности выполняется только один раз (при первой инсталляции системы), она может быть полезна для определения того, какие файлы были модифицированы в случае предполагаемой компрометации. Наконец, атакующий может так модифицировать файл, что использование 32-битной циклической контрольной суммы (Cyclic Redundancy Check – CRC) не определит модификацию. Следовательно, рекомендуются более сильные алгоритмы подсчета контрольных сумм для гарантирования целостности данных.
Программы проверки целостности должны выполняться ночью для проверки некоторой файловой системы, которая могла быть скомпрометирована. Если программа проверки целостности определит неавторизованные модификации системных файлов, должна быть рассмотрена возможность инцидента, связанного с безопасностью, и осуществлены соответствующие процедуры, согласно установленной политики безопасности.
Список действий для безопасного инсталлирования и конфигурирования web-сервера
Безопасное инсталлирование web-сервера.
Инсталлировать ПО сервера на выделенный хост.
Инсталлировать минимально требуемые сервисы Интернета.
Применить все patches и upgrades для устранения известных уязвимостей.
Создать выделенный физический диск или логический раздел (отдельно от ОС и приложения сервера) для web-содержимого.
Удалить или запретить все сервисы, инсталлированные приложением web-сервера, но в данном случае не требуемые (например, gopher, FTP и удаленное администрирование).
Удалить все примеры страниц, скриптов и выполняемого кода.
Удалить с сервера всю документацию производителя.
Протестировать сервер, применив различные образцы безопасности или скрипты взлома.
Переконфигурировать баннер НТТР-сервиса (и баннеры других сервисов, если требуется), чтобы он не сообщал о типе и версии web-сервера и ОС.
Конфигурирование управления доступом web-сервера со стороны ОС.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы процессы web-сервера могли только читать файлы web-содержимого, но не могли записывать в них.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы процессы web-сервера не могли записывать в директории, в которых расположено содержимое web.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы только процессы, авторизованные для администрирования web-сервера, могли записывать в файлы содержимого web.
– Сконфигурировать доступ к файлам со стороны ОС так, чтобы web-приложение могло писать в лог-файлы web-сервера, но лог-файлы не могли быть читаемы приложением web-сервера.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы временные файлы, создаваемые приложением web-сервера, были расположены только в указанной и соответствующим образом защищенной поддиректории.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы доступ к любым временным файлам, созданным приложением web-сервера, был ограничен только процессами, которые создали эти файлы.
Инсталлировать web-содержимое на отдельном жестком диске или логическом разделе, отличном от ОС и web-приложения.
Сконфигурировать доступ к файлам со стороны ОС так, что если допустима загрузка на web-сервер, то должно существовать ограничение на пространство жесткого диска или логического раздела, которое выделено для этих целей.
Сконфигурировать доступ к файлам со стороны ОС так, чтобы лог-файлы имели соответствующий максимальный размер.
Конфигурирование безопасной директории web-содержимого.
Выделить отдельный жесткий диск или логический раздел для web-содержимого и установить соответствующие поддиректории исключительно для файлов содержимого web-сервера, включая графику, но исключая скрипты и другие программы.
Определить отдельную директорию исключительно для всех внешних по отношению к ПО web-сервера скриптов или программ, выполняющихся как часть содержимого web-сервера например, CGI, ASP и т.п.).
Запретить выполнение скриптов, которые не находятся под управлением административных аккаунтов. Данное действие выполняется созданием доступа и управлением им к отдельной директории, которая предназначена для авторизованных скриптов.
Создать группы и пользователей для web-сервера.
Запретить использование жестких и символических ссылок (аналог shortcuts в Windows).
Определить полную матрицу доступа к web-содержимому. Определить, какие папки и файлы внутри документов web-сервера имеют ограничения и какие являются доступными (и кому).
Проверить политику паролей в организации и установить соответствующие критерии паролей (длина, сложность).
Использовать при необходимости файл robots.txt.
Использование программ проверки целостности.
Инсталлировать проверку целостности для защиты конфигурационных файлов web-сервера.
Пересчитывать контрольные суммы при изменении содержимого файлов.
Хранить контрольные суммы в защищенном от записи носителе.
Регулярно сравнивать контрольные суммы критичных файлов с эталонными значениями.
