Skip to main content
RJ45
RJ45
Visitor III
April 12, 2020
Solved

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

  • April 12, 2020
  • 1 reply
  • 4766 views

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.

    Best answer by lobstercreed

    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

    • 1 reply

    lobstercreed
    lobstercreed
    New Member
    April 13, 2020

    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
    RJ45Author
    Visitor III
    April 13, 2020

    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
    lobstercreedAnswer
    New Member
    April 13, 2020

    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

    • Terms & ConditionsAccessibility statement