Posts tagged ‘Palo Alto’

Adventures in DNS

I just posted about my new PA-220 firewall and mentioned URL filtering.  I have a number of categories blocked, including web-advertising, adult content, malware, etc.  But you can always make something better, right?

The PA-220 has a feature to enforce safe search with various search engines.  Unfortunately, it seems to not work very well on my iPhone, or in Safari on my Mac.  It could be the 8.0.2 firmware, or perhaps it’s something that I’m doing wrong.  In any case, I wanted to fix it, as it was annoying.

Both Google and Bing support a feature to enable Safe Search for your network via DNS.  What you have to do is, when someone requests, make your DNS return a CNAME record for  While this might sound easy, as I discovered, its a bit more complex than perhaps it should be.

First, the DNS proxy feature in my PA-220 does support configuring static entries, so I could add an entry for, but I can’t set it to CNAMEs, only IP addresses.  I  would have to hard code the IP address for, which could potentially change at any time, breaking things.

After a bit of research, my first candidate to truly do the CNAME change was found.


On my unRaid box, I installed a docker of Pi-Hole, which is a DNS based system (meant for the Raspberry Pi, but capable of running on other platforms) which blackholes DNS queries to Web advertising sites, etc.  It uses DNSmasq and has the ability to run DHCP as well as DNS.  With this integration, it can resolve local hostnames to their DHCP assigned addressing.  I could do that now by adding static entries to my DNS Proxy instance on the PA-220, but it wouldn’t pick up on DHCP entries.  But, alas, DNSmasq treats a CNAME entry added manually differently than I had hoped.  It will ignore it unless it has that record defined somewhere, such at a static definition or via DHCP…  It won’t resolve an external CNAME like a normal query and return it.  And since if I were to define as an A record in DNSmasq, that would really defeat the whole purpose of using the CNAME.

Pi-Hole does have a very nice modern web interface with statistics, graphs, and it looks extremely easy to whitelist or blacklist sites.  It gives you great visibility into what devices on your network are doing the most DNS lookups, and if you are wondering where your IoT devices go on the Internet, you can even filter the logs to see what an individual device is performing lookups against, assuming you have all your devices directly querying Pi-Hole, instead of chained like I’m doing here.  In fact, you can even disable the blocking functionality if you like.  With it disabled, it won’t block, but you’ll be able to see all the statistics and logs it has to offer, even showing you what it would have blocked.  Today, it has blocked about 8.8 percent of my DNS queries, though I haven’t really noticed much different than when I simply go through my PA-220.


While looking for other DNS packages that could do this CNAME trick, I ran across one that looked very interesting for a different reason.  Dingo is effectively a DNS resolver that takes requests in on port 53, and resolves them over encrypted HTTP/2.  It can be used with both Google and OpenResolve (by OpenDNS).  I installed it as another docker and it seems to work fine.  I did increase it to use 25 worker threads instead of the initial 10.  I don’t know if I’ll keep using this or not, but I’ll see how it goes.


Other research turned up some settings for Bind that would let me add the CNAME records I needed to for Google and Bing to enforce safe search, and yet another Docker was installed.  The one I chose included Webmin for easy administration of Bind.  It worked just fine.

So, now I have the initial DNS queries pointing to the PA-220, taking advantage of the Threat/URL Filtering there, then forwarding to a docker running Bind to handle google and bing domains, which forwards to Pi-Hole (which I may end up removing from this chain), and finally to Dingo to perform the actual DNS lookups over encrypted HTTP/2.


That sounds like a lot, but not including the PA-220 (which was doing this job before), I’ve added three hops that all exist on the same box.

May 21, 2017 at 7:48 pm Leave a comment

The PA-220 Firewall is here!

The PA-220 has 8 ports of Gigabit goodness on the front, aside from the management port.

The PA-220 supports some pretty high-end features, making it suitable for use in a small business office.  First, there is High Availability mode (HA), if you have a pair of PA-220s and duplicate your connectivity (even to your WAN, so you’d need a switch between a Cable/DSL modem and the pair of firewalls)  Another big feature is LACP support (Link Aggregation Control Protocol), so you could have multiple connections between your firewall and an Ethernet switch.  This redundancy is something that small offices would likely want, as when the WAN connection is down, there is probably work that can’t be done.

The PA-220 comes with a template and hardware to mount it sideways on a wall, something that I plan to do at some point but haven’t gotten around to yet.

