Check Point and Internal Network Scanners

[Cypress]

Problem Brief: Check Point gateway appears to be responding on behalf of "unused IP Addresses" causing internal network scans to take much longer to complete, and to find many more devices than actually exists.

More details:  Our security team runs some vulnerability scanners in our environment, which has become a common practice in enterprise networks.  Included in their scan ranges are some DMZ Networks behind Check Point gateways.  A brief example of this follows.

Check Point Gateway Interfaces:
Eth0: connected to external network
eth1: connected to internal network
eth2: connected to dmz network

In this example they are scanning the network configured on the eth2 interface on the gateway.  Let us say this is a /24 private IP subnet and only 5 or so devices are actually connected in the network.  I can confirm this viewing the arp table on the Gateway, and see there are only 5 devices in the network, and I can see the same on the network switch that there's only 5 mac addresses in the vlan.

What is happening, is the security scanner is finding all 254 devices in the network, it is seeing every unused IP Address as a "device," and the root cause appears to be that the Check Point gateway is responding on behalf of the unused IP Addresses with a SYN+ACK for some of the ports being scanned.. I am thinking the gateway should not respond with a SYN+ACK on behalf of the unused IP address?  Has this behavior been observed by anyone else?  I can see the SYN+ACK response on a tcpdump.

[Bob_Zimmerman]

Which ports?

This is needed for some traffic filtering options. For example, if you use an application/site object, the connection must first be allowed to figure out what name the client requests, which is then used to determine if the connection will be allowed or reset.

[Cypress]

It seems to be a pretty varied list of different ports.  I did notice if I put the Scanner's IP Address in our SSL Inspection Bypass group, I noticed it stopped responding with SYN+ACK on port 443... however other TCP Ports continue to show replies.

[Bob_Zimmerman]

Bypassing TLS inspection just gets the firewall to stop spoofing a reply for ports expected to be encrypted with TLS. Clear HTTP would still get the same behavior on various ports, and a few other services behave similarly. Off the top of my head, replies are spoofed for TCP port 1720 (h.323) if you use the "Any" object in the service column of a rule.

[Cypress]

OK I just had them run a new scan and captured it with tcpdump.  I am seeing SYN+ACK Replies on several different TCP ports.  More than I would have thought.  Ports 111, 993, 995, 1723, 554, and many others.. too many to name actually.  I wonder what is causing this?  There is definitely no actual device living at that IP Address, so it seems like the Gateway itself is sending the reply.

[Bob_Zimmerman]

Pick one address, confirm it definitely doesn't exist on your network (fw monitor when trying to connect to a port can help; replies spoofed by the firewall will show SYN for i and I but not o or O, and SYN-ACK for o and O, but not i or I), scan all TCP ports on it, and check the logs. What rule matches the traffic? What other information do you see in the log entry?

[Cypress]

The scans are hitting a rule we have set up "Allow Scanner to DMZ" which is an Allow for specific IP Source to specific subnet Dest, but Service is left as "any"

In the actual log entry, the matched service for the example of tcp/111 shows "sip-tcp-Protocol-Signature (TCP/111)" for the service, and for Rules Matched I am seeing a match on two layers (We are still using separate ordered layers for security and Application blade rules)

The rule match for the security layer is the previously mentioned "Scanner to DMZ" rule.

The rule match for the Application Layer is "CPNotEnoughDataForRuleMatch"

Based on that "CPNotENoughDataforRuleMatch" I am guessing this is part of the Application Awareness in Check Point, like you originally said.  The gateway must respond with a SYN+ACK and it is expecting the client to pass some specific protocol payload to see if the traffic should be allowed or denied.  I suppose this functionality cannot work if the Gateway doesn't spoof a bit of the response?

[Bob_Zimmerman]

That's exactly right. When the service or application object needs more data to confirm exactly which protocol is being used, the firewall spoofs a response to learn more from the client (e.g, to catch the HTTP GET request).

You might be able to work around this by building a service object for all TCP ports and using that instead of Any. As long as that rule is high in the policy, the traffic shouldn't be caught by one of the services causing the spoofed replies.