-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nginx "core dumped" #287
Comments
Hello @tacerus , Are you using lmdb? If so, there is a known crash scenario if the file location is one that the process does not have sufficient permissions to write to. See owasp-modsecurity/ModSecurity#2755. If that sounds like your situation, likely the simplest resolution is to use the nginx configuration item 'working_directory' (owasp-modsecurity/ModSecurity#2755 (comment)). If that is not your issue, then ... The message about 'HTTP/2 stream 1' might be an indication that HTTP/2 is a factor in causing the problem. If so, you could try experimentally allowing only HTTP/1.1. On the other hand the HTTP/2 could be a merely consequence of the crash. Are you able to supply a stack trace from the core dump? |
Hi @martinhsv, thank you for getting back! I am not using lmdb, however I have compiled ModSecurity with lmdb support. As for HTTP/2, I actually thought of that as well and did try to connect with curl's I now recompiled ModSecurity as well as the dynamic module without lmdb support - and I can no longer reproduce the worker crashes! I assume we can conclude it to #2755, which you linked, then? But if you'd like, I can try it again with lmdb and with nginx's Whilst my core dump issue is presumably solved now, I still have the issue with it not printing any log output:
Should I move this to a separate issue? I assume it's not related. |
Hello @tacerus, Given your use of italics ('using'), I'm assuming you mean that you don't care about using the functionality provided by lmdb. But of course if ModSecurity has been built with '--with-lmdb' and one or more relevant rules are triggered (which, as I recall, would likely be the case based on the rule set that you cited), then ModSecurity will use lmdb. (That's probably understood by you but I thought I'd be explicit for anyone else reading this item.) Note that for audit log, you have specified I have only ever seen failures to write to the debug log when there are permissions issues. If you want those particular locations, that's something you can check. (Incidentally, there is no need to pre-allocate the files yourself; ModSecurity will create them at the specified locations on startup if it has permissions to do so.) I personally always use:
and
|
Actually, I did not realize some of my rules were utilizing lmdb! and I missed that |
Hello,
This happens upon loading the sample rules suggested in the CRS documentation.
Nginx is configured like this:
The includes file is filled according to to https://coreruleset.org/docs/deployment/install/#includes-for-nginx, except for the BEFORE/AFTER rules.
Upon trying to connect to the webserver as configured above the connection is aborted:
And nginx's error.log reports the worker to have crashed:
ModSecurity's SecDebugLog stays empty, even with SecDebugLogLevel 9. I tested it with
SecRuleEngine On
as well asSecRuleEngine DetectionOnly
.The site is being served properly if I leave only the
modsecurity.conf
in the includes file.Most setup options have been left at their defaults, the most I changed were the log and data storage paths.
Versions:
CRS: 3.3.2
ModSecurity: 3.0.7
ModSecurity-nginx: 1.0.3
Nginx: 1.23.1
OS: openSUSE Leap 15.4
nginx -V
The module was loaded dynamically.
The text was updated successfully, but these errors were encountered: