This is a complex situation to troubleshoot. From the first post the modsec_audit.log shows...
Code:
Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.0; CWAF_Apache.
This indicates that both OWASP CRS and Comodo Rules are enabled.
While these 2 rule sets have totally different id numbering the Comodo set is essentially the OWASP rules with more production ready configuration and specific rules added for known vulnerable files and exploits.
So when they share so much code in common when you run them simultaneously the do wasteful things like setting the same variables twice and running many near identical rules.
I would not run these two rule sets together.
To add to this complexity the image url posted by 007basaran of the OWASP Vendor .conf files shows that the OWASP CRS is cPanel's older version, not the newer OWASP3 now available in the Vendors section. The older version was in Traditional Blocking mode which caused a large amount of false positive blocks.
The same image (as John pointed out) has Protocol, XSS and SQLI .confs disabled. Rule 981138 is not in any of these 3 files it is in REQUEST-10-IP-REPUTATION.conf. So disabling those 3 files could not possibly have fixed this problem.
My recommendation would be for 007basaran to disable the OWASP ruleset and use just the Comodo rule set with all the .conf files enabled. That would have the added benefit of removing rule 981138
All that said, I don't think any of those things are the cause of this problem.
I suspect it has to do with the connection to dnsbl.httpbl.org
Firstly check that you have obtained a key from dnsbl.httpbl.org and have entered it into...
Security Center » ModSecurity Configuration » Project Honey Pot Http:BL API Key text field.
In rule 981138 modsecurity's rbl operator is used to build a url by concatenating the...
honeypotkey + the TX:REAL_IP + dnsbl.httpbl.org
and ends up with something like honeypotkey.2.1.9.127.dnsbl.httpbl.org which it uses to do a nslookup.
You can test it from the command line of your server with...
nslookup honeypotkey.2.1.9.127.dnsbl.httpbl.org
If the ip is in the blacklist what looks like an ip address is returned
127.3.5.1
The last digit indicates what kind of threat the ip poses.
0 = Search Engine
1 = Suspicious
2 = Harvester
4 = Comment Spammer
So if you have a honeypot key and have tested from the command line and are still not getting either
NXDOMAIN or an ip address
as the response then you may have to look at your server's resolvers.
dnsbl.httpbl.org rate limits requests from each ip.
The ip appearing to dnsbl.httpbl.org as making the lookup is one of your resolvers.
Often a google ip is used as the resolver because of their speed and reliability, but when all these requests hit dnsbl.httpbl.org then that resolvers ip gets rate limited.
There is a few things you can do to avoid this problem.
Use dns servers other than Google's as your Primary, Secondary and Tertiary resolvers.