Обеспечиваем безопасность инфраструктуры веб-сервера

[haligali]

Всем форумчанам доброго времени суток. С установкой Apache2 и настройкой виртуальных хостов у меня проблем не возникло. Но вот когда пришлось взять напильник потоньше, возникли сложности. В частности меня интересуют вопросы безопасности Apache2. Вот довольно интересная статейка

(Нажмите, чтобы показать/скрыть)

Возьми индейца под защиту

Сергей «grinder» Яремчук

Хакер, номер #106, стр. 154

(grinder@ua.fm)
Обеспечиваем безопасность инфраструктуры веб-сервера

По последним данным британской компании Netcraft, самым популярным веб-сервером в интернете является Apache - его доля на рынке за последние 3 года постепенно увеличивалась и сегодня составляет 67%. Успех Apache объясняется стабильностью его работы, наличием хорошей репутации в плане безопасности и простотой в администрировании. Но нельзя забывать, что обычно Apache используется не один, а в связке LAMP – Linux, Apache, MySQL и PHP/Perl. Поэтому сегодня мы выясним, как можно повысить безопасность LAMP с помощью ModSecurity, Suhosin, модуля mod_chroot и встроенных средств индейца.

Настраиваем Apache

Несмотря на репутацию компонентов LAMP, сегодня только и слышно о PHP include, SQL injection, Cross site scripting (XSS) и других атаках, направленных на веб-сервисы. Согласно статистике Web Application Security Consortium (www.webappsec.org/projects/whid/statistics.shtml), именно они занимают первые места по количеству зафиксированных инцидентов. Среди основных причин такой негативной тенденции называют широкую доступность инструментов, необходимых для проведения атаки, и недостаточное внимание со стороны разработчиков сайтов к вопросам безопасности. Условно можно выделить 2 фактора, снижающих безопасность: ошибки в администрировании и ошибки в программировании веб-ресурса. С ними и будем разбираться. Советы и рекомендации даны применительно к Ubuntu/Debian. Подправив расположение файлов, их можно использовать и в любом другом дистрибутиве.

По умолчанию веб-сервер не скрывает название операционной системы, свою версию и информацию о некоторых установленных модулях. Все это злоумышленник может использовать при подготовке атаки. Чтобы сделать индейца менее болтливым, в конфигурационный файл apache2.conf (в некоторых дистрибутивах httpd.conf) необходимо добавить следующие строки:

Код: [Выделить]

ServerSignature Off

ServerTokens Prod
Директива ServerSignature отвечает за вывод информации внизу страницы, например страницы ошибки 404 или листинга файлов каталога. Что именно выводится, определяет ServerTokens, значение которой по умолчанию Full. При установке в Prod[uctOnly] будет выведено название сервера Apache без номера версии, без информации о модулях и версии операционной системы. Как вариант - можно сразу залезть в исходники (файл httpd.h в Apache 1.3 и ap_release.h в 2.x) и перед компиляцией подправить информацию по своему усмотрению.

В некоторых статьях рекомендуют запускать веб-сервер под отдельной учетной записью, приводя в качестве примера nobody. Запуск нескольких различных серверов под этим пользователем делает его не менее могущественным, чем root, поэтому для запуска любого сервера следует использовать отдельную учетную запись. Например, в Ubuntu и некоторых дистрибутивах это www-data:

Код: [Выделить]

$ sudo grep User /etc/apache2/apache2.conf

Код: [Выделить]

User www-data
Создаем пользователя, от имени которого будет запускаться и работать веб-сервер:

Код: [Выделить]

$ sudo adduser --no-create-home --disabled-password \

--disabled-login www-data
Затем в конфигурационном файле указываем:

Код: [Выделить]

User www-data

Group www-data
Теперь устанавливаем необходимые права:

Код: [Выделить]

$ sudo chown -R root:root /etc/apache2

$ sudo /etc/apache2 -type d | xargs chmod 755

$ sudo /etc/apache2 -type f | xargs chmod 644
Аналогичные команды выполняем для каталогов /var/log/apache2 (здесь хранятся журналы) и /var/www (соответствует DocumentRoot в Ubuntu). Нет никаких препятствий для того, чтобы убрать и право на чтение конфигурационных файлов Apache:

Код: [Выделить]

$ sudo chmod -R go-r /etc/apache2
По умолчанию индеец загружает довольно большое количество модулей. Чтобы просмотреть те, что скомпилированы вместе с Apache, используй apache2ctl –l или apache2 -l. К сожалению, лишнее из полученного списка убирается только путем полной пересборки индейца. Все динамически загружаемые модули (Dynamic Shared Object) можно просмотреть, введя:

Код: [Выделить]

