Palo Alto Networks - GlobalProtect - Overview

ATTENTION: Please visit the Palo Alto Networks Live site for the latest version of this post.

----------------------------------------------------------------------------------------------------------------

Given the current state of things, many technical professionals are scrambling to safely enable remote access to internal resources and the Internet for their end users. As a result, I thought I would update my GlobalProtect series of posts with additional details, as this is an extremely viable option for Palo Alto Networks customers that need a robust remote access solution.

GlobalProtect is a very flexible Palo Alto Networks core capability that allows remote users to access local and/or Internet resources while still being protected from known and unknown threats. This feature provides policy consistency regardless of end user location, and eliminates the need for managing additional point products in your environment. If you are looking for something highly scalable and do not wish to leverage on-premise hardware/software/licensing, Prisma Access is a great option, as it is just as robust from a capabilities standpoint, but is a SaaS service that leverages the scale of public cloud to accommodate a 100% remote workforce.

The goal of this series is to provide Palo Alto Networks users with a walk through for setting up a basic configuration that is applicable to both traditional GlobalProtect and Prisma Access for Mobile Users deployments. This can also be something that you can reference prior to kicking off a PoC or implementation to better understand the general implementation flow. Each post in the series builds upon the previous one. Here are the details:

• GlobalProtect Part I - A basic initial setup with a portal, external gateway, and local DB authentication.
• GlobalProtect Part II - An expanded setup to include various forms of authentication (LDAP, RADIUS, Duo), as well as an internal gateway.
• GlobalProtect Part III - A further expanded setup to include user-based and HIP-based policy, as well as HIP notifications.
• GlobalProtect Part IV - A further expanded setup to include authentication policy with MFA for HTTP and non-HTTP access to sensitive resources. 
• GlobalProtect Part V - A further expanded setup to include pre-logon authentication using machine certificates.

If you are unfamiliar with GlobalProtect terminology, see this link. Additional details regarding GlobalProtect administration can be found in the official Palo Alto Networks documentation.

Here is a diagram of the environment used in this series:

Palo Alto Networks - User-ID at Home

User-ID is one of the core tenets of Palo Alto Networks firewalls, and is very useful when implementing identity-based policy in an enterprise environment. User-ID can be leveraged from a variety of sources (GlobalProtect is a great option). Given the proliferation of IoT (especially at my house 😂), User-ID can be difficult to leverage across all devices given that technically there may not be an actual user logged in. With that in mind, I wanted to share a method that maps hostnames from DHCP leases in the system logs to their corresponding IP addresses. This allows administrators to leverage User-ID in policy for devices without an actual user account.

Note - This post assumes that you are using the firewall as your DHCP server, but realistically, any DHCP server capable of forwarding logs to the firewall can be used.

•  Navigate to Device -> Server Profiles -> Syslog -> Add to create a new syslog profile
• Enter a Profile Name
• In the Servers tab, Add a new server
• Enter a Name
• Enter the Syslog Server address
• In my case, it is the trust interface of the firewall

• Navigate to Device -> Log Settings -> System -> Add to create a new Log Setting - System
• Enter a Profile Name
• Set the Filter to (eventid eq lease-start)
• Add the Syslog server profile that you created previously
• Click OK

• Navigate to Device -> User Identification -> User Mapping -> Palo Alto Networks User-ID Agent Setup (the gear icon) -> Syslog Filters -> Add to create a new Syslog Parse Profile
• Enter a Syslog Parse Profile Name
• Set Type to Regex Identifier
• Enter DHCP\ lease\ started for Event Regex
• Enter hostname ([a-zA-Z0-9\_\[\]\-]+) for Username Regex
• Enter ip ([A-F0-9a-f:.]+) for Address Regex
• Click OK
• Click OK

• Navigate to Device -> User Identification -> User Mapping -> Server Monitoring -> Add to create a User Identification Monitored Server
• Enter a Name
• Set the Type to Syslog Sender
• Set the Network Address
• In my case, it is the trust interface of the firewall
• Set Connection Type to UDP
• Add the Syslog Parse Profile that you created previously
• Click OK

• Navigate to Network -> Zones -> select the zone(s) on which your devices reside -> check the Enable User Identification check box

• Navigate to Network -> Network Profiles -> Interface Mgmt -> Add to create an Interface Management Profile
• Note - If you already have one that is applied to your trust interface, then you can simply edit that one.
• Check the User-ID Syslog Listener-UDP check box
• Click OK

