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

     Корпоративный пользователь (какая-то компания) помещает свой Web-сайт на сервере. Он тоже записал CGI-сценарий, позволяющий пользователям его компании править свое расписание. Изменения в расписании записываются в текстовый файл, созданный CGI-сценарием. Владельцем данного файла представляется пользователь, от имени которого работает Web-сервер - обычно http, www или nobody.

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

Далее...

     WEB-скриптинг.

     Непонятно, почему многие администраторы закрывают глаза на используемые на их сервере CGI-скрипты, при данном они часами могут настраивать остальные аспекты безопасности системы, даже не ведая, что творится у них «под носом». А ведь CGI-скприпты, особенно написанные третьими лицами (форумы, гостевые книги и т.д.), отображают большую угрозу безопасности для Web-сервера.

     Ранее было показано, как надо употреблять CGI-скрипт для выполнения команд с привилегиями Web-сервера. Но это далеко не весь вред, который могут причинить Web-скрипты. Поэтому Web-скриптингу можно уделить значительно больше внимания, чем обычно.

     Нужно убедиться, что выключен SSI и CGI, если в них нет потребности.

     Рекомендуется создать для SSI и CGI два каталога (один для SSI и один для CGI), доступ к которым будет контролироваться. Если пользователю нужен CGI-сценарий, он должен будет попросить поместить этот сценарий в каталог CGI. Тогда, перед записью сценария можно проверить его на фигурирование вредоносного кода.

Далее...

Ранее был рассмотрен HTTP-доступ со стороны клиента, теперь посмотрим на него с другой стороны - со стороны сервера.

     Термины «авторизация» и «аутентификация» часто используются как взаимозаменяемые, но у каждого из них есть свое точное значение. Аутентификация - процесс проверки имени пользователя и пароля пользователя. А авторизация - это проверка полномочий пользователя: есть ли у данного пользователя права доступа к тому или иному объекту, к примеру файлу. Аутентификация часто (но не всегда) представляется первым шагом авторизации.

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

     Начнем с доступа по IP-адресу.

Далее...

     Если клиент отправит Web-серверу Apache запрос HEAD, то в ответ он получит заголовок ответа сервера, который содержит информацию об окружении, в котором он запущен. Проверить это довольно просто: можно запустить telnet и подключиться к Web-серверу на порт 80, затем надо ввести запрос HEAD / НТТР/1.0 и нажать Enter дважды:

Далее...

Одним из самых популярных OpenSource-приложений представляется Web-сервер Apache. Apache сделал революцию в мире Web-серверов, став эталонным стандартом на Web-серверы - теперь Apache входит во все дистрибутивы Linux, FreeBSD, даже есть версии Apache для Windows.

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

Далее...

Учитывая популярность вышеописанных систем, можно сказать, какая наиболее подходит для защиты конкретной системы. DTE является наименее распространенной, поэтому можно скон­центрировать все внимание на хорошо опробованных технологиях - SE­Linux, Grsecurity, LIDS и RSBAC.

     SELinux - самая сложная в настройке системы. Чтобы понять, как работа­ет SELinux, надо заново воспринять фундаментальные Unix-концепции пользователей, групп и прав доступа. Масла в огонь добавляет язык опи­сания правил - он очень сложен, хотя таким он кажется на первый взгляд, пока не разберешся с ним. Однако, несмотря на сложность настройки, SELinux - наверное, самая мощная и защищенная реализация МАС-модели.

     LIDS, RSBAC и Grsecurity основаны на ACL, благодаря чему данные системы заметно проще изучать, чем SELinux. Кроме данного, они содержат много дополнительных функций, к примеру определение сканирования портов (LIDS), защиту памяти РаХ (Grsecurity и RSBAC), и «укрепление» chroot (Grsecurity).

Далее...

Rule-Set Based Access Control (RSBAC).

     Rule-Set Based Access Control (RSBAC) - контроль доступа на основании набора правил - такое название еще у одной системы безопасности, доступной по адресу: http: //www.rsbac.org - которая появилась на свет в 1996 г. как несложной университетский проект. Как и другие проекты безо­пасности, со временем RSBAC набирала силу и становилась более гибкой и мощной.

     RSBAC использует общий интерфейс управления доступом (Generalized Framework for Access Control, GFAC), который позволяет употреблять много альтернативных методов управления доступом. Поддерживаются следующие методы:

Далее...