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)

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.
  • So, I used the compromised VPN to shut down my server behind the firewall and all is good.  I don't have remote access to the administrative side so I couldn't turn off the SSL features, so it's just going to have to bear it.

    I understand all the certificates and stuff need to be rebuilt after this issue, but is it enough of a risk that I need to rebuild the machine when I get back to it?  I received the patch email, but it looks like it requires intervention to deploy and I won't be able to do that for a couple days.  Should the machine be considered compromised from that time period?
  • I Manually Download and Uploaded the 3 files before the Up2Date "proceeded"

    Have to admit it was a mess but somehow it "started" installing when "3rd" file is uploaded.

    u2d-sys-9.109001-110022.tgz.gpg (Third File Manually)
    u2d-sys-9.110022-111007.tgz.gpg (Second File Manualy)
    u2d-sys-9.111002-111007.tgz.gpg (First File Auto Up2Date)

    1) Changed the Password for my SSL VPN Username.

    2) How to Re-Generate Certificates? Is there a step by step guide?

    3) Downloading the SSL VPN Client for windows to install.
  • The 9.200-11 to 9.201 update is in the FTP.

    ftp://ftp.astaro.com/UTM/v9/up2date/
  • But where is 9.2 update?


    Well, 9.2 is gone. I can't find the up2date package anymore. But they promise to deploy it ASAP.

    EDIT: it's here!

    ftp://ftp.astaro.com/UTM/v9/up2date/u2d-sys-9.200011-201023.tgz.gpg
  • When I install u2d-sys-9.200011-201023.tgz.gpg, it fails to install...see screenshot

    email notification:
    Firmware Up2Date installation failed: An error occured during the RPM pre-installation test (1) Please check the up2date log file for detailed information.
  • How to Re-Generate Certificates? Is there a step by step guide?


    There is a pretty useful guide for this and all other steps, in order: http://www.sophos.com/en-us/support/knowledgebase/120851.aspx
  • there is a pretty useful guide for this and all other steps, in order: Heartbleed: Recommended steps for UTM



    wooohooo, thanks!! :-)
  • Dear Sophos - did you just auto-update my ASG?

    After I got the downtime window and it did not work due to the version mismatch I have been waiting, checking for new Updates and finally set the search for updates back to automatic.

    At 19:41 my asg restartet - without interaction from my side, nor it was another admin.

    Did you set an automatic installation instruction? On my production machine?
  • fobe, show the lines from the Up2Date log relative to this.

    t-work, as soon as your box downloaded the missing 9.109-to-9.100 Up2Date, it restarted your failed installation of 9.111.

    Repeating a post from a prior page:
    If you don't also see the 9.109-to-9.110 Up2Date, download it at the command line as root by executing the following block of code:
    cd /var/up2date/sys
    wget http://ftp.astaro.com/UTM/v9/up2date/u2d-sys-9.109001-110022.tgz.gpg
    /sbin/auisys.plx --showdesc

    and then install in WebAdmin.

    Cheers - Bob
  • I understand all the certificates and stuff need to be rebuilt after this issue, but is it enough of a risk that I need to rebuild the machine when I get back to it?  I received the patch email, but it looks like it requires intervention to deploy and I won't be able to do that for a couple days.  Should the machine be considered compromised from that time period?


    Hi, 

    The certificates may have been compromised, and it's possible someone used that to get your passwords (if they could sniff your traffic when you logged in).

    And, if you allow admin logins from anywhere, they then may have logged in.

    If you don't allow admin (webadmin) logins from anywhere, then no one should have been able to get in, and re-keying the certs should be enough.

    You can re-key the webadmin cert remotely without affecting VPNs, etc.

    Barry