commit status warning on rules that are working the way I want them too

[jdprovine]

I have a rule that has webex enabled but dones not have ssl enabled and i keep getting a warning on that rule when i commit that says "Applicaiton 'webex-desktop-sharing requires ssl be allowed? But I don't want to allow ssl, so how can I get rid of these warnings so i can tell when i have a legitimate commit warning?

[Remo]

@jdprovine

I absolutely agree. In some cases it's not only annoying, it of course also obscure real warnings and errors. 

So a feature like a simple checkbox "ignore application dependencies" in the commit status would be helpful.

[jdprovine]

@BPry

So you are saying that just because I have some rule somewhere else allowing ssl traffic , but not specifically added to the google-play rule I have, it will still allow the rule I don't want to use ssl to use ssl from another rule? (can I say rule one more time :)) Thats doesn't sound good, it sounds like I have defeated the purpose of not adding it to my google-play rule

[jdprovine]

@Remo

The bigger issue to me, is that is appears that it is allowing that rule to do or allow something, like ssl,  that I don't want allowed to be allowed (can i say allowed 1 more time :))

[BPry]

@jdprovine,

Unless this one computer is excluded from the existing policies allowing general access, then yes.

Keep in mind that even if a computer is completely segregated and you've only allowed it access to one specific application (say google-play) the firewall will still allow a small amount of traffic to pass so that it can properly identify the traffic. If the traffic doesn't match google-play then it will start dropping all traffic, but it needs that small amount of traffic to see if the traffic actually matches google-play. 

[Remo]

@jdprovine

It now only depends on how much effort you want to spend to get rid of some or most of these warnings, as there is no easy checkbox to ignore and hide these.

In the example for google play you could analyze what URLs you have in that rule alllwing google play. With these rules you then create a custom URL category and add this category to the google-play rule in addition to the application ssl and google-base. This way the warning should be gone and you do not allow general internet access.

This method probably also works with webex and spotify for example. To even further limit it, you could also specify ip addresses. At least for the google rule this is possible, as google publishes all their IP ranges. For the other two examples I don't know.

[BPry]

@Remo,

Speaking from experiance both WebEx and Spotify both do a pretty good job of specifying their IP addresses. 

Spoitfy: 78.31.8.0/22 with URL ap.spotify.com

WebEx: Depends on the region but for AMER

64.68.96.0/19

66.114.160.0/20

66.163.32.0/19

173.39.224.0/19

173.243.0.0/20

207.182.160.0/19

209.197.192.0/19

216.151.128.0/19

and the URLs would be 

*.webex.com

*.ciscowebex.com

*.webexconnect.com

*.wbx2.com

*.ciscospark.com

(Not really needed but requested) 

*.localytics.com

*.rackcdn.com

*.clouddrive.com

*.crashlytics.com

*.js-agent.newrelic.com

*.bam.nr-data.net

(CRL)

*.quovadisglobal.com

@jdprovine,

Pretty much every warning can be eliminated through gathering the IP ranges and/or the URLs that the service actually uses, but as @Remo stated this can all take quite a bit of time to gather up and actually configure. 

[jdprovine]

@Remo @BPry

Great suggestions, I just want to keep my commit status message reasonable, it appears to be growing longer 

[jdprovine]

Here is another interesting commit status dependency warning

"Rule 14 application dependency warning: Application ms-update requires ssl be allowed but ssl is denied in rule 15. " Why is an application in the rule above getting on a rule below it?

[Remo]

This one is pretty clear I think. Rule 15 probably is your deny-all or an explicit deny-ssl rule. So the firewall checks the dependencies and also informes you where this dependency would be blocked. 

[jdprovine]

@Remo

that makes sense since it is not allowed in rule 14 it moves to rule 15 which is a deny and never finds a rule that will allow it. 

[Remo]

@jdprovine

You might want to ask your SE about the feature requests 1887, 2689, 4131. According to another topic here in the community these FR IDs all head in the direction of implizit allowing some application dependencies as long as the the actual app that you effectively want to allow shows up. Negativ part of something like that is probably that (a lot) more traffic needs to be allowed until the firewall knows for sure if it has to allow or drop further traffic.