QoS on Palo Alto Firewall

Quality of Service on Palo Alto Firewall

Reference:

https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/quality-of-service/configure-qos

 1. The process of classification

Anyone who has prior experience of Modular QoS CLI (MQC) on Cisco IOS will know that you first classify traffic that needs to be prioritized against other types of traffic.

Similar logic is applied while configuring QoS on Palo Alto firewall.

The first step towards configuring QoS on Palo Alto firewall is to classify the traffic.

Palo Alto allows you to classify traffic based on several parameters like:

1.  Source zone
2.  Source IP/subnet
3.  Source user
4.  Destination zone
5.  Destination IP/subnet
6.  Application
7.  TCP/UDP service
8.  URL category

You identify the traffic that needs preferential treatment and assign it to a class.

On Palo Alto firewall, you have 8 classes of traffic; so your traffic will eventually fall in one of the eight classes.

Also in this step, you are able to leverage App ID and User ID features of Palo Alto to classify traffic.

 2. Create a QoS Profile

Let us say that you have classified youtube traffic into class1

When you create a QoS profile for youtube traffic, you can set:

a. Priority

There are four configurable priorities – real time, high, medium and low

Real time being most important.

 b.  Egress Max

Maximum bandwidth to be set for this class.

Traffic beyond this rate will be dropped. This is similar to policer mechanism in Cisco IOS.

c. Egress Guaranteed

Amount of bandwidth which is guaranteed at all times.

In below example, you are setting 6 Mbps maximum bandwidth for youtube traffic and also giving youtube traffic guaranteed bandwidth of 3 Mbps

 3. Apply the QoS profile on physical interface.

Here you simply apply the QoS profile created in Step 2 above to a physical interface.

 4. Verification

To ensure that your configuration is indeed working, you need to navigate to

Network – QoS – Statistics

Where you will be able to verify your configuration.

DNS Sinkhole feature on Palo Alto Firewall

DNS Sinkhole feature on Palo Alto Firewalls

References:

https://www.paloaltonetworks.com/content/dam/pan/en_US/assets/pdf/framemaker/60/pan-os/NewFeaturesGuide/section_3.pdf

https://www.sans.org/reading-room/whitepapers/dns/dns-sinkhole-33523


Why use DNS Sinkhole?

Picture this that you have infected hosts on your network that are connecting to malicious websites, websites and portals that are totally not secure. DNS resolution and DNS queries play a vital role here in such communication.

When there is a DNS query for malicious domain, Palo Alto firewall can identify this and cause malicious domain to be resolved to a SINK HOLE IP ADDRESS that you provide/configure.

Palo Alto supports both IPv4 and IPv6 DNS Sinkhole address.

Configuring DNS Sinkhole on Palo Alto Firewall:

DNS Sinkhole configuration on Palo Alto firewall is as simple as including DNS sinkhole IPv4 address in antisypware security profile on Palo Alto.

This security profile will then be called in a security policy on the firewall allowing outbound DNS communication.

Important note here is that sinkhole address should belong to a zone on firewall other than the zone where DNS query is received.

https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-DNS-Sinkhole/ta-p/58891

Content Filtering Techniques on Palo Alto Firewall

Content filtering techniques on Palo Alto firewall

1. URL filtering

URL filtering allows you to block web browsing based on URL category.

For example, you could block these categories available on Palo Alto - abused drugs, alcohol and tobacco, phishing, peer to peer.

Palo Alto also allows you to check URL category for a particular website.

'Check URL category' feature on Palo Alto firewall will redirect the user to a website where URL category can easily be determined.

You can also create a custom URL category and specify websites here in the URL category.

The URL category can then be controlled using actions like alert, allow, block, continue, override.

More on the actions is here

https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/url-filtering/url-filtering-profile-actions

Response pages is something where the user would see a particular HTML page.

And this page would notify the user that URL is not allowed as per the internal company policy.

2. Application based filtering

Palo Alto firewalls have the App ID feature.

This essentially allows users to block applications like dropbox, skype very easliy.

So when you configure the security policy on Palo Alto, you specify the application type in addition to other parameters like

a. Source zone

b. Source user

c. Source IP

d. Destination zone

e. Destination IP

f. Application - YOU SPECIFY THE APP HERE

g. LEAVE SERVICE TO APPLICATION DEFAULT

h. URL category

i. Action

j. Security Profiles

3. File blocking

Here you could block upload/download of specific file types like .exe, .pdf, .rar

And these file types could be blocked for specific applications like gmail.

Several actions are available namely:

a. Alert

b. Block

c. Continue

d. Forward

e. Continue and Forward

You may find more on these different actions here

https://www.paloaltonetworks.com/documentation/61/pan-os/pan-os/policy/file-blocking-profiles.html

Palo Alto - x forwarded for feature

Enterprise internet set ups incorporate systems like Proxy Servers.
Such systems help cache internet data and eventually save a lot of internet bandwidth and cost.

What do proxy servers additionally do?

a. Source NAT (SNAT) client IPs and source internet traffic from itself.
Here you are hiding/masking client IP address. Such mechanism prevents client IP addresses from being spoofed.
To sum this up, when IP packet passes through a proxy server, source IP field of the IP packet is modified and source is changed to be IP address of proxy server.

b. Along with this, the proxy server will add “x-forwarded-for” in the http GET request from the client and client IP address to this field.
So the original client IP information is retained in the IP packet using x-forwarded-for field.

Picture this now, your internet destined traffic coming out of the proxy server now flows through Palo Alto firewall deployed in transparent mode.

And the traffic flow is something like this

Client system - Proxy Server - Palo Alto firewall (transparent mode) - Internet Router - Internet Cloud.

And the return traffic will be
Internet Cloud - Internet router - Palo Alto firewall (transparent mode) - Proxy server - Client system

Now with a proper Security Incident & Event Management (SIEM) solution in place, traffic flowing through Palo Alto firewalls could now be logged.
And the x-forwarded-for option will reveal the actual client IP on the logging system.

The x forwarded for feature on Palo Alto is covererd here:


https://live.paloaltonetworks.com/t5/Learning-Articles/X-FORWARDED-FOR-Feature-in-PAN-OS-6-1/ta-p/53879

Usage of failover exec mate command in Cisco ASA

So, recently I came across this situation  where I had to check the TACACS shared secret on standby ASA without directly logging into it.

Reason being that the standby firewall just wouldn't let me log in directly.
Standby unit was earlier integrated with the AAA server.

My efforts of firstly removing the standby device from AAA server failed.

AAA server was throwing logs which suggested mismatching TACACS shared secret.

Cisco ASA has this handy command which you can execute from the primary ASA to get output from standby unit.

On the active unit, you can execute commands like

failover exec mate show run


You may log the session output to a file and check/verify your TACACS key provided it is not encrypted.