• Navigate to Network -> Interfaces -> select the trust interface -> Advanced -> Other Info -> Management Profile -> select the Management Profile you created previously

• Commit the configuration
• Test the changes by clearing/renewing some leases and then navigate to Monitor -> Logs -> System and filtering by ( eventid eq lease-start ) to see entries such as:

• You will also see traffic logs with the Source User column populated by navigating to Monitor -> Logs -> Traffic:

Palo Alto Networks - DNS Proxy

DNS Proxy (configured by navigating to Network -> DNS Proxy) is a feature that can be very useful for environments where you do not have dedicated DNS servers, as it allows you to proxy all DNS requests through the firewall, as well as create static entries for forward and reverse lookups.

For example, if you use GlobalProtect in an Always-On configuration, you will need a way for the app to determine when it is on the internal network so that it does not build a VPN tunnel. The static entry below is an example:

See my first GlobalProtect post for additional details regarding internal host detection.

Palo Alto Networks - Duo Integration via RADIUS

Duo can be integrated with Palo Alto Networks in a variety of ways. In this post, we are going to be looking at RADIUS integration, specifically. This would allow administrators to add additional factors of authentication for mobile users connecting to specific GlobalProtect gateways, for example.

Note - This post assumes that you have an active Duo account, along with a domain controller running at least Windows Server 2012 R2 or later. There is a great Duo tutorial that covers this configuration, but I thought I would include the specific steps I followed in this post.

From the Duo interface:

• Navigate to Users to add a user name that matches a user in Active Directory
• Select Add Phone to add your mobile phone as a 2FA device
• You should then be able to send an activation link to the device
• Navigate to Applications -> Protect an Application -> search for Palo Alto SSL VPN -> Protect

From the Windows server:

• Download the latest Duo Authentication Proxy here and install it as a user with administrative rights
• Navigate to C:\Program Files (x86)\Duo Security Authentication Proxy\conf and edit the authproxy file using Wordpad (Notepad is discouraged)
• Delete all the contents of the file, and replace it with the following data:

[ad_client]
host=(enter the IP address of the server)
service_account_username=(enter the service account username)
service_account_password=(enter the service account password)
search_dn=DC=mydomain,DC=local

[radius_server_auto]
ikey=(enter the Integration Key found in the Palo Alto SSL VPN application in Duo)
skey=(enter the Secret Key found in the Palo Alto SSL VPN application in Duo)
api_host=(enter the API Hostname found in the Palo Alto SSL VPN application in Duo)
radius_ip_1=(enter the IP address of the trust interface of the firewall)
radius_secret_1=(enter a shared secret of your choice)
client=ad_client
port=1812
failmode=safe

From the firewall interface:

• Navigate to Device -> Server Profiles -> RADIUS -> Add
• Enter a Profile Name
• Set the Timeout (sec) to 60
• Set the Authentication Protocol to PAP
• Add a Server
• Enter a Name
• Enter a RADIUS Server
• This should be IP address of the AD server
• Enter the same Secret that was created in the authproxy file for radius_ip_1
• Click OK

• Navigate to Device -> Authentication Profile -> Add
• Enter a Name
• Set the Type to RADIUS
• Set the Server Profile to the RADIUS profile that was previously created
• Set the User Domain to your domain

• Navigate to the Advanced tab and select the user group (where applicable)
• Click OK

You can now test this by adding the Authentication Profile to an administrator or to a GlobalProtect configuration, like in this post.

Palo Alto Networks Minemeld - Part III - Additional Miners

This post elaborates upon the previous previous posts in this series. If you haven't read through parts 1 and 2, I highly recommend that you start there prior to moving forward.

NOTE: The post(s) associated with this topic assume(s) that you already have an active Minemeld instance running (either open source or via AutoFocus), and that you already have a firewall or third party security tool configured in a manner that can consume the data. More information about initial configuration can be found here (for hosted) and here (for open source).

The purpose of this post is to build onto the previous configuration to further illustrate how Minemeld can be used to prevent threats using a wide variety of data sources. Your Minemeld instance should currently look like this (navigate to Config):

The additional data sources used below are just examples, but could be considered a good baseline with which to start. Feel free to choose others that may be more applicable to your specific deployment. Add the following miners to the configuration by navigating to Prototypes and selecting the Clone option:

