NGINX and SecRequestBodyAccess On option, don't pass POST request to Upstream Server #664

zotgene · 2014-02-20T11:58:07Z

On Debian 7.3 64bit, same issue whit nginx 1.4.4 and 1.5.1, ModSecurity is 2.7.7 . Have try whitout rules, whitout SSL and have recompiling many times Nginx and ModSecurity whit different configure option, same issue : if on modsecurity.conf SecRequestBodyAccess is set on On, nothing arrive on upstream Server ( Wireshark checked ) .

#nginx.conf
upstream sharepoint  {
      server 192.168.1.100:80; #Sharepoint
}
server {
        listen 192.168.2.20:80;
        server_name pippo.pluto.it;
          location /      {
                        proxy_pass              http://sharepoint; 
                        proxy_redirect          off;
                        proxy_buffering         off;
                        proxy_set_header        Host                pippo.pluto.it;
                        proxy_set_header        X-Real-IP           $remote_addr;
                        proxy_set_header        X-Forwarded-For     $proxy_add_x_forwarded_for;
                        ModSecurityEnabled      on;
                        ModSecurityConfig       modsecurity.conf;
                        }
}

#modsecurity.conf
SecRuleEngine On
#
SecRequestBodyAccess On
#
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
     "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
#
SecRequestBodyLimit 13107200
#
SecRequestBodyNoFilesLimit 131072
#
SecRequestBodyInMemoryLimit 131072
#
SecRequestBodyLimitAction Reject
#
SecRule REQBODY_ERROR "!@eq 0" \
"id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
#
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200002',phase:2,t:none,log,deny,status:44, \
msg:'Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
#
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
#
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000
#
SecRule TX:/^MSC_/ "!@streq 0" \
        "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
#
SecResponseBodyAccess Off
#
SecResponseBodyMimeType text/plain text/html text/xml
SecResponseBodyLimit 524288
#
SecResponseBodyLimitAction ProcessPartial
#
SecTmpDir /tmp/
#
SecDataDir /tmp/
#
SecDebugLog /var/log/mod_security/debug.log
SecDebugLogLevel 9
#
SecAuditEngine On
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Concurrent
SecAuditLog /var/log/mod_security/audit.log
#
SecArgumentSeparator &
#
SecCookieFormat 0
#
SecUnicodeMapFile unicode.mapping 20127

#Modsecurity log
--398c3027-A--
[20/Feb/2014:12:11:56 +0100] AcAcxcAcAcAcAcYcAcACAcAc 11.22.33.44 54093 127.0.0.1 80
--398c3027-B--
POST /_layouts/login.aspx?ReturnUrl=%2f HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*
Referer: http://pippo.pluto.it/_layouts/login.aspx?ReturnUrl=%2f
Accept-Language: it
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: pippo.pluto.it
Content-Length: 569
Connection: Keep-Alive
Cache-Control: no-cache

--398c3027-C--
__LASTFOCUS=&__VIEWSTATE=%2FwEPDwUKMTc0NDQ2ODg4OQ9kFgJmD2QWAmYPZBYCAgMPZBYCAjUPZBYCAgEPZBYCZg9kFgICDQ8QDxYCHgdDaGVja2VkaGRkZGQYAQUeX19Db250cm9sc1JlcXVpcmVQb3N0QmFja0tleV9fFgEFJmN0bDAwJFBsYWNlSG9sZGVyTWFpbiRsb2dpbiRSZW1lbWJlck1l1qeKl1MHLq6QY7t46OHWkizdEl8%3D&__EVENTTARGET=&__EVENTARGUMENT=&__EVENTVALIDATION=%2FwEWBQKh1oXMDwLE96mtBQLLtsPBAgLkkP7MCgK%2FlZyyB7GYj%2B2NXtzlE%2BKZXCcgMOT2hSGC&ctl00%24PlaceHolderMain%24login%24UserName=admin&ctl00%24PlaceHolderMain%24login%24password=xxxxxxxx&ctl00%24PlaceHolderMain%24login%24login=Accesso&__spDummyText1=&__spDummyText2=
--398c3027-F--
HTTP/1.1 500 Internal Server Error

--398c3027-H--
Apache-Handler: IIS
Stopwatch: 1392894716000050 257181 (- - -)
Stopwatch2: 1392894716000050 257181; combined=73343, p1=1583, p2=70903, p3=0, p4=0, p5=701, sr=88, sw=156, l=0, gc=0
Producer: ModSecurity for nginx (STABLE)/2.7.7 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: ModSecurity Standalone
Engine-Mode: "ENABLED"

