SRX Services Gateway
Highlighted
SRX Services Gateway

Help with new Unified Security Policy - Applications as match criteria

‎11-13-2018 09:56 AM

We saw the new unified security policies that were released with 18.2 and wanted to test them out thinking it would help some of the issues we have had with the appFW before and for easier creation of security policies with applications as part of the match criteria. I know this is pretty new so not sure how many people are utilizing this.

 

In or scenario for easy testing, we want a security policy that permits the SIGNAL private messenger app with no SSL proxy enabled.  My assumption was that we could create a security policy with the match for the SIGNAL app and not apply the SSL proxy under the advanced services. SSL proxy is enabled on our default rule which breaks the cert pinning in the signal messaging app. This kind of scenario for us seems to be common with pinned certs in an application and attempting to exclude it from inspection.

 

In our test, we have a SRX340 running 18.3R1.9 and I have a security policy as listed below..... This is not working or matching in the logs. In the logs I can see it identifies the applciation as SIGNAL-PRIVATE-MESSENGER. The traffic never hits this policy and instead hits the default rule we have created. Yes, this rule is in higher sequence than the default outbound rule.

 

policy SSL-Exempt-Apps {
    match {
        source-address lan-net;
        destination-address any;
        application any;
        dynamic-application [ junos:SIGNAL junos:SIGNAL-PRIVATE-MESSENGER ];
    }
    then {
        permit;
        log {
            session-close;
        }
    }
}






<14>1 2018-11-13T11:58:14.531-05:00 Alpha-SRX340-AT29686712 RT_FLOW - APPTRACK_SESSION_CLOSE [junos@2636.1.1.1.2.135 reason="TCP FIN" source-address="x.x.x.x" source-port="1479" destination-address="52.203.236.220" destination-port="443" service-name="junos-https" application="SSL" nested-application="SIGNAL-PRIVATE-MESSENGER" nat-source-address="x.x.x.x" nat-source-port="10439" nat-destination-address="52.203.236.220" nat-destination-port="443" src-nat-rule-name="source-nat-rule" dst-nat-rule-name="N/A" protocol-id="6" policy-name="Default_Outbound_Traffic" source-zone-name="trust" destination-zone-name="untrust" session-id-32="15210" packets-from-client="6" bytes-from-client="644" packets-from-server="7" bytes-from-server="1872" elapsed-time="2" username="testuser" roles="testgroup" encrypted="No" profile-name="N/A" rule-name="N/A" routing-instance="default" destination-interface-name="ge-0/0/0.0" uplink-incoming-interface-name="N/A" uplink-tx-bytes="0" uplink-rx-bytes="0" category="Messaging" subcategory="miscellaneous" apbr-policy-name="N/A"]

 

 

5 REPLIES 5
Highlighted
SRX Services Gateway

Re: Help with new Unified Security Policy - Applications as match criteria

‎11-13-2018 10:18 AM

I have a couple of ideas/input;

 

I think your issue is the pre-id-default-policy and SSL FP... before matching the application there is a pre-id-default-policy of potential policy matches.. if just one of these have SSL FP enabled, your traffic is forced into SSL FP and it cannot be reverted to non SSL FP. That's how it's designed.

 

Validate if there is a potential match by enabling 'set security policies pre-id-default-policy then log'... that should give you a list of potential matches for the signal traffic and I expect your are hitting the SSL FP rule and things break.

 

To my knowledge you have to do the SSL FP exempt otherwise. Sorry.


--
Best regards,

Jonas Hauge Klingenberg
Juniper Ambassador & Technology Architect, SEC DATACOM A/S (Denmark)
Highlighted
SRX Services Gateway

Re: Help with new Unified Security Policy - Applications as match criteria

‎11-13-2018 12:16 PM

Thanks for your reply Jonas. 

 

Now that you mentioned it I do remember seeing this in some documentation we receieved after some extensive support issues that provided very detailed information regarding alot of the advanced services on SRX such as SSLFP, UTM, and Unified Policies. 

 

I did enable logging on the pre-id-default-policy but I am not sure how to view it. We are streaming the security logs to a log collector and I didn't see anything in there and looked for the policy name. Anything particular to match on to see it in a log file locally?

