Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Parabol
Contributor
Jump to solution

Preventing TLS 1.0 to a specific destination IP

Hi all,

We have a scenario where one of our external facing web servers is showing to support TLS 1.0 and 1.1 despite disabling this locally on the server. The reason seems to be because HTTPS inspection is used on the Checkpoint firewall with this server, and the firewall is enabling it.

I did see THIS previous checkmates post which shows how to set the minimum supported SSL version globally with the GuiDBedit tool, however this would obviously prevent ALL TLS 1.0 connections. We only want to prevent it to this specific server.

Also sk126613 shows how to disable specific ciphers, but this is for the whole gateway, again impacting ALL TLS connections.

One method we thought for sure would work was creating an IPS exception for TLS 1.0 & 1.1 with the action set to Prevent with the server destination IP. But this unfortunately did not work, the exception isn't triggered, the signature seemingly isn't identified.

We also noticed there are default objects in smartconsole named tls1.0 and tls1.1, we tried creating a standard firewall rule (also in the Application policy) to block this tls traffic destined to the server IP. But we found it blocked ALL https traffic (the objects seemingly match against tcp/443)

I was wondering if any of you guys had any other ideas of things we could try? 

Thanks

 

0 Kudos
1 Solution

Accepted Solutions
Parabol
Contributor

Hi all, apologies I forgot to update this sooner with the resolution. So we had the global IPS expectation in place to prevent TLS 1.0 & 1.1 traffic destined for our target web servers, however the traffic was still being permitted.

It turns out that the default profile behavior for the TLS 1.0 and 1.1 protections is "inactive". We changed this to "Detect" for the specific profile, and then the prevent exception became active and began blocking the TLS traffic. Which makes sense, having the protection set to "Inactive" essentially turns the protection off I guess, so any exception you make using the protection won't be enforced. 

View solution in original post

0 Kudos
5 Replies
PhoneBoy
Admin
Admin

I'm guessing this service won't work the way you expect until you enable the Protocol Signature for it:

image.png

Push policy after making this change.

Parabol
Contributor

Thank you, I did try this but unfortunately the TLS1.0 protocol still shows to be supported when testing.

I noticed that I could however still access the server on HTTPS, so it seemingly isn't blocking all HTTPS traffic as the rule did previously before enabling this setting. But the rule isn't showing to be blocking anything either in it's traffic logs.

I did try placing the rule as both a Network and Application rule to ensure both policies enforced this (Application blade is enabled).

0 Kudos
Blason_R
Leader
Leader

So If I understood the question correctly you are intercepting the inbound https traffic using certificate and have put source as any in your https inspection rule? Then why not go for WAF or something - That way you will get granular inspection.

I always have taken this approach and for my inbound servers have deployed the waf. Nowa days I am using Appsec with Nginx instead of intercepting inbound traffic.

Thanks and Regards,
Blason R
CCSA,CCSE,CCCS
Parabol
Contributor

Thanks, we have been looking into WAF products, it does seem like this type of solution would be more suitable to be honest. 

0 Kudos
Parabol
Contributor

Hi all, apologies I forgot to update this sooner with the resolution. So we had the global IPS expectation in place to prevent TLS 1.0 & 1.1 traffic destined for our target web servers, however the traffic was still being permitted.

It turns out that the default profile behavior for the TLS 1.0 and 1.1 protections is "inactive". We changed this to "Detect" for the specific profile, and then the prevent exception became active and began blocking the TLS traffic. Which makes sense, having the protection set to "Inactive" essentially turns the protection off I guess, so any exception you make using the protection won't be enforced. 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events