• alienvault.reputation
• bambenekconsulting.c2_dommasterlist_high
• bambenekconsulting.c2_dommasterlist
• bambenekconsulting.c2_ipmasterlist_high
• bambenekconsulting.c2_ipmasterlist
• blocklist_de.all
• dshield.block
• ETOpen.blockIPs
• feodotracker.badips
• feodotracker.ipblocklist
• itcertpa.DOMAINS
• itcertpa.IP
• itcertpa.URLS
• libraesva.LIBRAESVA_Malware_Domains
• phishme.Intelligence
• proofpoint.EmergingThreatsDomains
• proofpoint.EmergingThreatsIPs
• ransomwaretracker.RW_DOMBL
• ransomwaretracker.RW_IPBL
• ransomwaretracker.RW_URLBL
• recordedfuture.DomainRiskList
• recordedfuture.IPRiskList
• spamhaus.DROP
• spamhaus.EDROP
• usom.DOMAINs
• usom.IPs
• usom.URLs
• zeustracker.badips

The Config will look like the following:

Add the following processors to the configuration by navigating to Prototypes and selecting the Clone option:

• stdlib.aggregatorDomain
• stdlib.aggregatorURL

The Config will look like the following:

Add the following output nodes to the configuration by navigating to Prototypes and selecting the Clone option (note that you will do this multiple times based on the output formats required):

• stdlib.feedHCGreen
• stdlib.feedMCGreen

The Config will look like the following:

For each processor node in the Config, add all relevant miners as inputs. The Config will look like the following:

For each output node in the config, add all relevant processor nodes as inputs. The Config will look like the following:

Upon commiting the Config, your Minemeld instance should look like this (navigate to Prototypes -> alienvault_reputation -> GRAPH):

As shown above, all miners are now sending data to their respective processor nodes, and based on confidence level value, being added to either a high or medium output node. Note, you will likely see a red exclamation mark next to some miners under the Nodes tab. This is because some of these miners require an API key, user name and password, etc. in order to gain access to the data. 

Palo Alto Networks Minemeld - Part II - Custom Miner Configuration

The purpose of this post is to elaborate on the configuration used to walk you through how Minemeld works in my previous post. If you haven't read through part 1, I highly recommend that you start there prior to moving forward.

NOTE: The post(s) associated with this topic assume(s) that you already have an active Minemeld instance running (either open source or via AutoFocus), and that you already have a firewall or third party security tool configured in a manner that can consume the data. More information about initial configuration can be found here (for hosted) and here (for open source).

Configuration Steps

1. Let's start fresh by deleting existing nodes under Config.
2. Navigate to Prototypes, which has its own tab in the AutoFocus-hosted version. You can get there in the open source version by navigating to Config -> Browse Prototypes (three lines in lower right-hand corner).
3. Search for and select ETOpen.blockIPs. 
4. Note that there are two options, New and Clone. We are going to select New.
1. New - this option allows you to take the prototype and create another one from it.
2. Clone - this option allows you to take the prototype and create a node from it.
5. Enter/edit the following information:
1. Name - cisco_talos
2. Description - Cisco Talos threat intelligence feed.
3. Tags - ShareLevelGreen and ConfidenceHigh
4. Config - 
   1. attributes:
   1.     confidence: 80
   2.     share_level: green
   3.     type: IPv4
   2. ignore_regex: ^#
   3. source_name: cisco_talos.blf
   4. url: https://talosintelligence.com/documents/ip-blacklist
6. Select OK. 
7. Back in Prototypes, search for cisco, and you should see the prototype you just created.

8. Select the prototype and make sure it looks like the screenshot above, then select Clone.
9. Enter cisco_talos for the name and then select OK.
10. Navigate to Prototypes, search for and select stdlib.aggregatorIPv4Generic, and then select Clone.
11. Enter aggregatorIPv4 for the name and then select OK.
12. Navigate to Prototypes, search for a select stdlib.feedHCGreen, and then select Clone.
13. Enter ip_feedHC for the name and then select OK.
14. In the Config pane, click on the INPUTS field for aggregatorIPv4, select cisco_talos, and then select OK.
15. In the Config pane, click on the INPUTS field for ip_feedHC, select aggregatorIPv4, and then select OK.
16. In the Config pane, select Commit.

Upon commit, you should be able to navigate to Nodes, select cisco_talos, and then graph (the asterisk icon), which should show all of your nodes as connected and processing data.

The next post will expound upon this blacklist use case to include additional open source lists, paid lists, Palo Alto Networks competitor lists, etc.

Palo Alto Networks Minemeld - Part I - An Introduction

