Do I need https inspection to truly benefit from IPS?

[Logan]

Hi All,

As the subject states, do I need https inspection enabled to truly benefit from IPS protections? Does IPS perform just as good on traffic that isn't inspected? Any data that proves this one way or another?

While our workstations have https inspection, not all of our servers have inspection enabled. So we just want to make sure IPS is fully doing its job on servers.

Just trying to get some real data and information to educate myself and my team.

Thanks in advance!

Logan

[Bob_Zimmerman]

No data needed. IPS can't inspect what it can't see. TLS prevents anything between the TLS endpoints from seeing the data exchanged. Therefore, TLS prevents IPS on the firewall from inspecting the data exchanged unless the firewall terminates TLS.

HTTPS Inspection is the feature which lets the firewall terminate TLS.

Protocols which aren't wrapped in TLS can get IPS inspection without HTTPS Inspection enabled. It will catch ping-of-death attempts and so on. That said, most interesting traffic today uses TLS.

[genisis__]

HTTPS inspection is something only feasible on high-end devices.  I've repeated asked what the strategy is to ensure https inspect can be used on medium sized appliances, I've seen nothing suggesting Checkpoint can deliver this.
The only way forward is to radically rethink about the hardware platforms to ensure dedicated https inspection resource is built in (The NVidia card is likely to be utilised for this function, but this is high-end appliances).

So basically, if you have a regional office why buy checkpoint when other vendors have an appliance that is targeted at medium sized offices while ensuring all blades can actually be used without compromising on performance.  

Keep in mind business want security but they are not going to spend an unrealistic amount for a regional site installation.

Please Checkpoint can we understand what the road map will be for this targeting medium sized deployments.

[genisis__]

Have you also noted that in the sizing tool, there is no https inspection option...ummm wonder why!

[the_rock]

Never really paid attention to it, but no need to wonder any longer : - )

[PhoneBoy]

I would argue that many of those competitors compromise on security that they provide and/or the security of their own platforms.
Regardless, I understand the concern.
We've made some performance improvements in the most recent releases and more are planned for the next release (R82).
I presume some details about this will be covered at CPX.

It might be better to have a conversation with your local Check Point office with your precise performance requirements. 

[Alex-]

You can argue that but there is a moment when the renewal time is there, the prices of CP and the competition are in and we explain the customer that it will be better in the next release of the next platform when some are still only upgrading to R81.10 from R80.X because of cost, operational and hotfix maturity reasons, especially with VSX and advanced platforms.

Now I understand we'll be in a mix of R80.40, R81, R81.10, R81.20 and then R82 which each have their own set of capabilities, some of which might be ported back or not.

Some customers don't even know what version they run, they trust us integrators to make the best out of their installation base.

They don't ask for a new OS each year.

I might be naive but I'd rather see R81.10 as a long-term R81 release with all the features integrated along in jumbo's as long as it's feasible (IoT, Hyperflow, SD-WAN, the announced HTTPSi auto-detect) and R82 as a major stepstone with future improvements which really can't be ported back in R81.10.

That would be much clearer to customers.

[the_rock]

Very logical points @Alex- 

[Bob_Zimmerman]

Mellanox (acquired by Nvidia, but ConnectX predates that acquisition) makes programmable switch chips. ConnectX-6 adds AES-XTS hardware to offload the symmetric portion of TLS, and you can toss the asymmetric parts onto the card's CPU, but it's not great at the kinds of operations needed for TLS interception (generating new key pairs and low-latency signing operations). From the description of the Lightspeed cards, they sound more like ConnectX-5 (my bet would be the same chip as the MCX516A-CCHT), which does not have the AES-XTS hardware. I know Check Point's other cards like the 2x40g and 2x100g are ConnectX-4 and ConnectX-5.

For HTTPS Inspection acceleration, I would actually expect a Marvell (formerly Cavium) Nitrox V, which is the product line used by most load balancers with hardware TLS. Maybe an Intel QuickAssist card. Check Point gets their hardware from Lanner. Many of Lanner's 1U network-focused boxes have a fully-internal slot for a custom-form-factor PCIe card. I know of at least one load balancer vendor which also gets their hardware from Lanner, and they offer a Nitrox V card which goes in that internal slot.

[Timothy_Hall]

Great insight on the hardware side of things, thanks!

[Bob_Zimmerman]

This is way off topic, but if you want to see some other interesting hardware, check out Barefoot's (acquired by Intel in 2019) Tofino line. The Tofino 2 has up to 256x 56g SerDes lanes, allowing up to 128x100g interfaces per switch chip. Fully programmable data path with P4, which is a fascinating language. Essentially, you define a set of headers, the parsing logic to populate them, then stateful forwarding actions to take based on header values. It can do really fancy forwarding at line rate across all ports. The chip itself is HUGE. BGA4432 with roughly 1/2 the pins for ground, 1/4 for V+, 1/4 for all the SerDes lanes.

I haven't taken a Maestro orchestrator apart, but my understanding is they use a Broadcom Tomahawk. Intel bought Barefoot to compete with Broadcom in that space. The acquisition seems to have been connected with Omni-Path's discontinuation.

