Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Harald_Hansen
Advisor
Advisor

Anti-spoofing; network defined by routes with overlapping spaces

The network defined by routes feature in anti-spoofing is a very nice addition, though severely flawed.

My example:

We have 10.0.0.0/8 defined in the network and multiple gateways interfacing with their external interfaces toward each other. If there are overlapping routes, anti-spoofing will kill traffic passing the external interface even if there is a more specific route northbound. 

This also appears to happen with VPN traffic, where the gateway kills inbound VPN traffic that is routed towards the peer on an external interface route if there is a wider route matching an internal interface.

If this is intended behaviour, no real world scenario like the ones above have been considered. 

At the moment we have to create anti-spoofing exception groups or disable anti-spoofing all-together. This is probably not what Check Point must have had in mind when designing this behaviour?

Any suggestions? 

15 Replies
Danny
Champion Champion
Champion

Anti-Spoofing is not meant to fix your overlapping routes issue. What you're experiencing is just a subsequent flaw. In these cases I suggest choosing another Anti-Spoofing routine.

Harald_Hansen
Advisor
Advisor

What an awful answer, you are not contributing to solving this real world problem.

Danny
Champion Champion
Champion

C'mon, my One-liner for Address Spoofing Troubleshooting won a contribution of the year award.

PhoneBoy
Admin
Admin

Let's keep it friendly, folks. 😬

How are the routes in question defined?
Are they static routes defined on the gateway or via dynamic routes?

The primary use case for this is for gateways running dynamic routes.
One limitation is that we don't take into account route metrics when calculating topology.
That's discussed in more detail here: https://community.checkpoint.com/t5/Next-Generation-Firewall/Security-Flaw-in-Dynamic-Anti-Spoofing-... 

Tagging @Meital_Natanson to comment on whether this is operating as designed in your particular case or not.

0 Kudos
Harald_Hansen
Advisor
Advisor

We are moving toward dynamic routing, though you cannot get rid of static routes entirely. Like when you have a large WAN and the telco does not support DR, or like in this case, support it on the other link, that is connected to the other firewall/VS. We are moving slowly, the new connections are with BGP, and the hope was that we could transition just by adding more specific routes. Now we have to keep exclusion groups on all external interfaces or do route calculations that change all the time. Even worse, we don't have a choice when carving out small subnets for VPN tunnels, where there is some overlap in IP address use.

To me it seems like this feature only exists to serve customers that already use DR on all interfaces, at my customers this situation will never occur. Thus this post to clarify the need for an exclusion feature to anti-spoofing on external interfaces based on the more specific routes defined on that interface. This could be optional, so the purist can have their peace.

0 Kudos
Harald_Hansen
Advisor
Advisor

I forgot to answer your questions:

>Are they static routes defined on the gateway or via dynamic routes?

Both, OSPF in the zone connecting perimeter gateways and the various VSX VSes. Static routing southbound towards WAN-links, VPN gateways and internal networks.

>One limitation is that we don't take into account route metrics when calculating topology.

You also do not take smaller masks into account (I'm not sure if route metrics includes that as well).

0 Kudos
Meital_Natanson
Employee
Employee

Correct, this is the design.

For any behavior change requirement, I suggest to go with RFE process.

0 Kudos
Harald_Hansen
Advisor
Advisor

I've sent in the RFE to the local CP office yesterday. I'm working for a Check Point partner and will push for improvements through those channels as well.

I'm also a bit curious to how the design process worked on this feature. What was the goals and limitations? Did you take both mid-size and large scale Check Point customers into account when setting the parameters of this feature? 

0 Kudos
Meital_Natanson
Employee
Employee

Hi @Harald_Hansen ,

Let's take it offline.

Can you please send me the questions via mail?

meitalna@checkpoint.com

Thanks,

Meital

0 Kudos
Christian_Norda
Explorer

I hope this is not Check Point's final stance.. If so, it would be yet another example of Check Point providing a seemingly useful feature, that ultimately (and unfortunately) turns out to be utterly useless in real world scenarios, for all but the most basic environments.

 

Bob_Zimmerman
Authority
Authority

If I understand your problem correctly, it ultimately comes from what "External" really means: not Internal. An interface configured as External gets the topology of all internal interfaces, ORs them together, then NOTs the result.

Based on my experience with it, Check Point built the "Network defined by routes" URPF option for environments in which routing is used exclusively with exact networks, not summaries like 10/8. While yes, this is the correct way to build an environment in an academic sense, you also raise the valid concern that most real environments are not academically correct.

I actually just ran into a problem with some interior firewalls sitting between two of my datacenters and their WAN links to certain other datacenters. Nice, simple firewall topology. One datacenter-facing interface marked as Internal, one WAN-facing interface marked as External. I tried to flip the datacenter-facing interface on one of the firewalls to have topology defined by routes, and OSPF was lost between that firewall and the WAN-facing interface, which I did not change. The two datacenters were from an acquisition and have a WAN link between them set up to work as a redundant path between those two datacenters and these particular WAN links. The firewall I changed learned all the WAN-side routes from both its WAN interface and its datacenter interface, including the local networks for both the datacenter interface and the WAN interface. The datacenter interface picked up the routes from dynamic routing and added them to its antispoofing topology, and since the WAN interface was External, it had a topology of NOT those networks.

Still looking into how the system behaves if both interfaces are set to use topology defined by routes.

0 Kudos
Harald_Hansen
Advisor
Advisor

You'd probably need to have a dummy interface for external that won't be used. It could work, though there are other internals that depend on northbound traffic passing the external interface. 

To me all insecure networks should be regarded as external, including the WAN. My issues with networks based on routing stems primarily from the old design, merged over to a new VSX/maestro setup. Long term we aim for a more academically correct design, re the message above.

0 Kudos
Bob_Zimmerman
Authority
Authority

Traffic can be forwarded between External interfaces, which is what we're doing for the moment. It should also be easy to say both are internal with topology defined by routes, assuming that setting allows the same network to be learned on multiple interfaces.

Antispoofing topology and threat prevention topology were linked in the past, but now are not necessarily. I have several firewalls where the interface facing an Internet link is External in antispoofing, but more trusted in threat prevention terms (the goal is to protect datacenters from malware a user might accidentally bring into the office).

0 Kudos
Wolfgang
Authority
Authority

@Harald_Hansen 

I do understand your needs and expectations but what you see is expected behaviour. This is how it works. The networks are defined from your routing entries, regardless routes for more specific subnets.

Maybee there are plans for the future...

tagging @Meital_Natanson and mentioned Security Flaw? in Dynamic Anti-Spoofing (R80.20 and above) . There was a similarly discussion.

Wolfgang

PS. An RFE will be always a good idea.

0 Kudos
Harald_Hansen
Advisor
Advisor

An RFE is in the works, I also have discussions with the local office as well as the Professional Services consultant attached to the project I'm working on. Turning every stone ...

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events