Palo Alto Networks - Google 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. Luckily, this can also be manually controlled via static entries in the DNS Proxy configuration on the firewall.

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, Google has an IP specified to enforce Safe Search.

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 also blocked all search engines except for Google, 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.

Palo Alto Networks - Aruba Networks Instant User-ID Integration

Palo Alto Networks firewalls are built on three core technologies: App-ID, User-ID, and Content-ID. User-ID specifically, accomplishes two objectives:

1. The mapping of IP addresses to actual user account information. This is imperative for troubleshooting and/or analyzing logged data, as IP address assignments change over time.
2. The usage of user/group information within a security policy. This allows administrators to get very granular with how they enforce corporate security posture.

In most Palo Alto Networks firewall deployments, I see User-ID configured via an agent that ties into Active Directory. However, this is typically where the integration stops. It is imperative that as much user information as possible is ingested by the firewall so that logs and security policy remain consistent. User-ID provides other mechanisms by which we can tie into user account information (i.e. syslog, API, etc.). After all, active directory is only one of those ways. Specific to Aruba Networks Instant APs, the integration is very straightforward. 

In the virtual controller GUI, navigate to More -> Services -> Network Integration, enter the necessary information, and click OK.

Create a new SSID, leveraging 802.1X as the authentication mechanism. 

Upon logging into the SSID with Active Directory credentials, you will begin to see the source user information populate in the Palo Alto Networks firewall logs. 

Asymmetric Routing with Juniper Routed VLAN Interfaces

I ran into a scenario the other day which I thought would be worth sharing. The customer had a layer 2 trunk link between the SRX firewall and the EX switch was configured so that two VLANs could reach the Internet. Here is the configuration:

SRX:

set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 100
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 200
set interfaces vlan unit 100 family inet address 10.10.10.1/24
set interfaces vlan unit 200 family inet address 10.10.20.1/24
set vlans 100 vlan-id 100
set vlans 100 l3-interface vlan.100
set vlans 200 vlan-id 200
set vlans 200 l3-interface vlan.200

EX:

set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode trunk
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 100
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members 200
set interfaces vlan unit 100 family inet address 10.10.10.2/24
set interfaces vlan unit 200 family inet address 10.10.20.2/24
set vlans 100 vlan-id 100
set vlans 100 l3-interface vlan.100
set vlans 200 vlan-id 200
set vlans 200 l3-interface vlan.200
set routing-options static route 0.0.0.0/0 next-hop 10.10.10.1

Obviously in an ideal scenario, we would not set the environment up this way. Creating a layer 2 trunk between devices while also having layer 3 interfaces on each device will create routing problems. Why? Let's think about the path that traffic destined for the Internet will take for each VLAN...

A host on VLAN 100 (10.10.10.0/24 network) will hit the switch, look at the default route and see a next-hop of 10.10.10.1. Once to 10.10.10.1 (the SRX), traffic will follow that default route out to the Internet. Return traffic will follow the same path back to the host, but with one difference - when the traffic looks at its route table to get back to the host on VLAN 100 (10.10.10.x), it will use the route with the lowest preference. In this case it is a directly connected route to vlan.100, which works fine because it's on the same network.

However, this does not work for VLAN 200, or any other VLAN for that matter.  A host on VLAN 200 (10.10.20.0/24 network) will hit the switch, look at the default route and see a next-hop of 10.10.10.1 (which is on a different network). Once to 10.10.10.1 (the SRX), traffic will follow that default route out to the Internet. Return traffic will NOT follow that same path back to the host due to the fact that there is a more preferred route present. In this case as well, there is a directly connected route to the 10.10.20.0/24 network via vlan.200. To illustrate, here is what the route table looks like on the SRX:

10.10.20.0/24   *[Direct/0] 00:00:17
                    > via vlan.200

Traffic used the default route on the way out and a direct route on the way back. This means that Internet-bound traffic by hosts on VLAN 200 will fail due to asymmetric routing...

There are multiple ways to resolve this issue architecturally, but I thought I would use this scenario as an opportunity to demonstrate the flexibility of routing instances in Junos. We need a way to remove that direct route so that return traffic to the host on VLAN 200 uses the same path that was used on the way out. Here is how it could be accomplished using a routing instance on the SRX:

set routing-instances TEST instance-type virtual-router
set routing-instances TEST interface vlan.200
set routing-options static route 10.10.20.0/24 next-hop 10.10.10.2

By applying this configuration change, we can now see that the direct route is no longer present in the inet.0 route table:

inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.20.0/24   *[Static/5] 2d 13:07:42
                    > to 10.10.10.2 via vlan.234

test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.20.0/24   *[Direct/0] 1d 06:10:43
                    > via vlan.200

Traffic from a host on the 10.10.20.0/24 subnet now follows the same path in both directions. I want to be clear that the best way to resolve this issue would be to make architectural changes to the network. However, this is a way to "make things work" temporarily, if necessary.

Stand-alone vs. Integrated URL Filtering

In the field, I hear a lot of administrators talk about how they prefer to use a point-product for URL filtering rather than collapse that service into a Palo Alto Networks firewall. I somewhat understand the value of this approach because its possible that a stand-alone URL filter is going to have some capabilities that are required by the organization (i.e. a specific type of report). However, the biggest issue with that approach is that there is no integration with other security products (i.e firewall, IPS, anti-malware, etc.). This means that not only any logs from security devices would need to be aggregated and correlated with yet another security device (i.e. SIEM), but more importantly it would be very difficult to provide automated outcomes due to the disparate nature of each point product. At the end of the day, we want to make our lives as administrators easier, right? I know I do! Here is an example of what I'm talking about:

One of the most prevalent ways that malware is delivered to an endpoint is via drive-by download over an SSL connection. This type of attack is typically used in conjunction with some other form of attack (i.e. spear phishing, watering hole, etc.). A drive-by download is a download that occurs without a user's knowledge when visiting a website. The access method (i.e. browser, application, etc.) is exploited to automate the process so that the user is unable to take action until it is too late. Attackers will register new domains that have yet to be categorized by URL filtering products in attempts to bypass URL categories traditionally categorized as malicious, phishing, etc. Palo Alto Networks firewalls can intercept drive-by downloads because its URL filtering, file blocking, and SSL decryption capabilities are natively-integrated.

PAN-DB URL filtering within Palo Alto Networks firewalls have an unknown category to match newly registered domains by attackers, but more importantly, URL categories (whether pre-defined or custom) can be leveraged as match criteria within a security policy.



The security policy above signifies that any traffic going from domain users on the internal network to any website categorized as unknown on the outside internet will be allowed, but have specific Content-ID profiles applied. In this particular policy, we specify a File Blocking profile called Drive-by.



The File Blocking profile above signifies that any application or file type that is seen will result in a continue action. This means that if a user accesses an unknown URL and a file download or upload is attempted, then a response page will be generated forcing the user to either confirm or deny the download. Other options include alert (log and allow) and block (log and block). This is even when the session is encrypted over SSL. The response page can be customized, of course.



In summary, as the number of devices connected to the internet continue to rise, the more threats will also continue to rise. Its almost impossible to keep up with disparate products, logs, etc. and no correlation. Leveraging a platform with native URL filtering integration allows us to automate outcomes with very little to no manual intervention on our part.