Информация должна быть в безопасности, эта аксиома, пожалуй, известна всем. И несомненно, большинство пользователей знают, что такое Firewall и троянские вирусы и какими средствами можно обеспечить защиту сети. Однако не все знают, как они работают и как оптимально настроить систему защиты компании. Тем не менее именно от этого зависит не только сохранность данных, но и существование предприятия в целом.
Основные причины уязвимости веб-серверов:
Добавляя новые рабочие станции (иногда и сервера), порой забывают при этом тестировать ЛВС на безопасность. Разумеется, запретить подключать новых пользователей невозможно, но стоит задуматься о расширении сети заранее. Обозначить ее сегменты, которые способны к расширению, и проводить предварительное тестирование на безопасность.
Большинство веб-мастеров имеют корневой или администраторский доступ к серверу. Разумнее прописать каждому пользователю свою политику доступа, ограничивающую его права прямыми обязанностями. Например, сотрудник работает только с одним каталогом сервера, но имеет доступ на все остальные. Тем самым он ставит под угрозу не только свой сектор работ, но и все данные сервера. Конечно, статус веб-мастера имеет не каждый пользователь, хотя ограничить доступ из соображений безопасности следует и самым высоким профессионалам.
Программное обеспечение веб-серверов. Смесь из пиратских, лицензионных, sharewareи freewareпрограмм делает систему уязвимой. Самый безопасный подход – совместимое программное обеспечение от одного производителя. Скажете дорого? А не дороже ли потом восстанавливать данные после атаки?
Большинство растущих предприятий регулярно меняет конфигурацию своих сетей.
Эта статья предназначена для веб-мастеров, отвечающих за настройку системы безопасности вебсерверов, предоставляющих динамический контент для клиентов. В нем описаны общие вопросы безопасности, связанные с SSI и CGI-содержания, сокращения рисков CGI с обертками, а некоторые краткие конкретного языка – оговорками. Эта статья предполагает следующее:
Ваша сеть в безопасности, брандмауэр и сам сервер находятся в контролируемой среде.
В качестве операционной системы были надежно закреплены необходимые сервисы и все ненужные отключены.
Apache пользователей и группы директивы верны, и соответствующие разрешениям, назначенным. ServerRoot и журнала каталоги защищены.
Пользователь переопределяет отключение.
По умолчанию доступ отключен, и доступ открыт только для каталогов системы, обозначенной
«общественность». Например, в системе, настроенной для размещения пользователей веб-страниц с / дома / имя пользователя / public_html , Apache в httpd.conf, файл конфигурации должен содержать следующие директивы:
ServerName www.sitename.com UserDir public_html
<Directory />
Order deny,allow Deny from all
</Directory>
<Directory /home/*/public_html> Order deny,allow Allow from all
</Directory>
Общие соображения
Apache имеет различные механизмы обеспечения безопасности и разграничения доступа к данным. Основными являются:
Ограничение доступа к определенным директориям или файлам.
Механизм авторизации пользователей для доступа к директории по методу HTTP-авторизации (mod_auth_basic) и digest-авторизации (mod_auth_digest).
Ограничение доступа к определенным директориям или по всему серверу, основанное на IP-
адресах пользователей.
Запрет доступа к определенным типам файлов для всех или части пользователей, например, запрет доступа к конфигурационным файлам и файлам баз данных.
Существуют модули, реализующие авторизацию через СУБД или PAM [1].
Предположение, что введенные пользователем данные будут более 1024 символов. Если пользователь передает информацию в более чем 1024 символов, выше рутины сломает программу и позволит кому-то выполнить системные команды удаленно. Решение в этом случае заключается в обеспечении выделения памяти для переменной QUERY_STRING. Происходит это динамически с помощью вызова либо Malloc () или calloc () функций.
Другая распространенная проблема включает в себя системный вызов, который открывает подоболочки для обработки команды. В Perl такой вызов может быть сделан с помощью любой из следующих функций: системы (), Exec (), который поступает (), открытым (), или EVAL () . Урок – здесь никогда не доверять вводимым пользователем данным, что обеспечит всем вашим системным вызовам неуязвимость. Первое обычно достигается за счет четкого правила (например, путем проверки входа регулярным выражением) на то, что приемлемо, а что нет. Процесс дезинфекции системных вызовов зависит от языка. Весь фокус в том, чтобы всегда вызывать внешние программы напрямую, а не проходящие через оболочку. Использование Perl осуществляется путем передачи аргументов внешней программы в качестве отдельных элементов в списке, а не в одну длинную строку, вот так:
system “/usr/bin/sort”,”data.dat”
Связанная уловка, используемая многими хакерами, является изменением переменной PATH-среды указанием на программу, в которой они хотят выполнить свой сценарий, вместо ожидаемой вами программы. Эта их попытка может быть легко подорвана в результате применения какой-либо программы, называющей при использовании полный путь.
По умолчанию веб-сервер Apache в каждом HTTP-заголовке отдает клиенту информацию о своей версии и установленных модулях (н.р., mod perl, mod php, mod ssl) [2].
Защита сервера включает в себя:
Доступ к веб-серверу имеет пять уровней:
Общедоступный с возможностью только чтения всех URL за исключением тех, что помещены в каталогах /private.
Доступ сотрудников фирмы или организации, которой принадлежит сервер. Здесь также допустимо только чтение, но доступны и секции каталога /private.
Разработчики веб-сервера. Имеют возможность модифицировать содержимое сервера, инсталлировать CGI-скрипты, прерывать работу сервера.
Администраторы узла (сервера). Имеют те же привилегии, что и разработчики, но могут также реконфигурировать сервер и определять категорию доступа.
Системные администраторы. Имеют идентичные привилегии с администраторами сервера [3].
Многие веб-администраторы считают Server Side Includes (SSI) на одном уровне с приложениями CGI, когда речь идет о потенциальных угрозах безопасности. Любые программы или страницы, которые используют Exec-команду вызова, подвергают файловую систему огромной опасности, если вызов сделан неправильно. С другой стороны, это удивительно простой процесс, чтобы отключить все Execзвонки от всего веб-сайта, позволяют Exec, отзываться на вызовы из только конкретных каталогов. Это достигается с Параметры-директивы.
<Directory>
Options IncludesNOEXEC Order deny,allow
Deny from all
</Directory>
Параметры линии в листинг выше конфигурации отключают Exec-звонки и включают в себя вебсайт. Для того чтобы Exec призывает к конкретным подкаталог Веб ", объем-вниз" каталог контейнер следующим образом:
<Directory />
Options IncludesNOEXEC Order deny,allow
Deny from all
</Directory>
<Directory /subdirectory>
Options Includes # (or alternately, +Includes) Order deny,allow
Deny from all
</Directory>
Такая конфигурация позволяет использовать сегмент исполнения Exec-команды только из / подкаталога папки под сайт DocumentRoot. Обратите внимание, что пользователи могут выполнять CGI сценариев из документа, при условии что скрипты расположены в каталоге, назначенные ScriptAliasдирективой (см. следующий раздел о защите приложений CGI. Более подробно об использовании ScriptAlias директива).
HTM расширения файла, особенно на серверном трафике, высока. Все SSI-страницы обрабатываются на сервере. Плохо закодированные страницы могут потребляться ресурсами системы с удивительной скоростью, что в конечном счете приведет к сбою. Чтобы избежать такого сценария, обычной практикой является использование отдельных расширений для SSI-документов SHTML). Это можно сделать, добавив следующие строки в конфигурационный файл сервера Apache:
AddHandler server-parsed .shtml AddType text/html .shtml
Первая директива говорит Apache для лечения все файлы с расширением SHTML как страницы SSI; Вторая директива передает в браузер запрашивающего страницу, и говорит он, для отображения содержимого же, как бы для запроса HTML.
Защита CGI-приложений:
Администраторы имеют два варианта настройки CGI под Apache. Первый метод использует ScriptAlias директиву для обозначения каталога программы CGI. Второй метод использует комбинацию Alias и AddHandler-директивы. Каждый метод имеет место и свой собственный набор плюсов и минусов.
ScriptAlias подход
Первым надежным шагом в настройке CGI под Apache является создание центрального каталога для хранения CGI-приложения дюйма. Этот каталог всегда должен быть отдельно от дерева DocumentRoot, потому что, чем меньше мир знает о том, где ваши CGI-сценарии проживают, тем лучше. Это также гарантирует то, что только веб-администраторы могут получить доступ к файлам, которые находятся там. Так что, если / WWW / MySITE / htdocs ваш DocumentRoot, / WWW / MySITE / CGI-BIN, это будет хорошим выбором для вашего каталога CGI. Некоторые веб-мастера предпочитают размещать свои CGI-каталога на другой файловой системе полностью, например, / VAR / WWW / CGI-BIN . Следующий шаг заключается в информировании Apache, какой каталог содержит CGI-программы. Это делается с помощью ScriptAlias-директивы.
ScriptAlias /cgi-bin/ /www/mysite/cgi-bin/
Есть несколько моментов, которые необходимо отметить в отношении вышеназванной директивы:
Чтобы получить доступ к сценарию, test.cgi , на примере путь показан, пользователь должен ввести
http://www.mysite.com/cgi-bin/test.cgi в своем браузере.
Заметим, что оба – псевдоним и путь к каталогу CGI должны заканчиваться косой чертой (/). Apache поддерживает несколько ScriptAlias каталогов.
ScriptAlias назначенных каталогов не могут быть просмотрены (по умолчанию) по соображениям безопасности.
Каталог ссылается на ScriptAlias-директиву, которая должна иметь очень строгие настройки разрешений, возложенные на него. В идеале никто, кроме ведущего разработчика CGI и системного администратора, не должен иметь полный доступ (чтение, запись, выполнение) к файлам, содержащимся там. Это обстоятельство является одним из основных преимуществ использования благоприятных
CGI ScriptAlias-директивы. Она предлагает администратору центральный пункт управления CGIпрограмм (как правило, в серверах сScriptAlias-директива есть только один CGI-каталог), позволяющий получить доступ к каталогу CGI под жестким контролем. Недостатком использования ScriptAlias назначить каталог CGI является то, что Apache будет считать любой исполняемый файл, который он находит в алиасом каталоге приложения CGI.
Alias / AddHandler подход
AddHandler-директива используется для указания файлов, которые должны быть рассмотрены в CGI-программах. Но сначала нужно рассказать Apache, где ваш CGI-каталог, так как он находится вне дерева документа.
Начните с комментария любой ссылки на ScriptAlias-директива httpd.conf. Затем добавьте Alias-
директиву в файл конфигурации: Alias /cgi-bin/ /www/mysite/cgi-bin/
Теперь вы должны сказать Apach-пароль для выполнения CGI-программ из этого каталога. Это включает в себя определение<Directory...> контейнера. Это достигается следующим образом:
<Directory /www/mysite/cgi-bin> Options ExecCGI
AddHandler cgi-script .cgi .pl
</Directory>
Первая строка в приведенном выше сегменте конфигурации определяет полный путь к каталогу CGI, вторая строка говорит Apache, что CGI-приложение может быть выполнено, и третья линия обозначает какой-то файл в каталоге CGI с расширением . CGI или . PL считается применение CGI.
Эта конфигурация может быть расширена до предоставления отдельным пользователям доступа к их собственным каталогам CGI-BIN:
ServerName www.company.com UserDir public_html
<Directory ~ “/home/[a-z]+/public_html/cgi-bin Options ExecCGI
AddHandler cgi-script .cgi .pl
</Directory>
Когда приходит запрос на сервер для ~ www.company.com/, он будет перенаправлен на / home / tom
/ public_html, и индексная страница для этого каталога отправляется клиенту. Аналогичным образом, Apache переводит любые просьбы о www.company.com/ ~ Том / CGI-BIN / в / главный / Том / public_html
/ CGI-BIN / и позволяет любой программе CGI с соответствующим расширением ( . CGI или . PL ) для выполнения. Отметим, что Directory-директива требует, чтобы все имена значились в нижнем регистре. Если ваша система позволяет в разных регистрах буквенно-цифровые имена пользователей, различные регулярные выражения должны быть использованы.
Сокращение рисков CGI с оболочками
Совершенная система безопасности – высокая, но недостижимая цель. Обеспечение любой системы представляет собой динамический процесс – проверка и применение обновления операционной системы, программа исправлений и обновлений, сканирования, программа для изменения желательно дополнительной функции, анализ безопасности пользователей и разрешения, и т.д. Когда речь идет о сохранении на CGI вопросов, связанных с безопасностью, самое лучшее решение – не запускать любые приложения CGI на всех. Одно из распространенных решений для снижения рисков, присущих приложениям CGI, является использование оболочки программы на веб-сервере. Обертка позволяет CGI-приложениям, которые будут работать под идентификатором пользователя владельца сайта, то есть владельца каталогов и документов, составляющих веб-сайт. Эта система повышения безопасности простая. В-обертки в среде без CGI-скрипты выполняются пользователем Apache. Это означает, что пользователь Apache должен быть членом той же группы, что и владелец сайта. Это также означает, что любой человек с веб-учетной записи на сервере имеет возможность выполнять сценарии в любом другом каталоге сайта на сервере. Wrappering CGI-приложений ограничивает ущерб, пользователь может сделать для себя файлы самостоятельно. Как дополнительный бонус, большинство CGI-обертки выполняют дополнительные страховки безопасности, прежде чем они позволяют просить приложения для выполнения.
В данной статье изложены способы обеспечения безопасности веб-сервера Apache.
Вышеупомянутый метод позволяет достигнуть более высокого уровня защиты Web-сервера Apache, чем тот, который предлагается в заданной по умолчанию инсталляции.
Благодаря активации только абсолютно необходимых модулей Apache, обнаружение новой уязвимости в любом из них не должно указывать на то, что сервер уязвим. Сокрытие номера версии Apache, отключение службы индексации каталогов, изменение корневой директории и ограниченная конфигурация затрудняют взлом. Достижение высокого уровня защиты веб-сервера, использующего серверные технологии (PHP, ASP, JSP и т.д.) на практике является очень трудной задачей. Сам характер взаимодействий с веб-сервером, существенным способом уменьшает его защиту. Именно поэтому серверные сценарии должны использоваться только там, где это абсолютно необходимо.
ЛИТЕРАТУРА
- http://ru.wikipedia.org/wiki/Apache
- Скотт Хокинс, «Администрирование Web-сервера Apache», 2001г.
- http://blog.scopenco.net/2009/03/5/