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.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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]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
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
lobstercreed wrote:Many thanks for your reply. I'm new at this, and not a network engineer.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
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.
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]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
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.
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
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1696 | |
1091 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.