Установка mod_security на SLES10

Кратко

Введение

Модуль Apache mod_security — мощный модуль веб‑защиты уровня приложения. В сочетании с предопределёнными правилами он помогает закрывать уязвимости, которые могут появиться из‑за плохо написанных PHP/Perl приложений.

В SLES10 mod_security отсутствует в официальном репозитории, поэтому требуется сборка из исходников и установка сторонних пакетов. Этот документ проведёт вас по процессу установки, упаковки в RPM и базовой настройке. Также приведён чек‑лист, сценарии тестирования и варианты обхода проблем.

Важно: все команды нужно выполнять с правами root или через sudo.

Требования и объяснение терминов

mod_security — модуль веб‑файрвола для Apache, анализирует запросы и блокирует подозрительную активность.
liblua — библиотека для языка Lua, используемая для конфигурации правил mod_security.
checkinstall — утилита для создания RPM из “make install” и упрощённого удаления пакета.

Установка Apache2

Сначала установите Apache2 через YaST:

yast2 -i apache2

Примечание: на SLES YaST устанавливает совместимые версии пакетов и создаёт стандартную структуру /etc/apache2.

Установка необходимых пакетов для сборки

Для сборки mod_security понадобятся dev‑пакеты и компилятор:

yast2 -i libxml2-devel pcre-devel apache2-devel curl-devel gcc gcc-c++

apache2-devel нужен для apxs2, curl-devel — опционально (если планируете поддержку URL/HTTP в правилах).

Получение и установка checkinstall (для упаковки в RPM)

Чтобы отслеживать файлы, установленные “make install”, удобно использовать checkinstall. Он создаёт RPM и позволяет позже удалить пакет стандартным rpm.

Скачать можно по адресу: http://www.asic-linux.com.mx/~izto/checkinstall/download.php

Пример сборки и установки:

wget http://www.asic-linux.com.mx/~izto/checkinstall/files/source/checkinstall-1.6.1.tgz
make
make install
checkinstall
cp /usr/src/packages/RPMS/i386/checkinstall-1.6.1-1.i386.rpm .
rpm -ivh checkinstall-1.6.1-1.i386.rpm

После этого у вас будет установлен checkinstall и сгенерированный RPM будет доступен для удаления.

Получение и установка liblua

mod_security использует Lua для части конфигурации. Lua необходимо собрать как общую библиотеку (shared).

Источник: http://www.lua.org/ftp/lua-5.1.3.tar.gz

Команды сборки и упаковки:

wget http://www.lua.org/ftp/lua-5.1.3.tar.gz
tar -zxvf lua-5.1.3.tar.gz
cd lua-5.1.3
make linux
checkinstall

При использовании checkinstall вам будет предложено заполнить поля пакета, пример вывода:

