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.
Yes, I could probably just turn on Amazon AWS and Azure as an ISDB item and that would take care of it, which I may do. Thank you again.
One mystery remains:
localhost wrote: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 :)
How does one convert a link containing "Amazon CloudFront IP Ranges" or "Media Shuttle Service for AWS S3" into data I can enter into a policy without using an ISDB item?
If the only answer is "You can't, you must use the ISDB", then fine, I can do that. But your quote suggests there is another way.
What the ISDB gives is a pre-defined set of IP addresses that are managed and are updated as AWS change their infrastructure.
What @Localhost showed above was that the example media shuttle service IP address was also a part of the AWS ISDB entry, i.e. the media shuttle services are a subset of the AWS ISDB entries. So instead trying to reduce the IP address list to just the Media Service or Cloud Front addresses, just use the predefined IPs and you're good.
I knew the ISDB existed but not the details, now I have a great understanding how that could be leveraged in a scenario like this. My earlier comments on scripting this are also pretty simple, but require (much) more work than using the ISDB. You'd basically have to use a script to parse the JSON list into a format you can then transform into commands for the FGT that you'd then submit to the FGT (or if you used something like PowerShell and the PowerFGT module, you could have those done immediately for you). You'd want to configure your policy to point to an AddressGroup, and you'd add members to that group - that portion wouldn't need to change, as the AddressGroup members changed. If an IP address was removed from the group, your script would remove it from the addrgrp, then remove it's address entry (for cleaner configs); when a new address appears, you'd add a new address entry and add it as an addrgrp member.
Now, with ISDB, all you need to do is leverage their entry in your policy instead. That means you don't need to use a destination addrgroup, the policy is slightly different (but the same concept).
HTH.
poundy wrote:What the ISDB gives is a pre-defined set of IP addresses that are managed and are updated as AWS change their infrastructure.
What @Localhost showed above was that the example media shuttle service IP address was also a part of the AWS ISDB entry, i.e. the media shuttle services are a subset of the AWS ISDB entries. So instead trying to reduce the IP address list to just the Media Service or Cloud Front addresses, just use the predefined IPs and you're good.
I knew the ISDB existed but not the details, now I have a great understanding how that could be leveraged in a scenario like this. My earlier comments on scripting this are also pretty simple, but require (much) more work than using the ISDB. You'd basically have to use a script to parse the JSON list into a format you can then transform into commands for the FGT that you'd then submit to the FGT (or if you used something like PowerShell and the PowerFGT module, you could have those done immediately for you). You'd want to configure your policy to point to an AddressGroup, and you'd add members to that group - that portion wouldn't need to change, as the AddressGroup members changed. If an IP address was removed from the group, your script would remove it from the addrgrp, then remove it's address entry (for cleaner configs); when a new address appears, you'd add a new address entry and add it as an addrgrp member.
Now, with ISDB, all you need to do is leverage their entry in your policy instead. That means you don't need to use a destination addrgroup, the policy is slightly different (but the same concept).
HTH.
Ok, got it. I was hoping for an easier solution and it looks like I got one. Thanks to you both for your generosity and patience. I'll give this shot later today.
Well, the great news is that this all seems to work, from my testing, the way I've got it configured at the moment. It took 3 outbound policies and 1 inbound to cover it all, but so far I'm transferring files.
Thanks again.
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 |
---|---|
1702 | |
1092 | |
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.