Subscribing to the DShield Top 20 on a Palo Alto Networks Firewall

L4 Transporter

This was originally posted on InfoSec Community Forums by Richard Porter.


This question has come up a few times in my recent travels and it seemed like something to post for our readers, hope you find it useful, comments welcome!



This will walk you through the steps of subscribing to our top 20 block list on a Palo Alto Networks firewall. It will also show you how to make a rule using the external block list. You can create a rule to block both inbound and outbound, however these instructions include only an outbound rule. Any traffic transiting outbound from an internal host to this list on the top 20 should be considered suspect, prevented, and then investigated.


Our DShield Top 20 List can always be found here:

The source for the parsed and Palo Alto Networks formatted version of the DShield block list can be found here:


The full source of external block lists:


Creating the External Block List Subscription

  1. Go to Objects > Dynamic Block List.
  2. Click Add.
  3. Name the External Block List Subscription, DShield Recommended Block List for example.
    Copy and paste it into the source block.
  4. Click Test Source URL.

You have just subscribed to an External Block List (EBL). Once an hour this subscription will poll the external block source and automatically update the subscription. This does not actually apply the feed to any rules or polices, in the next section we will create an outbound blocking rule looking for Indicators of Compromise.


Creating the Outbound Rule


There are several ways to use an EBL. One of the most common is to block/restrict on inbound flows, and although this should be done we will be using a different method for this example. In the creating the outbound rule section we will block and alert on outbound traffic from our L3-Trust to L3-Untrust (basically from our trusted internal zone to our untrusted external zone, your naming convention may differ). This will serve as a possible indicator of compromise (IoC).

On the topic of of IoC, let’s be clear that this can only serve as a possible indicator of compromise. Miliage may vary depending on your EBL. The DShield EBL (the EBL selected for this lab) list is hosted by the Internet Storm Center that has been maintained for over a decade. Any communication to those hosts should be consider suspect, however not a clear case for declaration of compromise. Regardless, it should be best current practice (BCP) to at least alert on this traffic outbound. Traffic from these hosts and netblocks inbound are largely considered noise. Any questions regarding the DShield Recommended Block list please direct them to For a history behind the DShield top 20 check out



If you miss step 6 you will shadow all your other rules and stop all traffic outbound in your environment, please pay CLOSE attention to step 6, YOU HAVE BEEN WARNED!!!! Do not miss this step. Also for troubleshooting reasons if all your traffic stops after this walk-though, you can disable the rule and troubleshoot your External Block List.

  1. Go to Policies > Security.
  2. Click Add.
  3. Give the Rule a Name, EBL DShield Rule for example.
  4. Under the source tab select L3-Trust or your trusted internal zone name. Remember this is an IoC rule, not just a normal block noise rule.
  5. Under the destination tab select L3-Untrust or your untrusted external zone.
  6. Under the destination tab in the destination address select the DShield EBL subscription. (DO NOT MISS THIS STEP!)
  7. Under the actions tab change allow to deny. Optionally you can set logging to an external syslog here as well.
  8. Click okay.
  9. Highlight the new rule, click move, which can be found at the bottom of the GUI, and select top. We are moving this rule to the top as we want to catch all attempts to reach the EBL outbound before any other rule is triggered
  10. Commit

NOTE: if you receive warning as indicated in the screenshot check your internet connection as it indicates that the EBL was not reachable. Also, some EBL have maximum polling counts and only allow refresh every so often (e.g. 1 hour). This could have been triggered when you tested the URL connection. These are two reasons why your EBL may not be reachable.

It is also possible to check the EBL on the CLI:
> request system external-list refresh name


Congratulations, you have just created a rule using an External Block List (EBL). This walk-through rule is designed to provide an example of blocking outbound connections to known suspicious netblocks.


Check out this video:" width="420"

L1 Bithead

It was copied over, but something to be aware of...    In 6.x Panos, the default service/url category is 'application-default'.  So the way the original poster created this rule, they are only denying applications on their default ports.  If someone on the ISC block list tries to talk port 23 ssh to the endpoint, the firewall will happily allow it.  Application default for ssh is port tcp/22 only.

In general, having a deny with 'application-default' is a bad thing and maybe not what was intended.

L1 Bithead

Do you need to have Wildfire subscription to be able to implement this feature ?


Community Team Member

Sokonta, No. a Wildfire subscription is not needed for this, as this is not related to Wildfire in any way.

L4 Transporter

We have a high percentage of international students.  I am curious if this will affect them and how?

I quick filter on the first couple of lines does show some web browsing to some of those IPs


Community Team Member

If there are any URL's that those International Students will be visiting that are on the external block list, then this could be a problem.

But those are usually only questionable sites in the first place.. or some sites in China.

You would have to check those lists as well as the block list:

I honestly think that if they are doing work, then there should be no issues.

L6 Presenter

What about incoming connections from these sources ? The document describes a block rule for outgoing connections only. I've experienced brute force attacks from IP's in the DShield block list. I believe it'd be better to define two rules, one for inbound and one for outbound. Source Zone and Destination Zone both any on both rules. I would then add the DShield Dynamic Block List Address object as "Source Address" in the first rule, and "Destination Address" in the second rule.

Can the document be enriched to benefit from DShield for incoming connections ?

Community Team Member


Yes, I was able to confirm that you can use the a Dynamic list as a source in your rules.

Please see this document describing this:

Use a Dynamic Block List in Policy

I hope this helps.

L0 Member

Is anyone else having issues getting the block lists here to work properly?  Running

request system external-list show name [DBL Name] from the CLI gives this response: "Server error : external list file not found".  According to this document: Use a Dynamic Block List in Policy the format of these IPs needs /32 added to the end of single IP addresses.  As for the DShield list used in the example above, it is using IP ranges which according to the Use a Dynamic Block List in Policy, should work. I was able to use the Spamhaus DROP and EDROP list from the Spamhaus site successfully, and

L3 Networker

It is not May 24, 1985, I am not on my Commodore-64, C16, C128 nor 4+, I am not connected with my 300 BAUD modem  to Quantum Link for the hidden Usenet over NNTP alt.2600 groups?   It is 2018.  Why would a security company ever suggested anyone to pull security data over HTTP?   Why would one ever pull a dyamic block lists over HTTP?   And how can it be suggested to pull such a list from a generic 3rd party hosting site:  ?    Am I wrong, or should this data be encrypted behind an EV cert confirmed to actually be Palo Alto Networks?   


How do I actually know that Luigi Mori still works for Palo Alto Networks, that this is an official sanctioned feed and that someday these replicated feeds will not contain (or or and subsequently my FW is blocking everything?   Please tell me I'm being paranoid.


L7 Applicator


This is a fairly old article, and panwdbl is simply a collection of other BLs which I don't believe was ever actually sanctioned by Palo Alto Networks. Regardless there is now sanctioned Palo Alto lists included in recent software releases that are actually maintained by Palo Alto Networks, specifically 'Palo Alto Networks - Known malcious IP addresses' and 'Palo Alto Networks - High risk IP addresses'. 

Ask Questions Get Answers Join the Live Community