--398c3027-Z--

nginx debug log : http://bpaste.net/show/EZwvs4TsjkA64abviKMW/

The text was updated successfully, but these errors were encountered:

zotgene · 2014-02-20T15:45:57Z

same whit modsecurity 2.7.5

zotgene · 2014-02-24T20:13:45Z

From Modsecurity Serial Log (debug 9) i can see this :

[9] Input filter: Bucket type NGINX contains 569 bytes.
[9] Input filter: Bucket type EOS contains 0 bytes.
[4] Hook insert_filter: Adding input forwarding filter (r 7fa75946c0a0).
[4] Hook insert_filter: Adding output filter (r 7fa75946c0a0).
[4] Input filter: Forwarding input: mode=0, block=0, nbytes=-1 (f 7fa75946d2b0, r 7fa75946c0a0).
[4] Input filter: Forwarded 569 bytes.
[4] Input filter: Sent EOS.
[4] Input filter: Input forwarding complete.

It's normal that modsecurity forward back 569 bytes on " EOS container data type " ?
I need a EOS Bucket whit NGINX ?

zimmerle · 2014-03-05T15:03:39Z

Hi @zotgene thanks for the detailed report.

It seems to me that this is a duplicate of #142 and also #630. Can i mark this as duplicate?

zotgene · 2014-03-07T07:51:50Z

OK.
I think the problem is related whit APR library that the system use to compile/load.
I have now a Debian machine that work whit this installation steps

apt-get update
apt-get upgrade
apt-get install build-essential automake git libtool liblua5.1-0-dev apache2-threaded-dev libxml2-dev libcurl4-openssl-dev
git clone https://github.com/SpiderLabs/ModSecurity.git mod_security
cd mod_security
./autogen.sh
./configure --enable-standalone-module
make
cd ..
wget http://nginx.org/download/nginx-1.4.5.tar.gz
tar -xvf nginx-1.4.5.tar.gz
cd nginx-1.4.5
./configure --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/access.log --user=www-data --group=www-data --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --without-http_fastcgi_module --without-http_uwsgi_module --without-http_scgi_module --without-http_memcached_module --with-http_ssl_module --with-http_spdy_module --with-http_stub_status_module --with-http_gzip_static_module --add-module=/root/mod_security/nginx/modsecurity
make
make install
cd ..
cp nginx.script  /etc/init.d/nginx
chmod 755 /etc/init.d/nginx
update-rc.d nginx defaults

there nginx.script http://bpaste.net/show/185689/
For me is important to use a fresh installation whitout anything else than the packages writen above.
It is also important to use a default configuration files for the first time and only after change it

infinitnet · 2014-04-10T13:57:58Z

I'm having the same issue - mod_sec/NGINX doesn't properly forward validated POST requests to the upstream server, if SecRequestBodyAccess is enabled. I followed your suggestions and used your init script and compiled everything on a fresh machine, but still the same issue (500 error with POST requests when SecRequestBodyAccess is On). There are many bug reports regarding the very same issue, but still no solution. Any ideas?

falsandtru · 2014-05-06T07:12:34Z

When I enable SPDY in Nginx, problems of Wordpress login fails with 503 has occurred. I think it's the same problem that is addressed here probably. It works fine if I disable SecRequestBodyAccess or SPDY. Error log contains the following is recorded in the front-end (excerpt). No errors are recorded in the back-end.

[error] 14740 # 0: * 49 recv () failed (104: Connection reset by peer) while reading response header from upstream

CentOS 6.5 64bit
Nginx 1.6
ModSecurity 2.8.0
Wordpress 3.9

zimmerle · 2014-05-06T11:59:33Z

Hi @falsandtru, @infinitnet and @zotgene, there is a development branch of the nginx version where this issue should be fixed, can you guys test it?

it is available at:
https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring

zimmerle · 2014-05-26T13:59:43Z

Hi demofly, thanks for the input.

Just to confirm, what you are saying is that in this new branch (https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring), when you compile with "--disable-apache2-module" it stops to give you 500, but when you compiled it again without this option it starts to present problems again?

In your first attempt, do you had a chance to perform it in a clean directory? Your it was the same directory that you already had performed a build before? If so, can you test in a clean directory?

Thanks,
F.

zotgene · 2014-05-26T14:02:32Z

