Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
net-harry
Collaborator

Best practices for outbound Internet access for servers behind internal firewalls

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

0 Kudos
9 Replies
PhoneBoy
Admin
Admin

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
Collaborator

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

0 Kudos
Cyber_Serge
Collaborator

 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?

0 Kudos
net-harry
Collaborator

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

0 Kudos
PhoneBoy
Admin
Admin

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
Advisor

  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
Collaborator

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

0 Kudos
Bob_Zimmerman
Advisor

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
Collaborator

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!

0 Kudos