How to find application in Palo Alto (by tcp/udp ports)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

How to find application in Palo Alto (by tcp/udp ports)

L3 Networker

Dears,

I am working on a migration from Check Point to Palo Alto. We used that PA Migration Tool for CP rules into PA.

The main problem is all CP rules are based on services and we want to transform them into PA applications... BUT, the PA apps tool (applipedia) doesnt show the apps by ports...

SOmetimes is hard to uderstand the name of PA applications... and also we would like to know if there is a method to find PA application using ports numbers...

for example:

what is the PA Application name for service using TCP 5757 ?

right now we are searching on internet those aplications then relating with PA apps...

is there any easy way easy to do that ?

thanks in advance!!

1 accepted solution

Accepted Solutions

L6 Presenter

https://play.google.com/store/apps/details?id=ch.sourcenet.applipedia

Type 5757 and it will spit out:

msn-file-transfer

among other info:

Default ports: tcp/443, tcp/1863, tcp/1025-65535, udp/1025-65535

So I guess there is some API available to do these kind of searches...

Edit: Seems to be a custom API because a search for "tcp/5757" ends up with a http request for:

http://applipedia.sourcenet.ch/?app=tcp%2F5757

View solution in original post

10 REPLIES 10

L5 Sessionator

If there exits an application based on the port,you can find it using applipedia by simply typing the port number.

Application Research Center

L5 Sessionator

Navigate to monitor tab --traffic logs click on a port number and edit it, press enter you will see all applications for that port number.

L6 Presenter

https://play.google.com/store/apps/details?id=ch.sourcenet.applipedia

Type 5757 and it will spit out:

msn-file-transfer

among other info:

Default ports: tcp/443, tcp/1863, tcp/1025-65535, udp/1025-65535

So I guess there is some API available to do these kind of searches...

Edit: Seems to be a custom API because a search for "tcp/5757" ends up with a http request for:

http://applipedia.sourcenet.ch/?app=tcp%2F5757

L4 Transporter

One approach you might want to consider is to create the PA rules with services (ports) first like they were in Checkpoint.  Then as you see what applications are going out on the appropriate rule, you add the application to a duplicate rule above the services (ports) only rule. Based on the size add complexity of your rule base this may be an option.  We had a lot of special rules on our Checkpoint rule base to address applications that used the non-standard ports. These are the ones that were easily converted to Application based rules with service as "any".  I am assuming you are doing a in-place replacement as opposed to inline deployment followed by removal of checkpoint.

NEVER use "service:any", at least use "service:application-default" or if possible manually define the port/port-ranges to be used.

What's your rationale for not ever using service:any? One of the selling points that PA uses is that their firewall is "port agnostic" - App-IDs can be relied upon over TCP ports

The app cache pollution vulnerability that recently was an issue was fixed - they don't cache the App-ID anymore

We took the same approach as Hitsec when migrating from Check Point and it worked well for us.  We stared off with a policy that looked very similar to a Firewall-1 policy and then gradually Palo-ized it.  We always use "service: application-default" where possible when allowing applications and "service: any" when blocking them.

My first installation was done in a pretty simple manner which was (at the time, don't know if it still is) recommended by Palo Alto.

Three rules.

First rule - make an application group with applications you *know* the business requires - web browsing, SSL, whatever else. Apply URL/Virus filtering policy as defined, and then allow any/any to pass it.

Second rule - make an application group with applications you *know* the business does NOT require - bit torrent, TOR, nasties which the business doesn't want. Deny any traffic which matches.

Third rule - allow any/any, *but* mail yourself a report daily of everything which hits this rule, then use that report to refine your "good" and "bad" application list for a couple of months until you're happy you've caught everything - then  change this to a default deny.

Works, too. I cover probably 80% of my traffic with 2 rules. There are some other rules - mainly server or client specific ones (for example, I have one user who has a defined business need to be able to GRE tunnel out - he has a specific rule matched to his userID to allow it), but the rule base is not nearly as complex as a previous Checkpoint installation was!

App-IDs are still cached but the function has been modified.

Look at this video from Checkpoint (somewhat biased but still interresting):

Palo Alto Networks vs. Check Point - Did PAN "fix" the Firewall - YouTube

The point is the way App-ID works, depending on which App-IDs you have allowed, one or more packets will be let through the firewall in order to successfully (with low falsepositive rate) identify the application being used.

This can of course be bad if the packet(s) contain some vuln which the IPS currently doesnt have a signature for (given that you enabled IPS for these flows) - or for other reasons where you dont expect to see packets let through your firewall unless they are approved.

By using "service:application-default", or if possible, manually define which port is expected such as "service:TCP80" the packet must match the basics such as (srczone, dstzone), srcip, dstip and dstport before being inspected further to identify the application being used.

This precheck is defined in the workflow of what the PANOS will do to a packet that arrived to a PA box:

http://media.paloaltonetworks.com/documents/techbrief-app-id.pdf

If you use "service:any" this precheck will always fail (for the particular flow(s)) and exposing the service you actually is trying to protect. Or for that matter leak information in any direction.

The above is also confirmed by the security bulletin released due to the App-ID cache pollution case last xmas:

https://live.paloaltonetworks.com/docs/DOC-4315

"

App-ID Cache Pollution Avoidance Recommendations 

Do not use “any” as the service for allowed applications: 

It is Palo Alto Networks recommendation to use “application-default” or specific ports in the service field of the security policies. This prevents applications from running on unusual ports and protocols, which if not intentional, can be a sign of undesired application behavior and usage. Many of the evasion variants observed using the App-ID cache pollution would be addressed if “application-default” had been used in the security policies. All security rules with “any” in the service field should be double-checked and in most cases, should be modified to use a specific port or “application-default”. Note that the device still checks for all applications on all ports, but with this configuration, applications are only allowed on their default ports/protocols.

"

Thanks mikand for the well researched and informative post... I know I was "baiting" a bit by saying that PAN claims to be "port agnostic," and you provided the great response I was hoping to see Smiley Happy

  • 1 accepted solution
  • 15364 Views
  • 10 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!