[…]
1 - Summary: [ The LUA programming language ]
2 - Name: [ lua ]
3 - Version: [ 5.1.3 ]
4 - Release: [ 1 ]
5 - License: [ GPL ]
6 - Group: [ Development/Languages/Lua ]
7 - Architecture: [ i386 ]
8 - Source location: [ http://www.lua.org/ftp/lua-5.1.3.tar.gz ]
9 - Alternate source location: [ ]
10 - Requires: [ ]
11 - Provides: [ lua ]
[…]

Затем установите RPM:

cp /usr/src/packages/RPMS/i386/lua-5.1.3-1.i386.rpm ..
rpm -ivh ../lua-5.1.3-1.i386.rpm

Чтобы обеспечить динамическую загрузку библиотеки, соберите shared‑библиотеку liblua и создайте символьную ссылку:

cd /usr/local/lib
gcc -shared -o liblua.5.1.3.so /usr/local/lib/liblua.a
ln -s liblua.5.1.3.so liblua.so

Важно: путь и имена файлов должны соответствовать реальной установке. Если Lua установился в другое место, скорректируйте пути.

Получение и установка mod_security

Скачать архив: http://www.modsecurity.org/download/direct.html

Документация: http://www.modsecurity.org/documentation/index.html

Пример сборки:

cd modsecurity-apache_2.5.2
cd apache2
./configure
make
checkinstall

Пример информации checkinstall при сборке:

…
1 - Summary: [ mod_security application level firewall ]
2 - Name: [ apache2-mod_security ]
3 - Version: [ 2.5.2 ]
4 - Release: [ 1 ]
5 - License: [ GPL ]
6 - Group: [ Productivity/Networking/Web/Servers ]
7 - Architecture: [ i386 ]
8 - Source location: [ http://www.modsecurity.org/download/ ]
9 - Alternate source location: [ ]
10 - Requires: [ apache2 libxml2 ]
11 - Provides: [ mod_security ]

Установите полученный RPM:

cp /usr/src/packages/RPMS/i386/apache2-mod_security-2.5.2-1.i386.rpm ../../
rpm -ivh ../../apache2-mod_security-2.5.2-1.i386.rpm

После установки модуль mod_security должен присутствовать как /usr/lib/apache2/mod_security2.so.

Конфигурация Apache2 для mod_security

Создайте или отредактируйте файл конфигурации, например /etc/apache2/conf.d/mod_security.conf:

# /etc/apache2/conf.d/mod_security.conf
LoadFile /usr/lib/libxml2.so
LoadFile /usr/local/lib/liblua.so
LoadModule security2_module /usr/lib/apache2/mod_security2.so
Include modsecurity/*.conf
LoadModule unique_id_module /usr/lib/apache2/mod_unique_id.so

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

Извлечение и настройка Core Rules (CRS)

Скачайте Core Rules: http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.0.tar.gz

Пример распаковки и размещения правил:

cd /etc/apache2
mkdir modsecurity
cd modsecurity
tar -zxvf ../modsecurity-core-rules_2.5-1.6.0.tar.gz

Откройте файл modsecurity_crs_10_config.conf и настройте пути к логам и прочим файлам:

vi modsecurity_crs_10_config.conf SecAuditLog=… # путь к журналу аудита SecDebugLog=… # путь к отладочному журналу

Важно определить корректные права на файлы логов, чтобы Apache мог их писать.

Перезапуск Apache и тестирование

Перезапустите сервис Apache:

rcapache restart

Для теста можно создать небезопасный PHP‑скрипт, имитирующий уязвимость LFI (Local File Inclusion):

Затем в браузере или curl выполните запрос:

http://ip.of.your.server.de/index.php?file=/etc/passwd

Ожидаемое поведение: модуль блокирует попытку доступа и возвращает ошибку (в примере — 501). SecAuditLog должен содержать запись о блокировке, например:

[…]
GET /index.php?file=/etc/passwd HTTP/1.1 …
[…]
Message: Access denied with code 501 (phase 2). Pattern match “(?:\b(?:.(?:ht(?:access|passwd|group
)|www_?acl)|global.asa|httpd.conf|boot.ini)\b|\/etc\/)” at ARGS:file. [file “/etc/apache2/modsecu
rity/modsecurity_crs_40_generic_attacks.conf”] [line “114”] [id “950005”] [msg “Remote File Access A
ttempt”] [data “/etc/“] [severity “CRITICAL”] [tag “WEB_ATTACK/FILE_INJECTION”]

Это показывает, что правила CRS отработали и предотвратили чтение системных файлов.

Частые оговорки и исправления

При доступе по IP‑адресу CRS может блокировать Host‑header: откройте modsecurity_crs_21_protocol_anomalies.conf и найдите правило “Check that the host header is not an IP address” — при необходимости откорректируйте или деактивируйте.
Если библиотека liblua не загружается, проверьте ldconfig и пути в /etc/ld.so.conf.d: добавьте /usr/local/lib и выполните ldconfig.
Ошибки компиляции обычно вызваны отсутствием -devel пакетов; установите libxml2-devel, pcre-devel и apache2-devel.

Критерии приёмки

Модуль мод_security загружен: в выводе apachectl -M присутствует security2_module.
Правила CRS находятся в /etc/apache2/modsecurity и подключены через Include.
Тестовый LFI‑запрос блокируется и в SecAuditLog есть запись с id правила.
Apache перезапускается без ошибок в журнале ошибок (/var/log/apache2/error_log).

Чек‑лист по ролям

Администратор:

Установить apache2 и dev‑пакеты
Скомпилировать liblua и mod_security
Упаковать RPM через checkinstall
Настроить права на лог‑файлы

Инженер безопасности:

Проверить правила CRS и отфильтровать ложные срабатывания
Настроить SecRuleRemoveById для ложных срабатываний
Настроить уровни логирования и ротацию логов

Разработчик приложения:

Тестировать приложение с включённым модулем
При появлении блокировок присылать примеры запросов и логи

Мини‑методология внедрения (шаги)

Подготовка окружения: резервная копия конфигураций Apache.
Установка зависимостей и инструментов сборки.
Сборка и упаковка liblua и mod_security в RPM.
Настройка конфигурации mod_security и CRS.
Деплой в тестовую среду и функциональные тесты (LFI, XSS, SQLi).
Мониторинг логов, настройка правил и перевод в продакшн.

Когда этот подход не подходит и альтернативы

Если вы не можете собирать пакеты на SLES10, используйте готовые бинарные RPM от доверенного поставщика или репозиторий.
Для более лёгкой интеграции на современных дистрибутивах рассмотрите WAF на уровне обратного прокси (например, Nginx + ModSecurity или облачные WAF‑решения).
Если требуется минимальная нагрузка и вы контролируете приложение, лучше исправлять уязвимости в коде, а не полагаться только на WAF.

Уровни зрелости внедрения мод_security

Уровень 0 — нет модульной защиты.
Уровень 1 — базовая установка mod_security с дефолтными CRS.
Уровень 2 — настройка правил и исключений, мониторинг логов.
Уровень 3 — кастомные правила, интеграция с SIEM, автоматизация обновлений CRS.

Риск‑матрица и смягчения

Ложные срабатывания (False Positives): внедрить процедуру эскалации, регистрировать случаи и добавлять исключения (SecRuleRemoveById).
Пропуск атак (False Negatives): периодически обновлять CRS и дополнять правила под приложение.
Производительность: тестировать нагрузку и при необходимости включать режим “DetectionOnly” для постепенной отладки.

Полезные команды и проверка

Проверить загруженные модули Apache:

apachectl -M

Проверить логи ошибок:

tail -n 200 /var/log/apache2/error_log

Поиск записей mod_security в аудите:

grep -R "modsecurity" /var/log | less

Примеры файлов конфигурации

Конфигурация для подключения в Apache уже показана выше. Пример включения правил (в mod_security.conf или отдельном include):

Include /etc/apache2/modsecurity/modsecurity_crs_10_config.conf
Include /etc/apache2/modsecurity/modsecurity_crs_20_protocol_violations.conf
Include /etc/apache2/modsecurity/modsecurity_crs_40_generic_attacks.conf

Сценарии тестирования и приёмки (коротко)

Тест LFI: попытка чтения /etc/passwd должна блокироваться.
Тест XSS: ввод в форме — правило должно обнаружить попытку.
Нагрузочный тест: прогнать базовую нагрузку и убедиться, что задержки в пределах допустимых.

Критерии приёмки перечислены в соответствующем разделе.

Полезные ссылки

mod_security: http://www.modsecurity.org/
LUA: http://www.lua.org/
Checkinstall: http://www.asic-linux.com.mx/~izto/checkinstall/
Автор руководства: http://www.elconas.de

Краткое резюме

Установка mod_security на SLES10 требует сборки нескольких компонентов: liblua, самого модуля и упаковки через checkinstall для удобного управления RPM. После установки — подключите CRS, протестируйте на типичных атаках (LFI, XSS), отладьте ложные срабатывания и настройте мониторинг. Такой подход повышает безопасность приложений, но не заменяет устранение уязвимостей в коде.

Важно: регулярно обновляйте CRS и следите за логами SecAuditLog.

Как установить mod_security/mod_security2 на SuSE Linux Enterprise Server 10 (SLES10)