Best practices for outbound Internet access for servers behind internal firewalls

[net-harry]

Hi,

We have external firewalls that are connected to the Internet and several internal firewalls, both security gateways and virtual systems on VSX.

Many servers behind the internal firewalls need restricted access to the Internet. We would like to optimise the use of resources and licenses in order to get the best value for money and I have some questions regarding this:

1. Is it preferable to only perform URL filtering and anti-bot on the external firewall to reduce load on the internal firewalls?
2. Should domain objects and updatable objects ideally also be defined only on the external firewalls or is the extra load caused by these objects on the internal firewalls neglectable?
3. Should we use a dedicated external interface on the internal firewalls and use "ExternalZone" as destination to allow the required traffic from internal servers or is there a better way?

It would be great to hear how those of you with a similar architecture do this. Please note that we prefer using proxy servers (sitting between the internal and external firewalls) for outbound Internet access, but this is not possible for all services.

We are currently running R80.40 on management and R80.20 on the security gateways and VSX.

Thanks for your help!

Harry

[PhoneBoy]

It depends on all of these things.
If your internal gateways don't have Internet access themselves, you really can't use Updatable Objects or URLF/Anti-Bot.

Domain Objects do need to have access to a DNS server that can resolve to the Internet.
Likewise, Updatable Objects need access to the Internet.
Load for either of these things should be minimal.

[net-harry]

Thank you very much @PhoneBoy for your feedback!

The reason why I ask is that we are considering to use only the NGFW bundle on the internal firewalls and use the NGTP (or NGTX) bundle on the external firewalls.

If I understand correctly using domain objects and updatable objects on the internal firewalls will not increase CPU load much. Could you please confirm if the same is true for custom applications/sites? My understanding is that this feature is included with Application Control (included in NGFW bundle).

Thanks for your help!

Harry

[Cyber_Serge]

 I know NGTP bundle include Application Control, URL Filtering, IPS, Antivirus, Anti-Bot and Email Security; what does NGFW bundle include? Is it not IPS just basic layer 3 firewall?

[net-harry]

Hi @Cyber_Serge,

NGFW includes Firewall, Identity Awareness, IPsec VPN, Advanced Networking & Clustering, Mobile Access, IPS, Application Control and Content Awareness according to the following:

https://www.checkpoint.com/downloads/products/check-point-appliance-comparison-chart.pdf

Best regards,

Harry

[PhoneBoy]

If you are only doing basic firewall with no threat prevention features enabled, then enabling App Control will cause at least some traffic to go through the Medium Path, which will cause a performance impact.
The extent that will happen depends on how you construct your rulebase.
If you’re already using IPS or App Control, then the performance impact should be minimal.

And yes, you can use Custom Application/Sites with an NGFW license, which includes App Control.

[Bob_Zimmerman]

1. For load, it probably doesn't matter too much. Your environment sounds similar to mine, and I prefer to apply URL filtering and so on at the outermost perimeter because it gives me one consistent place to check when there are certain classes of problem. Human time is a vastly more expensive resource than processor time.
2. FQDN objects present negligible load in general. I'm not sure about updatable objects.
3. I personally think zones are a fantastic way to shoot yourself in the foot. I prefer to do everything by IP (or FQDN, which is ultimately by IP), so no matter how it arrives at the firewall, it gets the same treatment.

In my environment, I have a core transit per datacenter with a bunch of firewalls hanging off of it. There are interior firewalls which own networks servers live on, then there are transit firewalls which sit between the core transit and other things (for example, one transit firewall per Internet connection, one per WAN link category [to my other datacenters, to customers, to vendors, etc.], etc.). This allows the rules on any given interior firewall to be written for arbitrary clients to reach the services provided by that application. The transit firewalls then have all the rules relevant to their connection. I find this really simplifies plotting out the A-to-B path between endpoints, which simplifies making changes and troubleshooting when things break.

The doctrine of blocking things as close to the source as possible only really matters in extremely resource-constrained environments. Computers are fast, and networks are no longer as enormously oversubscribed. With the exception of rare edge cases like a firewall on the ISS, you can afford to block stuff where it makes your life easiest as opposed to where it makes the computer's life easiest.

[net-harry]

Thank you very much @Bob_Zimmerman for your feedback!

If I understand correctly you apply URL filtering only on the external firewalls. How do your rules on the interior firewalls look for sources that require traffic to the Internet where you do not know the IP address of the destination? I am now considering applying URL filtering (using domain objects, updatable objects or custom applications/sites) on the internal firewall, since these features are included in the NGFW bundle) and then do URL categories, anti-bot and other features that require the NGTP bundle on the external firewalls.

Harry

[Bob_Zimmerman]

In my particular case, my inside-to-outside rules on my interior firewalls generally look a bit like this:

• Specific sources which need the Internet access.
• Destination is RFC 1918 negated. If the things need access to internal services, they get that with explicit IP-to-IP rules.
• Service is the relevant services (typically 443).

Then on the perimeter firewalls, there is a whole separate layer for URL filtering, which is controlled by another team.

[net-harry]

Thanks for the information!

That is how I was planning to do it if we decide to only do filtering on the external firewalls.

I agree that this simplifies the topology and would be a good option,

Thanks again for your help!