IgnoreIP and IgnoreCIDR not whitelisting correctly

[noahbailey]

Just updated to Nginx 1.18.0 & NAXSI 1.1, and am not able to use the IP whitelisting feature.
I compile naxsi/nginx from source on this system. This particular server runs Ubuntu 16.04, but have also tested this on 18.04 with the same install procedure.

Config snippets

/etc/nginx/rules/naxsi.rules

#LearningMode;
SecRulesEnabled; 
DeniedRule "/RequestDenied"; 
IgnoreIP "1.1.1.1"; #my actual IPv4
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;
...

/etc/nginx/sites-enabled/my-site.conf

include /etc/nginx/rules/naxsi_core.rules;

server {
    listen 443 ssl; 
    server_name mycoolsite.com; 
    ##ssl stuff here 

    location / {
        include /etc/nginx/rules/naxsi.rules; 
        include /etc/nginx/rules/foo.rules; #specific to my app
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_pass http://my-cool-server:1337/;
    }
    location /RequestDenied {
        return 418;
    }
}

Nginx versions

$ nginx -V
nginx version: nginx/1.18.0
built by gcc 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
built with OpenSSL 1.1.1h  22 Sep 2020
TLS SNI support enabled
configure arguments: --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --user=www-data --group=www-data --add-module=/usr/src/naxsi/naxsi-1.1a/naxsi_src --add-module=/usr/src/nginx_cookie_flag_module --with-http_ssl_module --with-http_v2_module --with-openssl=/usr/local/src/openssl --without-mail_pop3_module --without-mail_smtp_module --without-mail_imap_module --without-http_uwsgi_module --without-http_scgi_module --with-http_realip_module --prefix=/usr

Let me know if I made an obvious mistake, or if this is a real bug... Thanks all!

[wargio]

can you provide a raw http request? even a cURL one generated by the browser is ok.

[noahbailey]

Hey, should have included that from the get go, my bad.

The curl command:

$ curl "https://mycoolsite.com/?something=1 or '1'='1'" -v
*   Trying x.x.x.x...
* TCP_NODELAY set
* Connected to xxxxxx (x.x.x.x) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Client hello (1):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* xxxxx
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* Using Stream ID: 1 (easy handle 0x561b0912a580)
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
> GET /?something=1 or '1'='1' HTTP/2
> Host: xxxxx
> User-Agent: curl/7.58.0
> Accept: */*
>
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
< HTTP/2 418
< server: nginx
< date: Fri, 23 Oct 2020 17:44:48 GMT
< content-length: 0
<

And, the log generated by NAXSI looks like this:

==> /var/log/nginx/ssl_error.log <==
2020/10/23 17:46:37 [error] 16401#0: *21 NAXSI_FMT: ip=x.x.x.x&server=mycoolsite.com/&vers=1.1&total_processed=4&total_blocked=3&c
onfig=block&cscore0=$LIBINJECTION_SQL&score0=8&zone0=ARGS&id0=17&var_name0=something, client: x.x.x.x, server: mycoolsite.com, request: "GET
/?something=1 or '1'='1' HTTP/2.0", host: "mycoolsite.com"

Note, this vhost does have Libinjection enabled too which was not included in the original configs above.

Let me know if you need any more info, thanks!

[rickygm]

I have the same situation, trying different methods.

#532 (comment)

[wargio]

probably there is a bug on the IgnoreXXX methods

[rickygm]

let us know when it's ready to do the tests.

[noahbailey]

Thanks for reproducing this issue... If there's more system info I can supply I'd be happy to. And, if there's a prerelease version or a testing build loop me in!

[noahbailey]

I also tried to use if statements (icky, I know) to accomplish the same thing but wasn't successful:

if ($remote_addr = 'x.x.x.x') {
  LearningMode;
}

Seems like the naxsi config pieces aren't allowed in if blocks, which is understandable.

[wargio]

i can confirm the bug. i'm trying to patch it and make a new release once confirmed working.

[wargio]

ok, it should be fixed. please test the master

[noahbailey]

Just reinstalled from master branch. Here's what I found:

1. IgnoreIP works as it should. With the same request above I am getting http/400 (the correct result)
2. IgnoreCIDR mostly works as correctly. When putting my own IP in as a /29 I get the 400 but when I use a /32 mask (single IP) it blocks my requests again. I don't know how many people will use /32 instead of IgnoreIP though.

Thanks for getting it to a workable state! The main issue is solved which is great.

[wargio]

hmm that's weird, but thank you for letting me know. actually i convert the /32 and /128 to IgnoreIP

[wargio]

Ok, found the bug and pushed to master. if both of you (@noahbailey and @rickygm) can confirm the fixes, i'll make a new release.
Now it should behave as expected.

[rickygm]

It's ready, it works perfect, just a suggestion, you could add a flag in the log, that says client_whitelist: 1.1.1.1

[noahbailey]

Yeah, that fixed /32 cidr's.
Done a few tests now and I think it's ready to go. Thanks @wargio