We have installed a new Juniper SRX firewall with IDP, so the firewall is inspecting the traffic for suspicious activity.
I've encountered 3 "false-positive" reports for SQL injection attacks that are just genuine usage:
- Using mDaemon's webmail, trying to forward a message was considered a SQL injection attempt
- In a .NET web-application, entering a load of text into a textarea and clicking submit triggered a SQL injection. It was 1 sentence that seemed to trip it - about an engineer travelling to Basingstoke all the way from South Wales. Remove that sentence it worked fine.
- In a classic-ASP application, trying to save a report (behind the scenes the page reads all the checkboxes selected and inserts this into a database table). The keyword that is causing the incorrect alert is "Goodmans"
With the 2nd problem above, if I pasted the text content into a different web-application (I simply copied the content into a different, unrelated classic-asp form with different objects) there were no problems at all. With the 3rd problem, the application works just fine - it's just this particular set of options that we've found causes the firewall to drop the connection.
The only way I can solve the mDaemon issue is to take the server out of the IDP policy.
I am going to submit a support request to Juniper to help find a fix, but how does everyone else handle false-positives? Is there anything else that can be done? I am worried that there are other conditions that will trigger more and this will be an endless exercise. Except we may not know about many false-positives because users assume the website went down and just give up (or don't report what they did/can't replicate it a second time).
Additional Information In the case of the third problem, it's not just "goodmans" that is causing the problem - it's much more widespread!
Though I am quite familiar with the SRX, I've not used the IDS engine much because it tanks the box so hard in performance. I can tell you that on our Palo Alto devices which have similar functionality (and dedicated chips to process it) that we set profiles based on risk ratings from Palo Alto Networks.
PAN is flexible in this regard, allowing you to block by risk level, or the specific vulnerability. We usually choose to go with the PAN recommended actions. I think what you're going to have to look for is some kind of setting or policy configuration that merely alerts. Perhaps there is a way if repeated attempts are made that it will then block. I'll read up on this tomorrow morning and see what I can figure out for you, but I'm just going to RTFM. Best of luck.