Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Insufficient data but still allowed the returning traffic to pass

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Insufficient data but still allowed the returning traffic to pass

L0 Member

Hi ,

 

We have a policy that has specific APPs and Service is any and I know that is permissive rule because it will match a lot of traffic until FW identify the APP . 

 

But , a user is testing through linux to see if the firewall is opened , test it with telnet for example and is responding that the port is open and is matching the security policy with a log of insufficient data .

 

My concern here is that since APP-ID is not listed on the security policy why is allowing returning traffic ? 

 

Then the user tests the real application from the source to destination and of course it doesn't work because the FW identifies the APP from the first packet .

 

For example : 

 

APPLICATION in security policy is mssql ,oracle , rpc. 

Service ANY 

 

The fw correctly matching the source IPs and destination IPs including zones .

User tests a telnet from source to destination and looks open .We take packet capture and we see that returning traffic is working and we have 4 packets . 

 

Since that APP is not identified , shouldn't the firewall to allow to pass the traffic but block it since it doesn't have data to see the APP ? 

 

I know that this is expected on matching rules with APP-ID and service any but I was not expecting that returning traffic will work as well. 

 

Also this is a problem for engineers who test before they submit a firewall request because they might test it with telnet and they will see that is working but then the real service app will not work. 

 

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@Gggg,

Same basic principal applies in this case even with the context, you can't just block any return traffic and still identify the application properly. You have applications specified with a service of any, so the rule needs to allow enough traffic to attempt to see if the traffic will match one of the specified applications. This is expected behavior with app-id and is exasperated by setting the service to any instead of application-default or specifying specific services.

 

Testing if the firewall is open via telnet when the firewall is doing L7 rules is no longer a valid test. I'd tell everyone that you need all requirements when they're updating/changing things. If you follow dev/test/prod promotion practices you could be slightly less restrictive in dev so you can get rules identified and pushed out to test/prod. Using telnet and saying "this port is open across the firewall" just isn't an effective test anymore.

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

@Gggg,

This is expected on any application based rule. The firewall needs to allow enough traffic to pass to identify the application, if it doesn't pass enough data to do so you'll end up in this situation.

Hi ,

I saw that you replied without context , I accidentally posted without info inside .

 

Can you check what I have posted now ? 

Cyber Elite
Cyber Elite

@Gggg,

Same basic principal applies in this case even with the context, you can't just block any return traffic and still identify the application properly. You have applications specified with a service of any, so the rule needs to allow enough traffic to attempt to see if the traffic will match one of the specified applications. This is expected behavior with app-id and is exasperated by setting the service to any instead of application-default or specifying specific services.

 

Testing if the firewall is open via telnet when the firewall is doing L7 rules is no longer a valid test. I'd tell everyone that you need all requirements when they're updating/changing things. If you follow dev/test/prod promotion practices you could be slightly less restrictive in dev so you can get rules identified and pushed out to test/prod. Using telnet and saying "this port is open across the firewall" just isn't an effective test anymore.

L4 Transporter

Hello,

Your criteria's:

                    APPLICATION in security policy is mssql ,oracle , rpc. 

                   Service ANY

will match all the traffic until a few packets will go thru your firewall.

First you need to understand why you are seeing Insufficient Data: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClibCAC 

Then, every application has standard protocol and ports and maybe an inter-dependency.

https://applipedia.paloaltonetworks.com/ 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClV0CAK 

In your particular case, I recommend doing at least two thinks:

  1. replace service ANY with APPLICATION-DEFAULT
  2. put msrpc into a separate security policy because it using dynamic ports (tcp/dynamic,udp/dynamic) and add extra criteria in that security policy (like: source IP, destination IP, source user if you can)

And try to avoid using msrpc (it's a application container) because once you allow the container, you are allowing everything from that container.

msrpc.png

 

Cheers,
Cosmin

Don't forget to Like items if a post is helpful to you!
Please help out other users and “Accept as Solution” if a post helps solve your problem!

Read more about how and why to accept solutions.
  • 1 accepted solution
  • 2208 Views
  • 4 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!