Palo Alto Networks - Google Authenticator and OpenOTP

I have been asked about how multi-factor authentication (MFA) with with Palo Alto Networks and GlobalProtect, so I thought I would put this tutorial together. GlobalProtect leverages VPN technology to safely enable applications, users, and content for remotely connected devices. Leveraging MFA for remote access provides an added authentication mechanism so that a user not only has know their password, but also possess a one time password or token. There are multiple MFA solutions out there, but for testing purposes I thought I would show how to use Google Authenticator and OpenOTP.

Install the OTP Server:

1. Download the appropriate virtual appliance from: https://www.rcdevs.com/downloads/VMWare+Appliances/. In my case, I am going to run the VM in VMware Player, so I downloaded the OVF. The user credentials for the VM by default are as follows:
1. SSH/console: root / password
2. Web: admin / password
2. Upon boot up, enter the following information (mydomain.com should be replaced with your actual domain):
1. Enter an FQDN of “otp.mydomain.com”
2. Enter an ORG name of "mydomain.com"
3. Enter "Y"
4. Enter "Y"
5. Enter "Y"
6. Press any key to continue
7. Press any key to finish
3. Log into the server via console and use "ifconfig" to locate or set the IP address.
4. Update /opt/webadm/conf/servers.xml with the details of your AD server.
1. ldap server name="servername"
2. host="ipaddress"
5. Save and quit
6. Update /opt/webadm/conf/webadm.conf with administrator account info for your AD server (you could always create a service account in AD for this function).
1. proxy_user "cn=Administrator,cn=Users,dc=mydomain,dc=com"
2. proxy_password "mypassword"
7. Comment out the following lines and add the following below it:
1. #super_admins "cn=admin,o=root", \
2. #                       "cn=super_admins,dc=WebADM"
3. super_admins "cn=Administrator,cn=Users,dc=mydomain,dc=com
8. In the "adminroles_container" section of the file comment the lines out as follows:
1. # Find below the LDAP containers required by WebADM.
2. # Change the container's DN to fit your ldap tree base.
3. # WebADM AdminRoles container
4. # adminroles_container "dc=AdminRoles,dc=WebADM"
5. # WebADM Optionsets container
6. # optionsets_container  "dc=OptionSets,dc=WebADM"
7. # WebApp configurations container
8. # webapps_container "dc=WebApps,dc=WebADM"
9. # WebSrv configurations container
10. # websrvs_container "dc=WebSrvs,dc=WebADM"
11. # Mount points container
12. # mountpoints_container "dc=MountPoints,dc=WebADM"
13. # Domain and Trusts container
14. # domains_container "dc=Domains,dc=WebADM"
15. # Clients container
16. # clients_container "dc=Clients,dc=WebADM"
9. In the "MS AD Settings" section of the file, make the following changes:
1. # With MS Active Directory use the following settings instead of the previous ones
2. # Note: Replace dc=mydomain,dc=com with your AD domain DN
3. adminroles_container  "cn=AdminRoles,cn=WebADM,dc=mydomain,dc=com"
4. optionsets_container  "cn=OptionSets,cn=WebADM,dc=mydomain,dc=com"
5. webapps_container "cn=WebApps,cn=WebADM,dc=mydomain,dc=com"
6. websrvs_container "cn=WebSrvs,cn=WebADM,dc=mydomain,dc=com"
7. mountpoints_container "cn=Mountpoints,cn=WebADM,dc=mydomain,dc=com"
8. domains_container "cn=Domains,cn=WebADM,dc=mydomain,dc=com"
9. clients_container "cn=Clients,cn=WebADM,dc=mydomain,dc=com"
10. Update the time zone, where applicable
11. Save a quit
12. Restart the server ("reboot")
13. Login via the browser ("https://<ipaddress>")
1. User / DN: cn=Administrator,cn=Users,dc=mydomain,dc=com
2. Password: mypassword
14. Select "Setup LDAP Schema"
15. Select "Extend Schema"
16. Select "OK"
17. Scroll down and select "Create Default Containers and Objects"
18. Select "OK"
19. Logout and then login again using your AD account
1. Administrator
2. mypassword
20. Select the "Admin" tab
21. Select "Local Domains"
22. Select the CN=Default hyperlink
23. Change the object name from default to "mydomain"
24. Select "Rename"
25. Select the "Applications" tab
26. Under "Web Services -> MFA Authentication Server" select "Register"
27. Select a user account on the left-hand side
28. Select "Activate"
29. Select "Extend Object"
30. Under "Application Actions" select "MFA Authentication Server"
31. Select "Register / Unregister OTP Tokens"
32. Select "I use a QRCode-based Authenticator (Event-based)" and wait for the screen to refresh and display a QR Code.
33. Download a QR reader and Google Authenticator to your mobile device.
34. Use the QR reader to scan the QR code on the screen.
35. After the QR code has been scanned successfully, click "Register"
36. Select "OK"
37. Navigate to the "Applications" tab and select "Configure" under "Web Services -> MFA Authentication Server"
38. Scroll down and select "Apply"