So many people are waiting for your reply demofly :) Inviata da dispositivo mobile. Da: Felipe ZimmerleInviato: lunedì 26 maggio 2014 15:59A: SpiderLabs/ModSecurityRispondi a: SpiderLabs/ModSecurityCc: zotgeneOggetto: Re: [ModSecurity] NGINX and SecRequestBodyAccess On option, don't pass POST request to Upstream Server (#664)Hi demofly, thanks for the input.

Just to confirm, what you are saying is that in this new branch (https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring), when you compile with "--disable-apache2-module" it stops to give you 500, but when you compiled it again without this option it starts to present problems again?

In your first attempt, do you had a chance to perform it in a clean directory? Your it was the same directory that you already had performed a build before? If so, can you test in a clean directory?

Thanks,
F.

—Reply to this email directly or view it on GitHub.

zimmerle · 2014-05-26T14:04:16Z

@zotgene: did you had a chance to give a test in this test branch ?

demofly · 2014-05-26T14:31:51Z

Sorry guys, It is not confirmed.

zimmerle · 2014-05-26T16:12:04Z

@demofly This specific issue, is fixed at branch nginx_refactoring ( https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring )

Please test and report your findings.

demofly · 2014-05-30T08:52:47Z

@zimmerle , I've built nginx 1.4.6 with the branch you have provided with no effect. It works in the same manner as the master branch:

==> /var/log/nginx/my.site.com-error.log <==
2014/05/30 12:48:45 [alert] 20778#0: *65 no upstream configuration, client: 128.66.1.1, server: my.site.com, request: "POST /api/v1/site_users/sign_in HTTP/1.1", host: "my.site.com"

==> /var/log/nginx/my.site.com-access.log <==
128.66.1.1 - - [30/May/2014:12:48:45 +0400] "POST /api/v1/site_users/sign_in HTTP/1.1" 500 186 "-" "Application/1 (Android)"

P.S. I should note the issue triggers for Android clients only (the same with the code from the master branch).

yicol · 2014-06-25T02:35:26Z

I've test nginx_refactoring branch, this issue seems be fixed, thank you Felipe Zimmerle.

infinitnet · 2014-07-03T14:40:23Z

~~@zimmerle I tested it as well now with the nginx_refactoring branch and it works without issues. Finally! Thank you a lot for your great work. I guess you can close this bug and #582 as well.~~

I didn't test it properly, I only tested GET requests. POST requests still result in "no upstream configuration" errors.

elialum · 2014-07-16T09:32:14Z

Still same issue with modesc 2.8, nginx 1.6
reported on - #751

infinitnet · 2014-07-16T09:40:46Z

@elialum check out #582 - kyprizel pushed a patch that you can find there and according to another user that fixes the problem. I'm just waiting for the main devs to push it to the nginx_refactoring branch to test it from there.

PS: Looks like @kyprizel 's patch doesn't work for me, still the same errors. I updated #582 regarding this.

ekreiser · 2014-12-30T18:10:57Z

Is there intent to address this issue? If so, any idea on ETA?

jowrjowr · 2015-01-06T08:22:46Z

It would be fantastic if this issue was resolved in mainstream. I just setup nginx with mod_security and while I'm loving how well it works (after a bit of tuning with the OWASP rules), it would be nice if I could have both the ability to do POST requests and the ability to have modsec to work on them.

wangxianwei · 2015-01-16T06:56:10Z

Hi @zimmerle @csanders-git, the issue Deny all the POST request #813 have been closed ,but I have installed the modsecurity-2.9.0-RC1 in the Nginx server, the issue is still appearing, after i set the SecRequestBodyAccess to Off, the problem not appear.

wangxianwei · 2015-01-20T08:56:50Z

Hi @zimmerle,
I find the issue is very insteresting! if I use the Domina name to vist the website ,all the post request been stoped by the modsecurity. but when I use the IP address to visit the website,the post request can pass. when use the HTTPS protocal, use the domina name to visit the website, the post request can pass.

zimmerle · 2015-01-20T12:50:44Z

Hi @wangxianwei for those nginx modifications please use the branch nginx_refactoring, available here:

https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring

The modification of the branch nginx_refactoring will be merge into mainline and released once we mitigate all the issues listed here.

wangxianwei · 2015-01-20T13:54:10Z

Hi @zimmerle, I have download the version from the branch nginx_refactoring, but i dont know how to compile it, because there is no configure file . can you please give me the complete installation package.

