- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: GAIA Portal Lockdown
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
GAIA Portal Lockdown
Guys,
I'm trying to lockdown the GAIA Portal and as such done the below which works, however the odd thing is, I expect TLSv1.2 and TLSv1.3 to work. When I did a test using SSLScan to just see what what ciphers are exposed, the output showed that TLS1.2 is disabled.
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 disabled
TLSv1.3 enabled
On the gateway we can see TLSv1.2 has one cipher enabled:
cpopenssl ciphers -v 'ECDHE-RSA-AES256-SHA384:AES256-SHA256:!ADH:!EXP:!RSA:+HIGH:+MEDIUM:!MD5:!LOW:!NULL:!SSLv2:!eNULL:!aNULL:!RC4:!SHA1'
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
I locked down the portal by using the below.
cp /web/templates/httpd-ssl.conf.templ /web/templates/httpd-ssl.conf.templ_ORIGINAL
chmod u+w /web/templates/httpd-ssl.conf.templ
sed -i 's/SSLCipherSuite HIGH:!RC4:!LOW:!EXP:!aNULL:!SSLv2:!MD5/SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:!ADH:!EXP:!RSA:+HIGH:+MEDIUM:!MD5:!LOW:!NULL:!SSLv2:!eNULL:!aNULL:!RC4:!SHA1/g' /web/templates/httpd-ssl.conf.templ
sed -i 's/SSLProtocol -ALL {ifcmp = $httpd:ssl3_enabled 1}+{else}-{endif}SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2/SSLProtocol -ALL {ifcmp = $httpd:ssl3_enabled 1}+{else}-{endif}TLSv1.2 +TLSv1.3/g' /web/templates/httpd-ssl.conf.templ
chmod u-w /web/templates/httpd-ssl.conf.templ
/bin/template_xlate : /web/templates/httpd-ssl.conf.templ /web/conf/extra/httpd-ssl.conf < /config/active
tellpm process:httpd2
tellpm process:httpd2 t
Can anyone spot why TLSv1.2 is not shown as enabled and not finding the single cipher?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
why not using cipher_util?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Will this work from Windows? I just grab whatever works on Windows to do a quick test.
I take it your referring to the tool related to sk126613
Which blade would you like to configure?
(1) Multi Portal
(2) SSL Inspection
1
Make sure the selected blade is active.
Cannot access the configuration file
Aborting...
Also the SK does not indicate if we can disable TLSv1.0, TLSv1.1
I've no license on the devices yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you finish the first time wizard yet or now? If you did not, please do.
Also, there are quite a few discussions for the matter in the community already, for example: https://community.checkpoint.com/t5/General-Topics/Disable-TLS-1-0/m-p/70338#M14237
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
First time wizard has been completed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Then license is not an issue, you should have 2 weeks evaluation. Did you try your modifications before or after you used cipher_util?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
before, so within the two week period.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is the version you are using?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
R81 with JHFA23
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Then it might be that you have messed with HTTPd settings and corrupted the config file, then cipher_util fails. I would re-install and use cipher_util before anything else. Also, the GW should have policy installed before and after modifications.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm doing another build right now, so I can try it on there as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sure, let me know if this works for you. If there is an issue with cipher_util, and before you make any modifications manually, please open a TAC case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a new build, and the policy will be installed within the cutover window.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Clean build - same result
Clean build with JHFA23 - same result
not in all cases no license and policy installed its just a clean build ready for commissioning.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Open a support case with TAC please.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
cipher_util is only relevant when you have a policy installed (and configuration such that multi-portal is active)
Same with the TLS versions configured in snx_ssl_max_ver and snx_ssl_min_ver
Without multi-portal in use, the httpd configuration is relevant.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cool - so back to my original question then related to why TLSv1.2 shows as disabled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
More update:
I've discovered that when locking down the ciphers etc you need to be careful. The symptom I experienced was:
Logs & Monitors > General Overview or new tab "Error loading tab - Error: SslVersionOrCipherMismatch" Gateway object license tab "Loading Error: ERRL_SSL_VERSION_OR_CIPHER_MISMATCH" for more details see sk166932.
I check the KB and found SK171707, after which then lead me to the lockdown I did. At this point I tweaked the setting to the following:
SLCipherSuite HIGH:!ADH:!RC4:!DHE:!LOW:!EXP:!RSA:!eNULL:!aNULL:!SSLv2:!MD5
SSLProtocol -ALL {ifcmp = $httpd:ssl3_enabled 1}+{else}-{endif}TLSv1.1 +TLSv1.2 +TLSv1.3
When run a scan against the IP for the SMS I get the following discovered:
SLCipherSuite HIGH:!ADH:!RC4:!DHE:!LOW:!EXP:!RSA:!eNULL:!aNULL:!SSLv2:!MD5
SSLProtocol -ALL {ifcmp = $httpd:ssl3_enabled 1}+{else}-{endif}TLSv1.1 +TLSv1.2 +TLSv1.3
When run a scan against the IP for the SMS I get the following discovered:
TLSv1.3 enabled
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
Compression disabled
Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-ARIA256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-ARIA128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-CAMELLIA256-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-CAMELLIA128-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253
Server Key Exchange Group(s):
TLSv1.3 128 bits secp256r1 (NIST P-256)
TLSv1.3 192 bits secp384r1 (NIST P-384)
TLSv1.3 260 bits secp521r1 (NIST P-521)
TLSv1.3 128 bits x25519
TLSv1.3 224 bits x448
TLSv1.2 128 bits secp256r1 (NIST P-256)
TLSv1.2 192 bits secp384r1 (NIST P-384)
TLSv1.2 260 bits secp521r1 (NIST P-521)
TLSv1.2 128 bits x25519
TLSv1.2 224 bits x448
Issue was resolved in the GUI.
If anyone can suggest further tweaking please shout, as I would like to lock this down much as possible.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I experienced that myself once...playing around with those ciphers can actually cause more harm than good. I dont know if there is a better solution to this currently...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
maybe the Gurus can give some guidance that will lock this down and to keep the security audit team happy, while not breaking anything.
I think what I've done is about as good as it gets without breaking something.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree cold heartedly. I would leave it alone if I were you.