Minemeld is an awesome tool provided by Palo Alto Networks that is available for multiple use cases, and comes in both open source and paid subscriptions (via AutoFocus). In my opinion, the open source version should only be used in test environments and not in production for the reasons below:

• The paid subscription is hosted and maintained as a SaaS service. Every time I have deployed the open source version, either myself or with customers, I have ran into issues with reliability, upgrades, and configuration.
• The paid subscription comes with access to the Palo Alto Networks Technical Assistance Center, which can be extremely useful when needing configuration or troubleshooting help.
• The paid subscription comes with AutoFocus. AutoFocus is a contexual threat intelligence service that allows security professionals to deeply analyze all data collected by WildFire. This service becomes even more powerful when used in conjunction with Minemeld, as WildFire data can be cross referenced with third-party data, WildFire data can be exported for use by third party security tools, etc. There are many examples, some of which I will be sharing in this series of posts.

The purpose of the first post in the series is to familiarize you with how Minemeld works using a very simple use case. This is a great place to start in order to understand how Minemeld actually works and see it in action. Subsequent posts will dive deeper into configuration, as well as other use cases and scenarios.

NOTE: The post(s) associated with this topic assume(s) that you already have an active Minemeld instance running (either open source or via AutoFocus), and that you already have a firewall or third party security tool configured in a manner that can consume the data. More information about initial configuration can be found here (for hosted) and here (for open source).

Important Minemeld Jargon

• Prototype - A prototype is what is used to create a Miner, Processor, or Output Node. There are many prototypes already present by default within Minemeld that can be used to create nodes. However, they can also be used to create new prototypes for specific use cases. In the example below, I used an existing prototype called ETOpen.blockIPs to create a new prototype called minemeldlocal.cisco_talos so that I can assign specific attributes, a source URL, etc. to be referenced in my configuration. 

• Miner Node - A miner is a resource created from a prototype that mines data from a specific source (i.e. Cisco Talos IP Blacklist in the screenshot above). Miners contain the specific attributes defined within the prototype, which can prove useful. An example of an attribute would be confidence level (i.e. the prototype above has a value of 80). Confidence value is an attribute that pertains to the operator's confidence of the validity of the data collected by the miner. For example, a feed that gets updated very often may be assigned a confidence level of 100, whereas a feed that gets updated once a month may have a confidence level of 25. By default, a miner with a value >75 is considered high, 50-75 is considered medium, and <50 is considered low. Below is a screenshot of the cisco_talos miner that was created from the minemeldlocal.cisco_talos prototype shown in the previous screenshot.  

• Processor Node - A processor is a resource created from a prototype that acts as a data aggregator for multiple miners that contain the same type of data (i.e. IP addresses). This function allows the data from multiple miners to be consolidated into a single source. In the screenshot below, I have created the aggregatorIPv4 processor node from the stdlib.aggregatorIPv4Inbound prototype to aggregate IPv4 addresses. 

• Output Node - An output node acts as a mechanism to distribute the data aggregated by a processor node so that it can be consumed by a security tool (i.e. a firewall). Output nodes can be customized based on attributes. For example, an output node can be configured to only distribute data that has a confidence value >75. It is also important to note that data can be distributed from an output node to an external destination (i.e. a firewall) via either a push (dynamic address group) or a pull (external dynamic list) method. I will provide more information on this in a subsequent post. In the screenshot below, I have created the feedHC output node from the stdlib.feedHCGreen prototype to distribute high confidence data. 

Bringing it All Together

The cisco_talos miner has collected 939 indicators, which based on the attributes we assigned to the various prototypes, are passed to the aggregatorIPv4 processor node, and subsequently the feedHC output node. This is permitted based on the attributes described above (i.e. confidence level value of 80).

My next post will provide a walk through of the configuration referenced in this post.

Palo Alto Networks - AWS VPN Configuration When Running OSPF

I ran into a scenario recently that I thought I’d share. A Palo Alto Networks firewall was being configured with redundant VPN tunnels to an AWS VPC. However, due to the fact that all static routes were being injected into OSPF in this particular firewall, this somewhat changed the “recommended” PAN-OS configuration that AWS provides.

To elaborate, when a user configures a VPN in an AWS VPC, there is an option to download a VPN configuration for the other side of the tunnel, based on the vendor being used. If Palo Alto Networks is selected, the full configuration in set commands is provided. That stated, the method used for failover to the backup tunnel if the primary tunnel fails is called Policy-based Forwarding (PBF). This is important to note because a PBF configuration does not place routes in the routing table, and therefore there is nothing to inject into OSPF.

