A Primer on Anti-Spoofing

[PhoneBoy]

Every once in a while, I run across a discussion around Check Point, and I think: you know, I wrote something about that back in the day.
Today, that topic is Anti-Spoofing.
The feature hasn't changed all that much since the first versions of the product.
That said, a major improvement is coming in the R80.20 release!

One of the ways it manifested itself back in the old days was you would see a packet accepted on one rule (say, rule 4), then immediately dropped by Rule 0.

You'd have log entries that looked like so (using "fw log" output):

17:13:45 accept kyle       >le0 proto tcp src jungleman dst kyle service telnet s_port 2390 len 48 rule 4 
17:13:45 reject kyle      

Pretty much since day one, the security gateway has always inspected packets against the rulebase twice:

• When the packet enters the firewall
• When the packet is exiting the firewall (after it has been routed)

Older versions of Check Point had some ways to modify this behavior (e.g. the "Apply Gateway Rules to Interface Direction" feature and "Install On"), but this did not apply to anti-spoofing, where the above logic always applies.

When anti-spoofing checks fail, they show up in the logs as either drops or rejects on rule 0. If you get a log entry that looks like:

17:13:45 drop   kyle       >le0 proto tcp src jungleman dst kyle service telnet s_port 2390 len 48 rule 0

it means that the source IP of the traffic (in this case jungleman) is not properly included in le0's "valid addresses" setting.
If, on the other hand, you see something like this (as was the example above):

17:13:45 reject kyle      

it means that the destination IP of the traffic (in this case, kyle) is not in qe0's "valid addresses" setting.

Note this may actually indicate a routing problem, particularly if the interface it is being rejected on is not the interface you expect.

How Does NAT Factor In?

In currently supported versions, NAT occurs before routing, but only if "Perform Destination Translation on Client Side" is enabled in the Global Properties, Network Address Translation section.

In FireWall-1 4.1 and earlier, both the incoming and outgoing anti-spoof checks are performed before address translation. This means that any traffic passing through the firewall must pass anti-spoofing checks before address translation rules are applied.

What about Dynamic Routing?

In an environment where the gateway participates in Dynamic Routing, if routing makes a change that is inconsistent with the anti-spoofing configuration, traffic could easily be dropped.
This has led some customers to disable anti-spoofing (which is, of course, not recommended).

In R80.20+ Gateways, there is an option to have routing define the anti-spoofing configuration.
You can see this option starting in R80.20.M1 and it's available for gateways R80.20 and above:

[_Val_]

>>In R80.20 Gateways, there will be an option to have dynamic routing define the anti-spoofing configuration.

Finally!

[Danny]

Everyone is waiting for R80.20 to reach GA state because of all these improvements it features.

[PhoneBoy]

We need more Production EA customers

[Vladimir]

About time for the dynamic routing integration with anti-spoofing!

It was one of the major pains for me in the past, when designing highly survivable infrastructures, as I had to account for all possible networks hitting the interface in question.

This, in turn, relaxed the normal security state, as that traffic was always allowed. 

[Petr_Hantak]

I agree for me is the one of biggest pain as well. So I'm happy to see it will change finally. Unfortunatelly we must always wait until new releases like R80.20 will settle down little bit after GA and after thet we can put it into production. So it seems I need to stay tunned and wait until I'll be to fully enjoy it.

[Kris_Pellens]

Hello Dameon.

Thank you for starting the topic on anti-spoofing.

Back in the day (R76), Check Point published a document regarding anti-spoofing; see: Preventing IP Spoofing. The document shows the following picture:

Item	Description		Item	Description
1	Interface IF1		6	Florida_LAN
2	Interface IF2		7	Alaska_RND_LAN
3	Interface IF3		8	Internet
4	Interface IF4		9	Alaska_GW
5	Alaska_LAN		10	Alaska_RND_GW

For the Alaska_GW, the Firewall makes sure that:

• All incoming packets to IF1 come from the Internet.
• All incoming packets to IF2 come from Alaska_LAN or, Alaska_RND_LAN or Florida_LAN.

For the Alaska_RND_GW, the Firewall makes sure that:

• All incoming packets to IF3 come from Alaska_LAN, Florida_LAN or the Internet.
• All incoming packets to IF4 come from Alaka_RND_LAN.

When you configure Anti-spoofing for a Security Gateway, specify if the interfaces go to the Internet (External) or an internal network (Internal).

Assumptions:

1. The diagram depicted above is a VSX/VSLS cluster.
2. The name of the gateway with interfaces if1 and if2 is vs1. if1 is connected to an ISP router.
3. The name of the gateway with interfaces if3 and if4 is vs2.
4. OSPF is configured for both vs1 and vs2.
5. Routes towards Internet are advertised on both vs1 and vs2: O E 0.0.0.0/0 via 192.168.1.250

Questions:

1. For VSX/VSLS, could dynamic routing define the anti-spoofing configuration in R80.20?
2. How would you configure if3, defined in vs2, when using R80.20 (if1, if2, and if4 are obvious)?

As External (leads out to the Internet)?

As Internal  (leads to the local network) + Networks defined by routes?

Or something else? Please describe.

I set up a lab environment earlier this week with R80.20 Public EA (August) but still get address spoofing messages.

Many thanks.

[PhoneBoy]

Are you using an R80.20 EA Gateway as well?

That looks like the correct configuration, but it's possible this is not functioning in the Public EA as of yet.

[Kris_Pellens]

Yes Dameon, we are using R80.20 EA; we hope R80.20 will be released soon, because we have to migrate our Cisco ASA 5585 appliances to Check Point 23800 before the end of the year. As soon as R80.20 is officially released, we can open TAC cases; at the moment, we can't.

Which one is the correct one, first (external) or second (internal + networks defined by routes) configuration? Please confirm.

In the example above, interface if3 can receive packets from private networks and public networks. How would you configure the topology for if3 then? Can you give an example for R80.10 and R80.20 (because I have no clue; and I can't find an example in Check Point's documentation)?

Many thanks.

[PhoneBoy]

if3 should be defined as External.

External really means "all IPs not defined as valid on other interfaces."

So, for example, if I have a gateway with:

• eth1: 192.168.1.1/24 (only this subnet behind the interface)
• eth2: 172.16.0.1/24 (Various subnets in the 172.16.0.0/16 range are reachable from this interface)
• eth3: 192.0.2.1/24 (Facing Internet)

The anti-spoofing configuration would be:

• eth1: Internal > Defined by IP and Netmask
• eth2: Internal > Specific (Network object that represents 172.16.0.0/16)
• eth3: External

This means that every IP that is not in 192.168.1.0/24 or 172.16.0.0/16 is considered valid on eth3 (regardless of whether it's a private IP or not).

This applies to all versions (including R80.20). 

Hope that makes things clear. 

[Timothy_Hall]

Although these commands have been previously disclosed, no anti-spoofing discussion would be complete without the real-time "panic button" gateway commands to temporarily disable anti-spoofing:

fw ctl set int fw_antispoofing_enabled 0

sim feature anti_spoofing off; fwaccel off; fwaccel on

Edit: Due to the changes introduced for SecureXL in R80.20+, the above commands (specifically the sim feature command) will only work on an R80.10 or earlier gateway.   For later versions see further down in this thread.

--
Second Edition of my "Max Power" Firewall Book
Now Availaible at http://www.maxpowerfirewalls.com

[PhoneBoy]

Agreed, I'm pretty sure these kernel variables didn't exist back in the day.

[Vladimir]

This has just saved me some time, thankfully in the lab environment.

BTW, I am seeing:  Command 'sim feature' has been replaced. Use 'fwaccel feature' instead.

[Timothy_Hall]

The ability to disable anti-spoofing "on the fly" in SecureXL has been reintroduced with the R80.30 gateway release, but at this time it only works on an R80.30 gateway that is using the new 3.10 kernel and on R80.20 Jumbo Take 103+.  I can't see any reason why the 3.10 kernel would be required for this feature, so the relevant SecureXL kernel variable sim_anti_spoofing_enabled may well be retroactively introduced into R80.30 using the older 2.6.18 kernel in a future Jumbo HFA.  I'm assuming the R80.30 SIM code for kernel version 3.10 is on a separate track from the kernel 2.6.18 SIM code which would explain the discrepancy.

Without further ado, here are the commands I successfully tested in my lab to disable anti-spoofing "on the fly" for an R80.30 kernel version 3.10 gateway, or R80.20 Jumbo Take 103+:

fw  ctl  set  int  fw_antispoofing_enabled  0

Set operation succeeded

fw  ctl  set  int  sim_anti_spoofing_enabled  0  -a

SIM:
Set operation succeeded
FW:
kiss_params: failed to update VS0
Set operation failed: failed to get parameter sim_anti_spoofing_enabled
set: Operation failed: Invalid argument

Note that SecureXL does NOT need to be restarted with fwaccel off;fwaccel on for the SIM change to take effect like it did in R80.10 and earlier with the sim feature command.

Also note the use of the new -a option which attempts to get or set a kernel variable in BOTH the Firewall Worker/Instances and the SIM driver (SND/IRQ) simultaneously like this, so errors on one side or the other will certainly be encountered:

fw  ctl  get  int  fw_antispoofing_enabled  -a

FW:
fw_antispoofing_enabled = 0
SIM:
Failed to get from ppak

fw  ctl  get  int  sim_anti_spoofing_enabled  -a

FW:
Get operation failed: failed to get parameter sim_anti_spoofing_enabled
SIM:
sim_anti_spoofing_enabled = 0

This new -a option for fw ctl set/get was introduced in R80.20, and for the first time allows SIM/SecureXL variables to be queried for their live values and even be modified "on the fly" which was not possible in R80.10 and earlier; to modify SIM/SecureXL variables in those earlier releases the new SIM variable values had to be placed in the simkern.conf file and the firewall rebooted.

[Iain_King]

The steps taken in R80 towards zone-ized anti-spoofing groups is a positive direction imho, the ease of use I have found with the change is welcome. Why uRPF has been so difficult and complicated to implement here has always been a mystery for me.

Having said that, using dynamic routing on firewalls has been controversial for as long as I've reluctantly been labelled 'a firewall guy' (too long a time). I think we all know the risks inherent in security zones that can be dynamically changed through triggers via adjacent advertisements and the implications of a compromised router on access control under those circumstances.

The integration of uRPF and OSPF has long been useful for for rapid first hop dropping of virus/worm infected hosts in operations situations (where injecting a null route into the table is used to black hole infected hosts quickly). I've seen this done when firewalls are overloaded and unresponsive (it's quick, effective and less resource cost to block at the L3 switch).

I wonder if a similar use case could be made here with these features (for legitimate or nefarious purposes).