Application vs Service? Specific to traffic being classified as APPs using the same 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.

Application vs Service? Specific to traffic being classified as APPs using the same ports

L4 Transporter

I use both but running into an issue with Lab specific traffic where I will allow a list of applications with service set to ANY but the PAN classifies some 443 traffic as (for example) 'windows push notification' or 'soap' but I am not allowing either of those APPs so it drops it. I am allowing web-browsing and windows push/soap both use tcp/443 so it seems to be classifying 443 traffic as any application that may or may not use tcp/443. How do I get around having to allow every application that may or may not use 80/443 or any other ports for that matter?  I tried setting it to application-default but it still seems to be happening.   Not doing any SSL decryption.  

 

What is odd is this seems to be a new problem for me since going to 8.1 from 8.0 for the longest time. Not sure I have run into this before and presently managed roughly 10 HA pairs of PANs across our environment.

1 accepted solution

Accepted Solutions


@drewdown wrote:

I get the whole concept and I am using app-ids on the permit statement and denying everything else across this environment so its not that.  What I didn't get is that if I did that and didn't allow whatever traffic pattern was being matched it would be dropped.  I assumed, albeit incorrectly, that if I allowed 80/443 and curl uses 80/443 and there is no 'curl' app-id it would be allowed.  


You're still missing a bit when it comes to the concept.

 

If you allow 'web-browsing", then it will only allow traffic that matches the "web-browsing" application.  Doesn't matter what generates the traffic (CURL, wget, telnet with manually entered HTTP commands, a web browser, something else), if it matches the "web-browsing" application pattern, then it will be allowed through.

 

Once it has identified the traffic, then it looks at the ports that are being used and checks those against the Service part of the Security Policy.  If it's set to "application-default", then (for web-browsing) it has to be on port 80.  If the traffic is on any other port, even if it matches the web-browsing pattern, it will be blocked.  If you set the Service to some other port (say 8080), then it has to match that as well.  (web-browsing on port 443 is only matched/shown for firewalls doing SSL decryption; otherwise it shows up as "ssl")

 

So, if you are using curl to connect through the firewall and it's not matching the web-browsing application, then it's not generating traffic that matches the web-browsing application pattern.

 

When using AppID, the port used only matters when the traffic matches the AppID already.  The AppID doesn't "allow all traffic on those ports", it only allows "traffic that matches this pattern, on these ports".

 

 

Easy way to look at is, if you don't care about the application, leave it at "ANY" and filter based solely on protocol and port.

View solution in original post

11 REPLIES 11

Cyber Elite
Cyber Elite

Hello there.

 

So, I am reading your query a few times, and trying to wrap my head around it.

 

It appears that you you are allowing web-browsing, believing that it will match multiple types of port 80/443 traffic, and I think/believe this is the issue.  The AppID uses signature patterns to match what traffic is really going through the FW.   For example, Gmail, hotmail,Yahoo Mail, and Xfinity web mail, all use port 443.  But the FW is able to determine which traffic is using the applications, by its app-id signature.

Would you want/expect Gmail to be used on the Hotmail/Outlook website? NO... so you do not have a policy for that, right?

 

So if you see windows-push, then it is (from my experience) the correct window-push, using 443.  Do you want window-push to be allowed?  If yes, then create/modify a rule to allow the window-push (on app-id).

 

The FW is designed for explicitly deny, so any traffic that you do not match, will be denied. I think this what you are saying.

 

Application Default is just the default service port that an app is normally expected to be found on.

For example, do you want DNS on port 5503? No, so you would DNS only on application-default (service port of 53)

 

Screen capture help, if you feel comfortable to share, but to answer your question, I do believe PANW made changes between 8.0 and 8.1, which may be why you are seeing these types of issues.  Respectfully, I think you may need to adapt your security rules.

 

What other questions can we answer for you?

 

Help the community: Like helpful comments and mark solutions

Yeah that is pretty much it. 

 

I understand it now but I guess I was just assuming if I allowed 80/443 via 'web-browsing' then it would allow all 80/443 and not try and match the traffic to a specific application-id.   Having only recently gone to 8.1 and this being a new deployment using the same thought process as the previous ones it was odd to me that it broke a fair amount of connectivity based on not allowing whatever APP the PAN was classifying it as.

 

For instance users were trying to curl www.google.com and the PAN was classifying that as 'google-base' but I would never equate curl to google-base (no curl app-id) so I would have never allowed it.  Its only when I looked at the logs I saw what it was doing and once I allowed google-base the curl commands worked.  

 

Anyways if I wanted to allow outbound 80/443 and not match any application how would I do that?  

Hello again.

 

With all respect... you have a L7 FW, you should WANT to match all apps using the correct application vs L3/L4 port and protocol rules.

What was the purpose of moving from a traditional FW to a NGFW, if you are looking to use the simliar wide open, policies.

 

Bad apps such as bittorrent, proxy anonymizing apps are all using 443 ports.  You should determine what apps you do NOT want to go across the FW, and then allow only those you DO want.  There are 3100 apps.  Do you really need all 3100 apps through the FW?  Maybe you can look at past reports to see what apps are really being used vs opening up all of them.

 

