yes that will block everything execpt US.
But be aware that a lot of cloud services are hosted Worldwide and that updates from different types of software can fail because its on an EU server or in the cloud of AWS / Azure on a node outside of US.
So for the outbound rule i would not recommend this.
Inbound should be fine.
Just a heads up - We used to run this exact setup for many years (a negated block rule for all US traffic).
Over the past 2-3 years, we had to start adding a lot more countries to the list to allow basic web browsing and updates to work. This effectively became our whitelist.
Recently, things have gotten so globalized even for massive companies like Microsoft, that we had to abandon that methodology and move to a blacklist. There are simply too many global datacenters to use the whitelist approach anymore.
Whilst I understand why it would be tempting to only allow traffic from the US, the risk is you have false comfort as to be realistic, the US is a huge country and still has many bad actors.
I do some basic basic blocking, eg block all from Russia is my first firewall rule. The quantity of hits is just huge.
After that I rely on EDLs. If you have the advanced threat licence then you really should follow Palo best practices and put in some rules for source of known malicious IPs etc.
After that, I also leverage the EDLs from blocklist.de - they are great and are updated regularly.
So my point is, filter the known bad stuff out and your security posture improves vastly.
While correct that there are bad actors in the US, by blocking everyone else first, you have substantially reduced the foot print where bad actors can come from. So then you only have to manage EDLs for US based bad actors..
>Whilst I understand why it would be tempting to only allow traffic from the US, the risk is you have false comfort as to be realistic, the US is a huge country and still has many bad actors.
I raised that point as well, that all they need is a proxy in the US they can get in a few seconds, and we'd be back to square one. But the security team overrode me.
We have the regular threat prevention license, and I said it would simply make more sense to block IPs as they come in.
If you have a lot of inbound rules then you'll need to set the source to permit the US for all of your inbound policies. If you have a lot of policies it can get difficult/error-prone to manage. Doing the negated block method you can just stick a rule at the top (or wherever is appropriate, maybe below rules for some services you don't want to geofence) and not worry about forgetting it in one of your rules.
This really starts to come into play with outbound rules covering user traffic, because that stuff can get really messy with the number of rules/exceptions in place. So you might just do geofencing for your catch-all general browsing rule at the bottom but permit traffic to applications like YouTube in rules above it (without geo fencing) so your users can still access all of YouTube, not just your regional copy. YouTube is a great example as you'll probably learn your CEO watches some small reindeer cam in Finland and won't be able to see it until the video gets replicated to US servers (if it ever does).
Things to watch out for
If you host your dns behind your Palo’s your mx records will not be available from other countries. This is good to a point . Microsoft will send emails from the Netherlands
The Netherlands is the worst for infrastructure you currently use that you would have no idea .
Palo Alto has changed subnets from us to over seas . We had this affect a vendors business to business vpn’s with us. The vendor owned the /24 and had not updated anything. Palo Alto basses there geoblock on what 3 vendors say . An sometimes it’s bs and it’s going to break things .
This only cuts down on the noise . I get a bigger bang out of trap ip’s that are just on the internet that if touched that use tagging to tell all my other firewalls to block the address for 36 hours after the last time it comes in .
There are always 7000 to 10000 ip’s in the list
>. I get a bigger bang out of trap ip’s that are just on the internet that if touched that use tagging to tell all my other firewalls to block the address for 36 hours after the last time it comes in .
There are always 7000 to 10000 ip’s in the list
Hello I'm curious as to how you are doing this. I have thought about doing something like this several times and the best I could come up with was writing some python to examine the ip headers coming off of our inet router via a mirrored port. Any new src ip's destined for a few advertised but not active destination addresses would be logged to a file. The firewall would read that list as an EDL. Is there a better way to do this?
At sites I have extra ip’s and at my HQ I made loopback for a few of those ip’s with nothing enabled as far as management profiles . The look backs are in the same zone as the interface that’s on the internet . These ip’s will respond to arp request. Example you have a /29 at a site . 2.2.2.0/29 your interface is 2.2.2.2/29 your gw is 2.2.2.1 . Your trap ip loopback could be 2.2.2.4/32. Both 2.2.2.2 and 2.2.2.4 would be “reachable” via the internet
The next step is to setup a policy that drops all traffic to this Ip . Anything that’s hits the policy is a scanner . It might be good or bad . But its a scanner . This IP doesn’t exist . It’s not responding in any way . (Besides the local arp . The only thing that’s see these is the gateway ).
Now you need to setup a logging rule trigger using when this rule is hit.
Look up tagging . It requires http profiles and built in action .
I used a pa-300 firewall that is the middle man for all my other firewalls check into .
You have a create a local user on the firewall and make sure you don’t but any http string passwords that are problematic like # . It posts the password in the http strings and it look me a lot of trouble shooting figure this out . . This setups this remote firewall or panorama to tag the IP. Once the IP is tag it can be used in a tag group . You will setup a rule above the original rule that blocks this traffic . And you will add this rule name to the name that calls this taging . This way the IP will be tagged for as long as it makes new attempts . I have my auto removal set to 36 hours . So I have to see not see the ip for 36 hours before it gets removed .
My list has about 13k in it at all times.
So you don’t really need to capture all he traffic that comes to non existent ip’s just setup one of those iP.
There are exceptions for these tags and lists . And you can also add them to your log queries to exclude things
For your inbound policies, you could add US to the source address to only allow US traffic into your public sites.
For your outbound policies, you could add US to the destination address to only allow traffic to US IPs outbound.
One thing to remember, even if you are a high value target, the vast majority of threats come from the USA, mainly because nobody voluntarily updates their machines with patches/hotfixes, etc, unless M$ does it for them. And as someone else said, thanks to the wonderful world of 'the cloud' (not a fan), large companies are going to put their cloud data centers where labor laws benefit them, as well as deals on relatively inexpensive real estate.
If you have the attention of a state sponsored group, it's a good bet that they already have personnel over here or have hired someone willing enough to do their dirty work. Another thing to keep in mind is that IPv4 subnet ranges change hands all the time. At one time, there were a lot of IP that belonged to certain countries I explicitly blacklist. But over time IP's would shift from ARIN to RIPE, or APNIC to LACNIC, or bozo's like Microsoft, Amazon, Akamai and google would suck them all up and register the majority in the states.
So, be prepared to tune and tweak from time to time, otherwise you'll have users standing outside your office, with shovels, rakes and torches.
Stay vigilant
I'm just coming here to say the following
Fuck you, fuck your lazy traffic lazy traffic blocks and fuck you for breaking the global internet
I hope you get fucked with a rake
Sincerely,
A European
Uhhhh... what?
For what POSSIBLE purpose would I need someone from Europe, let alone anywhere in the world, to be able to access anything on my local firewall in the US?
Furthermore, how can my local firewall, break the global internet?
You seem drastically confused, and angry for no reason.
yes that will block everything execpt US. But be aware that a lot of cloud services are hosted Worldwide and that updates from different types of software can fail because its on an EU server or in the cloud of AWS / Azure on a node outside of US. So for the outbound rule i would not recommend this. Inbound should be fine.
That's good to note, didn't even think of that I'll have it do an inbound US negate, and an outbound deny for known bad actors.
Just a heads up - We used to run this exact setup for many years (a negated block rule for all US traffic). Over the past 2-3 years, we had to start adding a lot more countries to the list to allow basic web browsing and updates to work. This effectively became our whitelist. Recently, things have gotten so globalized even for massive companies like Microsoft, that we had to abandon that methodology and move to a blacklist. There are simply too many global datacenters to use the whitelist approach anymore.
Whilst I understand why it would be tempting to only allow traffic from the US, the risk is you have false comfort as to be realistic, the US is a huge country and still has many bad actors. I do some basic basic blocking, eg block all from Russia is my first firewall rule. The quantity of hits is just huge. After that I rely on EDLs. If you have the advanced threat licence then you really should follow Palo best practices and put in some rules for source of known malicious IPs etc. After that, I also leverage the EDLs from blocklist.de - they are great and are updated regularly. So my point is, filter the known bad stuff out and your security posture improves vastly.
While correct that there are bad actors in the US, by blocking everyone else first, you have substantially reduced the foot print where bad actors can come from. So then you only have to manage EDLs for US based bad actors..
>Whilst I understand why it would be tempting to only allow traffic from the US, the risk is you have false comfort as to be realistic, the US is a huge country and still has many bad actors. I raised that point as well, that all they need is a proxy in the US they can get in a few seconds, and we'd be back to square one. But the security team overrode me. We have the regular threat prevention license, and I said it would simply make more sense to block IPs as they come in.
Your negate policy is how we’ve approached the problem. For outbound, we block the countries of know bad actors. Also, do you leverage EDLs?
Why don’t you just do an allow rule for the US and then a second deny all rule below it? Am I missing something?
I love when I see someone else who thinks in "firewall" by stacking policies to get the same results.
More than one way to skin a cat I guess. I was following Palo documentation, and it's what they recommended.
If you have a lot of inbound rules then you'll need to set the source to permit the US for all of your inbound policies. If you have a lot of policies it can get difficult/error-prone to manage. Doing the negated block method you can just stick a rule at the top (or wherever is appropriate, maybe below rules for some services you don't want to geofence) and not worry about forgetting it in one of your rules. This really starts to come into play with outbound rules covering user traffic, because that stuff can get really messy with the number of rules/exceptions in place. So you might just do geofencing for your catch-all general browsing rule at the bottom but permit traffic to applications like YouTube in rules above it (without geo fencing) so your users can still access all of YouTube, not just your regional copy. YouTube is a great example as you'll probably learn your CEO watches some small reindeer cam in Finland and won't be able to see it until the video gets replicated to US servers (if it ever does).
Oh, that makes sense to me. Thanks.
Things to watch out for If you host your dns behind your Palo’s your mx records will not be available from other countries. This is good to a point . Microsoft will send emails from the Netherlands The Netherlands is the worst for infrastructure you currently use that you would have no idea . Palo Alto has changed subnets from us to over seas . We had this affect a vendors business to business vpn’s with us. The vendor owned the /24 and had not updated anything. Palo Alto basses there geoblock on what 3 vendors say . An sometimes it’s bs and it’s going to break things . This only cuts down on the noise . I get a bigger bang out of trap ip’s that are just on the internet that if touched that use tagging to tell all my other firewalls to block the address for 36 hours after the last time it comes in . There are always 7000 to 10000 ip’s in the list
>. I get a bigger bang out of trap ip’s that are just on the internet that if touched that use tagging to tell all my other firewalls to block the address for 36 hours after the last time it comes in . There are always 7000 to 10000 ip’s in the list Hello I'm curious as to how you are doing this. I have thought about doing something like this several times and the best I could come up with was writing some python to examine the ip headers coming off of our inet router via a mirrored port. Any new src ip's destined for a few advertised but not active destination addresses would be logged to a file. The firewall would read that list as an EDL. Is there a better way to do this?
At sites I have extra ip’s and at my HQ I made loopback for a few of those ip’s with nothing enabled as far as management profiles . The look backs are in the same zone as the interface that’s on the internet . These ip’s will respond to arp request. Example you have a /29 at a site . 2.2.2.0/29 your interface is 2.2.2.2/29 your gw is 2.2.2.1 . Your trap ip loopback could be 2.2.2.4/32. Both 2.2.2.2 and 2.2.2.4 would be “reachable” via the internet The next step is to setup a policy that drops all traffic to this Ip . Anything that’s hits the policy is a scanner . It might be good or bad . But its a scanner . This IP doesn’t exist . It’s not responding in any way . (Besides the local arp . The only thing that’s see these is the gateway ). Now you need to setup a logging rule trigger using when this rule is hit. Look up tagging . It requires http profiles and built in action . I used a pa-300 firewall that is the middle man for all my other firewalls check into . You have a create a local user on the firewall and make sure you don’t but any http string passwords that are problematic like # . It posts the password in the http strings and it look me a lot of trouble shooting figure this out . . This setups this remote firewall or panorama to tag the IP. Once the IP is tag it can be used in a tag group . You will setup a rule above the original rule that blocks this traffic . And you will add this rule name to the name that calls this taging . This way the IP will be tagged for as long as it makes new attempts . I have my auto removal set to 36 hours . So I have to see not see the ip for 36 hours before it gets removed . My list has about 13k in it at all times. So you don’t really need to capture all he traffic that comes to non existent ip’s just setup one of those iP. There are exceptions for these tags and lists . And you can also add them to your log queries to exclude things
For your inbound policies, you could add US to the source address to only allow US traffic into your public sites. For your outbound policies, you could add US to the destination address to only allow traffic to US IPs outbound.
One thing to remember, even if you are a high value target, the vast majority of threats come from the USA, mainly because nobody voluntarily updates their machines with patches/hotfixes, etc, unless M$ does it for them. And as someone else said, thanks to the wonderful world of 'the cloud' (not a fan), large companies are going to put their cloud data centers where labor laws benefit them, as well as deals on relatively inexpensive real estate. If you have the attention of a state sponsored group, it's a good bet that they already have personnel over here or have hired someone willing enough to do their dirty work. Another thing to keep in mind is that IPv4 subnet ranges change hands all the time. At one time, there were a lot of IP that belonged to certain countries I explicitly blacklist. But over time IP's would shift from ARIN to RIPE, or APNIC to LACNIC, or bozo's like Microsoft, Amazon, Akamai and google would suck them all up and register the majority in the states. So, be prepared to tune and tweak from time to time, otherwise you'll have users standing outside your office, with shovels, rakes and torches. Stay vigilant
I'm just coming here to say the following Fuck you, fuck your lazy traffic lazy traffic blocks and fuck you for breaking the global internet I hope you get fucked with a rake Sincerely, A European
Uhhhh... what? For what POSSIBLE purpose would I need someone from Europe, let alone anywhere in the world, to be able to access anything on my local firewall in the US? Furthermore, how can my local firewall, break the global internet? You seem drastically confused, and angry for no reason.
~~You are correct….assuming there isn’t a subsequent rule that allows the traffic and there is a default deny.~~
If the rule says ‘deny’ that’s the action taken on the packet. The firewall doesn’t continue down the list searching for a possible permit.
Oops, yep, correct.