Palo Alto NGFW use case one: monitoring traffic (Tap mode)

All right, last time we did some basic maintenance of the Palo Alto Networks Next Generation Firewall. Let’s warm up with the very basic scenario, which is just monitoring network traffic to verify if it is in compliance with our security policy. As usual, here is our topology:

27-Aug-2014 10-35-19 AM

 

Let’s discuss briefly the scenario. We have two switches connected via trunk link. Each of them has a trunk port connected to physical Microsoft Hyper-V host which runs usual stuff: domain controller, SQL server, Exchange Server, Linux box, … These Hyper-V hosts are trunked to switches, because VMs running on these hosts belong to different VLANs.

Here is the configuration of the GigabitEthernet0/13 port on Switch181:

interface GigabitEthernet0/13
description Hyper-V Host 1
switchport trunk encapsulation dot1q
switchport trunk native vlan 199
switchport trunk allowed vlan 110,112
switchport mode trunk
spanning-tree portfast trunk

Nothing special about this. Similar to this is GigabitEthernet0/14 on Switch201 for another Hyper-V host:

interface GigabitEthernet0/14
description Hyper-V Host 2
switchport trunk encapsulation dot1q
switchport trunk native vlan 199
switchport trunk allowed vlan 110,112
switchport mode trunk
spanning-tree portfast trunk

Please have in mind that everything said in this blog applies also to ESXi hosts as well. It’s just that I have Hyper-V hosts at my disposal at this time.

And the trunk port between our two switches is also trivial:

interface GigabitEthernet0/24
switchport trunk encapsulation dot1q
switchport trunk native vlan 199
switchport mode trunk

Ok, enough with the Cisco for now ūüôā

Palo Alto NGFW is capable of being deployed in monitor mode. In this mode, we declare one of its interfaces as a “TAP interface“, assign it to a security zone and create a security policy we want to be checked.

First, let’s create a security zone our tap interface will belong to. Under Network we select Zones and click Add. Then we fill the dialog in:

27-Aug-2014 9-24-09 AM

We give the zone a name TAP_ZONE and click OK. Then we select appropriate interface under Network->Interfaces:

27-Aug-2014 9-21-58 AM

And make it a tap interface belonging to a security zone TAP_ZONE:

27-Aug-2014 9-25-00 AM

Now we will adjust security policy in a way that we disable default rule, create our own rule and place it at the top of the list. When creating rule, we only need to specify the source and destination zones, both of which are TAP_ZONE:

27-Aug-2014 9-28-17 AM

It’s time to commit our changes. While that’s cooking, let’s go back to Cisco switch and create a SPAN session. This is easy:

monitor session 1 source vlan 110
monitor session 1 destination interface Gi0/15

First line says that we want to capture the traffic from VLAN110 and whatever we capture, we send to port GigabitEthernet0/15, where our tap port is connected. We can verify our setup on Palo Alto by going to Monitor->Logs->Traffic:

27-Aug-2014 1-09-21 PM

We can see that traffic is being logged.

Our present security policy does not log any malicious activities, such as browsing unwanted sites or downloading malware. ¬†Let’s try downloading Eicar virus test file and see if we will catch that. We can try one of download options here:

http://www.eicar.org/download/eicar.com

Our Windows SmartScreen filter or another AV product will warn us about this, but Palo Alto will not log this event. This can be verified under Monitor->Logs->Threat.

We can also browse some unwanted sites and nothing will be reported under Monitor->Logs->URL Filtering.

We missed to log these activities¬†because we don’t have any security profiles attached to our security policy. For the sake of simplicity, let’s just attach default URL Filtering and Antivirus profiles to our policy. Under Policies->Security we click our rule in the Profile column which now states “none“:

27-Aug-2014 1-20-28 PM

And select default URL Filtering and  Antivirus profiles. We could also attach other profiles as well:

27-Aug-2014 1-23-02 PM

Now instead of “none”¬†we see our two profiles attached:

27-Aug-2014 1-24-51 PM

Let’s commit our changes…

After committing our changes, we again try to download the Eicar test file and browse some unwanted sites. The results are now different:

27-Aug-2014 1-29-49 PM

27-Aug-2014 1-32-20 PM

This is very important: although actions are deny and block-url, in tap mode we cannot block anything because we are working with a copy of traffic. These actions just allow us to see if our traffic is in compliance with our security policy.

Let’s go back to Cisco world. Up till now our Hyper-V host and Palo Alto tap interface were on the same switch and we used classic SPAN session. Let’s now imagine that our Hyper-V and tap port are on separate switches. In this case we would need another feature called RSPAN, or Remote-SPAN session. In order to do that, we first need to create dedicated VLAN and make it of type “remote-span”. This must be done on both switches, unless we are using VTP:

conf t
vlan 75
name RSPAN
remote-span
end

We now want to capture traffic from Hyper-V host on switch Switch201 and send it across trunk link to Switch181 and our Palo Alto tap interface. First, the source switch:

monitor session 1 source vlan 110
monitor session 1 destination remote vlan 75

We are capturing traffic from VLAN110 and sending it to our RSPAN VLAN. As long as this VLAN is allowed across the trunk link between two switches, this traffic will reach the destionation switch. On that switch we create yet another RSPAN session:

monitor session 2 source remote vlan 75
monitor session 2 destination interface Gi0/15

The logic here is this: we take what we received within our RSPAN VLAN and send it to our tap interface.

Let’s verify our configuration by¬†visiting another unwanted site:

27-Aug-2014 2-01-35 PM

And sure enough, we can see unwanted traffic.

This blog’s takeaway: with the tap mode deployment we can evaluate our security policy before putting it in production with Palo Alto deployed in a way it can actually block unwanted traffic. About deploying the PA such that it actually can block traffic some other time.

Thanks for reading.

 

 

 

 

 

Advertisements
This entry was posted in Firewall, Paloalto, Security and tagged , , , , . Bookmark the permalink.

4 Responses to Palo Alto NGFW use case one: monitoring traffic (Tap mode)

  1. Alfalin0 says:

    Nice explanation, is really helpfull. Thank you for your time popravak!

  2. Blash says:

    Good stuff! thanks

  3. Karthikeyan says:

    Great work !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s