It is definitely against against all best practices to allow "app any" "service 80/443" ports.

 

My suggestion is this.

After the very bottom of you policy, create a policy for allow ALL (so app any, service any)

Then create a policy above that, that allows any app, as long as it is using the correct application-default service ports.

 

You will see more hits on your "app-id" rule than your L3/L4 rule.  😛

 

Then you can start to determine what types of apps do NOT need to go through the firewall (high risk apps, gaming apps, proxy anonymizer apps, etc), and you can start to create good vs bad app policies.

 

This is way more secure than what you are trying to do, and we will all encourage you NOT to do just port/protocol rules.

Help the community: Like helpful comments and mark solutions

I wish I could remember what our PA rep told me about actual application-id adoption rate, but it was something paltry at best across the board.  Either way I know how to configure them and I think you missed the point of my argument.  Which was why is curl being classified as google-base?  I was also simply asking how to allow 80/443 and NOT classify the traffic at the same time.  Whether I do that or not is really up to me.  

@drewdown I think that you are missing the whole concept of Palo Alto Applications. The AppID is at the core of the firewall techology and classification can not be turned off. You can choose to ignore it, or override it, but traffic will always be classified as an App. 

 

Regarding you other question, maybe the word "Application" is confusing, but it referes to the actual traffic pattern and will not necessary match the sofware you use on your computer. You do not "classify" curl, but the traffic is  be clasified as google-base, regardless of if you are using curl, firefox or chrome or any other browser.  

I get the whole concept and I am using app-ids on the permit statement and denying everything else across this environment so its not that.  What I didn't get is that if I did that and didn't allow whatever traffic pattern was being matched it would be dropped.  I assumed, albeit incorrectly, that if I allowed 80/443 and curl uses 80/443 and there is no 'curl' app-id it would be allowed.  

You can't prevent the classification (log entries), but you don't have to use AppID.

 

Set the Application to ANY in the rule, set the Service to use tcp-443 and tcp-80, and you're done.  Any and all traffic that uses TCP on ports 80 and 443 will be allowed through the firewall.  And, in the logs, you will see what the firewall IDs the traffic as (application), in case you want to start using AppID in the future.

 

Simple as that.

 

We try to use AppID on as many rules as possible.  We have some devices, though, that don't fully match the algorithm used by PA for determining the application, so we have some rules which are just Services, no Applications.  Legacy heating panels, printing from OpenVMS, telnet for legacy video conferencing equipment, and a handful of others are one that don't work with AppID, for us.


@drewdown wrote:

I get the whole concept and I am using app-ids on the permit statement and denying everything else across this environment so its not that.  What I didn't get is that if I did that and didn't allow whatever traffic pattern was being matched it would be dropped.  I assumed, albeit incorrectly, that if I allowed 80/443 and curl uses 80/443 and there is no 'curl' app-id it would be allowed.  


You're still missing a bit when it comes to the concept.

 

If you allow 'web-browsing", then it will only allow traffic that matches the "web-browsing" application.  Doesn't matter what generates the traffic (CURL, wget, telnet with manually entered HTTP commands, a web browser, something else), if it matches the "web-browsing" application pattern, then it will be allowed through.

 

Once it has identified the traffic, then it looks at the ports that are being used and checks those against the Service part of the Security Policy.  If it's set to "application-default", then (for web-browsing) it has to be on port 80.  If the traffic is on any other port, even if it matches the web-browsing pattern, it will be blocked.  If you set the Service to some other port (say 8080), then it has to match that as well.  (web-browsing on port 443 is only matched/shown for firewalls doing SSL decryption; otherwise it shows up as "ssl")

 

So, if you are using curl to connect through the firewall and it's not matching the web-browsing application, then it's not generating traffic that matches the web-browsing application pattern.

 

When using AppID, the port used only matters when the traffic matches the AppID already.  The AppID doesn't "allow all traffic on those ports", it only allows "traffic that matches this pattern, on these ports".

 

 

Easy way to look at is, if you don't care about the application, leave it at "ANY" and filter based solely on protocol and port.

Again I get all that and I don't expect it to be perfect but when I want to allow CURL and to do-so I need to allow google-base that can be confusing to me and I am sure others.  Granted PA does make it easy to see what its doing and allow the appropriate app-id.  

Drew

 

I believe (respectfully) that you are thinking curl should have been an app-id (or something).

 

Your original comment was

For instance users were trying to curl www.google.com and the PAN was classifying that as 'google-base' 

 

 cURL is a tool to transfer data from or to a server, and the pattern that was seen was to the host-header of google.com.

Therefore, what the person is doing, is google-base.

 

If someone wanted to curl to facebook.com,. you would need to allow facebook-base

If someone wanted to curl to yahoo.com, you would need to allow yahoo-base.

Same if someone wanted to curl to your sharepoint site, you would allow sharepoint, probably ssl, and additional app-id defined apps.

 

I know you understand it, so I am not sure we can answer anymore to the degree you are looking for.

 

 

 

Help the community: Like helpful comments and mark solutions

Yeah pretty much.  

 

I think this thread has run its course, thanks everyone for the insight.  

  • 1 accepted solution
  • 16143 Views
  • 11 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!