- CheckMates
- :
- Products
- :
- Quantum
- :
- SMB Gateways (Spark)
- :
- Re: Anti-Spoofing detection
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anti-Spoofing detection
We've systems in the subnet A.A.A.A which is not directly connected with the firewall. While generating traffic from those systems (A.A.A.A) to servers behind the firewall (B.B.B.B), firewall blocks the traffic with the reason "anti spoofing". After disabling anti-spoofing feature, it's allowed.
Hope, Anti-Spoofing detects if a packet with an IP address that is behind a certain interface, arrives from a different interface. In our topology, network A.A.A.A not behind any firewall interface, so why we're getting anti-spoofing detect. Attached our topology.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
TAC unable to find root cause of the issue. They recommended to upgrade the firewall version. After upgraded firewall to latest version, issue got resolved.
Thanks all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anti spoofing verify that each packet arrived with src IP is really configured to be behind the ingress interface.
so if A.A.A.A arriving to the FW from the left interface in diagram, you need to enter this interface in smartconsole (assuming you are centrally managed) , and configure inside the networks behind this interface (the point to point + any subnets behind it).
any other subnets that not explicitly configured would expect to arrive only via the external interfaces.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Amir,
So you mean, all the subnets which is not directly connected with firewall like A.A.A.A will be detected as Spoof?
Also, our quantum spark 1600 security appliances is locally managed, how to permit the external subnets like A.A.A.A in locally managed firewall?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think it uses the routing table also as information for AS. So if you add the networks there the will be allowed.
I cannot find it in documentation so I dont have an example.
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lesley,
For return traffic, I already have static route to A.A.A.A subnet with the next hop as X.X.X.1. But still the traffic detected as Spoof.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You mention "network A.A.A.A not behind any firewall interface," -- for the purposes of anti-spoofing, A.A.A.A is behind your X.X.X.2 interface.
The anti-spoofing configuration is typically going to be consistent with your routing table as far as what network topology is defined "behind" which interfaces.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think, anti-spoofing is evaluating the traffic based on interface type. By default external interface will allow all the external traffic except internal interface subnet and internal interface permit only directly connected network.
We are locally managing the firewall, Hence we unable to select interface type. It's undefined. So how, Anti spoof evaluate traffic from undefined interface? May be it's considering undefined interface as Internal?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You need to ensure routes are defined for all subnets that are connected to the LAN and/or DMZ interface (directly or via another hop).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please provide the firmware version and routing table details as relevant to your example?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Chris,
Details given below.
Firmware version :- R81.10.07
FW-1> show route
Codes: C - Connected, S - Static, R - RIP, B - BGP (D - Default),
O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA),
A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed,
NP - NAT Pool, U - Unreachable, i - Inactive
C B.B.B.96/28 is directly connected, LANBOND0.108
LANBOND0.108
C X.X.X.0/29 is directly connected, LANBOND1
LANBOND1
S A.A.A.0/24 via X.X.X.1, LANBOND1, cost 0, age 3953839
S Y.Y.Y.8/32 via B.B.B.110, LANBOND0.108, cost 0, age 3953839
C 127.0.0.0/8 is directly connected, lo
lo
FW-1>
Source :- A.A.A.19
Destination :- B.B.B.100,
Source :- A.A.A.19
Destination :- Y.Y.Y.8
Both traffic flow detected by AS and dropped.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are all the concerned addresses from RFC1918 space?
When practical I would also recommend upgrading to R81.10.08 or higher.
I feel like we're otherwise missing something here and perhaps it's something that would be more easily navigated via a remote session with TAC.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
TAC unable to find root cause of the issue. They recommended to upgrade the firewall version. After upgraded firewall to latest version, issue got resolved.
Thanks all.
