Is manual entry necessary to open ports for 100 addresses?

[RJ45]

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.

[poundy · Accepted solution]

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?

[RJ45]

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.

[poundy]

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. 

[RJ45]

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.

[RJ45]

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.