Non HTTP Traffic over HTTP port: Invalid character

[dbrown3611]

- Smart-1 225 SMS
- Two 5800 Active/Standby clusters
- All running R77.30 Build 092 with Jumbo HFA 286

In early August we enabled IPS protection for Non HTTP Traffic over HTTP port, immediately started seeing traffic being blocked to our web servers in DMZ. Being unable to determine why so much incoming traffic was caught by this protection, we set it to "Detect" and opened support ticket with our 3rd party support provider. They were unable to determine if this was a legitimate block or a false positive. They escalated to Check Point on August 11. All requests for information have been met in a timely manner.

It is now two months on and no determination has been provided. I have twice asked for escalation within Check Point support. I have engaged my regional Check Point Account Rep and Security Engineer. None of this has led to anything beyond updates stating "we are still looking at the problem". This leaves my management asking if we are receiving good value for the annual fees we pay to use Check Point products. I continue to answer in the affirmative.

The point of this post is to see if others in the community have similar behavior with inspections for "Non HTTP Traffic over HTTP port", and if so are they false positives. More so to ask, how does one get a determination out of Check Point support when methods used above are ineffective?

Kind regards,
dbrown

[ShadowPeak.com]

- Smart-1 225 SMS
- Two 5800 Active/Standby clusters
- All running R77.30 Build 092 with Jumbo HFA 286

In early August we enabled IPS protection for Non HTTP Traffic over HTTP port, immediately started seeing traffic being blocked to our web servers in DMZ. Being unable to determine why so much incoming traffic was caught by this protection, we set it to "Detect" and opened support ticket with our 3rd party support provider. They were unable to determine if this was a legitimate block or a false positive. They escalated to Check Point on August 11. All requests for information have been met in a timely manner.

It is now two months on and no determination has been provided. I have twice asked for escalation within Check Point support. I have engaged my regional Check Point Account Rep and Security Engineer. None of this has led to anything beyond updates stating "we are still looking at the problem". This leaves my management asking if we are receiving good value for the annual fees we pay to use Check Point products. I continue to answer in the affirmative.

The point of this post is to see if others in the community have similar behavior with inspections for "Non HTTP Traffic over HTTP port", and if so are they false positives. More so to ask, how does one get a determination out of Check Point support when methods used above are ineffective?

Kind regards,
dbrown

Were you able to check "Capture Packets" on the "HTTP on Non Standard Ports" signature and get a capture of the packet containing the offending character(s)? Do you know what actual illegal character(s) are tripping the signature?

Is there any indication in the error message as to whether the invalid character is in the URL, request header, or response header? That might provide some valuable insight. I'm thinking the "ASCII Only Request" and "ASCII Only Response Headers" Protections might be related as well.

Also check out sk117392 if you haven't already.

[dbrown3611]

Were you able to check "Capture Packets" on the "HTTP on Non Standard Ports" signature and get a capture of the packet containing the offending character(s)? Do you know what actual illegal character(s) are tripping the signature?

Is there any indication in the error message as to whether the invalid character is in the URL, request header, or response header? That might provide some valuable insight. I'm thinking the "ASCII Only Request" and "ASCII Only Response Headers" Protections might be related as well.

Also check out sk117392 if you haven't already.

Thank you for the response.

- Packet captures have been taken, invalid characters have not been identified. It would seem this is the key to a solution.
- We have ASCII Only Request enabled, this was disabled on one cluster for testing, no affect on preventing the IPS protection from triggering.
- SK117392, early on when troubleshooting with 3rd party support provided, strict parsing was set to "0", again no affect on preventing the IPS protection from triggering, so it was returned to "1".