Since the speed that the PA-220 handles traffic is limited to about 500 Mbps firewalled, and down to about 150 Mbps with Threat enabled, I recommend only putting relatively low speed or volume devices directly on the ports of the firewall itself, if the primary thing they are communicating to is also on the local LAN.  You could always add a rule in for intrazone traffic to be allowed and not place any Threat profiles on that rule, giving you the maximum 500 Mbps speed to the internal network.

I’ve got it in place, doing SSL decryption, Threat, URL filtering, Wildfire, and GlobalProtect VPN.  It seems to perform pretty well so far.

May 21, 2017 at 11:20 am 7 comments

Meraki AP Syslog to Palo Alto firewall for User ID

I recently got a Meraki AP as a demo unit. Using Palo Alto’s Syslog listener, you can get user-id info from these units, if you are doing 802.1X authentication.

Just follow the instructions here, with some adjustments…

Navigate to the Device tab, User Identification menu item, then the User Mapping tab. There, select the gear icon, and on the following pop-up screen, select Syslog Filters.
Add a new filter, with these properties:
Profile Name: Meraki AP v1.0.0
Type: Regex Identifier
Event Regex: 8021x_eap_success
Username Regex: identity='([a-zA-Z0-9\\\._]+)
Address Regex: client_ip='([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})

Then, use your newly created filter for your Syslog Listener.

In my experience, it looks like the Meraki only logs authentication events every so often. Perhaps it is caching them? At any rate, set the Cache timeout value to something greater than the default 45 minutes. I set mine to 480, though this may need tuning, depending on the environment.

Also, be aware that the first time you authenticate after setting this up, you’ll probably show up in the ip-user-mapping with no IP address. That’s because when you initially authenticate, the first Syslog message from the Meraki shows an IP of Subsequent authentication attempts have your IP address in them. Not sure how this works out in the long term.

I wouldn’t say this is quite production ready, but it is definitely worth playing with, if you happen to have both a PA firewall and a Meraki AP.

March 2, 2016 at 7:04 pm Leave a comment

Mass upgrading Palo Alto firewalls

My company just bought 900 PA-200 firewalls.  Unfortunately, they all are pre-loaded with firmware version 5.0.6.  The current version is 7.0.1.  To get from 5.0.6 to 7.0.1, you must install a newer content version, then upgrade to version 6.0, then to 6.1, and finally to 7.0.1. Oh, and we want to install A/V as well, in preparation for shipping them to the stores.

They have a product called Panorama that manages their firewalls (can’t manage hundreds of firewalls without, if you ask me).  It can perform upgrades from one version to another, but isn’t smart enough to know what steps must be taken to get from 5.0.6 to 7.0.1.  Someone would need to know the process, and direct Panorama to do it, each step of the way.  Since I have 900 of them to upgrade, I needed to come up with a better way!  Waiting until they were at the store connected via a T1 circuit is not a good option either, as the content, A/V, and all the firmware upgrades would be over 1.1 GB in size.

A great feature for Panorama would be to have a “base” template you set for each Device Group.  That “base” template would include things like what Content and A/V versions, and what firmware for all the devices in the group.  Whenever devices are added to this device group, Panorama should automatically set them to the proper content, A/V, and firmware versions.

But, since Panorama isn’t that smart yet, the Palo Alto API and scripting magic to the rescue.

Since I’ve been writing a script to handle our installation process, I written a Palo Alto class to handle all the communications to the PA-200s and to Panorama.  I did have to add a few more routines to the Palo Alto class to handle everything that I needed, but it now works.

Our process works this way:
1.  A tech unpacks 10 PA-200 firewalls and attaches their Management port to a subnet on our corporate network.
2.  The tech scans the serial number bar codes on the back of the PA-200s, adding them to Panorama as “Managed Devices”.
3.  The tech adds them to the appropriate Template and a special device group that exists just for the upgrade process.
4.  The tech sets an IP address, Mask, and Gateway on each unit, pointing them to DNS servers and the Panorama server, then commits the change.  (This is a copy/paste process where the IP is different for each of the 10 units being upgraded.)
5. Finally, the tech performs a Commit in Panorama.
6.  The tech then gets back to other work, waiting for an email that will be sent once all the devices are upgraded.  This should happen about 1:35 to 1:45 minutes after the Panorama commit is done.

