NGINX Naxsi rules

[gdur]

I'm struggling recently to find out what the reason might be of a client getting an error (screenshot attached) while making a service request on our website. In the Naxsi log I think I found the error number. It would be handy if it were possible to toggle the rule to ensure this is indeed the reason for the error.
Would it be possible to add an enable/disable feature like the firewall rules to the Naxsi rules rather than deleting and creating the rule again?

[Fright]

I think that's what policies are for. using policies its possible combine rules with whitelists

[gdur]

Hi Fright, Thanks for your response but I'm not sure whether I got what you mean by that. Whitelisting/blacklisting  is something different than disabling/enabling in my view.

[Fright]

Hi.
there may be some confusion, yes, sorry.
I'm not talking about changing the Match Type for the Main rule from Blacklist to Whitelist, but creating Basic Rules with a whitelist match type to ignore certain Main rules and creating&adding "whitelisting" policies for individual locations. in this case, it is enough to include such a Basic rule in the location's whitelisting policy and check the result. while the Main rule will still be applied to other locations and servers.
Of course, you can simply lower the score in the Main rule (or delete the Main rule altogether?), but this will apply to all servers and locations

[gdur]

Hi,
OK, thanks for your explanation and I do understand your previous suggestion now and I believe that will work for me as well.

[gdur]

Hi Fright,
I didn't find the time to dive further into this issue but now I'm trying to figure out how a whitelist rule should look like. Would it be sufficient to just stick a senders IP address into the "Match Value" field to give full access to start with and than narrowing it down until access is prohibited?
Thanks!

[Fright]

Hi
not sure i follow..
A whitelist rule is a Basic Rule Type with a Match Type Whitelist and an ID matched an ID of the rule you want to whitelist

[gdur]

Hi,
I thought that just by creating a simple rule by just sticking a value in the  Description,  Message, ID fields and select Basic Rule at  Rule Type and a IP address in the Match Value field and last select Whitelist for Match Type would allow this specific IP address to pass. My problem is that the statement in the OPNsense documentation

The next two boxes are the score for libinjection. Both will add a score of 8 if they trigger. So values up to 8 will block.

while the example a few lines up shows the value 4 for Block XXS Score and Block SQL Injection Score confuses me. To me it is unclear what the relation is of these values and is not well explained.
Hope that clarifies my intention as a beginner.

[Fright]

I'm starting to think there's some kind of misconception here: naxsi is not intended to allow or deny access at the client address level (there are IP ACLs for this). it is designed to track and block unwanted behavior like exploiting vulnerabilities or using patterns that shouldn't be there in normal use.
for example, by default, we do not want to allow requests containing a sql DELETE statements. but if the published application uses such queries, then we need to whitelist this rule for that particular application. This is what whitelisting is for imho

[gdur]

Hi Fright, Really do appreciate your patience and trying to help me a bit further. Let me try to explain my objective somewhat clearer. The problem I'm trying to resolve is the as follows:
Our web server is part of our internal network. We use OPNsense Nginx to forward web traffic to the internal server where we host web based service handling for our clients. Obviously we'd like to protect our internal network against abuse and we see in the logs that works pretty well. However, one of our clients can't get through (see my first post) which is of course quite inconvenient. I try to determine in the http error log what the issue is and I find it somewhat cryptic how to determine the associated rule ID. This is an associated error message:

ip=x.x.x.x&server=xxxxxxxx&uri=/repairs/request_submitted&vers=1.3&total_processed=11832&total_blocked=281&config=block&cscore0=$policy22d06ae76d5c4e77bf8f341822272c5e&score0=12&zone0=BODY&id0=1015&var_name0=description&zone1=BODY&id1=1013&var_name1=damage, client: xxxxxxxxxx, server: xxxxxxxxxx, request: "POST /repairs/request_submitted HTTP/2.0", host: "xxxxxxxx", referrer: "https://xxxxxxx/repairs/request?nof_devices=1"

From this line I think that either the rule ID is 1015 or 1013 but I'm not sure if that's right. Obviously I've xxx'd the sensitive data in the above.
Rule 1013 stands for simple quote and 1015 stands for comma but I cannot find these as such in the POST expression. That's where I get lost.

[Fright]

yes, it seems that the naxsi saw a match to the rules 1013 and 1015. but if you look at the message and the syntax of the rules (https://github.com/nbs-system/naxsi/blob/master/naxsi_config/naxsi_core.rules), it is clear that the rule looks for matching data not in the address but in the request body.
that is, POST request body contains some data on the repair order (damage description, etc.)(?) to be added into the database. naxsi (quite justifiably) sees in this signs of possible sql-injection. but since in this case this is a completely legitimate action, this rules can be whitelisted.
more strict would be to create a rule like on attached img (not tested)
which should give a config rule like:

Code: [Select]

BasicRule wl:1015 "mz:$URL:/repairs/request_submitted|BODY";(ie "allow comma in request BODY if url is /repairs/request_submitted")

but for testing, I would start with a simple whitelisting and then narrow it down to specific addresses if I wanted to.

[gdur]

Hi Fright,
Thank you so much for your clear explanation and suggestion.
I will follow your proposal and will report the result once checked that this has indeed solved the problem. This may take a while because I depend on this specific submitter's cooperation.