Help with policy for domain/FQDN policies and SaaS providers

[mcdonamw_ews]

I have a situation where I need to open the FW to specific FQDN domains such as:  

*.insight.rapid7.com
*.endpoint.ingress.rapid7.com

This is because the vendor cannot provide all possible IPs (either do not know), or they can come from any number of the cloud providers network and we're not opening things up to the entirety of Azure or AWS.

My understanding is I can use domain objects on the CP application policy, but I'm seeing a couple of limitations that are preventing me from using this method.

FQDN domain objects:  

1. Does not support wildcards.  Must enter the exact FQDN for any possible host.subdomain.domain.
2. If I understand correctly, the CP will do a forward DNS lookup and cache the IP.
   1. What happens if the IP changes and/or the cloud provider provides different IPs as part of load balancing and/or geo-DNS? 
   2. How often is the lookup refreshed?  Is it based on TTL or is there a specific refresh interval set?

In short I see a potential caching problem with this method.

Non-FQDN domain objects: 

1. Does support wildcard domains.
2. The CP performs reverse DNS lookup of the IP.  If the resulting PTR record contains the domain specified in the rule, it will match.
   1. The problem here is many SaaS services in the cloud seem to not have proper PTR records setup and their IPs simply back-resolve back to the domain of the Cloud provider itself, e.g. *.compute.amazonaws.com. 

So with this method, there will be a conflict in the domain name not matching the PTR record so I don't see this as a valid option.

Now, one option is to potentially use the application filtering policy and create a custom URL/application and specify the URLs (with wildcards), but even this is problematic as it only works for a static set of web-based ports/protocols, e.g. HTTP/HTTPS.  This won't work for any non-standard ports in use, or non-Web based traffic.

Any thoughts as to how best approach this?

[Sorin_Gogean]

Hey,

Either use the FQDN objects or define an Custom URL/Application that would match all traffic towards those and should catch them - give it a try .

*.insight.rapid7.com
*.endpoint.ingress.rapid7.com

Tnx,

[mcdonamw_ews]

Thank you for your response, but it seems you either did not fully read or understand my original post.  It's possible my post is too wordy.  I'll try to sum it up better.

There are issues with both types of FQDN objects, and the custom URL/application only works for a default set of web ports/protocols.  You cannot add other ports needed, i.e. if the app is using a non-standard port.

[Bob_Zimmerman]

You actually can get URL Filtering to work on other ports, but still only with HTTP-based protocols. If you need to allow, for example, MSSQL traffic to any subdomain of a given domain, URL Filtering wouldn't work.

[mcdonamw_ews]

I overlooked this reply.  So in this case, what is the correct way to do it?  Only by IP or the domain objects on the security policy, correct?

[Bob_Zimmerman · Accepted solution]

For protocols which aren't HTTP-based, correct. For protocols which use TLS, there might be a way to cajole URL Filtering without HTTPS inspection to work based on the TLS SNI, but I doubt it would be supported. That leaves only FQDNs or specific IP addresses.

[mcdonamw_ews]

That's what I figured.  Thanks for the help.

[Sorin_Gogean]

I might got confused 😊 but still, I would define FQDN objects for each FQDN required to be allowed - that will map to the DNS and not to IP's - and will match all data that is hosted on whatever cloud out-there. 

We do the same on our CheckPoints.

And you are aware of this....  The FQDN issue you refer is the fact that you would expect to have an object like *.endpoint.ingress.rapid7.com (with or without the *) that would cover  whatever@#$@#$@#.endpoint.ingress.rapid7.com - and that is not correct. for that you need non-FQDN that does DNS and reverse DNS....

What you need ( and we do too for some traffic) is somethingA.endpoint.ingress.rapid7.com FQDN Object and somethingB.endpoint.ingress.rapid7.com and somother.endpoint.ingress.rapid7.com . 

Those will match whatever cloud will respond for those 3 names  somethingA/somethingB or somother on whatever protocol is used.

