Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 158 replies
  • Subscribers 3 subscribers
  • Views 151056 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
    "Better to rush it out" is something I've seen way too many times from vendors over the years, Microsoft most famously. Then the patch to fix the vulnerability breaks something else and the vendor has to send out a patch to fix the patch.

    For my user base at least, I would rather have to cripple that one aspect of the system for a few days (till a proper patch is released) in response to a vulnerability then to risk a hastily applied patch breaking things beyond just the vulnerability. I can tolerate downing the SSL VPN subsystem for a few days to a week, I can't risk a patch breaking my UTM and crippling close to a dozen offices in one go.
  • 0 in reply to barkas
    For this patch, I can not wait a couple of days, it is too critical. Better to rush it out and break something than leave all your installations open for days.
    I can not shut down every system, nor can I regenerate the certificates of certain systems.


    not at the expense of downing your security device...that's just shortsighted and NOT the way to run a security appliance.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0 in reply to William Warren
    not at the expense of downing your insecurity device...that's just shortsighted and NOT the way to run a security appliance.


    fixed that for you
  • 0 in reply to William Warren
    not at the expense of downing your security device...that's just shortsighted and NOT the way to run a security appliance.


    I couldn't disagree more. I'd rather want my security devices offline than vulnerable to this flaw.

    I'm certain that automated attacks are either already happening or are about to happen that make use of this bug.
  • 0 in reply to jnky
    I couldn't disagree more. I'd rather want my security devices offline than vulnerable to this flaw.


    Hi, I don't know if you read the whole thread, but all you need to do as a workaround is:

    1. enable Webadmin for your management LAN(s), and disable it for Internet and ANY

    2. disable the SSL remote access VPN

    3. probably disable Web Server Protection

    4. disable the End User Portal

    Barry
  • 0 in reply to BarryG
    and... once the patch is installed, it is recommended that you regenerate any SSL VPN certs, and the host cert, for the VPN as well, as you have no way of knowing if someone's "lifted" your certs or not (the attack is undetectable).

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0
    In this specific instance, the vulnerability in SSL affects three main subsystems, WebAdmin, User Portal & SSL VPN. The first shouldn't be exposed publicly anyways, the second & third can be disabled temporarily.

    For my organization, the cost to my firm for shutting down the SSL VPN for a week till it's patched is an order of magnitude smaller then the cost of downtime due to a bad patch dropping my primary UTM. Shutting off the SSL VPN affects half a dozen users, a broken UTM impacts over 100. You do the math.
  • 0 in reply to TheDrew
    Will this patch most likely update without intervention, or will I need to login to the UTM?

    I have User Portal running and VPN, but I'm not using the VPN.  I won't be able to turn it off due to lack of access to the administration side for a couple days.

    What kind of risk am I at if I do not use the VPN (it is available), but have the User Portal accessible?
  • 0
    My clients all have been advised to use a different port on UDP for the SSL VPN and a different port for the User Portal.  Are those that have taken this advice still exposed there?   I don't see any way to avoid turning off any Virtual Server definitions that use SSL.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    I don't believe changing ports will help you.  All an attacker need do is a portscan (slow one to avoid portscan detection, mind you)... that said, using an alternate port would slow them down -- the problem is many of my customers use the SSL VPN on TCP 443 because that's the best way to get through some of the hotel firewalls "out in the world."

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Cookie Information Banner