$ sudo grep –R LoadModule /etc/apache2/*
Внимательно изучаем полученный список и в конфиге комментируем то, что не нужно. Вот список модулей, которые можно безболезненно отключить, естественно, убедившись, что они действительно нами не используются: mod_imap, mod_autoindex, mod_include, mod_info, mod_userdir, mod_status.

Apache поддерживает два типа аутентификации: basic и digest (обеспечивается модулем mod_auth_digest). В первом случае пароль передается в открытом виде. При использовании этого типа аутентификации у злоумышленника есть возможность перехватить логин и пароль и получить доступ ко всей «охраняемой» области. В digest передается Response, который представляет собой контрольную (обычно MD5) сумму от комбинации логина, пароля, запрашиваемого URL, метода HTTP и строки nonce, генерируемой сервером при ответе. Строка nonce позволяет сделать эту строку поистине уникальной. Для включения digest-аутентификации используем:

Код: [Выделить]

AuthType Digest
Одной из особенностей Apache является использование типового доступа, когда многие параметры либо устанавливаются по умолчанию, либо наследуются от родительского каталога. Чтобы избежать неприятностей, следует принудительно ограничить выполнение CGI-скриптов, SSI (Server Side Includes) включений, индексирования каталога и следование символическим ссылкам. Для этого в описании ресурса необходимо деактивировать следующие директивы:

Код: [Выделить]

Options All -Indexes -Includes –ExecCGI -FollowSymLinks
Либо отключить все сразу:

Код: [Выделить]

Options None
Чтобы злоумышленник не смог прочитать временные или конфигурационные файлы, используй следующую конструкцию:

Код: [Выделить]

<Files "(^\.ht|~$|\.bak$|\.BAK$)">

Order Allow,Deny

Deny from all

</Files>
Во избежание доступа к файлам, расположенным вне корневого каталога веб-сервера, нужно сначала принудительно ограничить доступ, а затем явно разрешить его только для требуемых каталогов. При нормальном раскладе подключившийся пользователь не сможет выйти за DocumentRoot, но для страховки стоит указать:

Код: [Выделить]

<Directory />

Order Deny,Allow

Deny from all

Options None

AllowOverride None

</Directory>

<Directory /var/www>

Order Allow,Deny

Allow from all

</Directory>
При необходимости значения директив AllowOverride и Options переопределяются в конкретном каталоге.

Другим способом не выпустить пользователя за DocumentRoot является использование chroot, речь о котором пойдет далее.

Не всегда веб-сервер или отдельный ресурс должны быть видны из сети. Например, используется прокси, либо это внутренний сервер компании. Если нет возможности закрыть доступ брандмауэром или использовать отдельный интерфейс, тогда доступ к ресурсу следует ограничить на основании IP-адреса или диапазона IP-адресов:

Код: [Выделить]

Order Deny,Allow

Deny from all

Allow from 192.168.0.0/24
Несмотря на то что директива Satisfy имеет всего два параметра - All и Any, она предоставляет возможность более гибко контролировать доступ к ресурсу. Например, нам нужно, чтобы доступ к приватной папочке могли получить только зарегистрированные пользователи и только с указанных адресов. Как это сделать? Очень просто:

Код: [Выделить]

Order Deny,Allow

Deny from all

Require valid-user

Allow from 192.168.0.0/24

Satisfy All
А для того чтобы пользователи внутренней сети могли вообще не регистрироваться, ставим вместо All Any.

Если изменить значения некоторых параметров, можно смягчить эффект DoS-атаки. Например, Timeout определяет, в течение какого времени сервер будет ожидать ответа клиента. В более ранних версиях Apache значение этой директивы равнялось 1200 секундам, затем оно было уменьшено до 300 сек. Мы можем спокойно его урезать, например, до 60 сек (это отразится только на пользователях с плохим соединением):

Код: [Выделить]

Timeout 60
По умолчанию размер клиентского запроса неограничен. Это обстоятельство также может быть использовано для организации DoS-атаки. Администратор в силах принудительно указать размер запроса в пределах от 0 (неограничен) до 2 147 483 647 байт (2 Гб) как для всего сервера, так и для отдельных ресурсов. Например, чтобы ограничить размер запроса 100 килобайтами, пишем:

Код: [Выделить]

LimitRequestBody 102400
Если клиент загружает на сервер некоторые данные (например, содержимое заполненных форм), то этот параметр следует скорректировать.

Для противодействия атакам «Отказ в обслуживании» существует целый ряд директив: LimitRequestFields, LimitRequestFieldSize и LimitRequestLine, MaxRequestsPerChild, MaxClients и некоторые другие. При необходимости, возможно, их значения стоит пересмотреть, выставив оптимальные для конкретных условий. Как вариант - для борьбы с DoS-атаками можно применять специальный модуль mod_evasive (www.zdziarski.com/projects/mod_evasive).

Устанавливаем ModSecurity

Значительно повысить защищенность веб-ресурса можно с помощью ModSecurity. Этот проект, созданный Иваном Ристиком в 2003 году, позволяет защищать веб-приложения как от известных, так и от еще неизвестных атак. ModSecurity работает в виде модуля веб-сервера Apache, либо в автономном режиме. Его использование прозрачно, установка и удаление не требуют изменения настройки сервисов и сетевой топологии. Кроме того, при обнаружении уязвимого места теперь нет необходимости править исходные коды, создавая новые ошибки, - достаточно добавить правило, запрещающее вредоносную комбинацию.

В репозитарии некоторых дистрибутивов уже включен нужный пакет, следует поискать что-то вроде mod-security. В Debian достаточно добавить в /etc/apt/sources.list новый репозитарий:

Код: [Выделить]

deb http://etc.inittab.org/~agi/debian/libapache-mod-security2/ etch/
И затем можно инсталлировать:

Код: [Выделить]

# apt-get update

# apt-get install libapache2-mod-security2
Установить ModSecurity из исходных текстов тоже просто. Для сборки необходимы заголовочные файлы Apache, поэтому забираем исходные тексты веб-сервера из репозитария или с сайта проекта:

Код: [Выделить]

$ sudo apt-get apache2-src libxml2-dev
Если используются исходные тексты, взятые с сайта проекта, то перед компиляцией mod_security следует сконфигурировать веб-сервер командой ./configure с нужными параметрами (для работы модуля понадобится '--enable-unique-id'), а затем выполнить следующие действия:

Код: [Выделить]

$ wget –c www.modsecurity.org/download/modsecurity-apache_2.1.1.tar.gz

$ tar xzvf modsecurity-apache_2.1.1.tar.gz

$ cd modsecurity-apache_2.1.1/apache2

Теперь редактируем Makefile:

Код: [Выделить]

$ mcedit Makefile
# Меняем apxs на apxs2 (APache eXtenSion tool)

Код: [Выделить]

APXS = apxs2
# Каталог с исходными текстами Apache

Код: [Выделить]

top_dir = /home/grinder/source/httpd-2.2.4
Компилируем модуль, останавливаем Apache, устанавливаем модуль:

Код: [Выделить]

$ make

$ sudo /etc/init.d/apache2 stop

$ sudo make install
В конфигурационный файл веб-сервера добавляем две строчки:

Код: [Выделить]

LoadFile /usr/lib/libxml2.so

LoadModule security2_module /usr/lib/modules/mod_security2.so
Для удобства все настройки mod_security лучше вынести в отдельный файл, взяв за пример готовый шаблон и подключив его в apache2.conf директивой:

Код: [Выделить]

Include /etc/apache2/mod_security.conf
Копируем шаблон и правим:

Код: [Выделить]

$ sudo cp modsecurity-apache_2.1.1/modsecurity.conf-minimal /etc/apache2/mod_security.conf

$ sudo mcedit /etc/apache2/mod_security.conf

Код: [Выделить]

<IfModule mod_security2.c>

SecRuleEngine On

...

SecFilterDefaultAction "deny,log,status:430"

</IfModule>
Активируем модуль mod_unique_id:

Код: [Выделить]

$ sudo a2enmod unique_id
Теперь можно запускать Apache:

Код: [Выделить]

$ sudo /etc/init.d/apache2 start
Если все работает нормально, можно добавлять правила. Команда разработчиков уделяет большое внимание усовершенствованию кода mod_security, оставляя создание правил на откуп пользователю, поэтому оригинальный конфигурационный файл имеет всего несколько рулесетов, находящихся в подкаталоге rules. На сайте проекта лежит отдельный архив modsecurity-core-rules. Для подключения входящих в его состав правил достаточно скопировать все conf-файлы в каталог /etc/apache2 и в секции mod_security2.c указать:

Код: [Выделить]

Include rules/*.conf

Include rules/blocking/*.conf
Подключать все сразу не стоит. Некоторые правила требуют редактирования под конкретные условия, лучше разбираться постепенно.

Защищаем PHP с помощью Suhosin

Задача проекта Suhosin (www.hardened-php.net/suhosin) - защита серверов и пользователей от целого ряда известных проблем в приложениях и ядре PHP, так как safe_mode помогает далеко не всегда. Сам Suhosin состоит из двух независимых частей, которые могут использоваться как раздельно, так и совместно. Первая часть – небольшой патч к ядру, осуществляющий низкоуровневую защиту структур данных от переполнения буфера, уязвимости форматной строки и ошибок в реализации функции realpath, присущей некоторым платформам, а также от других потенциальных уязвимостей ядра PHP. Вторая часть реализована в виде расширения, которое фактически и осуществляет всю основную защиту, при необходимости его очень просто доустановить в уже рабочую систему без полной пересборки PHP. С полным списком возможностей можно познакомиться на сайте проекта www.hardened-php.net/suhosin/a_feature_list.html.

В случае нарушения установленных правил возможна блокировка переменных, отсылка определенного HTTP-кода ответа, перенаправление браузера пользователя, выполнение другого PHP-скрипта. Все события заносятся в журналы, для чего может использоваться syslog, свой модуль или внешний скрипт. Последние версии расширения Suhosin совместимы практически со всеми версиями PHP.

Установка Suhosin включает в себя 2 этапа: наложение патча на PHP с последующей его пересборкой и компиляция модуля расширения. Хотя возможна и сборка со встроенным расширением. Чтобы не было проблем с зависимостями, в Ubuntu перед началом установки рекомендую дать команду

Код: [Выделить]

sudo apt-get build-dep php5.
Скачиваем PHP, затем патч suhosin под используемую версию PHP и модуль расширения. Все это распаковываем, накладываем патч и компилируем:

Код: [Выделить]

$ tar xvjf php-5.2.3.tar.bz2

$ gunzip suhosin-patch-5.2.3-0.9.6.2.patch.gz

$ cd php-5.2.3

$ patch -p 1 -i ../suhosin-patch-5.1.6-0.9.5.patch

$ ./configure [--enable-so и другие параметры при необходимости]

$ make

$ make test

$ sudo make install
Теперь собираем модуль расширения:

Код: [Выделить]

$ tar xzvf suhosin-0.9.20.tgz

$ cd suhosin-0.9.20

$ phpize

$ ./configure --prefix=/usr/lib/php5/20060613+lfs/

$ make

$ make test

$ sudo make install
Проверить сборку можно, введя команду:

Код: [Выделить]

$ php –v
PHP 5.2.3 with Suhosin-Patch 0.9.6.2 (cli) (built: Jul 26 2007 11:35:13)

Все настройки Suhosin производятся в файле php.ini. Патч поддерживает только опции регистрации, поэтому первой записью обязательно подключаем модуль suhosin.so (он должен быть виден переменной LD_RUN_PATH):

Код: [Выделить]

extension=suhosin.so
После установки Suhosin будет работать с настройками по умолчанию, которые достаточны, но, возможно, не оптимальны для твоей конфигурации.

Строим chroot

Для построения chroot-окружения нам понадобится модуль mod_chroot (core.segfault.pl/~hobbit/mod_chroot). В репозитарии Ubuntu он присутствует:

Код: [Выделить]

$ sudo apt-get install libapache2-mod-chroot
Параллельно будет установлен пакет mod-chroot-common, содержащий документацию (/usr/share/doc/mod-chroot-common). Для самостоятельной сборки mod_chroot достаточно распаковать свежескачанный архив и ввести команду apxs2 -cia mod_chroot.c. Далее следует указать, что рабочий каталог теперь является корневым, то есть в apache2.conf прописываем:

Код: [Выделить]

<IfModule mod_chroot.c>

LoadFile /lib/libgcc_s.so.1

PidFile /var/run/httpd.pid

ChrootDir /var/www

DocumentRoot /

</IfModule>

Значение DocumentRoot изменяем с «/var/www» на «/» и все ссылки на ресурсы даем относительно корня. В apache2.conf не забываем подключить модуль:

Код: [Выделить]

LoadModule chroot_module /usr/lib/apache2/modules/mod_chroot.so
Либо в Ubuntu правильнее:

Код: [Выделить]

$ sudo a2enmod mod_chroot
При использовании Apache2 понадобится создать каталог для PID-файла.

Код: [Выделить]

$ sudo mkdir -p /var/www/var/run

$ sudo chown -R root:root /var/www/var/run

$ sudo ln -s /var/www/var/run/httpd.pid /var/run/httpd.pid
Перезапускаем индейца и проверяем работу.

Это далеко не все, что можно сделать для защиты LAMP. Также следует учесть, что приведенные советы не могут гарантировать абсолютной безопасности (такого просто не бывает в природе) хотя несколько уменьшить риск они позволяют. Кроме того, в некоторых средах часть параметров может вызывать проблемы или влиять на производительность. Поэтому к их использованию следует подходить осторожно, вводя изменения постепенно и тщательно тестируя результат. Универсальный совет по-прежнему один: следует изучать документацию и включать только то, что нужно.c

Информация хоть и 2007 года, но ничего свежее я не нашел. В статье не указано на каком именно дистрибутиве проводилась настройка, а у меня на ubuntu desktop i386 10.10 возникла проблема при задании прав на файлы и директории. Например команда

Код: [Выделить]

$ sudo /etc/apache2 -type d | xargs chmod 755 у меня не работает, просит ввести еще какие-то дополнительные параметры. Подскажите пожалуйста как это применить по отношению у ubuntu 10.10. Или киньте ссылкой, где можно почитать на эту тему. На окошках настроил бы все это быстро, а вот на ubuntu пересел недавно и с шелом еще пока не разобрался

Заранее спасибо за любое участие.

p.s. Кстати интересует мнение бывалых админов по поводу данной статьи и приведенных примеров, насколько они сейчас актуальны, какие существуют еще дыры (кроме криво написанного php кода) ну и т.д.

[xeon_greg]

тут имеется в виду установить права на все директории в каталоге apache2  в 755 и след комманда установить права на все файлы в этой же директории в 644
Пользователь решил продолжить мысль 28 Февраля 2011, 17:36:49:автор видимо пропустил find
и полная комманда должна быть такая

Код: [Выделить]

sudo find /etc/apache2 -type d | xargs chmod 755
sudo find /etc/apache2 -type f | xargs chmod 644


[haligali]

xeon_greg
Благодарствую.  Действительно, так работает!!! Для чего эти команды я и так знаю, а вот с синтаксисом у меня  проблема. Надо срочно где то ман по Shell-у нарыть.

[xeon_greg]

нигде рыть не надо 

Код: [Выделить]

man bash

[haligali]

xeon_greg
Оппа-ньки. Крута. Даже не знал. Обычно --help по команде набирал, но там инфы мало. Буду курить потихоньку.

[IP-2011]

Всем Привет!
Вот тоже занимаюсь этим вопросом...
Вернее пока только изучаю сервер, настройки, безопасность.
Так что сильно не пинайте если что не так... Я только учусь
Ну собственно по теме.
Вот ещё одна интересная статейка... И поновее.

(Нажмите, чтобы показать/скрыть)

Xakep

Последний рубеж: обзор нестандартных файеров и инструментов защиты веб-сервисов

Веб сегодня популярен настолько, что разработкой приложений под него занимаются практически все, кому не лень - от фрилансеров до больших софтовых компаний. Причем безопасности продукта обе эти категории граждан (и их сообществ) порой уделяют не самое пристальное внимание. Но даже проверка при помощи сканера не может гарантировать отсутствие проблем. Проекты, живущие не один год, и те подчас содержат уязвимости. Специальные файеры седьмого уровня позволяют защититься, абстрагировавшись от конкретного приложения.
Защита СУБД с GreenSQL-FW

Классическое веб-приложение любого назначения для своей работы использует собственно веб-сервер с активным модулем интерпретатора языка и базу данных, в которой хранятся данные. Все известные на сегодня атаки (XSS, SQL-injection, XPath-injections, CSRF/XSRF, HTTP Response Splitting, Include-атаки и другие) в той или иной мере используют недоработки программистов, позволяющие в итоге получить доступ к закрытой информации. Обнаружить и устранить все возможные ошибки просто нереально, и веб-приложения здесь - не исключение. Впрочем, приемы атакующих хорошо известны. Этот факт используют в специальных средствах, разработчики которых отслеживают все потенциально опасные, да и просто запрещенные администратором запросы, и пытаются их блокировать или изменить. На страницах журнала уже рассматривались такие приложения, как AppArmor, SELinux и TOMOYO Linux (][ от 08.2010), которые также подходят под наши цели и способны противостоять многим атакам.

Сегодня рассмотрим некоторые другие решения. Обзор начнется с проекта GreenSQL-FW), который, работая как прокси-сервер между веб-приложением и SQL-сервером, анализирует SQL-команды на предмет аномальных запросов и команды администрирования SQL-сервера, которые часто используются взломщиками (DROP, CREATE и т.д.). Используя GreenSQL, админ может определить список допустимых и запрещенных масок для операций DELETE, UPDATE и INSERT, а также блокировать запросы, содержащие ID администратора. При обнаружении атак кроме "опасных" команд используется "степень риска", которая вычисляется для каждого запроса к СУБД. В числе факторов, влияющих на коэффициент риска, могут выступать самые популярные приемы хакеров: обращение к служебным таблицам и конфиденциальным данным, запросы, всегда возвращающие TRUE, попытка обнулить поля с паролем, использование в запросе OR, сравнение констант и другие. При превышении уровня риска установленного порога запрос блокируется, а приложению отправляются пустые данные.

GreenSQL поддерживает несколько режимов работы:

    * Simulation Mode - пассивная система обнаружения атак (IDS), только протоколирующая SQL-запросы и выдающая предупреждения на консоль управления;
    * Blocking Suspicious Commands - атаки не только обнаруживаются, но и блокируются (IPS) в соответствии с установленными правилами, указывающими на аномальность запроса;
    * Active protection from unknown queries - блокирование всех неизвестных запросов (db firewall);
    * Learning mode предназначен для прогона и настройки правил в "чистой" среде, что позволяет сформировать белый список для предотвращения ложных срабатываний впоследствии.

Сразу после установки разработчики рекомендуют включить "Learning mode", а после сбора данных перевести GreenSQL в режим "Active protection".

На сайте проекта доступны три версии файера: Community, Light и Pro. Первая - бесплатная (по лицензии GNU GPL) и предоставляет основные возможности, поддерживая СУБД MySQL и PostgreSQL (появилась в версии 1.2) и установку в Linux. Коммерческие версии, кроме этого, умеют защищать MS SQL Server и работают еще и на Win2k3/2k8.

Само защищаемое приложение роли не играет - это может быть портал, CMS и вообще все, что угодно. GreenSQL обычно устанавливается на том же сервере, что и SQL-база, хотя это необязательно. По умолчанию GreenSQL слушает локальный порт 127.0.0.1:3305, после анализа перенаправляя SQL-запросы на стандартный порт MySQL - 127.0.0.1:3306. При необходимости эти параметры легко изменить в консоли.

Управление программой и просмотр статистики запросов и блокировок производится через консоль или веб-интерфейс. При помощи одной консоли можно управлять защитой нескольких СУБД.

Кратко разберем настройку GreenSQL Community. На сайте проекта доступны исходные тексты и пакеты для Ubuntu, RHEL/CentOS 5, Fedora, Debian, SLE/openSUSE и Mandriva. Установка в Ubuntu проста: скачиваем deb-пакет, затем устанавливаем из него, как обычно:

$ sudo dpkg -i greensql-fw_1.2.2_amd64.deb

После этого в появившемся окне нужно выбрать тип СУБД, которую будет защищать GreenSQL, IP-адрес или имя сервера, порт, данные root, название базы данных, в которой будут храниться настройки. Дальше скрипт предложит создать новую учетную запись для подключения к БД. В случае, если в дальнейшем понадобится изменить эти установки, можно поступить просто:

$ sudo dpkg-reconfigure greensql-fw

Как вариант, можно запустить скрипт "greensql-create-db". Конфигурационные файлы GreenSQL находятся в каталоге /etc/greensq. Основной файл называется greensql.conf и содержит настройки подключения к БД, журналирования и рисков. Установки рисков по умолчанию подходят для большинства случаев и ничего трогать внутри обычно не нужно, хотя при необходимости можно поиграться цифрами рисков, просматривая журнал (/var/log/greensql.log) и подгоняя под свои условия. Все поля комментированы, поэтому их назначение должно быть понятным.

Проверить, работает ли GreenSQL, очень просто: подключаемся к 3305 порту, нас должны перебросить на 3306, на котором скучает MySQL.

$ mysql -h 127.0.0.1 -P 3305 -u root -p

Все как обычно, но, например, на запрос "show databases" мы получим пустой список. Осталось переправить настройки всех клиентов, работающих с БД, на новый порт 3305, хотя проще поступить наоборот, заставив GreenSQL слушать порт 3306, а мускул перестроить на тот же 3305. Тогда трогать клиентские приложения не понадобится. Для управления разработчики предлагают веб-интерфейс. Чтобы его настроить, подключаем файл /etc/greensql/greensql-apache.conf в конфиге апача:

Include /etc/greensql/greensql-apache.conf

В greensql-apache.conf также нужно произвести некоторые настройки:

# снимаем комментарии с этих строк
<IfModule mod_alias.c>
    Alias /greensql "/usr/share/greensql-fw"
</IfModule>

Разрешаем всем запись в подкаталог templates_c:

$ sudo chmod 0777 /usr/share/greensql-fw/templates_c

В файле config.php устанавливаем корректные данные для доступа к БД:

$db_type = "mysql";
$db_host = "localhost";
$dbport=3306
$db_name = "greendb";
$db_user = "green";
$db_pass = "pwd";

Включаем mod_alias и перезапускаем веб-сервер:

$ sudo a2enmod alias
$ sudo service apache2 restart

Теперь регистрируемся через веб-интерфейс, использовав для входа учетную запись "admin" с паролем "pwd".
Файер для апача - ModSecurity

Основой для всех веб-приложений является, естественно, веб-сервер. Поэтому неудивительно, что попыток остановить атаку на этом уровне предпринимается достаточно много. Усилиями разных организаций создан консорциум WASC (Web Application Security Consortium) - некоммерческая организация, состоящая из экспертов, задача которой - сбор и обмен информацией по безопасности веб-приложений, разработка рекомендаций и критериев. Плюс ко всему, WASC поддерживает несколько десятков проектов, связанных с безопасностью в веб. Файерволы веб-приложений ModSecurity и WebDefend  являются, наверное, самыми известными из них. По сути, они разрабатываются одной и той же группой. Первый (стартовал в 2003 году) распространяется по OpenSource-лицензии, второй является полностью коммерческим продуктом.

Реализован ModSecurity в виде модуля к веб-серверу Apache 2.0/2.2, его использование прозрачно и не требует изменений в настройке сервисов. Настройка работы производится благодаря правилам, которые описываются при помощи гибкого языка. В случае обнаружения проблемного места зачастую проще создать новое правило, блокирующее уязвимость, а затем уже не спеша разобраться с приложением, не останавливая его работу. Именно поэтому ModSecurity идеально подходит для защиты веб-сервисов от известных и неизвестных атак. Правила, по сути, определяют возможности текущей установки ModSecurity. Сами разработчики занимаются исключительно разработкой ModSecurity и добавлением новых функций, а правила создаются сторонними организациями.

Так, под руководством OWASP разрабатываются Сore Rule Set (CRS), находящиеся в свободном доступе и предлагающие общую защиту веб-сервисов от всех известных и неизвестных (0-day) атак и их разновидностей. Правила CRS обеспечивают контроль HTTPзаголовков, выявляя аномальность и соответствие требованиям, обнаруживают попытки сканирования, детектор атак и обращения к бэкдорам. Правила периодически можно обновлять через сервис Rules Subscription Service. Возможна проверка файлов при помощи ClamAV. Кроме этого реализованы расширенные (но не бесплатные) рулесеты, Enhanced Rule Set (ERS), обеспечивающие защиту коммерческих приложений (IIS, Outlook Web Access и др.), поддержку стандарта PCI DSS (Payment Card Industry Data Security Standard), проверку сложности пароля и прочее.

На сегодня актуальной является версия ModSecurity 2.5.12, в которой использован более быстрый механизм поиска соответствий, кэширования промежуточных значений для каждого запроса, вставки произвольного текста в HTML-контент (Content Injection), анализ запроса на наличие номеров кредитных карточек (оператор @verifyCC), универсальная защита от XSS через локальные ссылки в PDF-файлах. Язык получил новые директивы: skipAfter, SecMarker, ctl:ruleRemoveById (динамическое удаление правил), переменную GEO для привязки правил к географической принадлежности посетителя, директиву SecRuleScript, которая позволяет подключать сценарии на языке Lua. Добавлен новый скрипт, rules-updater.pl, позволяющий автоматически обновлять правила из внешнего репозитория.

Пакет с ModSecurity доступен в репозиториях всех основных дистрибутивов. Смотрим актуальность пакета в репозитории Ubuntu:

$ sudo apt-cache search libapache-mod-security | grep -i version
Version: 2.5.11-1

В принципе, не самый последний релиз, но можно ставить:

$ sudo apt-get install libapache-mod-security

Кроме исходных текстов, на сайте можно найти ссылки на репозитории сторонних разработчиков, предлагающих сборки под Debian, RHEL/CentOS, Fedora, Gentoo, FreeBSD, Apache под Windows и другие. Правда, на поверку оказывается, что некоторые версии в них еще более поздние.

Самостоятельная сборка модуля при помощи исходных текстов не сложна, хотя ее порядок чуть меняется от версии к версии. Все зависимости вытянуть просто:

$ sudo apt-get build-dep libapache-modsecurity

Для работы ModSecurity понадобится модуль unique-id, в Ubuntu просто включаем его:

$ sudo a2enmod unique_id

При самостоятельной сборке Apache необходимо сконфигурировать веб-сервер с параметрами "--enable-uniqueid" и "--with-pcre". Распаковываем архив:

$ tar tar xzvf modsecurity-apache_2.5.12.tar.gz
$ cd modsecurity-apache_2.5.12/apache2
$ ./configure

Для сборки используется apxs (APache eXtenSion tool), который устанавливается из зависимостей:

$ make
$ make test
All tests passed (576).

Опционально можно собрать коллектор журналов ModSecurity Log Collector, введя "make mlogc". Ставим:

$ sudo make install

После чего следует изменить права доступа к собранному модулю:

$ sudo chmod 644 /usr/lib/apache2/modules/mod_security2.so

Редактируем конфиг веб-сервера, чтобы загружать нужные библиотеки и модули:

LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so
LoadModule security2_module modules/mod_
security2.so

Осталось отредактировать конфигурационный файл ModSecurity. При установке с помощью пакетов он скопируется автоматически, а вот если ты использовал исходники, то придется сделать это вручную:

$ sudo cp modsecurity-apache_2.5.12/modsecurity.conf-minimal /etc/apache2/mod_security.conf

Синтаксис и список параметров в конфиге в последних версиях изменился. Настроек стало больше, но на первых порах можно использовать дефолтные. Все подробности можно просмотреть в документации ModSecurity. Вместе с ModSecurity поставляются правила CRS, новую версию которых всегда можно скачать на OWASP (текущая версия 2.0.8, есть и доступ к CVS). Например, в архиве с исходными текстами лежат два конфига, настраивающих работу CRS и подкаталога с правилами base_rules и optional_rules. Создадим для правил подкаталог /etc/apache2/modsecurity и скопируем в него файлы:

$ sudo mkdir /etc/apache2/modsecurity
$ tar xzvf modsecurity-crs_2.0.8.tar.gz
$ sudo mv -v modsecurity-crs_2.0.8/* /etc/apache2/modsecurity/

Теперь все файлы следует подключить в конфиге апача:

<IfModule security2_module>
    Include modsecurity/*.conf
    Include modsecurity/base_rules/*.conf
# и если требуются опциональные правила
    Include modsecurity/optional_rules/*.conf
</IfModule>

В конфиге modsecurity_crs_10_config.conf, описывающем работу правил ModSecurity, указаны общие установки; изменяя значение некоторых параметров, можно сделать их более лояльными или наоборот, установить параноидальный режим. В каждых конкретных условиях лучше разбираться постепенно.

Теперь можно перезапускать апач:

$ sudo service apache2 start

И наслаждаться защищенными сервисами. Всю информацию по работе MosSecurity можно получить, анализируя журналы, и в случае необходимости корректировать настройки и правила.

    Файервол уровня приложений Zorp

    Разработчик популярного Syslog-NG, венгр Балазс Шайдлер , является также автором еще одного проекта - Zorp. Его задача - защита приложений от направленных атак. Являясь расширением к Netfilter/iptables, Zorp представляет собой прозрачный прокси, который различает протоколы верхнего уровня, "знает" их особенности и на основании настроек может принять решение о необходимости продолжения текущего соединения. Версия Zorp GPL доступна по лицензии GNU GPL.

Suhosin - щит для PHP

Судя по результатам разных опросов, язык PHP является основным при разработке веб-приложений, ему отдают предпочтение как минимум половина программистов. Но не все они обладают опытом, достаточным для того, чтобы предусмотреть все проблемы, в результате которых наскоро написанные сайты легко подвергаются взлому. На сегодня известны несколько проектов, позволяющих повысить защищенность: suPHP, htscanner и Suhosin. Проект suPHP предлагает модуль для Apache (mod_suphp) и оболочку для PHP, сочетание которых позволяет выполнять PHP-скрипты с правами их владельца. В htscanner пошли еще дальше, позволив настраивать доступ к скриптам в стиле htaccess.

И, наконец, Suhosin, задача которого куда серьезнее - низкоуровневая защита данных против атак на переполнение буфера, уязвимостей форматной строки, различных реализаций include (от ошибок в реализации функции realpath и экспериментальной поддержки защиты SQL до фильтрации некоторого контента и многого другого). Полный список приведен на сайте проекта в Feature List.

Функционально Suhosin разделен на два компонента, которые могут использоваться вместе или независимо друг от друга. Первая часть реализована в виде патча к ядру PHP, обеспечивает низкоуровневую защиту (Engine Protection). Некоторые приложения не особо дружат с Suhosin-патчами, поэтому не всегда в дистрибутивах он идет в штатной поставке PHP.

Проверить наличие патча в своей сборке PHP очень просто. В Ubuntu 10.04:

$ sudo apt-get install php5-cli
$ php -v
PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built:Sep 17 2010 13:49:46)

Вывод показывает, что PHP уже собран с патчем Suhosin. Вторая, высокоуровневая часть реализована в виде модуля PHP suhosin.so, который легко установить в любую систему без пересборки самого PHP. По сравнению с патчем, модуль обеспечивает большее количество функций. Кроме различного рода блокировок переменных, отсылки кода ответа и перенаправления браузера предусмотрена запись событий в журнал или передача во внешний скрипт/программу. В Ubuntu он по умолчанию не устанавливается.

$ sudo apt-get install php5-suhosin

Кроме собственно модуля устанавливается конфигурационный файл /etc/php5/conf.d/suhosin.ini. Переменных внутри много, все они, кроме разрешающего загрузку модуля, закомментированы. Описание параметров можно найти в man-странице и на сайте проекта в документе Configuration.
Заключение

Защитить веб-приложение, даже не зная всех его особенностей, вполне реально. Тем не менее, любое из рассмотренных решений требует подгонки под конкретные условия, чтобы работать с максимальной эффективностью!
Теги: Linux , администрирование , защита , файрвол

Собственно заинтересовал mod-security
Ну и решил его поставить.

(Нажмите, чтобы показать/скрыть)

Нашёл в синаптике, установил.
Зашёл в папку индейца и началось...
Не обнаружил там файл конфигурации мода безопасности...
В файл конфигурации индейца тоже ничего не добавилось...
Почесав репу пошёл снова к синаптику и спросил какие файлы от мода и где лежат...
Он меня послал в /usr/share/doc/lib-apach...mod_security
Там в папки exampl нашёл файл настроек который упоминается в обоих статьях и папку рулесетов.
Скопировал это всё дело к индейцу.
Добавил в файл настроек индейца такое

Код: [Выделить]

<IfModule security2_module>
Include modsecurity/*.conf
Include modsecurity/base_rules/*.conf
Include modsecurity/optional_rules/*.conf
</IfModule>
Правила вроде подцепились...
Индеец заматерился при запуске нескольких правил из папки options.
Посмотрев и не найдя ошибки удалил 2 правила.
Пнул индейца и он завёлся.
Ну так мне и не было понятно подхватил ли он файл настроек самого мода или нет...
Добавил ниже это
Include modsecurity.conf
Индеец снова заматерился при запуске на то что нет директории для логов, создал и снова его пнул.
На этот раз он завёлся.

Ну а теперь собственно вопросы...
Кто пользует этот мод подскажите всё правильно ли я сделал???
Или что где пропустил?
P.S. Ubuntu 10.10
И ещё вопросы из предидущей статьи...
1 Разве индеец и так по умолчанию не от пользователя www-data запускается?
2 Зачем выставлять права 755 и 644 ?
Насколько я знаю и насколько у меня в Ubuntu  на эти папки и файлы и так эти права стоят...
Или я что-то не допонимаю?
И Администраторы со стажем и опытом поделитесь своим мнением по всему этому...
Насколько это всё эффективно и практично???
Увеличивает ли это всё безопасность на средний хотябы уровень???
Заранее благодарен за любые отзывы!

[AnrDaemon]

Ну во-первых по настройке - файл настройки апача всю жизнь писался наоборот.
Не IfModule - Include - настройки, а Include - IfModule - настройки.
Вместо засорения форума дурацкими статьями, могли бы просто ссылку дать.

[IP-2011]

Ну во-первых по настройке - файл настройки апача всю жизнь писался наоборот.
Не IfModule - Include - настройки, а Include - IfModule - настройки.
Вместо засорения форума дурацкими статьями, могли бы просто ссылку дать.

Спасибо!
 Тогда так должно что ли быть?

Код: [Выделить]

Include <IfModule security2_module> modsecurity/*.conf </IfModule>
Include <IfModule security2_module> modsecurity/base_rules/*.conf </IfModule>
Include <IfModule security2_module> modsecurity/optional_rules/*.conf </IfModule>

Include modsecurity.conf
Или можно вобще без Ifmodule ... /IfModule ?
2. Учту на будущие
Хотя специально взял под сполер статью...
А по поводу прав на папки /etc/apache2/ и вложеные в них файлы можете что-нибудь сказать?
И про юзера от которого запускается индеец?

[AnrDaemon]

Мда. Вы хоть в существующие конфиги апача гляньте...

[IP-2011]

Мда. Вы хоть в существующие конфиги апача гляньте...

Вы это про что "Да" сказали?
Про include или про остальные вопросы?
1. Я в конфиги смотрю...
Если про include то там вобще у меня прописано без IfModule всё с дефолта поэтому и спросил...
т.е у меня с include всё вот так...

Код: [Выделить]

# Include all the user configurations:
Include httpd.conf

# Include ports listing
Include ports.conf2. Например если Вы по поводу юзера от которого работает индеец,
то у меня например эта настройка выведена из файла конфигурации...
т.е. у меня так

Код: [Выделить]

User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}И все настройки вынесены в

# These need to be set in /etc/apache2/envvars

А там уже www-data .
Вот я и спрашиваю зачем описано ещё раз делать из мухи слона и вымучивать то что написано про юзера и права пользователя в первой статье...
P.S.
А про IfModule вы помойму не правы...
Лично у меня написано в конфигах так как я писал первый раз...
Вот пример из конфига...

Код: [Выделить]

<IfModule mpm_worker_module>
    StartServers          2
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>