IPS not preventing sql injection

[Toolmaker]

Hi Checkmates,

long post - grateful if you could help me with this one:

For a demonstration, I created a small web/DB application intentionally vulnerable to SQL injection and ran sqlmap (a standard tool for pen testing sql injections) against it.

Traffic (plain HTTP on port 80) was routed through a CheckPoint R81.20 with IDP enabled using the "strict" profile.

To my surprise, the sql injection still worked and sqlmap was able to enumerate and dump the complete database.

Sqlmap used several dozens very obvious SQL injection attempts. The firewall logged and passed all of them, without preventing or noticing the SQL injection attack - with one exception:

The protection "Sqlmap Automated SQL Injection Tool" fired once, and only once.

This did not prevent the other requests, and did not stop the extraction of the data base.

Now, did I miss something in configuring the firewall IDP, or do the protections simply not protect against sqlmap?

On the firewall, I checked:

• IPS, Anti-Bot, Anti-Virus Blades are enabled:

# enabled_blades
fw av ips anti_bot

• IDP is enabled, pattern are up-to-date, firewall is using the "Strict"-Profile:

# ips stat
IPS Status: Enabled
Active Profiles:
Strict
IPS Update Version: 635256678
Global Detect: Off
Bypass Under Load: Off

• IPS bypass under load is diabled:

# ips bypass stat
IPS Bypass Under Load: Disabled

• The target network 172.20.11.0/24 is in the "Protected Scope" (Security Policies / Threat Prevention / Custom Policy)
• There are no exceptions to the IDP protections (Manage & Settings / Blades / General / Inspection Settings / Exceptions)
• There are no exceptions in the Threat Prevention Policy (Security Policies / Threat Prevention / Exceptions)
• Assigned Inspection Profile is "Recommended Inspections" (Manage & Settings / Blades / General / Inspection Settings / Gateways)
• Topology for firewall interfaces is set:
  • eth1 (towards attacker/sqlmap) is "External"
  • eth2 (towards vulnerable application) is "Defined by routes (Internal)"
• IPS Activation Mode is "According to Policy", not "Detect only" (Gateways / "firewall" / IPS)
• Installing the Threat Prevention Policy gives no warnings.

Here is an example of a successful sqlmap command:

sqlmap --batch \
--flush-session \
--dump \
-D mydb_name \
-T admins \
--headers="Content-Type: application/json" \
-u http://172.20.11.11/search \
--random-agent \
--data='{"text1":"*", "andor":"and", "text2":""}'

The vulnerability is in an unchecked JSON parameter ("text1") sent as a POST request) to /search.

An example of a sqlmap request the firewall lets pass is this:

POST /search HTTP/1.1
Content-Length: 85
Content-Type: application/json
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Safari/605.1.15
Host: 172.20.11.11
Accept: */*
Accept-Encoding: gzip,deflate
Connection: close

{"text1":";SELECT DBMS_PIPE.RECEIVE_MESSAGE(CHR(106)||CHR(74)||CHR(109)||CHR(86),5) FROM DUAL--", "andor":"and", "text2":""}

What else can I check to find out why the sql injection is not blocked - any thoughts?

[Chris_Atkinson]

Do you not see even "Detect" logs, how does your protections activation look for that "strict" profile? 

Any other considerations that we should be aware of such as NAT etc.

[Toolmaker]

Hi Chris,

- settings are exactly as in your image

- no NAT configured

- no Detect Log entries

Kind regards,

Bernhard

[Chris_Atkinson]

If you're expecting the "Core" SQL Injection protection to fire then there are potentially additional configurations required (see below).

If however the expectation is that another of the IPS protection should trigger I would suggest it may need to be reviewed with TAC who can then do a remote session and take any necessary debugs / packet captures internally etc.

[Henrik_Noerr1]

and what object was used to allow the connection, the builtin http object?

I would think inspections are tied to the selected protocol parser.

/Henrik

[Toolmaker]

Yes, the unmodified, predefined "http" service using protocol  "HTTP". 

[Don_Paterson]

The Strict Profile is in Prevent (block) for most of the 901 SQL Injections (in today's updated IPS database), but 8 of the Protections (1 Core and 7 ThreatCloud) are note enabled for blocking.

4 of those are Performance Impact Critical, which means that Profiles never consider those for use, and the administrator must enable them manually.

The other 3 are in Detect mode because of Low Confidence.

What you could try it to set them to Prevent using the Override option and then test. See screenshots and files attached.

In the IPS Protections window:

1. Search "SQL Injection"
2. Click the Strict column so sort (look for the 7 at the top)
3. Select them all
4. Actions > Select Protections > Prevent Selected
5. Read the message/s carefully
6. Publish
7. Install TP policy

Keep an eye on the cpview running on the gateway to see how much performance impact you see when running testing.

You can also run hcp -r all or hcp -r "Threat Prevention" during the test and see what that says.

Something else you can try is an IOC Indicator (IOC File). Add that and modify the Strict Profile to reference it.

That will force you to save it as a newly named Profile (so that your changes can stick) and then make sure that is in the rule (replace Strict).

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_ThreatPrevention_AdminGuide/...

[Don_Paterson]

This is something else that you can explore.

Each protection carried tags/categories.

EDIT (take 2)

That is probably not relevant and you can ignore it.

One thing to be aware of if you look into this:

"These categories only filter out or add protections that comply with the Profile settings (Confidence, Severity, Performance in the General Policy page of the Profile).

For example, if a protection is inactive because of its Performance rating, it is not enabled even if its category is in Protections to activate."

Reference:

Page 64

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_ThreatPrevention_AdminGuide/...

In summary:

If you use the settings in the screenshot (Protections to activate > SQL Injection) then the result is that only 889 of the total 16777 Protections will be in Prevent mode. 

15,892 will be Inactive.

3 will be Detect

It would be great for performance and only SQL Injection testing but not other IPS protections are active.

Not great for performance if the Critical Performance impact Protections are enabled with the Override.

Note: The number of Protections in the ThreatCloud database during testing on 11 Oct. 2025

[the_rock]

I would certainly follow what @Don_Paterson  suggested, but if no dice, would open TAC case.

Best,

Andy