In response to What happens if the IP changes and/or the cloud provider provides different IPs as part of load balancing and/or geo-DNS? In short I see a potential caching problem with this method. for that particular connection will be allowed by the firewall, for new connections the detection process will be the same....

So in case it will happen once every month... so be it.... we can't have dynamic like we would really want.

Thank you, 

PS: I recommended URL/App because our Rapid7 servers talks to outside only 80/443 - therefore I assumed it's Rapid7 related only

[mcdonamw_ews]

---

@Sorin_Gogean wrote:

I might got confused 😊 but still, I would define FQDN objects for each FQDN required to be allowed ...

And you are aware of this....  The FQDN issue you refer is the fact that you would expect to have an object like *.endpoint.ingress.rapid7.com (with or without the *) that would cover  whatever@#$@#$@#.endpoint.ingress.rapid7.com - and that is not correct. for that you need non-FQDN that does DNS and reverse DNS....

What you need ( and we do too for some traffic) is somethingA.endpoint.ingress.rapid7.com FQDN Object and somethingB.endpoint.ingress.rapid7.com and somother.endpoint.ingress.rapid7.com . 

Those will match whatever cloud will respond for those 3 names  somethingA/somethingB or somother on whatever protocol is used.

As you noted, yes I am aware and I stated this exact thing.   "FQDN domain objects:  Does not support wildcards.  Must enter the exact FQDN for any possible host.subdomain.domain."

With that said, I was not clear however, that the vendor in this case does not document exactly what those hosts are.  They simply provide the wildcard domain only.  So this is not an option.

Also this question is not specifically about one vendor.  That was just one example.  This is becoming more problematic as more vendors move to large cloud providers so I'm trying to get a proper handle on it.

---

@Sorin_Gogean wrote:

...

In response to What happens if the IP changes and/or the cloud provider provides different IPs as part of load balancing and/or geo-DNS? In short I see a potential caching problem with this method. for that particular connection will be allowed by the firewall, for new connections the detection process will be the same....

So in case it will happen once every month... so be it.... we can't have dynamic like we would really want.

---

Not so much worried about dynamic IPs, per se.  I'm talking about static IPs that are part of some type of either DNS load balancer type situation.  I've used such a service where the DNS server only responds with a single IP (of many) depending on which backend server is active at the time.  This can change very frequently based on load.  Alternatively Clouds also use region based failover where the DNS record could potentially completely change to another region/IP from either a load or outage perspective.   

I can't have my firewall deny a connection because it hasn't yet resolved/cached the current IP in these scenarios.

---

@Sorin_Gogean wrote:

PS: I recommended URL/App because our Rapid7 servers talks to outside only 80/443 - therefore I assumed it's Rapid7 related only

---

Even though this extends further than Rapid7, I'm curious as to how you have your policy set up.  My situation for this particular case, it's not just about a single Rapid7 server.  We are deploying Rapid7 agents throughout our enterprise and these clients need to hit Rapid7 servers on the internet.  The problem is I have protected networks that have no internet access so when we open this up we ONLY want those networks/servers to have access to Rapid7 servers ONLY.   

If I'm using URL/App, I still have to set up a security policy to go along with it.  So my question on what to do on the security side still applies.  With that said though, as noted it's not just about Rapid7 and I have cases where systems need to do non-HTTP protocols to cloud hosted systems as well, so the URL/App filtering is not an option.

[Bob_Zimmerman]

Wildcards make the domain no longer fully-qualified, so correct, FQDN objects don't support them. 😉 The strings you listed earlier also are not fully-qualified domain names, since they have wildcards.

I'm not sure I understand your question about whether the forward lookup is done at startup. Specifically, what do you mean "startup"? The firewall keeps a list of all FQDNs and it looks them up periodically. I think it's every 15 minutes by default. When the IP changes, the firewall learns the new IP via the periodic lookups.

As for DNS-based geographical load distribution, this is why it's important the firewall use the same name resolution path as the clients going through it. As long as the firewall and the clients use the same DNS resolvers, there's no chance of inconsistency.

