Palo Alto Networks - Clientless VPN and RDP

With the 8.0 release of the PAN-OS operating system, the ability to access applications via web portal has now been added. This is sometimes referred to as "Clientless VPN." Prior to this release, some existing Palo Alto Networks customers may have been hesitant to fully migrate away from point products like PulseSecure or Aventail because they offer pretty robust capabilities around Clientless VPN. Although this capability is still relatively new to the platform and additional features will be added over time, I thought I would highlight how one can currently leverage Clientless VPN for remote access to a desktop.

In its current state, the Palo Alto Networks client-less VPN supports access to internal applications via web browser. With the development of HTML5, this means that we can leverage tools like Apache Guacamole. In this scenario, we are going to leverage this application.

• Chase Wright has a fully scripted version of the Apache Guacamole install for Ubuntu here. Just in case his site is not accessible for some reason, here are some of the details (I would recommend viewing all details/comments on his site):
• The following will install Guacamole 0.9.11, Tomcat 8, and MySQL for you. All you have to do is pick a MySQL Root Password and change the guacamole_user password

wget https://raw.githubusercontent.com/MysticRyuujin/guac-install/master/guac-install.sh
chmod +x guac-install.sh
apt-get update
apt-get -y install dos2unix
dos2unix guac-install.sh
./guac-install.sh

