Установка mod_security 2.9.0 под apache24 на FreeBSD 10.x

28.12.2015 https://anteh.ru

04.01.2016 Усовершенствованный скрипт автоматической генерации sitemap для заданного списка хостов с учётом совместно работающего mod_security

Апач стоит
Установка mod_security
# cd /usr/ports/www/mod_security
...

Ставим git-lite без опций
# cd /usr/ports/devel/git-lite
...

Скачиваем правила OWASP ModSecurity Core Rule Set (CRS) в /usr/local/etc/modsecurity/crs директорию:

# cd /usr/local/etc/modsecurity
# git clone git://github.com/SpiderLabs/owasp-modsecurity-crs crs
Cloning into 'crs'...
remote: Counting objects: 1506, done.
remote: Compressing objects: 100% (56/56), done.
remote: Total 1506 (delta 26), reused 0 (delta 0), pack-reused 1449
Receiving objects: 100% (1506/1506), 11.46 MiB | 6.42 MiB/s, done.
Resolving deltas: 100% (951/951), done.
Checking connectivity... done.
#

Файл /usr/local/etc/modsecurity/crs/modsecurity_crs_10_setup.conf.example копируем в ту же папку с переименованием в modsecurity_crs_10_setup.conf

Удаляем git-lite
...
==> You should manually remove the "git_daemon" user.
удаляем "git_daemon" пользователя, удобно удалить через # bsdconfig -> Login/Group Management -> Delete Login

В конфигурации апача:

#Add ap24-mod_security config files
LoadModule security2_module libexec/apache24/mod_security2.so
#<IfModule security2_module>
# Include ModSecurity configuration
             Include etc/modsecurity/modsecurity.conf
