Blocking most of the world using the negate source

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Blocking most of the world using the negate source

L1 Bithead

Based on this doc - https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/policy/security-policy/create-a-security-p...
I want to create a policy that blocks all traffic from every country but the US, Canada, UK and Netherlands. In order to do that, I add to the source those 4 countries and then select the negate box. Seems simple enough.
My question comes from the note on step 3 item 2 that states:

"If you decide to Negate a region as a Source Address, ensure that all regions that contain private IP addresses are added to the Source Address to avoid connectivity loss between those private IP addresses."
I don't believe that we have any external traffic from the private IP addresses that aren't encapsulated in a GP tunnel, but to be extra sure, is it just a matter of adding the standard private ranges to the source list along with the countries?
Thanks!
See my proposed rule below.

Block_all_countries_BUT {
target {
negate no;
}
to trust;
from untrust;
source [ 10.0.0.0-10.255.255.255 172.16.0.0-172.31.255.255 192.168.0.0-192.168.255.255 CA GB NL US];
destination any;
source-user any;
category any;
application any;
service any;
hip-profiles any;
tag Inbound;
action deny;
rule-type universal;
negate-source yes;
description "This deny rule blocks any traffic NOT from the US, CA, GB (Great Britain), the Netherlands and standard private IP ranges by utilizing the Negate parameter";
log-setting Logger;
disabled no;

1 accepted solution

Accepted Solutions

L7 Applicator

Hi @JPhilip 

For connections from the internet you do not need to add private IP adresses. There never will be a situation where you have incoming connections from RFC1918 addresses.

 

My advice in general would be: use an allowlist approach and not a blocklist. This means in the rules where you allow incoming connections specify the countries that you want to allow. Of course your rule will do the job, but instead of the action deny, configure it to drop to have a "stealth" mode because with deny the firewall sends back a tcp-rst.

View solution in original post

5 REPLIES 5

L7 Applicator

Hi @JPhilip 

For connections from the internet you do not need to add private IP adresses. There never will be a situation where you have incoming connections from RFC1918 addresses.

 

My advice in general would be: use an allowlist approach and not a blocklist. This means in the rules where you allow incoming connections specify the countries that you want to allow. Of course your rule will do the job, but instead of the action deny, configure it to drop to have a "stealth" mode because with deny the firewall sends back a tcp-rst.

Thanks for confirming what my aging brain knew under the cobwebs.
As for the general advice, is that because the allow rules are easier to read and follow? Or, if not that, then why?

I just personally think it is the better way to only allow the traffic that you want to have and everything else then hits the drop all rule at the end of the policy instead of mixing this with drop rules higher in the ruleset or at the top of it.

 

But the one with the deny action you should consider I think, or is there a reason why you choose the deny action?

I'm definitely taking your suggestion for the drop instead of deny. Great idea.
As for the policy preference, I like the idea of blocking all foreign traffic at the top of the list as the firewall then doesn't have to process those packets through all the other rules. It just drops them right away and therefore there is much less burden on the system. 

Unless you have thousands of rules the precessing burden for this isn't that big. Even when you dig deep into the debug logs the difference in processing time will not really increase. But I get your point and in this situation maybe you want to check the dos rules. Create a dos rule that blocks the traffic from everything else than the countries you want and you can block this traffic even earlier in the traffic processing stages.

  • 1 accepted solution
  • 9883 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!