The real work gets done in a script that runs every 5 minutes.  This script:
1.  Gets a list of all the devices in the special device group.
2.  Attempts to create an object of my custom PA class for each device.  If it can’t communicate to it, that one is discarded for now, since this script will retry in a few minutes.
3.  Panorama is checked to make sure there are no active jobs for this serial number.  If so, it’s removed from further checks.
4.  Each firewall is checked to make sure there are no active jobs.  If so, it’s removed from further checks.
5.  The content version is checked for each PA-200.  If one isn’t found, it’s serial number is added to the Content queue and it’s removed from further checks.
6.  The anti-virus version is checked for each PA-200.  If one isn’t found, it’s serial number is added to the Anti-Virus queue and it’s removed from further checks.
7.  If the firmware starts with “5”, it’s serial number is added to the 6.0 upgrade queue and it’s removed from further checks.
8.  If the firmware starts with “6.0”, it’s serial number is added to the 6.1 upgrade queue and it’s removed from further checks.
9.  If the firmware starts with “6.1”, it’s serial number is added to the 7.0.1 upgrade queue and it’s removed from further checks.
10.  If 7.0.1 is installed, it sets the IP address back to the default and issues a commit.
11.  Finally, if 7.0.1 has been installed, and the box is unreachable (because the commit has taken effect), the device is removed from the special device group and moved to a Pending group.
12. All the various “queues” I mentioned get kicked off, with the serial numbers of the devices that need that step performed passed to Panorama via the XML API.  There’s additional logic to send emails when all the devices are out of the device group.

In practice, this is taking about 1:35 to fully upgrade 10 firewalls, though I suspect we could ramp this up to 20 or more, and it would likely take very close to the same time, since Panorama is upgrading all the devices in parallel.

This will have to do until Palo Alto upgrades Panorama to do it for me.

August 9, 2015 at 5:08 pm Leave a comment

Palo Alto and the power of an API

We recently bought Palo Alto PA-200 firewalls for our retail locations to replace our aging CheckPoint UTMs.  I didn’t investigate their API at all during the time we were looking at CheckPoint competitors.  I knew it had one, but hadn’t really given it a lot of thought.  Now that we have a massive roll-out ahead of us, I’ve started scripting parts of the process.  I must say that I love the flexibility that their API gives us.

In the past, for any major roll-out, I’ve scripted the process using telnet / SSH / HTTP (for web scraping), basically whatever interface the vendor allowed.  My goal is to make the installation fast and easy to support, while reducing the chance of human error as much as possible.  The hassle with CLI scripting for remote devices is always the parsing.  While it’s possible to do a good job parsing things manually, it’s time consuming and prone to error.  With an API, it’s faster and easier to code and you get data back in a predictable format.

If what you want to do can be done via SSH, Palo Alto has included a “Secret Decoder Ring” to help you figure out the API…  The secret is that the WebGUI and CLI both use the API whenever you do most anything.  So, in the CLI you can simply turn on “debug cli on”, and get most of the XML you need to pass to issue your API call by watching what the CLI does.  For example, if I do a “show jobs all”, I get this XML back:

<request cmd=”op” cookie=”8856737959639002″ uid=”500″><operations><show><jobs><all/></jobs></show></operations></request>

To do an API call to get the status of all your jobs, add in the blue and red portions from above appropriately:

http(s)://hostname/api/?type=op&cmd=<show><jobs><all/></jobs></show>&key=[Your API Key]

To reboot your firewall via the API:

http(s)://hostname/api/?type=op&cmd=<request><restart><system></system></restart></request>&key=[Your API Key]

Granted, there are some things I’ve not been able to figure out how to do via the API, like checking for the existence of an imported config file.  Via the CLI, just enter “show config saved ” and hit TAB after the last space.  The auto-complete feature of the PA CLI will show you a directory listing of saved config files.  If you do this with debugging turned on, you’ll note that you don’t see any “debug” info, so the autocomplete function must not use the API (or debugging autocomplete is disabled for readability purposes).

I expect that everything I need to do relative to the installation process can be handled via the API:

1. Import a pre-generated configuration file
2. Load the imported configuration file
3. Issue a local Commit
4. Check the status of the Commit
5. Read the Serial Number of the remote device being installed
6. In Panorama move the device from the “Pending” device group to the “Production” device group
7. Issue a Panorama commit for this device (by Serial Number)

If you have any need to programmatically interact with a Palo Alto firewall, I encourage you to dig into the API.  There’s tons of very good data, just waiting to be accessed.  Very easily.


July 23, 2015 at 7:33 pm Leave a comment


January 2022

Posts by Month

Posts by Category