- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- SSH medium strength ciphers suited supported(SWEET...
- 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
SSH medium strength ciphers suited supported(SWEET32)
Hello Everyone ,
Can anybody suggest me remediation for SSH vulnerability of checkpoint Gaia R80.10 OS build 462 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's just like any other Linux box. Go tweak the /etc/ssh/sshd_config and exclude the ciphers you don't want the system to offer. The keyword you're looking for is "Ciphers".
Up through R80.30 GAiA 3.10, Check Point includes OpenSSH 4.3, which corresponds to OpenBSD 3.9. Here is the version of the manpage you should use:
https://man.openbsd.org/OpenBSD-3.9/sshd_config
As an aside, shipping an OpenSSH version from 2006 borders on malpractice. Come on, guys. I want to move to P521 keys, and Check Point shipping software more than a decade out of date is holding me back.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No need. Our official response is: not vulnerable
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Except it clearly is a potential issue as long as 3DES is offered. As long as it is offered, it is possible for it to be negotiated, making that session subject to cryptanalytic attack. The only way to definitely and provably avoid this analysis is to prohibit the affected ciphers from being negotiated at all.
It is extremely unlikely a session could fall victim to this. Extremely unlikely does not mean impossible.
Claiming to not be vulnerable when you are is definitely malpractice.
Further, even if sshd has been modified to offer 3DES but to immediately close any connections which end up using it, some people just want the easiest way to get the audit result to go away. In my experience, telling the auditors the vendor said that isn’t a problem is never fast, and everybody forgets about the justification the next time around.
Removing the cipher from the list offered by the server is easy, and it should be permanent until the OS is reinstalled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Bob_Zimmerman
Please allow me be clear on this.
1. "Not vulnerable" statement is correct. The only way you get 3DES is when user requests is specifically. This does not happen with any of the modern browsers, as the quoted SK clearly explains. To BE VULNERABLE you have to craft the request for 3DES & weaker cyphers, which does not go beyond audit use cases.
Unless you redefine the term malpractice in your dictionary, this argument does not stand.
2. However, we do understand necessity and desire to remove weak, obsolete and outdated cyphers from the system. To provide you a proper way of configuring your specific cyphers with any of the elements: SmartPortals and HTTPSi alike, we provide Cipher configuration tool described in here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
Hope this addresses your concerns. If not, please let me know, we will be happy to assist any further.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In addition, you can easily force only desired ciphers for sshd: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