[mcdonamw_ews]

---

@Bob_Zimmerman wrote:

Wildcards make the domain no longer fully-qualified, so correct, FQDN objects don't support them. 😉 The strings you listed earlier also are not fully-qualified domain names, since they have wildcards.

I'm not sure I understand your question about whether the forward lookup is done at startup. Specifically, what do you mean "startup"? The firewall keeps a list of all FQDNs and it looks them up periodically. I think it's every 15 minutes by default. When the IP changes, the firewall learns the new IP via the periodic lookups.

As for DNS-based geographical load distribution, this is why it's important the firewall use the same name resolution path as the clients going through it. As long as the firewall and the clients use the same DNS resolvers, there's no chance of inconsistency.

---

I incorrectly use FQDN interchangably with domain but yes I am aware they are not FQDN.  That's why I stated for FQDN objects I need the exact hostname since wildcards cannot be used in those cases.  The problem is the vendor does not provide those exact hosts. 

The question about startup was a misunderstanding on my part.  I read the following in the CP documentation:  Changes in Gaia DNS servers are implemented only after you run cpstop/cpstart or reboot the appliance. If not, the DNS servers that were configured at startup will continue to be used.

I did not realize at the time they were talking about DNS server changes, not the addition of new FQDN domain objects so I was thinking that adding new FQDN objects required a restart.

I know I mentioned geo DNS, but that really likely doesn't apply as you are correct the resolution path would be the same for the FW and the clients passing through it.

I'm referring more to a DNS load-balancer type service where DNS servers respond with the active IP only though there's a cluster of them providing the service.  Healthchecks are constantly run and the DNS server will change the IP it resolves depending on load/failover.  The TTL of such a record was as low as 5 minutes.  I've used such a service and I imagine cloud providers have similar options.

Can the CP perform lookups at such low intervals (and without a huge performance hit)?  If so this should be less of a concern, but this is just one of the few concerns I've outlined.

The primary issue with domain objects still apply, specifically the vendor not providing the exact FQDNs so forward DNS couldn't work.  I'd have to rely on reverse DNS option which is broken due to the IPs not back-resolving to the forward domain.

[Bob_Zimmerman]

For a company which claims to be interested in security, providing you the fully-qualified names their product needs to be able to hit is the absolute barest minimum they can do. Claiming they are unable to provide it suggests a stunning lack of understanding of their own product. If they don't know the endpoints their code talks to, what else don't they know about their own code?

I forget the actual frequency with which the firewall looks up the names of FQDN objects. Might be sub-minute. I've never had a problem report when outside vendors change the IP backing one of their names.

[mcdonamw_ews]

I couldn't agree with you more.  This all started because they do provide a list of IPs for their various regions, however whitelisting those we still had issues and our diagnostics lead us to the agent hitting an IP that isn't even listed in their documentation and support could not answer as to why.  Likely just expansion and lack of updates to documentation and level 1 support not really able to answer those questions.

Either way, this is clearly a problem on their side.  The same with not setting up their reverse DNS appropriately, but these are common issues with many companies so I'm trying to find the best way to account for these kinds of issues, if possible and within reason.

Ultimately I just want to make sure I'm not missing something on the Checkpoint side that can make this easier or if this just is what it is and I have to deal with it.

[Tobias_Moritz]

You can take a look at the Passive DNS Learning Feature, introduced with R80.40 (and ported back to R80.30 with some JHF).

Check out sk161612 for more information.

When you can live with the limitations (mostly relevant: The gateway which should allow the non-HTTP(S) traffic to some wildcard domain needs to see the DNS lookup traffic and the resolver needs to be defined in Check Point database as DNS server), you can use domain objects (non-FQDN) without overhead and need for PTR records.

Also see this CheckMates discussion:

https://community.checkpoint.com/t5/General-Topics/DNS-Passive-Learning-Design-Question/td-p/77213