Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
RJ45
New Contributor

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

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.

1 Solution
lobstercreed
Valued Contributor

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

  • View solution in original post

    6 REPLIES 6
    lobstercreed
    Valued Contributor

    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
    Valued Contributor

    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
    Esteemed Contributor III

    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

     

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    RJ45
    New Contributor

    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

    Announcements

    Select Forum Responses to become Knowledge Articles!

    Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

    Labels
    Top Kudoed Authors