My question is based the following document.
The case on above document is allowing rule.
I wonder another case when there is a blocking rule with service any how traffics are matched.
There are rules as below image.
I have found some odd traffic logs out as below screenshot.
There are traffic logs application are incomplete and insufficient-date else bittorrent.
I do not understand why these traffics were matched torrent's rule.
I expect traffics wiil be matched this rule after identified bittorrent application when blocking rule case.
Probably, Were traffics matched by application cache?
I think application cache affect it happened.
How do you think it?
And I need your help.
These sessions are potential matches for the block torrent rule so the PA must keep track of them until the application is confirmed as torrent or not.
If they do become recognized as torrent they will drop at that point. But all the previous packets until classified as torrent were permitted.
In your case the sessions ended before classification as any application could occur so they are logged as unknown or incomplete ended sessions.
Hello Steven Puluka,
Thanks for your answer.
I understand your detail explanation.
But my customer does not want to allow any traffic on blocking rules.
I had tested about it on another case.
I sent a only syn packet to another destination IP else matched torrent rule IPs on traffic logs.
This packet was matched allowing on "any any allow" rule, not torrent rule.
So I think PA remember destination address and application and then when packets of same destination address receive, PA keep theses packets on previously matched rule by using application cache and allow it on this rule before identified application.
So I expect if application cache was disable, packets before identified application will be matched "any any allow" rule. PA never allow any packet on blocking rule.
Would be it right? If my thought is wrong, I hope to get your help.
Have a look at the Packet Flow process chart in this document.
The App Cache is a short cut to preliminarily identify a connection as an application prior to getting that identification from the actual packet content inspection match. This verdict can be updated by the actual stream as the session develops as seen in the flow check. Anything logged as unknown and incomplete has not be identified by any engine as of the end of the session.
With application identification on random port services like bittorrent really do have no choice but to behave in this fashion. The PA must see enough of the traffic to positively identify the traffic. So these initial few packet streams must be allowed until the bittorrent can be identified and the session dropped.
First, I want you know I don not speak English very well.
I understood your mention.
But I just want to know results on two cases what rule is matched.
There are only two rules.
rule1 ; source address any ; destination address any ; application bittorrnet ; service any ; action allow
rule2 ; source address any ; destination address any ; application any ; service any ; action deny
in this case, you and I knew what packets before identified application are matched to rule1 and then PA will allow them.
Packets After identified application are matched to rule2 and then PA will deny them.
If session ended before identified application, PA will record as below log on traffic logs.
"application incomplete or insufficient-data ; action allow , rule1"
There are also only two rules
rule1 ; source address any ; destination address any ; application bittorrent ; service any ; action deny
rule2 ; source address any ; destination address any ; application any ; service any ; action allow.
I tested packets are matched what rule before indentified application.
So I sent only syn-packet and not successful for 3-way handshake.
I checked traffic logs and looked this a packet was matched to rule2 with incomplete. NOT rule1 with same "service any".
Is it right?
If yes, my customer said there are "incomplete" and insufficient-data" logs on rule2 be allowed.
So I do not understand why it happen and I need your help.
In both cases the incomplete sessions are allowed through the firewall the the question from the PA logging engine is where to mark those sessions in the logs.
In the first case, you clearly cannot log them with rule 2 because this is a final deny all policy, and we allowed the packets so they must log on rule 1.
In the second case we have a final permit all policy. So there is a clear match of permit for these incomplete sessions and no need to show that the application block rule is permitting the traffic. This traffic is allowed by rule 2 even if the application block rule did not exist. So we log the sessions on rule 2 as a better match.
The important note here is that application based rules are not as instantaneous as port based rules. There needs to be some actual packet data to determine the application match that may take some time to occur. As a result application based block rules do permit small amounts of packets on the flow before stopping the traffic once correctly identified. The PA logging is set up to give you visibility to these permitted partial flows in the rules.
Thanks for your kind answer.
I wrote wrong for case2.
I mentioned the following sentences
If yes, my customer said there are "incomplete" and insufficient-data" logs on rule2 be allowed."
I wanted to say "If yes, my customer said there are "incomplete" and insufficient-data" logs on rule1 be allowed." not rule2.
I am so sorry. and I appreciate your watching patient for my question.
The important note here is that incomplete and insufficient sessions are permitted when you use this type of rule construction. So once we want to identify and block by application we do have to accept that short packet counts before the application is identified will be permitted.
the only question is where will those sessions log. You cannot drop them before identification.
In the case you outline now the PA is using the first match logic to log the traffic. As we look at the rule set they are processed from top down and first match stops processing. So using this logic PA is logging your incomplete/insufficient data sessions are hitting the application based rule.
It was my understanding that incomplete/insufficient data (ie, sessions where a few packets were let through, but not enough for an app-id) would match the first allow rule with a service of any (or an allow rule with an app that happens to have the same default port). In his screenshot it seems they are matching a deny rule, which is weird -- although I could've been wrong in my thinking.
Should they match a deny rule?
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!