Geo Lookup: Failed to lock proc mutex

[quenenni]

Server: Debian Wheezy
PHP Version 5.4.45-0+deb7u3
Apache-npm-itk v2.2.22
libapache2-mod-security2: v2.8.0-2~bpo70+1
modsec rules: last from git repo

---

I know this is an old problem with several tickets still open (#712 / #426), but I prefer to write a new ticket in case i'm wrong and it's not the same.

I also have plenty of "ModSecurity: Geo Lookup: Failed to lock proc mutex: Identifier removed" in my log files.

What I noticed is that these errors don't appear for all the files accessed.
Mainly, these errors occurred for static files but not for php (and maybe others) files.

It means that the GEO Lookup system works and the problem is not about rights on some log files or *.dir and *.pag files in SecTmpDir and SecDataDir.
(I put all these files with the rights 0666)

I made a test.php file with:

test
<img src="wp-content/themes/expound/screenshot.png">

What I noticed is that the call to test.php doesn't create the GEO Lookup errors (it works perfectly) and the call to screenshot.png generate 2 errors and then GEO Lookup works on a third attempt.

I put SecDebugLogLevel 9 and.. omg.. so verbose this one :) .. I attached the relevant part to this ticket (I you want the whole log, I can send it to you).

To test my theory, I created a custom rule to do a Geolookup only when not a static file is called and since then, I only have few errors from time to time.

SecRule REQUEST_FILENAME "\.(ico|png|jpg|jpeg|gif|tiff|ods|fods|odt|fodt|odp|fodp|odg|doc|docx|xls|xlsx|rtf|csv|ppt|pptx|pps|ppsx|pdf|txt|css|js|ogg|ogm|mp4|flac|ape|wav|mkv|mpg|mpeg|swf|flv|mov|avi|wma)$" "phase:1,id:2100,log,pass,skipAfter:END_MARKER_STATIC_FILES"

SecRule REMOTE_ADDR "@geoLookup"     "phase:1,id:2101,log,pass"

SecRule &GEO "@eq 0"    "phase:1,id:2102,deny,nolog,auditlog,msg:'Failed to lookup IP'"

SecMarker END_MARKER_STATIC_FILES

I hope this help you to find a solution.

In the meantime, I'll stay with my custom rule as to do a Geo Lookup only on few requests is not a bad idea I think.

modsec.log.zip

[zimmerle]

Hi @quenenni,

Thanks for the report. That shouldn't be a problem in libModSecurity. I am marking it to be closed once libModSecurity will be ready for production.

[quenenni]

@zimmerle : Are you talking about the new version of Modsec? It won't be a library like "libapache2-mod-security2" anymore?
What is your ETA for this libModSecurity?

Thanks

[zimmerle]

Hi @quenenni,

Exactly! Complete free of Apache. You can test it already:
https://github.com/SpiderLabs/ModSecurity/tree/libmodsecurity

and:
https://github.com/SpiderLabs/ModSecurity-nginx

You can read more about it here:
http://blog.zimmerle.org/2016/01/an-overview-of-upcoming-libmodsecurity.html

Tasks missing to have it 100% compatible with OWASP CRS:
https://github.com/SpiderLabs/ModSecurity/milestones/v3.0.0%20-%20OWASP%20CRS%20Compatible

[quenenni]

Excellent 👍

Some good reading for this evening.

[shawnholt]

PLEASE TELL CPANEL - they are blocking modsec and ruid2 or itk and going to create a bit security hole. They reference #712 . They sepcifically changed the release to make them incompatable There are hundreds of issues if you do a google and https://forums.cpanel.net/threads/modsecurity-mpm-itk-compatibility-inconsistent-documentation.507051/#post-2250391

I don't know if they are aware of the library but I hope SpiderLabs and CPANEL can work together to resolve.

[victorhora]

The global mutex is optional since 112ba45 (included in 2.9.2 release).

PR #1912 is up for evaluation address the compatibility issue with apache2-itk and mod_ruid2 modules.

And indeed, this shouldn't be a concern with libModSecurity. libModSecurity (aka v3) is already officially released: https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.2 (3.0.3 upcoming)

Thanks!