Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 158 replies
  • Subscribers 3 subscribers
  • Views 150916 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Timeline for patching SSL vulnerability (Heartbleed Bug)

strategicdata
Heatbleed Bug (CVE-2014-0160)

Hi

Is there any timeframe for patching this SSL/TLS bug for Astaro Security Gateway V8.
We are on the latest 8.311 (as V8 is an approved appliance for us and V9 is not).

Thanks


Heartbleed Bug
https://news.ycombinator.com/item?id=7548991


This thread was automatically locked due to age.
  • 0
    Does the IPS have a signature for this leak?
  • 0
    As it is not traceable, there is no signature for it I assume...
  • 0 in reply to R0n1
    Gents,

    we are actually working for a patch for all affected systems. Please have a look at 

    up2date | Sophos Blog

    A knowledge base article that describes the issue as well as what to do if a system is compromised is in preparation and will be published soon.

    I will kepp you posted.

    Dominic
  • 0 in reply to M.Rottler
    As it is not traceable, there is no signature for it I assume...


    Snort has a rule for it. VRT: Heartbleed Memory Disclosure - Upgrade OpenSSL Now!

    Sophos, does the IPS detects this?
  • 0
    RED tunnles are also affected and should be disabled, right?? [:(]
  • 0
    Hi everyone,

    just wanted to add my 2 cents to this discussion. First of all, I think Astaro/Sophos is handling this issue not very good. There is not a single word about how to tighten up security on exploitable systems in here IMPORTANT NOTE: OpenSSL Vulnerability (CVE-2014-0160) in Sophos UTM | Sophos Blog.

    Users have already figured out that they should close the user portal and SSL VPN. I want to add a third proxy to the mix: SMTP (with TLS enabled) could also be exploitable. So for all of you who are running said proxy - think about disabling it for the time being. I don't know how to test if it's really compromisable. But if you want to know if the proxy uses TLS do a telnet mail.yourdomain.com 25 and issue an EHLO. If it brings up STARTTLS, that's maybe a bad thing..

    Or what do you think?
  • 0 in reply to dschmidl
    Gents,

    we are actually working for a patch for all affected systems. Please have a look at 

    up2date | Sophos Blog

    A knowledge base article that describes the issue as well as what to do if a system is compromised is in preparation and will be published soon.

    I will kepp you posted.

    Dominic


    I hope you tell us how to find out if a system has been compromised [8-)]
  • 0
    People have mentioned renewing SSL certs for reverse proxy (web server protection) is this the case when using a third party SSL wildcard cert from Go daddy?

    Thanks
  • 0 in reply to Ross86
    People have mentioned renewing SSL certs for reverse proxy (web server protection) is this the case when using a third party SSL wildcard cert from Go daddy?

    Thanks


    Yes. Due to the attack having the potential to obtain the private key it would be strongly recommended to remove the existing certificate and private key from any servers and install a new one.

    I believe you may be able to do this be re-keying the SSL certificate. GoDaddy enables you to do that by following these steps. You will need to generate a new private key and certificate signing request, then obtain a new signed certificate.

    Do not do this until after you've patched all the servers that use the current private key and certificate, otherwise you'll need to repeat the process once they are patched to be sure they haven't been compromised.
  • 0 in reply to barkas
    I hope you tell us how to find out if a system has been compromised [8-)]


    There's a difference between compromised and affected. Every system using the buggy openssl libs is affected. If the security hole was used to gain access to private keys then your system may be compromised or not. But one thing is clear in this case: Somebody has your private key an can use it to read your encrypted data. Wait for a fix, implement it and change ALL of your keys is the only thing you can do. Nearly no business is able to turn off nearly it's whole firewall for hours or days i think.

    I hope there will be a fast fix.