это первый раз, когда я столкнулся с такой проблемой. У меня есть настройка Java-приложения за apache2, используя mod_ajp on 8009. Я заметил, что не могу получить IP-адрес клиента, поэтому создал еще один файл виртуального хоста и переключился на mod_jk. Затем я отключил виртуальный хост, используя mod_ajp. Так что мой mod_jk работал нормально, пока я не начал усиление безопасности с фанклуб. Я применил метод, показанный на notpad2.blogpost.com и я все еще был в порядке. Сегодня утром я видел логи в файле modsecu_audit.log:
Action: Intercepted (phase 1)
Stopwatch: 1394809780952048 3090 (- - -)
Stopwatch2: 1394809780952048 3090; combined=812, p1=492, p2=0, p3=0, p4=0, p5=253, sr=143, sw=67, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.6.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.5.
Server: Apache
WebApp-Info: "default" "C35A8A3AB916218E923E5A8E6A73595B" ""
--81b0e75f-Z--
В журнале ошибок virtualhost у меня есть ошибки ниже
[Thu Mar 13 11:18:43 2014] [error] [client xxx.xxx.xxx.xxx] client denied by server configuration:
[Thu Mar 13 11:18:44 2014] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 2). String match "HTTP/1.1" at REQUEST_PROTOCOL. [file "/etc/modsecurity/owasp-crs/activated_rules/modsecurity_crs_20_protocol_violations.conf"] [line "220"] [id "960020"] [rev "2.2.5"] [msg "Pragma Header requires Cache-Control Header for HTTP/1.1 requests."] [severity "NOTICE"] [tag "RULE_MATURITY/5"] [tag "RULE_ACCURACY/7"] [tag "https://www.owasp.org/index.php/ModSecurity_CRS_RuleID-960020"] [tag "PROTOCOL_VIOLATION/INVALID_HREQ"] [tag "http://www.bad-behavior.ioerror.us/documentation/how-it-works/"] [hostname "mysite.com"] [uri "/"] [unique_id "UyGUFAqzjt0AADfWBbEAAAAA"]
[Thu Mar 13 11:23:52 2014] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 0 at REQUEST_HEADERS. [file "/etc/modsecurity/owasp-crs/activated_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "47"] [id "960015"] [rev "2.2.5"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "mysite.com"] [uri "/"] [unique_id "UyGVSAqzjt0AADfWBbIAAAAH"]
В основном журнале ошибок apache у меня есть:
[Fri Mar 14 15:07:11 2014] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 1). Match of "streq %{SESSION.IP_HASH}" against "TX:ip_hash"
required. [file "/etc/modsecurity/owasp-crs/activated_rules/modsecurity_crs_16_session_hijacking.conf"] [line "35"] [id "981059"] [msg "Warning - Sticky SessionID Data
Changed - IP Address Mismatch."] [hostname "mysite.com"] [uri "/"] [unique_id "UyMbH8QokBEAAH5mFvgAAAAB"]
[Fri Mar 14 15:09:35 2014] [notice] SIGUSR1 received. Doing graceful restart
[Fri Mar 14 15:09:36 2014] [notice] Apache/2.2.22 (Ubuntu) mod_ssl/2.2.22 OpenSSL/1.0.1 mod_jk/1.2.32 configured -- resuming normal operations
[Fri Mar 14 15:09:40 2014] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 1). Match of "streq %{SESSION.IP_HASH}" against "TX:ip_hash"
required. [file "/etc/modsecurity/owasp-crs/activated_rules/modsecurity_crs_16_session_hijacking.conf"] [line "35"] [id "981059"] [msg "Warning - Sticky SessionID Data
Changed - IP Address Mismatch."] [hostname "mysite.com"] [uri "/"] [unique_id "UyMbtMQokBEAAH7dJ3sAAACB"
Я отключил modsecurity, но теперь он показывает страницу индекса по умолчанию, «это работает». Я даже повторно активировал известный рабочий виртуальный хост, используя mod_ajp и ни один из них, кажется, больше не работает.
Я понимаю, что страница заблокирована и т. Д., Но я не могу понять, почему обратный прокси перестал работать.
Вопрос 1 это известная проблема или неправильная конфигурация?
вопрос 2 как мне восстановить виртуальный хост? быстрое исправление - удаление modsecurity (хотя я не вижу корреляции).
Все предложения приветствуются. Спасибо
Безопасность MOD вступает в силу до того, как запрос фактически достигнет логики apache, следовательно, есть вероятность, что обратный прокси не будет работать. Столкнувшись с подобной ситуацией, я проанализировал, что показало сообщение об ошибке.
Итак, для первой ошибки вы можете проверить этот файл
activated_rules/modsecurity_crs_20_protocol_violations.conf"]
и Id
[id "960020"}
И проверьте, что на самом деле делает правило. Вы можете отредактировать это в соответствии с вашим запросом, не вызывая его блокировку. Немедленным исправлением было бы удаление этого правила (вы можете либо снять его, либо настроить так, чтобы оно было принято
Сообщите мне, если вам нужна помощь в понимании CRS