Are you a member of CheckMates?
×
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
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:
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:
- The diagram depicted above is a VSX/VSLS cluster.
- The name of the gateway with interfaces if1 and if2 is vs1. if1 is connected to an ISP router.
- The name of the gateway with interfaces if3 and if4 is vs2.
- OSPF is configured for both vs1 and vs2.
- Routes towards Internet are advertised on both vs1 and vs2: O E 0.0.0.0/0 via 192.168.1.250
Questions:
- For VSX/VSLS, could dynamic routing define the anti-spoofing configuration in R80.20?
- 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.
.png "Wolfgang"){kind=avatar}