• You will be prompted to enter passwords for mysql.
• Reboot once the install is complete.
• Once rebooted, navigate to the GUI (http://<IP address of Ubuntu machine>:8080/guacamole)
• user: guacadmin
• password: guacadmin
• Within the GUI, you can add multiple multiple users, as well as add connection types, like RDP.
• Within the firewall, we will build upon my first GlobalProtect post, by adding Clientless VPN functionality.
• Navigate to Network -> GlobalProtect -> Clientless Apps -> Add
• Enter a Name for the Clientless Application
• Enter the Application Home URL
• This is the URL of the Apache Guacamole server
• Click OK

• Navigate to Network -> GlobalProtect -> Portals -> (Select the portal) -> Clientless VPN -> General
• Enable the Clientless VPN
• Enter a Hostname
• This should be the FQDN or IP address of the GlobalProtect Portal
• Select a Security Zone
• To keep things simple in this example, I have selected the zone in which the Clientless Application resides
• Select a DNS Proxy
• For more information on how to configure DNS Proxy, see this post

• Navigate to the Applications tab and select Add.
• Enter a Name
• Select the Application that was previously created
• Click OK

• Click OK
• Commit the configuration
• You can now test remote access to the application via Clientless VPN by navigating to the FQDN/IP of the GlobalProtetct Portal (https://<FQDN or IP>/)
• Once logged in, there will be an option to select the application

• Upon selecting the application, you will be redirected to the Apache Guacamole login page, and upon logging in, you will have successfully established an RDP session through your web browser

Palo Alto Networks - How to Import Address Objects from a .csv File

Although there are a variety of ways to accomplish this task, I thought I would put together a quick script to satisfy this particular requirement.

Let's say you are trying to migrate from a firewall that isn't supported via the Migration Tool, and you have 1000's of address objects. What would be a simple way to get this data imported into a Palo Alto Networks firewall from a .csv file?

Step 1:

Install Python and Jinja2 (easy_install jinja2 or pip install jinja2) on a machine (I did this on a VM running Ubuntu). Create a directory somewhere on the machine for the files you will be creating.

Step 2:

Rename your existing .csv file to "device_data.csv". Here is an example.

Step 3:

Create a jinja2 file called "conf_template.j2" with the configuration parameters and variables that reference each column in the .csv file. Here is an example.

Step 4:

Create a python script called "make_config.py" so that upon execution it will use the information from your jinja and csv files to create a configuration file. Here is an example.

Step 5:

Place all three files (.csv, .j2, and .py) in the directory you previously created.

Step 6:

Open the terminal and navigate to the directory where the files are stored (in Ubuntu, cd ~/Desktop/scripts/address-objects/)

Step 7:

Run the script (in Ubuntu, sudo python make_config.py). This will produce a file in the same directory called, "address_objects.conf". Here is an example.

Step 8:

Open the "address_objects.conf" file and copy and paste the contents into the cli of the firewall. Don't forget to commit the configuration.

In summary, this methodology can be applied in a variety of scenarios (here is one example), but the main goal is to save time and avoid doing things manually.

Palo Alto Networks - Application Prioritization

In many customer environments, administrators may not have the approval from management to block specific applications that are considered to be bandwidth intensive (Netflix). This is particularly evident in the education vertical. Fortunately for Palo Alto Networks users, QoS Policies are very flexible way of throttling or prioritizing traffic based on application, users, URL category, etc. This feature eliminates the need for 3rd party packet shaping or QoS for traffic traversing the network segment where the Palo Alto Networks firewall is deployed. Here is a configuration example based on the Netflix example above:

• Navigate to Network -> Network Profiles -> QoS Profile -> Add and create a QoS Profile. You can create up to 8 queues. In our example, we will just create one.

In the example above, we have an Egress Max of 100Mbps because that is the size of our WAN interface. We added class1 and assigned it an Egress Max of .01 Mbps. Essentially, even though the traffic is allowed the application itself won't work.

• Navigate to Network -> QoS -> Add and configure QoS for the appropriate interface(s).

In the example above, we have an Egress Max of 100Mpbs because that is the size of our WAN interface. We select ethernet1/2 for the Interface Name because this is our Trust interface. QoS is always applied to the egress interface for traffic. Since Netflix is a very download-intensive application, we will apply our Throttle Streaming Apps profile to this interface only. 

• Navigate to Policies -> QoS -> Add and configure a policy to identify the application and apply a specific QoS class.

In the example above, we are applying Class 1 to all Netflix traffic that originates from the Trust zone and is destined for the Untrust zone.

Once the changes are committed, you can then test and verify traffic classification by navigating to Network -> QoS -> Statistics.

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.

Junos Space Security Director - Part IV

The fourth part of this guide demonstrates how to configure SRX logging in Junos Space Security Director (version 14.1R3.4). It assumes that Junos Space, Security Director, an SRX, and a Log Collector are already deployed and operational. For steps on how to install Junos Space components, start here.

1. Navigate to Devices -> Device Management, right-click on the SRX and select Device Configuration -> Modify Configuration -> Security Logging
   
2. Set the mode to Stream (better for performance on the branch SRX and required on the high end SRX), the source address should be the IP address of the SRX, and the format should be sd-syslog
3. Click on the green "+" icon to add a new stream configuration
   
4. Select Deploy and review the configuration changes to be deployed
5. Select Approve and then Deploy
6. Click on the job to verify successful deployment

You will then begin to see logged events under Event Viewer.

Junos Space Security Director - Part III

The third part of this guide demonstrates how to import an SRX series firewall into Junos Space (version 14.1R3.4). It assumes that Junos Space, Security Director, and a Log Collector are already deployed and operational. For steps on how to install Junos Space components, start here.

1. In Security Director, navigate to Devices and select Click here to Discover Devices.
2. Follow the prompts to add a device target. In this example, we will add the SRX via its IP address.
3. Continue to follow the prompts to add options like ping, SNMP, and SSH as methods to discover the device.
4. Select Discover. Upon completion a status page will be displayed showing success.
   
   
   
5. Navigate to Security Director Devices to verify configuration/connection status, and the schema version in use.
1. If the schema version is out of date:
2. Navigate to Network Management Platform -> Administration -> DMI Schemas -> Update Schema
3. Select SVN Repository and then Configure
4. Enter https://xml.juniper.net/dmi/repository/trunk/ for SVN URL
5. Enter your Juniper Networks support credentials
6. Test the connection and then save
7. For Device Family select junos-es
8. Click Connect
9. Select the Junos version that matches the version installed on the SRX and click Install
10. Once installed, navigate back to Network Management Platform -> Administration -> DMI Schemas, select the OS version recently installed and then under actions select Set as Default Scheme
11. Navigate back to Security Director -> Security Director Devices to verify that the correct schema version is showing
    
6. Right-click the device and select Import
7. Select the policies to import (in this case we would import both NAT and Firewall policies, and click Next
8. A summary will be shown listing the configuration elements to be imported. Click Finish.
9. A summary will be shown listing the configuration elements that were imported. Click Close.
10. Navigate to NAT Policies, right-click on the SRX host name and select Assign Devices
11. Select the SRX host name and then select Modify
12. In NAT Policies, right-click the on the SRX host name and select Publish NAT Policy
13. Click Publish and then verify that it was successful
    
14. Navigate to Firewall Policies, right-click on the SRX host name and select  Assign Devices
15. Select the SRX host name and then select Modify 
16. In Firewall Policies, right-click the on the SRX host name and select Publish Policy
17. Click Publish and then verify that it was successful
    
18.  To test things out, navigate to Firewall Policies, click on the SRX, and then click on the green lock to edit.
19. Modify or create a policy (in my case, I changed an existing policy's action from permit to deny)
20. Click Save and the right-click the SRX and select Publish
21. Click on Publish and Update
22. Verify that the update was successful by viewing the job status and/or doing a show | compare  from operational mode in the CLI 
23. Don't forget to revert your change after testing is complete :)

The next post will show you how to configure logging for security policies.

Junos Space Security Director - Part II

The second part of this guide demonstrates how to add the Log Collector subsystem to Junos Space (version 14.1R3.4). It assumes that Junos Space and Security Director are already deployed and operational. For steps on deploying Junos Space and Security Director, see this post.

1. Download the Log Collector OVA image from the Juniper Networks support site.
2. Install the Log Collector image in your virtual environment. Refer to this Juniper document for details on how to size things.
3. Upon starting the VM, enter the following credentials:
1. root
2. juniper123
4. Change the password.
5. Follow the prompts to configure the following settings:
1. Configure IP address
1. eth0 pulls a dynamic address, which you can change to a static (i.e. 10.10.10.6)
2. eth1 is statically set by default. You can leave this alone.
2. Configure time zone
3. Configure name server settings
4. Configure ntp settings
5. Quit
6. In Junos Space, navigate to Administration -> Fabric, and select the green button to add a fabric node.
7. Name the node, type the IP of the collector, check the Add as a specialized node option, and enter the login credentials. 
   
8. Check the job status under Jobs -> Job Management. 
9. Once complete, log out and then log in again.

The next post will show you how to import and manage an SRX series firewall, and begin logging traffic.

Junos Space Security Director - Part I

The first part of this guide demonstrates the initial deployment of Junos Space and Security Director (version 14.1R3.4) in a virtual environment.

1. Download the Junos Space (OVA) and Security Director (IMG) images from the Juniper Networks support site.
2. Install the Junos Space image in your virtual environment. Refer to this Juniper page for details on how to size things. 
3. Upon starting the VM, enter the default credentials:
1. admin
2. abc123
4. Change the password.
5. Select "S" to install Space.
6. Configure the interface for eth0 to be used for management access (i.e. 10.10.10.5)
7. Configure the interface for the GUI (i.e. 10.10.10.100)
8. Junos Space will then be deployed, with the GUI showing the following:

9. Upon completion, enter the following credentials:
1. super
2. juniper123
10. Change the password.

11. Login using the new password.
12. Navigate to Administration -> Applications to add an application (green button).
    
13. Upload the Security Director image via HTTP.
14. Select the Security Director image that was previously uploaded and click Install, then OK.
• Note - If you navigate away from the upload page, you will have to navigate back to Administration -> Applications and click the green button again to see the uploaded application.
15. Navigate to Jobs -> Job Management to check the status of the install.
16. Once complete, log out and then log back in, and then navigate to Administration -> Applications to look at what was installed.

The next post will show how to add the Log Collector subsystem to Junos Space.

VPN Between a Dell SonicWALL and a Juniper Networks SRX

I have seen multiple people in forums asking how to setup a site to site VPN between a Juniper SRX firewall and a Dell SonicWALL firewall. I originally created this post to provide the steps to get things working. I noticed while working with a client that following the old steps no longer work. Below are the revised steps that I took to get it working, and is based on the following topology:

First we will configure the SRX:

Configure Interfaces:

set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.2/30
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.1/24
set interfaces st0 unit 0 point-to-point family inet

Configure Routing:

set routing-options static route 172.16.1.0/24 next-hop st0.0
set routing-options static route 0.0.0.0/0 next-hop 10.10.10.1

Configure VPN Parameters:

set security ike policy SRX-TO-SW mode main
set security ike policy SRX-TO-SW proposal-set standard
set security ike policy SRX-TO-SW pre-shared-key ascii-text thisismypsk

set security ike gateway SRX-TO-SW ike-policy SRX-TO-SW
set security ike gateway SRX-TO-SW address 11.11.11.2
set security ike gateway SRX-TO-SW external-interface ge-0/0/0.0

set security ipsec policy SRX-TO-SW proposal-set standard

set security ipsec vpn SRX-TO-SW bind-interface st0.0
set security ipsec vpn SRX-TO-SW ike gateway SRX-TO-SW
set security ipsec vpn SRX-TO-SW ike proxy-identity local 192.168.1.0/24
set security ipsec vpn SRX-TO-SW ike proxy-identity remote 172.16.1.0/24
set security ipsec vpn SRX-TO-SW ike proxy-identity service any
set security ipsec vpn SRX-TO-SW ike ipsec-policy SRX-TO-SW
set security ipsec vpn SRX-TO-SW establish-tunnels immediately

set security flow tcp-mss ipsec-vpn mss 1350

Configure Security Zones:

set security zones security-zone UNTRUST interfaces ge-0/0/0.0
set security zones security-zone UNTRUST host-inbound-traffic system-services ike
set security zones security-zone TRUST interfaces ge-0/0/1.0
set security zones security-zone TRUST host-inbound-traffic system-services all
set security zones security-zone TRUST host-inbound-traffic protocols all
set security zones security-zone VPN interfaces st0.0 host-inbound-traffic system-services all
set security zones security-zone VPN interfaces st0.0 host-inbound-traffic protocols all

Configure Security Policies:

set security policies from-zone TRUST to-zone UNTRUST policy TRUST-TO-UNTRUST match source-address any
set security policies from-zone TRUST to-zone UNTRUST policy TRUST-TO-UNTRUST match destination-address any
set security policies from-zone TRUST to-zone UNTRUST policy TRUST-TO-UNTRUST match application any
set security policies from-zone TRUST to-zone UNTRUST policy TRUST-TO-UNTRUST then permit

set security policies from-zone TRUST to-zone VPN policy TRUST-TO-VPN match source-address any
set security policies from-zone TRUST to-zone VPN policy TRUST-TO-VPN match destination-address any
set security policies from-zone TRUST to-zone VPN policy TRUST-TO-VPN match application any
set security policies from-zone TRUST to-zone VPN policy TRUST-TO-VPN then permit

set security policies from-zone VPN to-zone TRUST policy VPN-TO-TRUST match source-address any
set security policies from-zone VPN to-zone TRUST policy VPN-TO-TRUST match destination-address any
set security policies from-zone VPN to-zone TRUST policy VPN-TO-TRUST match application any
set security policies from-zone VPN to-zone TRUST policy VPN-TO-TRUST then permit

Configure NAT:

set security nat source rule-set TRUST-TO-UNTRUST from zone TRUST
set security nat source rule-set TRUST-TO-UNTRUST to zone UNTRUST
set security nat source rule-set TRUST-TO-UNTRUST rule SRC-NAT match source-address 192.168.1.0/24
set security nat source rule-set TRUST-TO-UNTRUST rule SRC-NAT then source-nat interface

Next we will configure the TZ:

Enable and add a VPN:

Navigate to VPN->Settings, and then check the box to enable VPN and then click Accept.

Add a new VPN by selecting Add... under VPN Policies on the same page. Enter parameters as shown in the subsequent screenshots for each tab, and then click OK.

That's really it. You can then enable or disable the VPN on the SonicWALL at any time via a checkbox next to the newly created VPN on the VPN->Settings page.

Monitoring the Tunnel:

On the TZ:

You can verify tunnel status by going to VPN->Settings, and looking under Currently Active VPN Tunnels. 

On the SRX:

To verify Phase1 is complete, from operational mode issue the following command:

show security ike security-associations

To verify Phase 2 is complete, from operational mode issue the following command:

show security ipsec security-associations

Juniper, Zero Touch Provisioning, and Raspberry Pi

Recently, a client had the need to replace about 500 switches at multiple remote sites. ZTP came to mind as a possible shortcut to getting this done with the littlest possible work effort. After doing some reading about automation and Junos, I started playing around with python, jinja, and yaml. During this time period, it turned out that a colleague of mine was actually going through the same exercise with one of his clients. Special thanks to Vince Loschiavo, who came up with a way to build device-specific configuration files while also leveraging ZTP. His Git repository can be found here, which goes over all the steps one must take to get things working. I would highly recommend reading through his, and other documentation prior to moving forward, but in a nutshell, here's how ZTP works:

1. By default, when a new Juniper switch's management interface is plugged in, it attempts to go through the ZTP process.
1. It requests an IP address.
2. It attempts to download and upgrade the Junos OS.
3. It attempts to download and install a configuration.

 This process can be manipulated to satisfy more complex requirements. Below is a brief overview:

1. A user scans/enters the MAC address of each switch's management interface into a CSV file, along with other device-specific data (i.e. host name, IP addressing, VLANs, etc.).
2. This CSV file is then placed on a server somewhere on the network where python, jinja2, apache2, the required Junos OS version, and a DHCP server are installed/loaded.
3. Two jinja templates exist on this server that allow for the generation of device-specific configuration files.
1. A configuration template that contains variables for all data that differs per device.
2. A DHCP reservation template that contains variables for certain device-specific information (i.e MAC address of a switch's management interface).
4. A single python script exists on this server, which when executed, analyzes the CSV file, generates configuration files, as well as creates DHCP reservations for each switch.
5. Upon plugging each switch into the network, the ZTP process is triggered, and switches are deployment-ready in minutes.

This is awesome! However, in my case the customer did not have a management network built, and time constraints would not allow it...

Discussing my constraints with Vince and other team members, we came to the conclusion that a small, portable mini-computer just might work for this type of scenario. Enter Raspberry Pi!

Together we were able to validate that a Raspberry Pi gets the job done. It is super cheap and can be powered via a USB port on a switch. Once everything is loaded and the python script is executed, it is very plug and play. The Raspberry Pi can then be shipped from site to site to perform OS upgrades and provision configuration data.

In effort to make things a little simpler for network engineers that would like to try this out, I have taken a snapshot of my 8GB microSD with all the necessary applications installed and configured. It even has a sample CSV file, and generated samples from the python script. If you would like a copy just let me know. If you would like to build your own, here is what I installed:

• Snappy Ubuntu Core - https://wiki.ubuntu.com/ARM/RaspberryPi
• apache2 - used to transfer files via http
• python - used to generate files
• jinja2 - used to create templates
• isc-dhcp-server - used to serve IP addresses
• openssh-server - used to allow SSH access

 Enjoy!