Looking for advice on how to open ports that a service says will require a large number of addresses on, say, port 51000.
Please tell me if I'm doing this correctly: In a new policy, I'm creating Address entries for each IP or IP range (attached to Destination), then creating a Service with the port needed to open and leaving the address as 0.0.0.0.
Can manual entry for services that use large amount of IP addresses be avoided? This would be for services that DON'T appear in the Internet Service database.
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.
ok, now I get a bit more context, but can i ask another question or two before I suggest an answer?
What does the "inside" portion of the infrastructure look like? Is there just one server (or a small, fixed number) sitting behind the FGT and it needs to talk to all those endpoints over just that set of ports? And if so, would you want to restrict it in such a way that the internal server can only talk on those ports to those endpoints? Or does the internal side look like a
My first hint about those IP addresses is possibly a little abstract. AWS and Azure give you these in a consumable format, so that you can maintain them in an automated way. You should be considering a way to transform that feed into the FGT. You could have a script to churn the AWS endpoint JSON file into a set of CONFIG FIREWALL ADDRESS command lines that also adds them to an address group.
I will say I'm a pretty new FGT admin, but I'd approach this as a policy that permits traffic from inside group of IP addresses on a particular service to a particular destination. In this case, I'd create a policy for TCP80 to AWS EC2 destination, a policy for TCP443 to AWS Cloudfront, a policy for TCP/UDP49221 to AWS Media Shuttle. I'd define an address group for each of those, so the policy wouldn't need to change only the addrgrp, as the IPs published changed.
Does this help?
(1) You mentioned the external domains... my question is: Are these external domains treated separately from the list above which are ports? Meaning, if I whitelist the external domains, I might not need to deal with the port list above, or I do still need to open the ports (as services)? It's confusing when you don't know quite what you're doing.
Only the ISDB contains IP addresses AND ports. Actually If you use ISDB entries like Amazon-AWS as a destination address iny our policy, it's not even possible to define any ports at all.
For all other firewall policies you must define ports/services.
The FQDN Address object behaviour is a bit different for FortiOS 5.4.
pre FortiOS 5.4:
The Fortigate will just do a DNS lookup for the FQDN entry, and will replace the DNS Value with an IP address in the firewall policy. It will do this DNS lookup regulary. (basically like you would do a 'nslookup update.signiant.com' in a command shell)
>= FortiOS 5.4:
The Fortigate will monitor all DNS request passing the firewall. And will cache DNS Response from the server. This makes it possible to use wildcard FQDN entries.
May I assume I can use an Address group for the above, then instantiate THAT in the destination field of a policy
Sure, you can create groups for address and ports objects and use these in the firewall policies.
I don't understand your scenario (and I suspect that's why you haven't had any other responses either). Perhaps you can better describe it or point to info that describes the service and it's behaviour?
Here is an example of what I'm talking about. I am trying to create a policy by entering the data given to me by this web site:
The ranges of IPs in the links under "Target IP Address" are anywhere from 30 IPs to hundreds. I can create a policy with each of these ports set to ALLOW in a series of Services, but I don't understand how I'm expected to enter an enormous set of IP address.
Here is the link, for example for the above "Amazon CloudFront IP Ranges". What am I supposed to do with this information? I'm not going to enter those hundreds of IPs by hand.
Can I enter these links themselves as a FQDN in a Service where the port is specified? The lack of documentation on this type of thing (or ability to Google successfully) is truly disappointing.
Thanks
ok, now I get a bit more context, but can i ask another question or two before I suggest an answer?
What does the "inside" portion of the infrastructure look like? Is there just one server (or a small, fixed number) sitting behind the FGT and it needs to talk to all those endpoints over just that set of ports? And if so, would you want to restrict it in such a way that the internal server can only talk on those ports to those endpoints? Or does the internal side look like a
My first hint about those IP addresses is possibly a little abstract. AWS and Azure give you these in a consumable format, so that you can maintain them in an automated way. You should be considering a way to transform that feed into the FGT. You could have a script to churn the AWS endpoint JSON file into a set of CONFIG FIREWALL ADDRESS command lines that also adds them to an address group.
I will say I'm a pretty new FGT admin, but I'd approach this as a policy that permits traffic from inside group of IP addresses on a particular service to a particular destination. In this case, I'd create a policy for TCP80 to AWS EC2 destination, a policy for TCP443 to AWS Cloudfront, a policy for TCP/UDP49221 to AWS Media Shuttle. I'd define an address group for each of those, so the policy wouldn't need to change only the addrgrp, as the IPs published changed.
Does this help?
I'll try to elucidate, assuming I understand you fully. Thanks for your help.
poundy wrote:ok, now I get a bit more context, but can i ask another question or two before I suggest an answer?
What does the "inside" portion of the infrastructure look like? Is there just one server (or a small, fixed number) sitting behind the FGT and it needs to talk to all those endpoints over just that set of ports? And if so, would you want to restrict it in such a way that the internal server can only talk on those ports to those endpoints? Or does the internal side look like a
It's just two computers behind the FGT, and the basic policy idea is a full lockdown, with holes poked for essential services and web sites, such as the one I posted. I have no employees that I need to control their traffic or productivity (I'm the only employee), it's just to prevent hacking and unauthorized data egress.
poundy wrote:
My first hint about those IP addresses is possibly a little abstract. AWS and Azure give you these in a consumable format, so that you can maintain them in an automated way. You should be considering a way to transform that feed into the FGT. You could have a script to churn the AWS endpoint JSON file into a set of CONFIG FIREWALL ADDRESS command lines that also adds them to an address group.
This is the sort of information I'm looking for. I'm a small business and would have no idea how to do this intuitively. Any details on how to do this is what I need most desperately.
poundy wrote:
I will say I'm a pretty new FGT admin, but I'd approach this as a policy that permits traffic from inside group of IP addresses on a particular service to a particular destination. In this case, I'd create a policy for TCP80 to AWS EC2 destination, a policy for TCP443 to AWS Cloudfront, a policy for TCP/UDP49221 to AWS Media Shuttle. I'd define an address group for each of those, so the policy wouldn't need to change only the addrgrp, as the IPs published changed.
OK, so talk me through this procedure if you don't mind. I know that I need to associate the above mentioned ports with this abstract notion of "AWS EC2" or "AWS CloudFront" (these are not input-able data in and of themselves!), but I have no idea how to ingest of all those addresses, especially if they are given in a way that means they will change on the service's end, as you suggest.
OK, ready to learn how. Thanks again.
Hi
You can use Internet Service Database entries as your destination in policies:
This includes all IP's and Ports used by Amazon-AWS and is updated automatically (requires FortiCare license).
Another way to go is to use FQDN address objects as a destination.
If you scroll down in the system-requirements they also list externals domains, which you can whitelist.
https://help.signiant.com/media-shuttle/general/system-requirements
FortiOS 6.4 supports wildcard domains in your firewall policies. But for this to work DNS queries must pass your firewall!
So you could just create these domains as wildcard domains.
If outbound HTTPS access is restricted, ensure that the following wildcard domains can be reached:
[ul]*.signiant.com *.amazonaws.com *.mediashuttle.com[/ul]
If you are pre FortiOS 6.4 you should create single FQDN entries:
If your firewall is unable to support wildcard domains, allow access to the following hosts:
[ul]updates.signiant.com device-service.services.cloud.signiant.com server-events.services.cloud.signiant.com prod-installer-useast1.services.cloud.signiant.com prod-installer-uswest2.services.cloud.signiant.com mediashuttle.com mscloud.mediashuttle.com updates.mediashuttle.com license.mediashuttle.com portals.mediashuttle.com a2xy0445m8zinb.iot.us-east-1.amazonaws.com a2xy0445m8zinb.iot.us-west-2.amazonaws.com[/ul]
localhost wrote:Thank you, Localhost, that could not have been more helpful. I have seen the Amazon AWS Internet Service but not all big services like that are in the list, so I wasn't sure how to deal with the ones not represented.Hi
You can use Internet Service Database entries as your destination in policies:
This includes all IP's and Ports used by Amazon-AWS and is updated automatically (requires FortiCare license).
[attachImg]https://forum.fortinet.com/download.axd?file=0;185815&where=message&f=amazon-aws.png[/attachImg]
Another way to go is to use FQDN address objects as a destination.
If you scroll down in the system-requirements they also list externals domains, which you can whitelist.
https://help.signiant.com/media-shuttle/general/system-requirements
FortiOS 6.4 supports wildcard domains in your firewall policies. But for this to work DNS queries must pass your firewall!
So you could just create these domains as wildcard domains.
If outbound HTTPS access is restricted, ensure that the following wildcard domains can be reached:
[ul]*.signiant.com *.amazonaws.com *.mediashuttle.com[/ul]
If you are pre FortiOS 6.4 you should create single FQDN entries:
If your firewall is unable to support wildcard domains, allow access to the following hosts:
[ul]updates.signiant.com device-service.services.cloud.signiant.com server-events.services.cloud.signiant.com prod-installer-useast1.services.cloud.signiant.com prod-installer-uswest2.services.cloud.signiant.com mediashuttle.com mscloud.mediashuttle.com updates.mediashuttle.com license.mediashuttle.com portals.mediashuttle.com a2xy0445m8zinb.iot.us-east-1.amazonaws.com a2xy0445m8zinb.iot.us-west-2.amazonaws.com[/ul]
I have two questions:
(1) You mentioned the external domains... my question is: Are these external domains treated separately from the list above which are ports? Meaning, if I whitelist the external domains, I might not need to deal with the port list above, or I do still need to open the ports (as services)? It's confusing when you don't know quite what you're doing.
(2) May I assume I can use an Address group for the above, then instantiate THAT in the destination field of a policy?
MUCH appreciated.
(1) You mentioned the external domains... my question is: Are these external domains treated separately from the list above which are ports? Meaning, if I whitelist the external domains, I might not need to deal with the port list above, or I do still need to open the ports (as services)? It's confusing when you don't know quite what you're doing.
Only the ISDB contains IP addresses AND ports. Actually If you use ISDB entries like Amazon-AWS as a destination address iny our policy, it's not even possible to define any ports at all.
For all other firewall policies you must define ports/services.
The FQDN Address object behaviour is a bit different for FortiOS 5.4.
pre FortiOS 5.4:
The Fortigate will just do a DNS lookup for the FQDN entry, and will replace the DNS Value with an IP address in the firewall policy. It will do this DNS lookup regulary. (basically like you would do a 'nslookup update.signiant.com' in a command shell)
>= FortiOS 5.4:
The Fortigate will monitor all DNS request passing the firewall. And will cache DNS Response from the server. This makes it possible to use wildcard FQDN entries.
May I assume I can use an Address group for the above, then instantiate THAT in the destination field of a policy
Sure, you can create groups for address and ports objects and use these in the firewall policies.
Okay, so far I have done the following (These domains are for the Signiant App, not the longer list, which was for the server side, which you quoted above):
Then I made an address group of the five, and created this policy:
Since these domains were not specified to have certain ports that need to be opened, is it adequate to leave this as it is? Basically, I've just told it that whatever service is going out to these destinations, it's allowed.
Then, if I wanted to use the ISDB to address the ports, There are is an entry for Azure, and several Amazon-based items, including two for AWS, but nothing specifically for EC2, CloudFront, so wondering what you would do there.
Thanks again to you both for your assistance. I'm learning a lot here.
If I understand the manual correctly you'd need to allow following ports into the direction of the domains:
TCP 80 Amazon EC2 IP Ranges TCP 443 Amazon CloudFront IP Ranges TCP/UDP 49221 Media Shuttle Service for AWS S3 Media Shuttle Service for Azure Storage
But destination service 'any' is also fine :)
Btw.
I think the Amazon-AWS IDBS entry contains all EC2 and Cloudfront ip ranges.
You can verify this on the CLI.
C:\>nslookup mediashuttle.com
Server: dns.server.intern
Address: 1.2.3.4
Nicht autorisierende Antwort:
Name: mediashuttle.com
Addresses: 76.223.25.251
13.248.156.178
Fortigate CLI:
#diagnose internet-service match root 76.223.25.251 255.255.255.255
Internet Service: 393320(Amazon-AWS), matched num: 2
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 |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
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.