If you run into this scenario, rather than configure the tunnelmonitor and PBF features listed in step 4 of the downloaded configuration from AWS, here are the changes that must be made in order to have redundancy work properly:

• Create a static route for each tunnel, with a next-hop of the other end of the tunnel subnet. Here are some screenshots of the tunnel interfaces and the associated static routes and path monitoring conditions:

Note that the backup route has a metric set to 11 rather than the default value of 10. This ensures that both routes are in the route table, but the aws2 route only becomes available when the aws1 route is removed from the FIB as a result of the Path Monitoring condition failing.

Failover can be tested by simply disabling the primary tunnel under Network -> IPSec Tunnels -> (select the tunnel) -> Disable.

Palo Alto Networks - How to Safely Enable Applications - Part II

My previous post details the problems associated with a legacy layer 4-based security policy approach, and how organizations can move to a layer 7-based positive control model that reduces attack surface via a manual, but very methodical way. 

If you haven't read that post yet, I would recommend you do so prior to continuing with this one.

With the release of PAN-OS 9.0, a new feature called Policy Optimizer is now available. This capability allows for organizations to take the same approach that is detailed in my previous post, but in a much more automated way.

In the scenario above, there is a rule allowing any application over any port out to the Internet. On the same page (Policies tab), administrators can now navigate to Policy Optimizer to begin migrating legacy rules to App-ID.

Selecting the No App Specified option will allow administrators to begin to analyze applications hitting different security policy rules. Selecting the compare option of a specific rule will bring up the following window: 

As shown above, 81 different applications have matched the trust-untrust - allow - home rule since it was created, and can now be either be added to the existing rule, or used to create a clone. My recommendation is similar to my previous post from a process standpoint. The best option is to create a clone, as that will provide a failsafe for anything that is missed by the new rule to match the previous legacy rule below it and not disrupt production traffic (below). As time goes on, the original rule can slowly be phased out.

This approach essentially provides organizations with a way to take the same methodical approach described in my previous post, but in a more automated way. 

Palo Alto Networks - How to Safely Enable Applications - Part I

In the field, I tend to run into the following security policy scenario quite often because administrators either just migrated away from a legacy, port-based firewall, and/or they do not know how to effectively get to the Palo Alto Networks best practice of safe application enablement:

This is a pretty rudimentary example, but it does a good job of illustrating the problem. Every application other than a few known bad ones are being allowed over any port on the network. This results in a very large attack surface (there are many applications over which an attack can be delivered), and the ability to block unsanctioned applications requires a very manual response (every bad application has to be identified and added to the block rule).

The recommended action is to take the opposite approach, by only allowing applications that are sanctioned by the organization. This results in a much smaller attack surface (anything not explicitly allowed is implicitly denied), and the ability to block unsanctioned applications is automatic (whether it is known or unknown). All that said, how do we get there? The following methodology can be used in any organization, but it does require buy-off from management in order to determine what applications should be sanctioned vs. unsanctioned.

As shown above, all sanctioned applications are manually defined and added to the first rule. All unsanctioned applications are manually defined and added to the second rule. Finally, all other traffic hits the third rule. The third rule is reserved for applications that are either traversing non-standard ports or have not yet been added to the sanctioned or unsanctioned rules. A custom report referencing the rule can be created and ran to gather all applications identified via the tolerated rule over a certain period of time (i.e. 30 days). 

Over time, all applications will be identified and can be added to either the Sanctioned or Unsanctioned rules. There may be some instances where administrators will have to create secondary sanctioned rules for applications that are sanctioned, but are traversing non-standard ports (i.e. a web server that is accessed over TCP port 8080). Once you are satisfied, Unsanctioned and Tolerated rules can be deleted, as anything that is not explicitly allowed in the Sanctioned rule will be implicitly denied in the default deny rule.

This is a great way to migrate from a legacy blacklist, layer 4-based policy approach, to a positive control model that reduces attack surface and leverages the platform the way it was intended. 

My next post details how to leverage the new Policy Optimizer feature (available in PAN-OS 9.0) that makes migrating to App-ID and a positive control model even easier.

Palo Alto Networks - Querying Multiple URL Categories at Once

Palo Alto Networks offers a way to query a URL via https://urlfiltering.paloaltonetworks.com/. However, if you want to query multiple URLs at the same time, then you need to leverage the API.