I did run the command: show security policies information which did tell us it was using the default setting for implicit match. 

 

I disabled the implicit match to test and added junosSmiley FrustratedSL and junos:HTTP as part of the dynamic-application match and still doesn't appear to be working.

 

policy SSL-Exempt-Apps {
        match {
            source-address ss-noc-net;
            destination-address any;
            application any;
            dynamic-application [ junos:SIGNAL junos:SIGNAL-PRIVATE-MESSENGER junos:SSL junos:HTTP ];
        }
        then {
            permit;
            log {
                session-close;
            }
        }
    }



pre-id-default-policy {
    then {
        log {
            session-init;
            session-close;
        }

 

 

 

Highlighted
SRX Services Gateway

Re: Help with new Unified Security Policy - Applications as match criteria

‎11-13-2018 12:26 PM

One additional thing to note is that I tested by disabling SSLFP on the only rule we had it configured on and it is still not matching that policy with Signal as the dynamic-application match.

Highlighted
SRX Services Gateway

Re: Help with new Unified Security Policy - Applications as match criteria

‎12-13-2018 05:23 AM

what is a potential policy?

Highlighted
SRX Services Gateway

Re: Help with new Unified Security Policy - Applications as match criteria

‎02-13-2019 09:13 PM

I still haven't been able to fully get Unified Security Policies working just yet.

 

I recently had some very strange network issues getting hit by the Junos"default-policy deny-all" (enabled by default) that was ultimately resolved by removing "dynamic-application" as a match criteria in a security policy.

 

On my SRX I am using the standard zone-to-zone security policies as well as the global security policies for matching mutiple zones in a policy. The gloabl is where I created my default outbound rules and default deny rule among others. 

 

I have a server in a zone named "servers" attempting to communicate on the web in the zone untrust. No traffic was being permitted. Match policies command showed it was hitting the built in Junos "default-policy" which is set to deny-all. It was never processing any of my global policies. I tested that theory by creating a test rule in the from servers zone to untrust zone policy which started working. 

 

I enabled traceoptions on security flow with the flag for basic-datapath. When I reviewed the logs it showed my traffic was doing a "flow_first_policy_search: dynapp_none_policy" and the packets were being dropped. 

 

Feb 13 22:59:41 22:59:41.790737:CID-0:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.86.110.10, x_dst_ip 8.8.8.8, in ifp ae0.110, out ifp N/A sp 2361, dp 1, ip_proto 1, tos 0
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:Doing DESTINATION addr route-lookup
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:flow_ipv4_rt_lkup success 8.8.8.8, iifl 0x49, oifl 0x54
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:  routed (x_dst_ip 8.8.8.8) from servers (ae0.110 in 0) to ge-0/0/0.0, Next-hop: 172.127.48.1
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:flow_first_policy_search: policy search from zone servers-> zone untrust (0x0,0x9390001,0x1)
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:Policy lkup: vsys 0 zone(10:servers) -> zone(8:untrust) scope:0
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:             10.86.110.10/2048 -> 8.8.8.8/17442 proto 1
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:flow_first_policy_search: dynapp_none_policy: 1? is_final: 0x0, is_explicit: 0x0, policy_meta_data: 0x0
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:  app 0, timeout 60s, curr ageout 60s
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:  packet dropped, denied by policy
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:  denied by policy default-policy-logical-system-00(2), dropping pkt
 
Feb 13 22:59:41 22:59:41.790737:CID-0:RT:  packet dropped,  policy deny.

This is when I realized I had a test rule in the "from servers to untrust zone " policies that was attempting to use dynamic-application as part of the match criteria. But what was odd is that the test rule for dynamic-application match had nothing to do with the server that I was having issues with. In fact it was impacting every device that was in that zone policy pair (servers to untrust).

 

Once I deactivated the rule that contained the dynamic-application match everything started working again. 

 

When the Unified Security Policies were announced I felt like it was going to make things simplier. I still have yet to quite grasp all of the caveats. Can anyone provide some clarification on why this rule with dynamic-application match was effecting my traffic and ultimately hitting the built in default-policy that is deny?