Security Flaw? in Dynamic Anti-Spoofing (R80.20 and above)

[Tobias_Moritz]

Hello community,

I think some of you did really appreciate the new Anti-Spoofing feature in R80.20 which finally allowed us to define Anti-Spoofing by routes, which makes admins live easier as only routing has to be configured correctly (and it allows some dynamic routing scenrios to work without scripting)

My team was also happy about that and tests showed that is was working. Well, at least we thought so.

While this feature is not blocking traffic it should allow, it allows traffic which it shouldn't.

Maybe we were expecting too much or did not understand the documentation correctly, so please tell me, what you think.

Please take a look at this very simple static lab setup (I guess it is also a pretty common one in small real life setups):

What do you think what happens, when you send a spoofed IP packet which has a source address of 10.0.5.1 from intranet to firewall?

We expected it would be dropped by Anti-Spoofing, because routing table on gateway says this address would be routed to DMZ A and not to Intranet. There are two reasons for this routing decision (one would be enough):

• more specific route for this IP address on DMZ A instead of Intranet
• directly connected instead of static route

There is only one scenario, where gateway would send traffic to this IP address over the intranet heading interface from the routing point of view: If gateways interface to DMZ A is down. But in our test case, all interfaces are up and working.

So routing clearly says, this IP address belongs to DMZ A and therefor IP packets which such a source address should never come from Intranet.

Unfortunately, this is not how Checkpoint implementation is working currently. This spoofed traffic is accepted.

It looks like Checkpoint implementation is just grabbing all routing table entries for the interfaces and not takes care which routes have higher priority if conflicts exists and how routing decision is really done.

So now the question to the community and Checkpoint staff: It this the expected behaivior?

Thank you for any ideas!

---

All tests were done with R80.30 JHFA T191 on Gaia 2.6.

[Meital_Natanson]

Hi Tobias,

What you described is the expected behavior.

We don't consider routes priorities.

Thanks,

Meital

[Tobias_Moritz]

Thank you very much for confirming this as expected behavior from Check Point side!

May I ask, if there a plans to reconsider this decision?

Maybe I'm wrong with that assumption, but I think many customers will think that "Anti-Spoofing by routes" means it follows the routing logic. And having overlapping route advertisments (or even static routes like in my simple example above) in enterprise networks is a quite common scenario out there...

[Meital_Natanson]

Hi,

The are currently no plans to change it.

Correct me if I'm wrong, but as long as the route exists (even with lower priority), you can't consider it as spoofed traffic.

Otherwise, the routes should be changed.

Customers are using this feature when their networks are updated frequently or when using dynamic routing. So anti spoofing will be applied according to the routes defined on the GW and they won't need to update the networks in SmartConsole on every route change.

[Tobias_Moritz]

I also see the improvement with having this feature to finally allow dynamic layer 3 topologies. Really appriciate it.

But:

Almost every larger enterprise network I've seen so far in my career was using overlapping route advertisments or static routes to either make network admins life easier or to provide redundancy in having fallback routes.