zimmerle · 2015-01-20T18:15:09Z

Hi @wangxianwei, that is a development version. The configure is generated after the execution of the ./autogen.sh

wangxianwei · 2015-01-21T02:03:31Z

Hi @zimmerle,

I have installed the version from the branch nginx_refactoring,but the issue is not resolved. please see the folliowing information.

wwwlogs
192.168.1.250 - - [21/Jan/2015:09:39:01 +0800] "POST /common/memberLogin.jsp HTTP/1.1" 500 186 "http://www.352.com/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0" -0.034

Error Nginx
2015/01/21 09:39:01 [alert] 11601#0: *354 no upstream configuration, client: 192.168.1.250, server: www.352.com, request: "POST /common/memberLogin.jsp HTTP/1.1", host: "www.352.com", referrer: "http://www.352.com/"

Data
--1ff89643-A--
[21/Jan/2015:09:39:01 +0800] AcAcAcAQqcAcA8AcAcAcAcAc 192.168.1.250 59224 127.0.0.1 80
--1ff89643-B--
POST /common/memberLogin.jsp HTTP/1.1
Host: www.352.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: application/json, text/javascript, /; q=0.01
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://www.352.com/
Content-Length: 18
Cookie:
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

--1ff89643-C--
date=1421804526217
--1ff89643-F--
HTTP/1.1
Content-Type: text/html
Content-Length: 186
Connection: close

--1ff89643-E--

^M <title>500 Internal Server Error</title>^M ^M

500 Internal Server Error

^M

nginx^M ^M ^M