• Generate the API key for the firewall. See this link for instructions.
• Create a text file with all the URLs you want to check. For example, create a file called urls.txt with the URLs entered in the following format:

www.google.com
www.facebook.com
www.yahoo.com
purple.com
chase.com

• Create a bash file to query PAN-DB using the text file created in the previous step. For example, create a file called url_checker with the following details:

#!/bin/bash

for url in $(cat urls.txt); 

do curl -k 'https://{firewall ip}/api/?type=op&cmd=<test><url>'$url'</url></test>&key={api key here}'; 

done

• From the command line, run the bash script. For example, in OSX, ./url_checker
• The output should give you a list of all URLs in the file and their corresponding categories.

SJCMACF0UPG8WM:Desktop smitchell$ ./url_checker

<response cmd="status" status="success"><result>www.google.com search-engines (Base db) expires in 3000 seconds

www.google.com search-engines (Cloud db)

</result></response><response cmd="status" status="success"><result>www.facebook.com social-networking (Base db) expires in 3000 seconds

www.facebook.com social-networking (Cloud db)

</result></response><response cmd="status" status="success"><result>www.yahoo.com internet-portals (Base db) expires in 3000 seconds

www.yahoo.com internet-portals (Cloud db)

</result></response><response cmd="status" status="success"><result>purple.com home-and-garden (Base db) expires in 0 seconds

purple.com home-and-garden (Cloud db)

</result></response><response cmd="status" status="success"><result>chase.com financial-services (Base db) expires in 9000 seconds

chase.com financial-services (Cloud db)

</result></response>SJCMACF0UPG8WM:Desktop smitchell$

Palo Alto Networks - Tags, Dynamic Address Objects, and Policy Automation

Palo Alto Networks offers a variety of ways to automate configuration tasks. One of these ways is through the concept of tags. Tags allow administrators to group and visually distinguish objects within the PAN-OS GUI. A simple, real-world example would be when you manage multiple networks that may dynamically change, and don't want to have to update configuration information in multiple areas.

• Navigate to Objects -> Tags, and create a tag that references an address group.

• Navigate to Objects -> Address Groups, and create a Dynamic Address Group that references the tag created in the previous step.

• Navigate to Objects -> Addresses, and create address objects that reference the tag created in the first step.

You can now create policies that reference the Dynamic Address Group as a source or destination address. This means that moving forward, any policy changes (from an address object perspective) will be updated automatically via how tags are applied.

Palo Alto Networks - Bing Safe Search Options

Safe Search allows administrators to block explicit content. This especially important in educational institutions (i.e. K-12). Palo Alto Networks offers multiple ways to enforce this feature. However, each of these options require implementing SSL Forward Proxy, as most search engines now leverage SSL. That being said, Bing does not adhere to the safe search settings over SSL, so it is recommended in the Palo Alto Networks documentation to disable SSL for Bing searches. For some organizations, this may not be a viable option. Luckily, Bing currently offers a DNS method that can be leveraged to ensure that safe search is enforced over SSL. It is recommended to leverage SSL Forward Proxy on the Palo Alto Networks firewall in conjunction with this method so that you have full control and visibility into user searches. Below are the DNS Proxy configuration steps for the firewall if public DNS servers are in use in the environment. Keep in mind that the same objective can be accomplished via an internally managed DNS server, outside of the firewall configuration.

Navigate to Network -> DNS Proxy. Define your servers and the interfaces on which you would like to leverage DNS Proxy.

In the Static Entries tab, define specific FQDNs that you would like to map to specific IP addresses. As you will see below, Bing has an IP specified to enforce Safe Search (you can do an nslookup to verify the current IP that maps to restrict.bing.com).

Navigate to Device -> Setup -> Services -> Service Route Configuration, and select DNS. Verify the interface that is assigned. In my case, it is my trust interface.

Navigate to Policies -> Security. Create a security policy that only allows DNS for the source address specified in the Service Route Configuration. This will ensure that an end user will not be able to enter other DNS servers and successfully bypass your static entries. We are explicitly allowing only the firewall, and all else is denied (assuming you don't have an "allow all" policy configured below this rule).

Upon testing you will find that safe search is enforced. It should be noted that as part of my configuration I have followed Palo Alto Networks best practice of blocking all search engines except for Google, Bing, and Yahoo, so that I can be more granular with how users on my networks are performing searches. This step is optional, but I recommend it because it will make things easier to control.