I have a firewall with some packet inspection configured to detect SQL Injection attacks. (Dell SonicWall NSA 3500) There is a rule (HTTP Request URI with SQL Statement (IF) 2) that seems to consider any string as an attack if "and" or "or" or some other words are in a query string.

I have a web site hosted behind the firewall. It has a search feature. A user types in a phrase in a text box and this string is sent to the server, where it is parsed, split, massaged, and compiled into a search target to locate entities in the system that have content conforming to the search request entered by the user.

The string is posted in a GET request. If I try to find content with "this or that" the firewall sees "OR" and drops the request, because sometimes you can write SQL queries that have "or" in it, I guess.

I am able to modify my own systems to resolve this issue. I am not interested, here, in finding ways of making my system work. I am, instead, interested in understanding why the rule has been included, and if it is a good thing to include.

Is a firewall rule that says something like "any request string that has any word that might possibly be used to construct an evil SQL statement deemed evil, itself" a reasonable rule?

Skip Sailors

  • Whenever a rule is simpler than the application's logic for a given input, you will experience false-positives or false-negatives. Some IDPS have very complex ('smart') rules and decent protection from SQL injection is high priority. It isn't clear whether the rule you describe is a built-in rule or a custom rule (added by the sonicwall administrator). I assume it is a custom rule as no IDS support center would want to handle the volume of complaints such an obviously flawed rule would produce. You are unlikely to be the only person affected, so I recommend applying social pressure.
    – Jeff K
    Commented Feb 24, 2017 at 20:59

2 Answers 2


IPS systems are not plug-and-play, set-and-forget devices. They need to be tuned and monitored constantly to work effectively in your environment. If you enable every possible rule, you are going to get lots of false positives like the one you are seeing. That particular rule might make sense to be enabled in some environments, but clearly it is not appropriate in your environment because there is a lot of legitimate traffic that matches that rule.

The usual approach for setting up an IPS system is to put it in passive, monitoring mode where it doesn't block any traffic. Then the alerts are manually reviewed, and any rules that keep triggering false positives are disabled. Once you are confident that the system won't interfere with legitimate use, then you can re-enable blocking. Adjust your IPS to work with your environment, not the other way around.


In addition to @tlng05's good and correct implementation advice (Adjust your IPS to work with your environment, not the other way around), I would start by building a solid example case, demonstrating a valid business use of the word "OR" and also showing the IPS logs that caused the tool to discard the connections. You might continue searching the logs looking for other places where the tool is interrupting your legitimate business traffic, and gathering more data. But don't raise the alarm bells until you're prepared.

The reasons are entirely political. The team that installed the IPS is undoubtedly proud of their shiny new tool, they can see that it's being effective, and they have probably showed it off to the VPs and such. Furthermore, if you say "it should have been installed in reporting mode first, tested like this, and had the rules adjusted before being switched on", you're implying they didn't do a good job of installing it. You risk the IPS team getting defensive, and refusing to cooperate. This can easily blow up way out of proportion, and you certainly don't want to make things worse. Your presentation/report should show only a few facts:

  1. The business legitimately permits the use of words like "AND" and "OR" in the public query interface.
  2. The IPS tool definitely intercepted these messages and interrupted legitimate user queries (show the IPS logs where the rule(s) were being triggered, and provide a number of impacted clients here.)
  3. You are seeking only the remediation of the specific rules that are interfering with these queries.
  4. (optional) During your work with the log files, you could see that the tool is otherwise effective and is doing a great job, and has continued merit in the organization.

Don't say anywhere in here that the IPS team didn't follow proper procedures, or even acknowledge that there are well-known procedures for installing these things. Let anything blame-related just slip away, unanswered. Finally, let the IPS team take credit for fixing the problem.

Yes, this may be "Intra-company Politics 101" stuff that you already know, but not everybody may think to approach a problem like this as carefully as they could.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .