cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question
Admin
Admin

A Primer on Anti-Spoofing

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       <qe0 proto tcp src jungleman dst kyle service telnet s_port 2390 len 48 rule 0

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       <qe0 proto tcp src jungleman dst kyle service telnet s_port 2390 len 48 rule 0

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 will be an option to have dynamic routing define the anti-spoofing configuration.

You can see this option in R80.20.M1:

13 Replies

Re: A Primer on Anti-Spoofing

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

Finally!

Danny
Pearl

Re: A Primer on Anti-Spoofing

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

Admin
Admin

Re: A Primer on Anti-Spoofing

We need more Production EA customers Smiley Happy

Vladimir
Pearl

Re: A Primer on Anti-Spoofing

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
Silver

Re: A Primer on Anti-Spoofing

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.

0 Kudos

Re: A Primer on Anti-Spoofing

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:

Preventing IP Spoofing

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.

0 Kudos
Admin
Admin

Re: A Primer on Anti-Spoofing

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.

0 Kudos

Re: A Primer on Anti-Spoofing

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.

0 Kudos
Admin
Admin

Re: A Primer on Anti-Spoofing

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. 

Re: A Primer on Anti-Spoofing

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
 
--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com
Admin
Admin

Re: A Primer on Anti-Spoofing

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

0 Kudos
Vladimir
Pearl

Re: A Primer on Anti-Spoofing

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.

0 Kudos
Iain_King
Copper

Re: A Primer on Anti-Spoofing

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).

0 Kudos