Palo Alto Firewall: External Dynamic Lists

I recently attended Palo Alto’s annual Ignite conference for the first time.  It was a great experience for learning about best practices and networking with others.  One of the things I learned was Palo Alto’s way of handling basic threat intelligence feeds.  When I say basic I’m referring to IPs, domains, and URLs.

It turns out that with an active Threat Prevention license, you’ll immediately get access to two Palo Alto-provided threat intelligence feeds.  I’ve listed them below with their provided-descriptions.:

  • Palo Alto Networks – Known malicious IP addresses: Malicious IP addresses that are currently used almost exclusively by malicious actors for malware distribution, command-and-control, or for launching various attacks.
  • Palo Alto Networks – High risk IP addresses: High risk IP addresses, shared IP addresses that have recently been featured in threat activity advisories distributed by high-trust organizations, however Palo Alto Networks does not have direct evidence of maliciousness.

There are of course a myriad of these types of malicious IP lists available.  Lucky for us, someone has compiled several of these sources and formatted the data such that Palo Alto can properly ingest them.  I added most of these to my own configuration and added one from’s Ransomeware Tracker.

It’s pretty easy to add these lists, just follow the steps below.

Create External Dynamic Lists

  1. Once logged into the Palo Alto firewall, navigate to Objects -> External Dynamic Lists.
  2. If you have a valid Threat Prevention license, you should already see the two Palo Alto-provided lists noted above.  Click Add to add a custom external dynamic list.
  3. Populate the required fields:
    • Name: Give a name for the list.
    • Type: Select the type of list, for this entry we’ll use IP List.
    • Description: Enter a helpful description for the list.
    • Source: This is the URL of the threat intelligence feed.  It is preferred that https URLs be used so that the feeds are not compromised in transit.  However, I did notice that the firewall would not properly download from the https-version of
    • Server Authentication: The Certificate Profile to authenticate to the Source. This is optional.
    • Repeat: The frequency for updating the list.  I’ve set all of mine to hourly.

    You can optionally click on Test Source URL to confirm that the firewall can successfully reach the URL.

  4. Once finished, click OK to save the new list.
  5. Repeat for any additional threat intelligence feeds you may have.
  6. Optional. Select a rule and click Import Now to download list data and verify everything is in working order.
  7. Commit the changes to save the configuration.

Note: There are limits to the list capacities.  At the time of this writing they are as follows:

  • IPs: 50,000
  • Predefined IPs: 20,000
  • Domains: 50,000
  • URLs: 50,000

Now that we’ve got our External Dynamic Lists created, we need to create a security policy rule that blocks traffic to the malicious IPs contained in these lists.

Create Security Policy Rule to block traffic to External Dynamic Lists

  1. Navigate to Policies -> Security and click Add.  First populate the General tab.
  2. In the Source tab, click Add to add your trusted internal zones and/or addresses.  In my case, my internal network is all within the Trust-L3 zone.
  3. In the Destination tab, click Add to your untrusted zones and addresses.  This step is critical as you’ll want to add both the zone AND the addresses from the External Dynamic Lists.  Completing only the Destination Zone and NOT the Destination Address will result in all outbound traffic from being blocked.  You probably don’t want that. 😛
    In my case, anything outside my internal network, namely the Internet, is referred to as the Untrust-L3 zone.  Under Destination Address, click Add and find the lists we created earlier under the External Dynamic List section.

    Repeat this step for each of the lists you’d like to add.

  4. In the Actions tab, select Deny under Action Setting.
  5. Click OK to save the new policy rule.  Place your new rule at the top of all other rules so that it supersedes any Internet outbound rules.
  6. Commit the changes to save the configuration.
  7. Now let’s test our rule to ensure we’re blocking traffic.  I’ve taken one of the IPs from the list above and tried pinging it.
