Clarification about connection persistence and SK115871

[Albin_Petersson]

Helloes.

We have Rematch connections set in the options for Connection Persistence, on our gateway.

We figured it would remove the "additional engines" alerts in the logs, but it hasn't really made any difference.

When i read SK115871 it speaks of an additional option you can set in the firewalls, but could i get some clarification on what it actually means if it's turned off?

"Drop connection that were opened prior to policy installation and new policy can't be applied to them due to engines activated on the connection"

Would old connections be instantly dropped and unable to be renegotiated?

The bigger question would be why we still see so many alerts in the logs? it's been a while since we altered the setting for connection persistence and we figured they would ebb out.

[_Val_]

The SK article in question is related to a situation when you have advanced software blades: AC/URLf, AVI, Ani-Bot, Threat Emulation/Extraction, Content Awareness - enabled in your security policy.

Connection persistence filed is related to the classic FW security policy, where decision is simple, and the question is - what to do with the connections in progress that are no longer allowed by the new security policy. If you re-match, then connections that are now disallowed, will be dropped.

Now, let's say, you are moving from basic filtering to AC & Content awareness. Both SBs require streaming. For ongoing connections that you allow through connection persistence feature, streaming will fail, hence the log alert. 

The logic here is simple. Since building the full stream for ongoing connections is impossible, you can either accept them through the new policy (and alert about it), or drop, with up_rematch_accept_possible_action parameter mentioned in SK.

If you decide to drop, you are risking to break legitimate connections where stream is unavailable. 

[Benedikt_Weissl]

You are using AppControl/URL Filtering, right? AppControl works by scanning the first bytes of each new connection (SNI, HTTP-Header, etc) to detect the Application. Once you apply a new rulebase AppControl has to match old established connections to the new rules, but since the connection is already established its impossible to scan for certain markers e.g. the SNI Field. This is where the kernel parameter value "int up_rematch_accept_possible_action" comes in.


The SK says:

... "New" policy installation will trigger the rule base execution on the next packet, that will now require ‘Application Control' engine inspection on this connection in order to reach a final decision. This cannot be done for connections that are already open. The final action will be determined by the value of kernel parameter "up_rematch_accept_possible_action". Default value is "1", therefore the connection will be accepted."...

> Would old connections be instantly dropped and unable to be renegotiated?

Old connections would be dropped if you set int up_rematch_accept_possible_action to 0 and the firewall is unable to match them to a rule. I don't know what you mean by "renegotiated", but new connections should work provided they are allowed by the new rulebase.

> The bigger question would be why we still see so many alerts in the logs? it's been a while since we altered the setting for connection persistence and we figured they would ebb out.

You will see this alert for some time after a new policy has been installed because the gateway is trying to rematch old connections to a new rulebase.

[Albin_Petersson]

ok, then I understand better what it does.

Yes, we have AppControl/URLF. We actually have 2 near-identical rules, one where we would like to identify certain things with AppControl/URLF and one where we let through the rest with any as service.

with renegotiated I meant that the application would re-establish the session if it died. 

we've had this setting for at least 3 months and still see this error, so i don't feel like there should be any old connections left. But we can think about changing the fw parameter then. 

oddly enough this alert shows up a lot for normal microsoft-ds traffic. 

[_Val_]

"Old connections" here means those which were crossing through FW before the last policy was installed.