Oxide is using Tofino 2 to do some extremely cool stuff in their switches. Incidentally, their sleds use 100g network interfaces from Chelsio, which is a whole other rabbit hole.

[Bob_Zimmerman]

Turns out I was wrong about the Maestro orchestrators. I had completely missed that Mellanox has their own semi-whitebox Ethernet switch line (now that they're owned by Nvidia, they sell them directly with Cumulus preinstalled, but they're also available with ONIE) which they call Spectrum. The MHO-140 appears to be an Nvidia SN2410 and the MHO-175 appears to be an Nvidia SN3700 or possibly SN3700C. Not sure about the MHO-170.

Given the normal interface cards from Mellanox and the "lightspeed" accelerated data path cards also from Mellanox, this makes sense.

[Bob_Zimmerman]

I finally got a chance to poke a QLS250. It has a nearly identical PCIe topology to the 16200. The only difference is the 16200 has four PCIe 3.0 x8 root ports going to the slots, while the QLS250 has two PCIe 3.0 x8 root ports and the other two are combined into one PCIe 3.0 x16 root port. The specialized network card has the PCIID 15b3:101d (find the card in 'lspci -vv', take note of the address, then find it in 'lspci -nv'), which is a Mellanox ConnectX-6 Dx. Nice to see I underestimated the hardware used for the specialized forwarding path.

[Logan]

This is what we thought and were afraid of. However, I suppose I just assumed IPS was smarter and able to detect more somehow.

[Timothy_Hall · Accepted solution]

Realistically, yes you do need HTTPS Inspection for proper IPS functioning.  Without it IPS will still be able to inspect cleartext payload data, packet headers, and the initial client/server negotiations prior to the start of encryption in the case of HTTPS.  Given that around 85-90% of web traffic is now HTTPS you will be missing a lot.  This is why HTTPS Inspection was extensively covered in my IPS/AV/ABOT Immersion class even though it is not directly related to those features.  Also don't forget about SSH, Check Point firewalls do support SSH Deep Inspection and the cool ability to block port forwarding, but this feature can only be configured from the CLI of the gateway which is why few people know about it.

Performance is definitely a concern, but at least some of that can be mitigated with a properly ordered & configured HTTPS Inspection Policy to avoid multiple HTTPS Policy lookups for the same connection, and avoid unnecessarily triggering Active Streaming when it is not absolutely needed.  See here: HTTPS Inspection Policy Rule Order

At some point the Lightspeed/Nvidia card will probably be able to handle at least the HTTPS bulk encryption & decryption aspect, as part of this initiative SecureXL is making the transition out of the kernel (sim) to User Space (UPPAK/usim) starting in R81.20 on Lightspeed systems. 

The unofficial way to estimate the performance impact of HTTPS Inspection is to cut the rated throughput of the appliance in half.  So if an appliance is rated for 3Gbps with the features you will be using(NGTP,NGTX, etc), to account for HTTPS Inspection cut that number in half to 1.5Gbps.

[G_W_Albrecht]

Check Point firewalls do support SSH Deep Inspection and the cool ability to block port forwarding, but this feature can only be configured from the CLI of the gateway which is why few people know about it.

Any links or references ? 😎

[Alex-]

Module "CPSSH" (SSH Inspection) (checkpoint.com)

SSH Deep Packet Inspection (checkpoint.com)

[Timothy_Hall]

SSH Deep Packet Inspection got a mention in my IPS/AV/ABOT Immersion course and the relevant page is below.  There is no SK article for this feature; it is only documented in the Threat Prevention Administration guide starting in R80.40 when it was introduced.

[the_rock]

I think you got all excellent answers, specially from @Timothy_Hall . In short, ANY vendor would tell you the same, to truly benefit from IPS/app control, you definitely should have inspection enabled. I mean, its reality nowdays that literally 99% of the world's websites are https, so it only makes sense to have that feature enabled for proper inspection.

[genisis__]

and thats my point hardware base https inspection should be in all the models a vendor has; now clearly if you have a 6200 the real work performance level will difference to say a 16200.
So it would make sense that hardware https inspection would be rated to say 500Mbps on a 6200 but 2GBps on a 16200 because the hardware https module would be spec'ed according to the gateway appliance used.
Without https inspection you realistically can only just use the firewall blade if this is just an internet gw., which makes Checkpoint expensive and negates all the real cool blades that justify the costs.

[PhoneBoy]

From the recent CheckMates Fest:

While it clear that HTTPS Inspection is needed to inspect traffic up fully, there are challenges with both implementation and the fact not all traffic can be inspected. What are we doing to improve these challenges?

We are addressing both performance and usability challenges during the coming year, some of which will land in the next major release (R82). We are also developing a "learning mode" which will help identify potential issues during deployment and provide recommendations.

You can see what Gera has to say about this in the video, and I suspect we'll have more to say about it at CPX.
Note that at this point, we're focused on software-level changes.

[the_rock]

R82? I expect SPECTACULAR things out of that version...I mean it : - ). And, if I may, here is the name suggestion...Hercules ; )

[Chris_Atkinson]

Appreciate the generalization but what about non-HTTPs traffic? 

Also controls such as Anti-bot & DNS security for example...