➜ ~ ping
PING ( 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3

Looks pretty good from the client side.  Let’s see what the firewall sees.

Success!  Looks like everything’s working as expected.  Assuming our External Dynamic Lists are of high quality, any hits to this rule should be a strong indicator of possible compromise on our network.  We could update our security policy rule to send us an email anytime this rule was triggered.

To take this even further, you could sign up for an open source threat intelligence repository like Critical Stack’s Intel feeds and write a script to download this data, format it for Palo Alto, and then use Palo Alto’s API to automatically generate and update these lists in your firewall.  Perhaps a future blog post. 🙂


Palo Alto Firewall on a home network

My very own Palo Alto!

I’m a big fan of Palo Alto Networks firewalls due to their focus on security and giving both network and security professionals incredible insight into network traffic.  To improve my understanding of these firewalls, I recently purchased my very own PA-220 for my home network.  I successfully set it up but not without running into a few issues.  Since it took a fair amount of Google-searching to troubleshoot and resolve the issues, I’m sharing my experiences below in the hopes that it will help others.

Initial Setup

Problem: Configure Outbound Internet Security Policy

For initial setup, I highly recommend using the “Setting Up the PA-200 for Home and Small Office” guide, found on Palo Alto’s “Live Community” site.  For the most part, I followed it exactly except the section regarding the outbound internet security policy.  When creating this policy, the guide does not mention editing the “Service/URL Category” tab.  Notably, if you do not edit this, Palo Alto defaults to the “application-default” option as shown below.

What does this mean?  From the firewall’s help page it states that: The selected applications are allowed or denied only on their default ports defined by Palo Alto Networks. This option is recommended for allow policies because it prevents applications from running on unusual ports and protocol which, if not intentional, can be a sign of undesired application behavior and usage.

This sounds reasonable, except that it broke my ability to use and more importantly, broke my Apple/iOS Mail clients from connecting to Gmail via IMAP.  It turns out, that those apparently don’t use what Palo Alto thinks are “application-default” ports.  Unless you’re cool with that behavior, you’ll actually want to select “any” instead.


Problem: DNS Proxy

Like most people, I was using my wireless router as my DNS server for resolving hosts on my local network.  It’s not critical as there are only a few devices on my home network, but it is convenient to have a few “A records” configured.  Wanting to maintain this same functionality, I configured my Palo Alto firewall using the “DNS Proxy” option.

After a hard day’s work, we decided to watch some Netflix and I noticed the Netflix app on my TV and Apple TV no longer worked.  Interestingly, there was no issue streaming Netflix on my laptop, iPhone, or iPad.  After much searching, I found a helpful “Live Community” post regarding DNS Proxy as the possible issue.

It turns out that DNS Proxy, at least on PAN-OS 8.x (which is what the PA-220 ships with as of today), does not play well with Netflix.  As soon as I disabled DNS Proxy, Netflix streamed without issue.

Online Console Gaming

Problem: NAT Dynamic IP & Port Policy

Anyone who knows me knows I’m a giant Nintendo fanboy.  Shortly after setting up the Palo Alto firewall, I decided to play some online Mario Kart, only to find that my new Nintendo Switch would no longer connect.  Sadface.

It turns out that Palo Alto firewalls do not support “Universal Plug and Play” (UPnP) which had allowed me to connect easily on my consumer-grade wireless router.  This makes sense from an enterprise-grade firewall perspective as you would want to explicitly control what’s allowed inside and outside of your network.

Back to searching and I found a helpful comment on a post discussing how Palo Alto handles game console traffic.  It turns out you need to create a specific NAT policy ahead of your default internet outbound NAT rule. This NAT policy should specify the IP of your video game console as the source address and use only “dynamic-ip” source translation instead of “dynamic-ip-and-port” source translation.

So that I don’t have to periodically update the Nintendo Switch’s source address in the NAT rule due to DHCP, I configured the firewall’s DHCP relay to always assign my Switch the same IP and created an Address Object on the firewall using this same IP.  See the screenshot below for how the NAT policies ultimately looked in the end.

Ring Video Doorbell Pro

Problem: Session Initiation Protocol (SIP) Application Layer Gateway (ALG)

At home, I use a Ring Video Doorbell Pro and it has worked great for seeing who’s at our front door whether we’re at home or not.  Ring will send push notification alerts whenever it detects motion or if someone presses the doorbell.  From the alert you can then view a live stream of who is at your door.  You can also trigger the live stream on-demand.

I noticed that once the Palo Alto was in place, the live streams, whether based on alerts or on-demand, would always hang and never load.  After a few minutes I’d be able to watch the recorded video after the fact.  Not ideal.

This particular problem took the most time to figure out.  I found a few articles that spoke of similar issues but nothing quite exactly what I was seeing.  I started playing around with the on-demand live stream functionality and observing the traffic in the firewall’s Monitor tab to see what type of traffic was being generated and if anything was being blocked.  At first I thought it might’ve been a NAT issue, similar to what I saw with my Nintendo Switch.

Eventually, I noticed that Ring used the session initiation protocol (SIP) when creating these live stream communications.  Looking through the “Live Community” again, I found an article regarding how to disable SIP Application Layer Gateway (ALG) in Palo Alto.  It mentioned that SIP ALG can cause issues with certain SIP implementations.  Figuring I had nothing to lose I followed the steps and lo and behold, live streaming worked again.  Yay.


I hope these tips help anyone else that was crazy enough to purchase a Palo Alto firewall for their home network.  I’ll continue to post more about my experience if I run into more issues or test out additional functionality and integrations.


The Missing CISSP Domain

In the security world, the CISSP is the gold standard certification for information security professionals.  The exam is incredibly broad covering a number of domains.  However, over the course of my career I’ve realized that there’s a key domain that’s missing.

Oh really, Eric?  And what might that domain be?

Securing relationships.

Huh?  Securing relationships?  What does that even mean, Eric?  Have you finally gone security-mad?

Ok, hear me out.  What I’m referring to specifically is, developing and cultivating relationships across teams outside of security.  For a team often viewed as curmudgeonly, elitist, and an all-around roadblock to the business, it is imperative that significant effort is made reaching out and “securing relationships.”

A major function of security is performing risk assessments so that the business can make informed decisions.  In that sense, security is serving the business and should have a service-oriented mindset.  To that end, rather than simply saying no or objecting to a request, consider an alternative approach.  Patiently educate others on the risks of a given situation, suggest a secure solution that meets or beats expectations, and always go the extra mile to ensure that any given recommendation continues to be the optimal method.  Yes, it takes more time and effort and goes against our natural I-hate-everything-especially-people M.O. but the payoff will be more than worth it.  While the business won’t always do exactly what we want, folks will be more willing to engage and listen to us if we offer reasonable solutions versus the traditional high-and-mighty-security-rage-and-hate.

This is certainly easier if you’re naturally social to begin with.  And I know, we’re 1337 haxx0rs too busy saving the world to be bothered to look up from our computers.  But it turns out, if we leave our desks once in a while to say hello or smile and to casually discuss security in a real-world context with someone who may not be as knowledgeable, we might just find that people are more interested and willing to support security than we may think.  And ultimately, this leads to more security advocates, more support for our security (and career!) goals, and yes a more secure workplace.  Plus, you might even make a friend or two. 😛

I think security professionals often operate with a superiority complex.  We wrongly assume everyone knows and defaults to the “secure choice” and that anyone who doesn’t is “an idiot.”  We rant that we’re the last to be told and first to be blamed for anything and everything (well maybe that’s kinda true… :P).  But what are we doing to help this?  What makes us think that internalizing the frustration, becoming more snarky, and fitting the classic grumpy security guy/girl stereotype solves this?

The truth is, if we want people to appreciate security and what we do, we’ve got to return the favor and recognize that what others do is equally valuable and work with them to educate and demonstrate how security can positively impact their own work.  I honestly believe that most people want to be more secure, they just don’t know how.  Typically, people don’t make the “secure choice” simply because no one’s ever illustrated the risks and outlined recommendations in a way that’s understandable to them.  Ironically, people are intimidated to ask the security personnel (you know, the team paid to secure things all day) how they can help the company be more secure and it’s often a result of stereotypes that we as security professionals do little to change.

So I urge us to recognize our core strengths and use those to develop relationships.  Personally, I use humor and my love of teaching to help make security fun and less intimidating.  In my current position, through both effort and chance, I’ve had the opportunity to meet and work with a large part of the organization.  I’ve made the most of this by making it a point to develop friendly and strong relationships with teams outside security.  It has led to these same teams reporting possible security incidents, asking for security’s opinion before moving forward, and spreading the good security word to create a security-minded culture.  It seems obvious, but as with most things, it takes significant effort.

Speaking of security-minded cultures, a great way to secure relationships is through awareness trainings.  In a future post, I’ll share my thoughts on the importance of security awareness trainings and how to deliver these in an effective manner.