APP-ID Doubt

[marcelocampos]

hello community,

I have a question that I have not been able to solve with the study material and it keeps breaking my head.

Here it goes, when I generate an application-based security policy, for example from "trust" 10.xxx to "untrust" any
with app anydesk specification (with the ssl dependency), I see the corresponding traffic between the internal lan and the destination on the internet corresponding to anydesk is fine, but here comes the doubt, I see traffic to other addresses by ssl but the record indicates that the application is incomplete (understanding that after the 3-way handshake there is no more packets) can I assume that traffic is not establishing a session and that the policy is doing its job of accepting "ANYDESK" and denying everything else?

As long as the application output is incomplete, that traffic is not being established even though the traffic log indicates allow?.

And the last one, when I configure a security policy towards any internet, only specifying the application and its dependencies, am I opening a communication flow towards any destination according to the applications and dependencies?

example a conection ssl to microsoft destination can forward by the policy maked for anydesk? 

Thank you in advance for your guidance and clarification.

[Chacko42]

Hi,

when you build a policy trust > untrust app anydesk&ssl, then ssl is allowed for untrust:any.

In that case you do well, by restricting the public IPs to the relevant ones.

Especially microsoft is difficult, but for the dynamic and automation, you can generate an EDL with minemeld (a free PAN tool).

incomplete means, the Three-Way-Handshake didn't finish - that can be only a SYN or a SYN, SYN, ACK.

If the Security Policy is on allow and the traffic correclty natted, it's typically a problem with the website you're accessing.

[BPry · Accepted solution]

@marcelocampos,

can I assume that traffic is not establishing a session and that the policy is doing its job of accepting "ANYDESK" and denying everything else?

That's not really correct. Incomplete traffic is simply caused by the three-way handshake not completing, or by traffic which doesn't pass enough traffic for the application to be identified. Once enough traffic is passed to actually identify the traffic properly however, the traffic would be re-analyzed and no longer match your security rulebase entry allowing anydesk traffic. 

And the last one, when I configure a security policy towards any internet, only specifying the application and its dependencies, am I opening a communication flow towards any destination according to the applications and dependencies?

example a conection ssl to microsoft destination can forward by the policy maked for anydesk? 

This depends on how you have your security rulebase actually built out. If you included the application members [ anydesk ssl ] to satisfy the dependency within the same policy, then you are by virtue allowing all traffic identified as ssl through this policy. As long as you are satisfying the application dependency somewhere in your rulebase, you don't need to include ssl within the anydesk entry and can just leave the application as anydesk. 

I wouldn't really worry too much about the incomplete traffic; that will be allowed in your rulebase as soon as you add a security entry utilizing app-id, the traffic will just match the first rule which allows it access across that zone. 

For your next question I would generally recommend not including common dependencies directly in your AnyDesk rule, because it's likely already being satisfied in your rulebase. Just have leave anydesk in this security entry, so that the rule being hit actually makes sense (IE: AnyDesk traffic matches your AnyDesk allow entry, while SSL traffic matches your general browsing access).

Hopefully that helps make things a bit more clear. 

[marcelocampos]

Hi, @BPry 

You have helped me a lot, with the explanation now it is clear to me!

Thank you very much!