Dameon Welch-Abernathy

A Primer on Anti-Spoofing

Discussion created by Dameon Welch-Abernathy Moderator on Aug 28, 2018
Latest reply on Sep 10, 2018 by Iain King

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:

 

Outcomes