Ineffective IP spoofing protection

[SThatipelly]

I have IP spoofing protection enabled on PaloAlto but it is not effective due to the following reason:

My external Interface IP is 1.2.3.1/24 . The spoofed attacks are coming from a fictitious source IP for e.g. 1.2.3.25 destined to 1.2.3.50(web server). As per Palo's IP spoofing definition, this is not blocked because 1.2.3.25 is routable over that interface. I am considering to write an ACL on the neighboring router that says block all inbound connections with source IP in 1.2.3.0/24 subnet. 

Has anyone implemented this? Am I right in my approach?

Thanks.

[Remo]

Hi @SThatipelly 

Did you enable "Strict IP Address Check" or only "Spoofed IP address" in the packet based attack protection of the zone protection profile?

[SThatipelly]

@Remo I have none of them enabled. I was worried they may drop any legitimate traffic so, didn't enable them.

[Remo]

Hi @SThatipelly 

Now I am a little confused. Without these options, how did you expect the firewall to block spoofed connections?

[SThatipelly]

@Remo I understand but what I'm looking for is has anyone enabled this and observed such attacks getting dropped? as per the definition, those attempts will not be blocked by that IP spoofing protection feature. 

[Remo]

Hi @SThatipelly 

I made a short test (as so far I have never seen such a spoofing attack - or missed it when it happened 😛 ).

The setup is a pa-220 with a default route towards the internet. Then I have an internal interface with a public /24 IP range. The first test was without a zone protection. This traffic was allowed - as I expected - but the connection would never work as the destination server would send the response not back to the firewall as it would be an answer to an IP from the network where the server is located. So this scenario is only a problem because of DoS attacks or vulnerabilities that could be exploited with a single packet.

The next test was with the option enabled to drop spoofed IP address. This connections were dropped with the reason spoofed IP address. Then I also added the option for strict IP address check, but compared to the second test, this made no difference in my situation. Here is a screenshot that shows the dropped packets in the threat log (the first 4 or 5 were only with drop for spoofed IP addresses enabled):

So this option definately will work to drop connections from spoofed IP addresses and as long as the route table is correct (as I assume because otherwise you would have other problems in your network) it shouln't cause any issues.

[SThatipelly]

@Remo I greatly appreciate you taking time to test this. I see that is working just as described which is great however I have a concern here. So, some of my DMZ servers are in that public IP range and also a neighboring public router(outside the firewall) that has the  IP in that same public IP range. so, let's say there is a packet from that public router(1.2.3.10) destined to SNMP server(1.2.3.80). Does the IP spoofing prevent that traffic? if so, is there a way I can exclude that rather than putting in an additional security policy?

[Remo]

They are in the same IP range but in different subnets, right? For example you have the public IP range 1.2.3.0/24. The subnet between your router and the firewall is 1.2.3.0/28 and the servers are located in 1.2.3.64/26. Or at least something similar?

[SThatipelly]

Nope, they are in same IP range and subnet. My Outside interface is a /24 which hosts the public routers and public IPs for the DMZ servers. This is what throwing me off on the protection steps I need to take.

Should I simply put in a rule saying that traffic from all but few 1.2.3.x should be blocked to 1.2.3.0/24 on firewall?

[Remo · Accepted solution]

So you have this network between the router and the firewall and use the IPs for destination NAT to the servers which have private IP addresses?

Now I think I understand your problem and in this case - if you do not want to change a little bit in your setup - the ACL on the router probably is the best option with the downside that then you don't see these dropped connections in the threat log.

[SThatipelly]

Yeah, I think I'm left with that one option only for now.

Sorry for not wording the question properly. Thanks so much for your help.