Which is more secure—Services and/or Address—for whitelist Policy?

[RJ45]

I am trying to poke a hole to allow Spotify. I managed to set two services in a new policy, which was successful:

TCP/UDP/SCTP

78.31.8.0-78.31.15.255

TCP 4070

TCP/UDP/SCTP

193.182.8.0-193.182.15.255

TCP 4070

In the policy's Destination field, do I need to limit the Destination to the same address ranges to be safe? I'm confused as to whether specifying an IP range in the Service makes specifying a destination unnecessary. Thanks.

[lobstercreed]

Hey Dan,

Nice username, ha!  Welcome to the forums.  Specifying the IP/FQDN in the service does make specifying the destination in a policy unnecessary. 

If you're creating a policy specifically for Spotify, I would remove the destination in the service definition and add it as destination addresses. Where it comes in handy to add it in the service is if you have a policy to allow general outbound traffic (destination "all") and you want to bundle something like this with it. 

For example we do not allow outbound DNS traffic from user workstations (they must use our local DNS) with the exception of 8.8.8.8 for the occasional test nslookup.  So I created a special Google-DNS service with UDP 53 and destination 8.8.8.8 and bundled it with my StandardOutboundPorts service group to attach to most of our policies.

Hope this helps.  - Daniel

[RJ45]

lobstercreed wrote:

Hey Dan,

Nice username, ha!  Welcome to the forums.  Specifying the IP/FQDN in the service does make specifying the destination in a policy unnecessary. 

If you're creating a policy specifically for Spotify, I would remove the destination in the service definition and add it as destination addresses. Where it comes in handy to add it in the service is if you have a policy to allow general outbound traffic (destination "all") and you want to bundle something like this with it. 

For example we do not allow outbound DNS traffic from user workstations (they must use our local DNS) with the exception of 8.8.8.8 for the occasional test nslookup.  So I created a special Google-DNS service with UDP 53 and destination 8.8.8.8 and bundled it with my StandardOutboundPorts service group to attach to most of our policies.

Hope this helps.  - Daniel

Many thanks for your reply. I'm new at this, and not a network engineer.

Let me see if I understand: If I want a specific Spotify policy, I should make Addresses instead (to be instantiated in the DESTINATION field, and remove the Services), right?

Unless I'm wrong (I'm no longer in front of it, so I can't check) I don't recall being able to specify TCP ports in Addresses, which could spell trouble. I'll give it a shot first thing.

[lobstercreed · Accepted solution]

Hey Dan,

Sorry for the confusion.  I was simply suggesting that IF you intended to create a separate policy for Spotify traffic, you can do two things.

[ol]

What you set out to do, creating the custom service with appropriate ports AND addresses, and then using that service in a policy with the appropriate source addresses and a destination address of ALL, letting the service do the IP restriction.

Or, my suggestion, create the custom service with the appropriate ports but leave the addresses out of the service, and then use the appropriate source addresses while also creating and using Spotify destination addresses, letting the destination do the IP restriction.[/ol]

The reason I believe #2 to be superior is because it's easier to understand when you're looking at the policy listings and will probably help avoid confusion for you or others down the road.  The IP restriction doesn't show up in the tooltip for a service, so you might want to make sure to include it in the comments for that service.

You certainly can do #1 and it will work great, or you could do #3: use IP restrictions in BOTH the service and destination addresses, but that's just redundant and maybe more likely to cause confusion.

Finally, I'll say that if you weren't wanting to create a separate policy but maybe to just add the Spotify service to an existing general outbound policy, then you should do what you were planning in #1.

Thanks - Daniel

[RJ45]

Daniel,

Thanks again, I get it now. That all makes sense. Tomorrow I'll weigh whether I want to roll it into a general whitelist policy or keep it separate for flexibility. I think you're right about #2, though. A bit visually cleaner. Much appreciated.

[emnoc]

Suggestion, why not use application control? Spotify falls into video/music and should be easily id . This would be the most secure way to control the application.

Ken Felix

[RJ45]

Good morning.

I wondered about Application Control and I'd be glad of any wisdom about configuring it. Please tell me if I'm doing this right: I duplicated the Default profile, found Spotify, added it to the Application and Filter Overrides and set it to ALLOW. Now I have to turn on this profile in my whitelist policy.

I'm a one-man corporation, so I don't need apps to be blocked per se... I trust myself implicitly, so if I'm imposing overly-Draconian measures, that wouldn't be necessary.

Is that all I should have to do? If I enable App Control, do I also need to hold onto the IP and Port-based rules or are they obviated? So far, I've learned a ton on this forum in one day. Many thanks.

Dan