Test the OTP User:

1.  Select the same user on the left-hand side that you previously assigned a token
2.  Under "Application Actions" select "MFA Authentication Server"
3.  Select "Test User Login"
4.  Enter your AD password under "LDAP Password" and select "Start"
5.  Launch Google Authenticator and refresh the token
6.  Enter the token in the "OTP Password" field
7.  Select "Continue"
8.  Click "OK" once successful
1.  If you are unsuccessful, go back and review the configuration steps above

Configure GlobalProtect to Use MFA:

*** The steps below assume that you already have a working GlobalProtect Configuration that leverages an LDAP profile for user authentication. If you are just getting started with GlobalProtect, see this post. ***

1.  In the firewall, navigate to "Device -> Server Profiles -> RADIUS" and select "Add"
1.  Name - OTP
2.  Under Server
1.  Click Add
2.  Name - OTP-Server
3.  Authentication Protocol - PAP
4.  RADIUS Server - "IP Address of your OTP server"
5.  Secret - testing123
6.  Confirm secret - testing123
7.  Port - 1812
3. Select "OK"
2. Navigate to "Device -> Authentication profile" and select "Add"
1.  Name - OTP
2.  Under the "Authentication" tab
1.  Type - RADIUS
2.  Server Profile - OTP
3.  User Domain - "mydomain"
3.  Under Advanced Tab
1.  Select "Add"
2.  Include All
3.  Select "OK"
3.  Navigate to "Network -> GlobalProtect -> Gateways" and edit your gateway
1. Make sure your OTP Authentication profile is selected and not your LDAP profile
2. Select "OK"
4.  Commit 

Test MFA from the Palo Alto Networks CLI

1.  Enter "test authentication authentication-profile OTP username <username> password" from operational mode
2. You should see the following output:
1. "Got challenge response, which is regarded as failed auth since "test auth ..." CLI command does not support it. User "<username>" is replied with msg "Enter your TOKEN password"

Test MFA from the user's smart phone with Google Authenticator

1.  Open Google Authenticator and generate a pin
2.  Open GlobalProtect, enter your username and password, and select "Connect"
3.  You will then be prompted to enter your pin and will be connected

Palo Alto Networks - NAT Issue

I ran into a NAT situation recently that I thought I would share. Here is the scenario:

Firewall Untrust IP: 1.1.1.1/24
Firewall Trust IP: 10.10.10.1/24
Web Server Public IP: 2.2.2.2/32
Web Server Private IP: 10.10.10.10/32

The web server should be publicly accessible. Here are the typical steps to make that happen:

• Create the NAT policy

• Create the security policies

• Commit the configuration

Even though the NAT and security policies are correct, you will notice that the web server is still not publicly accessible and it cannot access the Internet. You will also notice that if you look in the traffic logs it does not show any traffic. This is because the public IP assigned to the web server in not on a subnet that is assigned to an interface in the Untrust zone. In other words, the firewall doesn't know where to send traffic because the web server's public IP is not in the route table.

There are three options:

1. Create loopback interface with an IP of the web server public IP and assign it to the Untrust zone.
2. Create a sub-interface on the Untrust interface with the web server public IP and assign it to the Untrust zone.
3. Create a route using the IP of the web server public IP as the destination, with the interface assigned to the Untrust zone, and give it a next hop of none.

This forces the IP to show up in the route table and traffic will begin to route properly.

Palo Alto Networks - Ruckus 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 Ruckus Wireless, the integration happens via syslog. As users authenticate via 802.1X or captive portal with their credentials, this information is logged in the controller. We just need to share it with the firewall.

On the Ruckus controller(s):

1. Enable the Client Association option in the Debug Logs. This will allow ZoneDirector to log the client associations containing client login information and IP.
2. Enable syslog forwarding in ZoneDirector to the firewall's MGT IP or User-ID agent IP. 

On the Palo Alto Networks firewall:

1. Enable the MGT interface to receive syslog under Device -> Setup -> Management -> Management Interface Settings.
   
2. Navigate to Device -> User Identification -> User Mapping -> Palo Alto Networks User ID Agent Setup -> Syslog Filters -> Add.
3. Create a filter to recognize the syslog messages sent from ZoneDirector. 
1. Name: Ruckus Wireless
2. Type: Regex Identifier 
3. Event Regex: operation=(update|add){1} 
4. Username Regex: sta_name (?:=.*\\|=)([a-z]+);
5. Address Regex: sta_ip=(10\.[0-9]+\.[0-9]+\.[0-9]+); ## change this to reflect your IP range
   
4. Navigate to Device -> User Identification -> Server Monitoring -> Add
1. Name: Ruckus Wireless
2. Type: Syslog Sender
3. Network Address: (IP of ZoneDirector)
4. Filter: Ruckus Wireless
   
5. Commit

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.