Firewall-Blades Order of Operation

[ahmedaburaihan]

Hallo Mates

What is the order of operation of Firewall-Blades in a normal environment? 

Let suppose a packet from Internet enters an OUT Interface of a Firewall, How does the Firewall deal with it?

- Does the Policy/Rule is checked against.

- Does the Threat Prevention Module works first?

... and so on. 

I would be grateful for a detailed answer in this regard. 

Thank you, 

A. 

[_Val_]

This pic should answer your quesiton

[ahmedaburaihan]

Yes, thank you for the pic. Could you please also put some light on this? 

[_Val_]

It depends. You asked about the order of different blade enforcement.

When the packet comes to your GW, it is being inspected before forwarding. The first action is anti-spoofing. Then, and even before it is filtered through the security policy, TLS inspection policy is applied, if the feature is enabled on your GW.

The next step is your Security policy in combination with Application Control, URL filtering, and Content Inspection if they are used. If the result is Accept action, the next step is Threat Prevention: AV, IPS, and anything else you have in your Threat Prevention Policy.

The whole logic is linear, without loops.

[ahmedaburaihan]

@_Val_ Thanks for the details. 
For me it is not so much clear because, as of Order of OSI layer, TLS inspection should be done at L4 and L1 (because of TCP and HTTPS). I thought that it could be Linear, first Source and Destination and then Port and then application. I am kinda not getting into details. Where can i find resource which tells me exact behavior step by step? thanks. 

[_Val_]

TLS inspection is a special case. You have to decrypt the traffic in order to inspect it with your security policies. To make it happen, GW will proxy your HTTPS traffic. In a sense, it is "the man in the middle" situation. TLS connection from the client is terminated on the GW, and a secondary TLS tunnel is opened to the server, allowing your GW to see the cleartext traffic.

I sense you are new to Check Point. if this is true, please browse our Check Point for Beginners materials in this community, it will help.

[Bob_Zimmerman]

Two noteworthy items are missing from that diagram: VPN decisions (like flagging a packet for encryption to a given VPN peer) and NAT.

My memory is VPN decisions are made between antispoofing and HTTPS inspection. This is before any address translation can happen, and it affects which addresses you need to include in a firewall's encryption domain.

NAT rule matching is done with the firewall policy matching, but decisions aren't actually applied until later (after the Threat Emulation/Extraction part of this diagram). All rules should be written based on how the traffic will look when it arrives at the firewall.

[_Val_]

The question was, in which order the policies are being enforced. 

VPN description is happening on inbound before FW filtering, but the decision to do VPN is also part of FW filtering, together with NAT.

I keep saying that it is pointless trying to put everything in a single diagram.  If the question is, in which order policy is applied, the answer is above. If you want to how a connection can be modified (decrypted/NAT-ed/encrypted) as part of the traffic handling by your security gateway, it is a completely different story, much deeper, with a lot of information you need to know before you understand the answer. 

[Bob_Zimmerman]

Sure, but generally people ask what order things happen in because they want to know something deeper like how rules should be written. The details of VPN domain matching and NAT affect how VPN domains and rules are written, so they are often relevant for the question behind the question.

[_Val_]

@Bob_Zimmerman

I was addressing the specific question raised by the topic starter: What is the order of operation of Firewall Blades in a typical environment?

I’d like to reiterate my perspective regarding providing an all-encompassing answer to questions that haven’t been explicitly asked.

Based on my professional experience, attempting to address every possible scenario in a single response is both impractical and potentially counterproductive.

To fully understand how traffic interacts with firewalls, it’s essential to make a deep dive into the intricate details of firewall software modules, chains, and the various parameters associated with connections and packets. This includes how these parameters are presented, controlled, and manipulated by different security blades. This is a complex subject that requires significant time—weeks, months, or even years—to master comprehensively.

That said, this level of detail is not typically necessary for the day-to-day responsibilities of security administrators and architects. While such knowledge is indispensable for software developers and TAC experts, most field tasks, including deployment, management, and even troubleshooting of security systems, can often be performed effectively without diving into every technical nuance. 

Once again, this is just my personal opinion. In my trainings I tend to do the opposite: take a complex case and creak it down to a number of simple to grasp subjects, then slowly and carefully deepen the understanding, to be efficient. And then repeat the principle to the required depth. 

Looking at the questions from the author here, I am not ready to dive to the bottom of everything in a single sentence of even a paragraph.

I hope this makes sense. If not, let's talk further 🙂