Nginx sends response without headers #238
Comments
|
@airween appreciate if you'll be able to check this one: defanator@51cbaf3 (I'm still trying to figure out the better way(s) of handling this.) |
|
Hi @defanator, so many thanks for quick work - looks like it works as we expect: $ curl -vvv 'http://localhost/modsec-full/ncl_items.shtml'
* Expire in 0 ms for 6 (transfer 0x55aac808bf50)
...
* Expire in 1 ms for 1 (transfer 0x55aac808bf50)
* Trying ::1...
* TCP_NODELAY set
* Expire in 149997 ms for 3 (transfer 0x55aac808bf50)
* Expire in 200 ms for 4 (transfer 0x55aac808bf50)
* connect to ::1 port 80 failed: Connection refused
* Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 149997 ms for 3 (transfer 0x55aac808bf50)
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /modsec-full/ncl_items.shtml HTTP/1.1
> Host: localhost
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Server: nginx/1.19.6
< Date: Mon, 25 Jan 2021 16:02:18 GMT
< Content-Type: text/html
< Content-Length: 153
< Connection: keep-alive
<
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.19.6</center>
</body>
</html>In the error.log I got: I'm using the temporary small rule set above (with 5 rules and 3 But I'm still wondering why did phase:3 rule was triggered when phase:1 rule intervened the transaction? (Phase:5 obliviously triggered) Thanks again! |
That's a great question. According to the https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#processing-phases diagram, phase 3 means "response headers", right? |
|
Exactly. But if one of the request header contains an attack, and the engine blocks the request (with The next question is: if the phase:3 rules activated, then it means the engine got the response from the server/upstream? But the server/upstream sends back the response headers only when it got the request body too (eg. if the request is So the request header contains an attack what we wants to block, it no matters, the Nginx sends the request body (without inspect), server got it? (I don't know is that true or not, just asking). Here is the relevant part of Apache's error.log: Here I'm using CRS with blocking_early feature, so the 1st line just a warning, where engine sets the anomaly score. The second line shows that the engine blocked the transaction - and there isn't more phase, only the logging (phase:5). |
Meanwhile I've checked this functionality: if any phase:1 rule intervened transaction, then the request body won't send to server. |
|
Hi @defanator, looks like nothing changed in behavior since the previous version: error.log: The second The response is (still) correct now. |
|
I think I've used that commit: Then I recompiled the Nginx with This gives me the result above. |
|
@airween that's weird because that commit effectively removes 2nd error log entry for phase 3 - here's what I'm getting here locally with the test case introduced: |
can you show me your config? Just because I have How can I debug that I'm using the right connector? Eg. increased log level shows the git version...? Output of |
|
Ah, sorry - I was confused and compiled the module but used a previously installed code. I can confirm, after the last commit the connector works as we expect: with this Sorry for my mistake. |
|
@airween no problem, thanks for confirming. I've added a test case for this to the modsecurity.t, so the config can be found here: (You also may set the TEST_NGINX_LEAVE=yes env. variable to keep temporary |
|
Thanks, I can check that later. Is there any timing for merge (and/or make new release)? |
|
@airween this change may have an effect on a couple of other opened issues/PRs (#90, #204) but given the state of those I think I'll merge this one and proceed with further investigation on possible For the release - I'd ask @zimmerle on their input here. I'm not the right guy here for making releases. :) |
|
Ah, okay - thanks! :) |
As we discussed in ModSecurity issue #2465, the nginx connector tries to do all the processing as early as possible.
The unexpected behavior is the server doesn't send the response headers to client. It can reproduced with this minimal rule set:
The request can be anything, the set contains 3 rules which will triggered always in phase 1, 3 and 5.
The disrputive action of these rules are
denywhich means the rule wants to terminate the process, but Nginx continues.The text was updated successfully, but these errors were encountered: