Timeline for patching SSL vulnerability (Heartbleed Bug)

"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.

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.

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

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.

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

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).

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.

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?

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

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."