# Include OWASP Core Rule Set (CRS) configuration and base rules
              Include etc/modsecurity/crs/modsecurity_crs_10_setup.conf
          Include etc/modsecurity/crs/base_rules/*.conf
# Add custom configuration and CRS exceptions here. Example:
# SecRuleRemoveById 960015</IfModule>

Проверяем, чтобы апач подключал unique_id_module, без него mod_security работать не будет:
LoadModule unique_id_module libexec/apache24/mod_unique_id.so

После перезапуска с подключённым mod_unique_id.so, апач может не запуститься. Если в error логе апача такое сообщение:

[Mon Dec 28 18:38:41.884948 2015] [unique_id:alert] [pid 581] (EAI 8)hostname nor servname provided, or not nown: AH01564: unable to find IPv4 address of "some.host.name"

2 варианта решения:

1. В /usr/local/etc/apache24/httpd.conf параметр some.host.name строки "ServerName some.host.name" меняем на реально зарегистрированное DNS имя. В текущем случае "ServerName anteh.ru:80". Далее # bsdconfig -> Networking Management -> Hostname/Domain и проверяем, чтобы было anteh.ru -это реальное DNS имя.

2. Или в /usr/local/etc/apache24/httpd.conf параметр some.host.name строки "ServerName some.host.name" меняем на реальный статический адрес "ServerName aa.bb.cc.dd:80" и bsdconfig -> Networking Management -> Hostname/Domain меняем на aa.bb.cc.dd. Т.е. теперь hostname сервера -это его внешний статический адрес.

После этого нужно открыть доступ к DNS серверу/серверам провайдера на 53 порт. Например, если на сервере используется блокирующий IPFW и нет DNS сервера, то ему можно задать такие правила:

fwadd="/sbin/ipfw -q add"
ext="re1"
ip_ext="aa.bb.cc.dd"
dns_1="d.n.s.1"
dns_2="d.n.s.2"
${fwadd} 10320 allow udp from ${ip_ext} to ${dns_1} 53 out xmit ${ext} keep-state
${fwadd} 10322 allow udp from ${ip_ext} to ${dns_2} 53 out xmit ${ext} keep-state

Правилами разрешено с любого порта сетевого интерфейса ${ext} с IP адресом ${ip_ext} отправлять udp пакеты на 53 порт DNS серверов ${dns_1} и ${dns_2} провайдера. Причём инициировать передачу может только сервер, если передача будет инициирована DNS серверами провайдера, то эти udp пакеты будут отброшены.

В /usr/local/etc/modsecurity/modsecurity.conf меняем "SecRuleEngine DetectionOnly" -только информирование на "SecRuleEngine On" -применение.

Перезапуск апача для запуска modsecurity # apachectl restart
В httpd-error логе апача должно быть что-то похожее на:

[Mon Dec 28 15:40:09.043830 2015] [:notice] [pid 57960] ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/) configured.
[Mon Dec 28 15:40:09.043852 2015] [:notice] [pid 57960] ModSecurity: APR compiled version="x.x.x"; loaded version="x.x.x"
[Mon Dec 28 15:40:09.043864 2015] [:notice] [pid 57960] ModSecurity: PCRE compiled version="y.yy "; loaded version="y.yy 2015-00-00"
[Mon Dec 28 15:40:09.043874 2015] [:notice] [pid 57960] ModSecurity: YAJL compiled version="z.z.z"
[Mon Dec 28 15:40:09.043892 2015] [:notice] [pid 57960] ModSecurity: LIBXML compiled version="a.a.a"
[Mon Dec 28 15:40:09.043933 2015] [:notice] [pid 57960] ModSecurity: StatusEngine call: "2.9.0,Apache,ea5ea...38"
[Mon Dec 28 15:40:09.591583 2015] [:notice] [pid 57960] ModSecurity: StatusEngine call successfully sent. For more information visit: http://status.modsecurity.org/

Ключевая фраза: "StatusEngine call successfully sent"

Загруженные модули апача можно посмотреть так:
# apachectl -t -D DUMP_MODULES

# httpd -M

# apachectl -M
...
security2_module (shared)
...

Теперь проверяем, что получилось:
Здесь логи modsecurity /var/log/modsec_audit.log
Опция "SecAuditEngine RelevantOnly" означает занесение в лог только отфильтрованных "нехороших" запросов. Можно временно установим опцию "SecAuditEngine On" тогда в лог будет попадать всё.

Проверяем работоспособность по наличию обращения на DNS провайдера при перезапуске апача, наличию строки "ModSecurity: StatusEngine call successfully sent. For more information visit: http://status.modsecurity.org/" в error логах апача после перезапуска. По наличию записей в /var/log/modsec_audit.log

Главный признак работоспособности mod_security -это сообщения в логе. Нужно убедится, что содержимое запрашиваемых страниц в буквальном виде не заносится в лог. Иначе нужно исправлять содержимое страниц. Например были ситуации, когда страница заносилась в лог и не отдавалась клиенту из-за наличия недопустимых символов и/или их сочетания, тэг pre и замена стандартных запрещённых символов не помогла. Искал проблемные блоки текста последовательно удаляя из со страницы и проверяя лог mod_security.

Теперь, когда что-то заработало, настраиваем mod_security.

Ошибки /var/log/modsec_audit.log

1.

Message: Access denied with code 403 (phase 4). Match of "rx (?:\\b(?:(?:i(?:nterplay|hdr|d3)|m(?:ovi|thd)|r(?:ar!|iff)|(?:ex|jf)if|f(?:lv|ws)|varg|cws)\\b|gif)|B(?:%pdf|\\.ra)\\b)" against "RESPONSE_BODY" required. [file"/usr/local/etc/modsecurity/crs/base_rules/modsecurity_crs_50_outbound.conf"] [line "39"] [id "970903"] [rev "2"] [msg "ASP/JSP source code leakage"] [data "Matched Data: <% found within RESPONSE_BODY: \x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x03\xed}ko\x1c\xc7\xb5\xe0g\xf1WT\xe8E,mfz\xde\x1c\xceD\x16BKr\xac\x8d^+J\xb6\x03\xc3 zf\x9adG3\xdd\x93\xee\x1e>\xf2\xc9\x92\xfc\x84\x13+\x0en\xb0F\xee\xf5\x8d\x9d\x5c`\xb1\xc0.@=\xc6\xa2H\x8a\x02\xf6\x17\x90\xffh\xcf9\xf5\xe8\xea\xd7\xcc\x90\x94Dy/i\x8b\x8f\x9e\xea\xaaSU\xa7\xce\xab\xce\xe3\xec\xcf.\x5c;\x7f\xf3\xb7\xd7/\xb2wo^\xb9|n\xea\xecr\xd0\xeb\xb2\xae\xe9,\xbd5\xed\x0d\xa6xcf\x9d\xfdY>\xcf.9~`:m\xebmk\xc9vX`\xf5\xf..."] [severity "ERROR"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP"] [tag "WASCTC/WASC-1
Message: Warning. Operator GE matched 4 at TX:outbound_anomaly_score. [file "/path/modsecurity_crs_60_correlation.conf"] [line "40"] [id "981205"] [msg "Outbound Anomaly Score Exceeded (score 4): ASP/JSP source code leakage"]

Пробное отключение сжатия проблему устраяло. Решение, в httpd-vhosts.conf или httpd.conf:

LoadModule security2_module libexec/apache24/mod_security2.so
Include path/modsecurity/some.conf
Include path/modsecurity/some2.conf
Include path/modsecurity/somedir/*.conf

SecDisableBackendCompression on

"SecDisableBackendCompression on" -эта опция в конфигурационном файле апача решает проблему

2. Execution error - PCRE limits exceeded (-8)

Message: Rule 8095b18d8 [id "970003"][file "somepath/modsecurity_crs_50_outbound.conf"][line "123"] - Execution error - PCRE limits exceeded (-8): (null).

PCRE -Perl Compatible Regular Expressions

Проверяем установленные модули perl:

# instmodsh
Available commands are:
   l            - List all installed modules
   m <module>   - Select a module
   q            - Quit the program
cmd? l
Installed modules are:
   ...
        ...
   ...
   Perl
   XML::Parser
cmd?

# /usr/local/bin/pcretest -C
PCRE version 8.37 2015-04-28
Compiled with
  8-bit support
  UTF-8 support
  16-bit support
  UTF-16 support
  32-bit support
  UTF-32 support
  Unicode properties support
  Just-in-time compiler support: x86 64bit (little endian + unaligned)
  Newline sequence is LF
  \R matches all Unicode newlines
  Internal link size = 2
  POSIX malloc threshold = 10
  Parentheses nest limit = 250
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack

Всё в порядке.

В файле /path/modsecurity/modsecurity.conf

Есть параметры

SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

Для решения проблемы рекомендуют выставить такие параметры:

SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000

150000 сто пятьдесят тысяч. Встречалась информация, что это может снизить производительность.

Проблема вроде решена, сообщений в логе modsecurity по поводу PCRE больше не наблюдается, для проверяемой страницы. Позже сообщения снова появились, но для станиц с очень большим количеством текста, чем ранее тестируемая страница сайта. Увеличил параметр ещё раз:

SecPcreMatchLimit 900000
SecPcreMatchLimitRecursion 900000

Страницы с большим количеством текста стали недоступны, в логе обнаружились записи о наличии недопустимых символов -что для текущего контента обычное дело. Т.е. при увеличении параметра, страницы стали обрабатываться и у них обнаружились проблемы, которые и заблокировали выдачу страницы. Было 2 статьи с большим количеством текста, содержащими недопустимые спец символы. Спец символы экранируем, статьи разбиваем, SecPcreMatchLimit и SecPcreMatchLimitRecursion уменьшаем до минимального, чтобы не появлялись записи в логе modsecurity.

Если в лог файле modsecurity появляется полное содержимое страницы, значит параметры SecPcreMatchLimit SecPcreMatchLimitRecursion нужно увеличить, если страница не отображается в браузере, то скорее всего проблема в наличии запрещённых символов или комбинации символов на странице.

В итоге для html страницы из 117000 символов SecPcreMatchLimit SecPcreMatchLimitRecursion были установлены в 800000 восемьсот тысяч.

modsecurity блокирует страницу с текстом:меняем на mysql _. Между mysql и нижним подчёркиванием вставляем пробел. Это знание тяжело далось.

3. operator eq matched 0 at request_headers

Правильное решение в конце

Здесь обсуждение на тему http://serverfault.com/questions/580651/mod-security-960015-blocks-google- and-other-good-bots

Согласно RFC 2616 заголовок accept должен быть во всех запросах к серверу. И в то же время это не является абсолютным требованием. Браузеры отправляют заголовок, многие боты не отправляют. Правило в modsecure на обязательность наличия заголовка нужно для борьбы со спамом. Получается, что "хороших" ботов modsecurity может блокировать. В логе modsecurity часто встречались записи Message: Access denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS. для:

user-agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)

User-Agent: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; YPC 3.0.2; .NET CLR 1.1.4322; yplus 4.4.02b)

Для Google бота такая же проблема и для ряда других ботов.

Наблюдалась такая картина: в Google резко упала позиция выдачи по отслеживаемому запросу c начала 3й на конец пятой страницы, затем в течении недели сайт плавно поднимался и почти добрался до 4й страницы, потом упал в начало 6й. В Yandex изменений вроде не было или не заметил. В Google webmaster tools на вкладке "Сведения о файле Sitemap" наблюдались предупреждения URL недоступны. Разное количество от 6 до 10, причём страницы через браузер были доступны. Не уточнял вопрос, но получается, что Google ботов несколько и какие-то из них не содержат нужного заголовка, поэтому в webtools выдаётся предупреждение не на все страницы сайта а только на некотрые, которые пытался проиндексировать агент с отсутствующим заготовком, который и блокировался modsecure. Что и навело на мысль о проблемах с modsecure. Но это всё предположения.

Решение проблемы в httpd-vhosts.conf, после загрузки mod_security2.so и соответствующих правил добавляем:

#Solve trouble with "operator eq matched 0 at request_headers"
SecRule REQUEST_HEADERS:User-Agent "Google|Mail|Yandex" "phase:1,id:'123567',t:none,pass,nolog,ctl:ruleRemoveById=960015"

Для Google Mail Yandex ботов отключаем правило 960015. Если от этих ботов приходят запросы без заголовка, то они не блокируются. Работоспособность решения проверена. Загрузка mod_security2.so с правилами может производиться и в другом конфигурационном файле апача.

Сейчас доступ к серверу разрешон Google Mail Yandex ботам с наличием и без наличия заголовка accept. Все другие боты без accept блокируются. В течении суток ошибки доступа к страницам сайта при просмотре через google webmaster tools исчезли.

09.03.2016 По опыту использования, правило 960015 нужно отключить совсем, в том же месте конфигурационного файла apache прописываем:

SecRuleRemoveById 960015

Базовая работоспособность modsecurity получена, приступаем к настройке