--1ff89643-H--
Apache-Handler: IIS
Stopwatch: 1421804341000041 75947 (- - -)
Stopwatch2: 1421804341000041 75947; combined=329, p1=136, p2=179, p3=0, p4=0, p5=13, sr=0, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for nginx (STABLE)/2.9.0-RC2 (http://www.modsecurity.org/).
Server: ModSecurity Standalone
Engine-Mode: "ENABLED"

--1ff89643-K--

--1ff89643-Z--

the error log of the modsecurity:
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Initialising transaction (txid AwOcAcAcAcEcADAcvYAV6cAL).
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Transaction context created (dcfg 155c208).
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Starting phase REQUEST_HEADERS.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Recipe: Invoking rule 149d168; [file "/app/soft/nginx/conf/modsecurity.conf"] [line "29"] [id "200000"].
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Transformation completed in 4 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Executing operator "rx" with param "text/xml" against REQUEST_HEADERS:Content-Type.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Operator completed in 5 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Rule returned 0.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Recipe: Invoking rule 149ed58; [file "/app/soft/nginx/conf/modsecurity.conf"] [line "36"] [id "200001"].
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Transformation completed in 2 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Executing operator "rx" with param "application/json" against REQUEST_HEADERS:Content-Type.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Operator completed in 3 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Rule returned 0.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Second phase starting (dcfg 155c208).
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Input filter: Reading request body.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Input filter: Completed receiving request body (length 18).
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Starting phase REQUEST_BODY.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Recipe: Invoking rule 14aaae0; [file "/app/soft/nginx/conf/modsecurity.conf"] [line "66"] [id "200002"].
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Transformation completed in 2 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Executing operator "!eq" with param "0" against REQBODY_ERROR.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Operator completed in 5 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Rule returned 0.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Recipe: Invoking rule 14b2a90; [file "/app/soft/nginx/conf/modsecurity.conf"] [line "87"] [id "200003"].
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Transformation completed in 2 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Executing operator "!eq" with param "0" against MULTIPART_STRICT_ERROR.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Operator completed in 2 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Rule returned 0.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Recipe: Invoking rule 14d0958; [file "/app/soft/nginx/conf/modsecurity.conf"] [line "92"] [id "200004"].
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Transformation completed in 1 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Executing operator "!eq" with param "0" against MULTIPART_UNMATCHED_BOUNDARY.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Operator completed in 4 usec.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Rule returned 0.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Recipe: Invoking rule 14dc088; [file "/app/soft/nginx/conf/modsecurity.conf"] [line "106"] [id "200005"].
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Rule returned 0.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Hook insert_filter: Adding input forwarding filter (r 146ee50).
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Hook insert_filter: Adding output filter (r 146ee50).
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Input filter: Forwarding input: mode=0, block=0, nbytes=-1 (f 1470268, r 146ee50).
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Input filter: Forwarded 18 bytes.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Input filter: Sent EOS.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Input filter: Input forwarding complete.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Starting phase RESPONSE_HEADERS.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Output filter: Completed receiving response body (buffered full - 162 bytes).
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Starting phase RESPONSE_BODY.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Output filter: Output forwarding complete.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Initialising logging.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Starting phase LOGGING.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Recording persistent data took 0 microseconds.
[21/Jan/2015:15:05:28 +0800] [sz-test-rd01/sid#155bed0][rid#146ee50][/common/memberLogin.jsp][4] Audit log: Ignoring a non-relevant request.

wangxianwei · 2015-01-22T13:37:30Z

Hi @zimmerle,
we have found that when we used the 80 port the Post requests failure to pass, but they can success to pass if we used any other ports . by now we don't know how to troubleshoot the issue. any advice is appreciated.

Regards,

zotgene · 2015-01-22T15:11:03Z

I think that if we use a redirect the problem go away. Someone can try? Inviata da dispositivo mobile. Da: wangxianweiInviato: giovedì 22 gennaio 2015 14:39A: SpiderLabs/ModSecurityRispondi a: SpiderLabs/ModSecurityCc: zotgeneOggetto: Re: [ModSecurity] NGINX and SecRequestBodyAccess On option, don't pass POST request to Upstream Server (#664)Hi @zimmerle,
we have found that when we used the 80 port the Post requests failure to pass, but they can success to pass if we used any other ports . by now we don't know how to troubleshoot the issue. any advice is appreciated.

Regards,

—Reply to this email directly or view it on GitHub.

ton31337 · 2015-01-23T06:41:33Z

@zotgene, try this #826

On Thu, Jan 22, 2015 at 5:11 PM, zotgene [email protected] wrote:

I think that if we use a redirect the problem go away. Someone can try?
Inviata da dispositivo mobile. Da: wangxianweiInviato: giovedì 22 gennaio
2015 14:39A: SpiderLabs/ModSecurityRispondi a: SpiderLabs/ModSecurityCc:
zotgeneOggetto: Re: [ModSecurity] NGINX and SecRequestBodyAccess On option,
don't pass POST request to Upstream Server (#664)Hi @zimmerle,
we have found that when we used the 80 port the Post requests failure to
pass, but they can success to pass if we used any other ports . by now we
don't know how to troubleshoot the issue. any advice is appreciated.

Regards,

—Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#664 (comment)
.

Donatas

sasah · 2015-02-13T13:10:48Z

Hello, any news?

daniilyar-confyrm · 2016-01-27T13:59:32Z

Hello,
Fix in https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring branch works well for us.
Is there any chance for it to be released in nearest stable version?

zimmerle · 2016-01-27T14:07:15Z

Hi @daniilyar-confyrm,

The `nginx_refactoring' branch in fact contains a lot of fixes, however, some of those fixes may be a problem depending on your environment. We are studying this possibility to release it.

Most likely the next stable release for nginx will be the version 3.0 with the ModSecurity nginx connector: https://github.com/SpiderLabs/ModSecurity-nginx

We don't have a release date yet.

maxmonterumisi · 2016-11-21T09:21:42Z

Example of error:
2016/11/18 17:34:15 [alert] 13738#0: *18 no upstream configuration, client: 194.183.77.239, server: waf.xxxx.xxxx.cloud, request: "POST /2016F/Session/KeepSessionAliveJson HTTP/1.1", host: "waf.xxxx.xxxx.cloud", referrer: "http://waf.xxxx.xxxx.cloud/2016F/Booking?Albergo=900000&Lingua=0&IdRequest=1078489321"

My system:
root@waf:/usr/local/nginx/logs# uname -a
Linux waf 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

root@waf:/usr/local/nginx/logs# nginx -v
nginx version: nginx/1.10.2

Version of ModSecurity installed:
https://github.com/SpiderLabs/ModSecurity/tree/nginx_refactoring

cd /usr/src/
git clone https://github.com/SpiderLabs/ModSecurity.git
cd /usr/src/modsecurity
./autogen.sh
./configure --enable-standalone-module --disable-mlogc

zimmerle · 2016-12-16T22:34:54Z

Hi @maxmonterumisi

Please use the ModSecurity-nginx connector:
https://github.com/SpiderLabs/ModSecurity-nginx

zimmerle · 2017-05-09T14:29:39Z

Marking as won't fix in 2.x. It is no longer a concern in libModSecurity: https://github.com/SpiderLabs/ModSecurity/tree/v3/master

zimmerle added Platform - Nginx labels May 6, 2014

zimmerle added this to the v2.8.1-RC1 milestone May 6, 2014

zimmerle self-assigned this May 6, 2014

zimmerle mentioned this issue Jul 28, 2014

Nginx 1.6 / Modsec 2.8 -> Upload scanning returns " no upstream configuration " error #751

Closed

zimmerle removed this from the v2.8.1-RC1 milestone Nov 14, 2014

csanders-git mentioned this issue Dec 15, 2014

Deny all the POST request #813

Closed

jhill-cmd mentioned this issue Feb 16, 2015

Nginx with Modsecurity: POST request gives 500 error #582

Closed

hwdsl2 mentioned this issue Apr 30, 2016

multiblog not working hwdsl2/setup-ghost-blog#1

Closed

zimmerle mentioned this issue Aug 1, 2016

Post request lead to nginx crash on nginx 1.7.0 and ModSecurity nginx_refactoring branch #748

Closed

zimmerle added the TBF by libmodsec label Oct 21, 2016

zimmerle closed this as completed May 9, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NGINX and SecRequestBodyAccess On option, don't pass POST request to Upstream Server #664

NGINX and SecRequestBodyAccess On option, don't pass POST request to Upstream Server #664

zotgene commented Feb 20, 2014

zotgene commented Feb 20, 2014

zotgene commented Feb 24, 2014

zimmerle commented Mar 5, 2014

zotgene commented Mar 7, 2014

infinitnet commented Apr 10, 2014

falsandtru commented May 6, 2014

zimmerle commented May 6, 2014

zimmerle commented May 26, 2014

zotgene commented May 26, 2014

zimmerle commented May 26, 2014

demofly commented May 26, 2014

zimmerle commented May 26, 2014

demofly commented May 30, 2014

yicol commented Jun 25, 2014

infinitnet commented Jul 3, 2014

elialum commented Jul 16, 2014

infinitnet commented Jul 16, 2014

ekreiser commented Dec 30, 2014

jowrjowr commented Jan 6, 2015

wangxianwei commented Jan 16, 2015

wangxianwei commented Jan 20, 2015

zimmerle commented Jan 20, 2015

wangxianwei commented Jan 20, 2015

zimmerle commented Jan 20, 2015

wangxianwei commented Jan 21, 2015

wangxianwei commented Jan 22, 2015

zotgene commented Jan 22, 2015

ton31337 commented Jan 23, 2015

sasah commented Feb 13, 2015

daniilyar-confyrm commented Jan 27, 2016

zimmerle commented Jan 27, 2016

maxmonterumisi commented Nov 21, 2016

zimmerle commented Dec 16, 2016

zimmerle commented May 9, 2017

NGINX and SecRequestBodyAccess On option, don't pass POST request to Upstream Server #664

NGINX and SecRequestBodyAccess On option, don't pass POST request to Upstream Server #664

Comments

zotgene commented Feb 20, 2014

zotgene commented Feb 20, 2014

zotgene commented Feb 24, 2014

zimmerle commented Mar 5, 2014

zotgene commented Mar 7, 2014

infinitnet commented Apr 10, 2014

falsandtru commented May 6, 2014

zimmerle commented May 6, 2014

zimmerle commented May 26, 2014

zotgene commented May 26, 2014

zimmerle commented May 26, 2014

demofly commented May 26, 2014

zimmerle commented May 26, 2014

demofly commented May 30, 2014

yicol commented Jun 25, 2014

infinitnet commented Jul 3, 2014

elialum commented Jul 16, 2014

infinitnet commented Jul 16, 2014

ekreiser commented Dec 30, 2014

jowrjowr commented Jan 6, 2015

wangxianwei commented Jan 16, 2015

wangxianwei commented Jan 20, 2015

zimmerle commented Jan 20, 2015

wangxianwei commented Jan 20, 2015

zimmerle commented Jan 20, 2015

wangxianwei commented Jan 21, 2015

500 Internal Server Error

wangxianwei commented Jan 22, 2015

zotgene commented Jan 22, 2015

ton31337 commented Jan 23, 2015

sasah commented Feb 13, 2015

daniilyar-confyrm commented Jan 27, 2016

zimmerle commented Jan 27, 2016

maxmonterumisi commented Nov 21, 2016

zimmerle commented Dec 16, 2016

zimmerle commented May 9, 2017