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 abuse.ch’s Ransomeware Tracker.
It’s pretty easy to add these lists, just follow the steps below.
Create External Dynamic Lists
- Once logged into the Palo Alto firewall, navigate to Objects -> External Dynamic Lists.
- 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.
- 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 ransomwaretracker.abuse.ch.
- 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.
- Once finished, click OK to save the new list.
- Repeat for any additional threat intelligence feeds you may have.
- Optional. Select a rule and click Import Now to download list data and verify everything is in working order.
- 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
- Navigate to Policies -> Security and click Add. First populate the General tab.
- 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.
- 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.
- In the Actions tab, select Deny under Action Setting.
- 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.
- Commit the changes to save the configuration.
- 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 184.108.40.206 PING 220.127.116.11 (18.104.22.168): 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. 🙂
I use SiteGround for web hosting. Performance and customer service are top notch. Quick and easy https implementation via built-in Let's Encrypt integration. I highly recommend giving them a try. 🙂