I guess every network admin knows how routing works and that the current layer 3 network topology is defined by routing decisions on every hop which follow known rules. That said, traffic coming from directions where the current network topology would not route it back the way it was coming from has to be treated as spoofed ("URPF strict" in Cisco terminology, there is even a RFC for that: RFC#3704).

When looking at my little drawing in the first post here, there is only one theoretical case, where traffic with source 10.0.5.1 can come from Intranet - from the routing perspective. And this case is when the interface to DMZ A is link down. In that case, we have other problems than thinking about spoofed traffic. So I guess it is valid that a firewall admin will see this as valid and secure configuration - from the routing perspective.

What I want to say: If you advertise a feature called "Anti-Spoofing defined by routes", I guess most customers will think Anti-Spoofing is following the routing logic of the gateway OS. And because the real implementation is not overblocking, almost nobody will see that it is not working this way. That's why I used a headline with "Security flaw?" in it.

[cosmos]

While I agree this logic should apply to route priorities; if we lose a higher priority route for a network we want accept traffic via the the next priority route that gets installed in the FIB, which suggests the process is pulling routes from the RIB rather than FIB. This is OK, and I also appreciate having this well needed feature.

But a more specific route always takes precedence over a less specific route regardless of priority weight or admin distance, and unless asymmetric by design we should not expect to receive traffic on one interface where a more specific route exists via another. Just as this logic applies to the default route, it should also apply to less specific routes as in the OP's lab.

I would agree the current implementation presents a security flaw especially when less trusted networks appear on private addresses where route summarisation is in use.

It would be great if Check Point made plans to follow the RFC, rather than a loose interpretation of it 🙂

[cosmos]

I have recently discovered this flaw also operates in reverse, at least with the Get Topology with Interfaces process which appears to rely on the same principles.

My client is routing many public subnets southbound, with a few more specific routes heading north. Anti-spoofing drops traffic from the northbound net because:

1. SPF on external is exception based (i.e. you don’t define what networks are behind external, as all networks not internal should be external)
   1. External is determined by default route
2. If network exists on internal interface, it will not be permitted on external interface
   1. Even if a more specific route exists for that network via external
3. Fixes
   1. Group with exclusion on internal interface SPF (not automatically generated by Get Topology or dynamic SPF (CP limitation))
   2. Don't check from these networks

The same client is now asking why they can no longer manually edit the anti-spoofing groups as they could in R77 - I would consider the "based on routes" option but am concerned it may be subject to the same limitations.

[Tobias_Moritz]

You can still use manual defined antispoofing groups in R80+ the same way you did it in R77. We are doing it this way, because of the limitiation "based on routes" as discussed here.

[cosmos]

IMHO anti-spoofing would be best implemented in the firewall kernel by performing route lookups a la Reverse Path Forwarding.

[SriNarasimha005]

Hi Tobias,

Many thanks for this thread. I'm also having a similar setup where entire 10.0.0.0/8 is pointing towards the downstream switches and the DMZ subnets with DMZ1: 10.0.5.0/24, DMZ2: 10.0.6.0/24 and so on...

Since DMZ networks are overlapping routes, in this case, should I need to create an exception of 10.0.5.0/24 network in the DMZ1 interface ALONG with the "Antispoofing config: by network and mask" or just "Antispoofing config: by network and mask" works fine? 

Thanks in advance.

[Chris_Atkinson]

No exceptions should be required here, assuming those DMZ are terminating on the CP.

If you read the OP the concern is more that the behaviour is "loose" enforcement and permits scenarios they didn't expect. 

This behaviour is as designed because we don't consider route priority/rank nor are we saying the feature is URPF.

[SriNarasimha005]

Hi Chris,

Thanks for the reply. DMZ subnets are directly connected to Checkpoint firewall (VLAN interfaces).

As you said, CP doesn't consider route metrics (direct vs static), in this case, will be traffic from 10.0.5.0/24 be dropped?

I'm new to CP and I was of opinion that, when more wider route (10.0.0.0/8) pointing towards Internal and the traffic from the DMZ (directly) subnets will be dropped for Address spoofing (overlapping routes) and thus exception is required on DMZ interfaces.

[Chris_Atkinson]

No this is not the case the traffic will not be dropped here.

I think you are confusing this with your initial problem statement from your other thread where an "External" interface was involved which wouldn't expect to see "Private" or "Internal" traffic coming from the internet side of the device.

[SriNarasimha005]

Hi Mate,

Yeah, I was confused with the other thread and now I have a better comprehension about this and many thanks for your help.

Can you please share any checkpoint doc link explaining this behaviour, as I'm not able to find any. Thanks again

[Chris_Atkinson · Accepted solution]

The admin guide provides only a basic example but it is there none the less:

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_SecurityManagement_AdminGuide/Topi...

[Tobias_Moritz]

A few years later, this appeared today in Changelog of R81.20 JHF T43:

PRJ-48154, PRHF-29602

Security Gateway

Topology and Anti-Spoofing ranges are not calculated on an external interface when adding a route to an internal interface that shares the same subnet.

Is this maybe the fix for the problem discussed here? Or something different?

[Chris_Atkinson]

I suspect not, such changes would most likely arrive in a major release.

Did you raise this as an RFE with your account team at all?

[DZ_KB]

Hello @Chris_Atkinson,

As mentioned by @Tobias_Moritz , what solves the fix : 

"Topology and Anti-Spoofing ranges are not calculated on an external interface when adding a route to an internal interface that shares the same subnet." ?

[Chris_Atkinson]

Sorry your question is unclear. Are you using this JHF level (or higher) and having a problem?

If yes please contact TAC for assistance with understanding your symptoms.