0

this is the first time I have run into issue like this one. I have a java application setting behind a apache2 using mod_ajp on 8009. I have noticed that I could not get the client's IP so I have created another virtual host file and switched to mod_jk. I have then disabled the virtual host using mod_ajp. So my mod_jk has been working fine until I started the security hardening from thefanclub. I have applied the method shown on the notpad2.blogpost.com and I was still fine. This morning I have seen logs in the modsecu_audit.log file :

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--

On the virtualhost error.log I have the errors below

[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"]

On the main apache error.log I have:

 [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"

I have disabled modsecurity but it now shows the default index page "it works". I have even reactivated the known working virtualhost using mod_ajp and none of them seems to be working anymore.

I understand the page is blocked etc but I can't figure out why the reverse proxy would stop working.

Question 1 is this a known issue or misconfiguration?
Question 2 how do I get the virtual host back up? quick fix would be removing modsecurity(even though I do not see the correlation).

All suggestions are welcomed . Thanks

1 Answer 1

1

MOD security comes into action before the request actually reaches the apache logic, Hence there is a chance that the reverse proxy will not work. Upon facing a similar situation what i did was to analyse what the error message showed

So for the first error what you can do is check this file

activated_rules/modsecurity_crs_20_protocol_violations.conf"] 

and Id

[id "960020"}

And check what the rule is actually doing, You can edit that to match your request hence not causing it to be blocked. An immediate fix would be to remove this rule ( You can either take it off or make the configuration so that it is accepted

Let me know if you need help understanding the CRS

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .