Timeline for patching SSL vulnerability (Heartbleed Bug)

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.

so the patch downs your devices..how do you then get back online to patch the issues that took your entire network offline?  How much in lost revenue are you willing to tolerate?  I can bet your boss wouldn't be happy with this type of attitude...and if you are the owner you need to see beyond the immediate hysterics you are promoting.

Thanks Bruce, those were my assumptions, so I've already emailed every one of my clients with instructions similar to what Barry gave above.  I'll start dialing into the boxes of those for whom I didn't receive a read receipt in about 10 minutes. 

Cheers - Bob

Sorry for any short responses.  Posted from my iPhone.

Keep cool guys xD

I really hope that everyone understands that regenerating your certificates is not optional if you value your security and must be done *after* the patch is applied. 

Don't assume you weren't hacked. 
Unless you have evidence to the contrary, you should assume you were hacked. This attack can be carried out *silently*. 

I have questions about whether or not I should change my IPSec PSKs and other credentials in the UTM as well, my understanding of this attack is that anything "secret" stored on the server being attacked can be revealed. I'm thinking about PSK's, CA's, user information... Looking in the backend reveals that the UTM leverages chrooted environments, but I'm still concerned.

Edit: To clarify, my understanding is that anything sitting in memory can be revealed by this attack. This does not mean that the passwords are available in plaintext, but the ciphertext of them may be available. 


Yes it sucks but being secure is inconvenient sometimes.

I really hope that everyone understands that regenerating your certificates is not optional if you value your security and must be done *after* the patch is applied. 

Don't assume you weren't hacked. 
Unless you have evidence to the contrary, you should assume you were hacked. This attack can be carried out *silently*. 

I have questions about whether or not I should change my IPSec PSKs and other credentials in the UTM as well, my understanding of this attack is that anything "secret" stored on the server being attacked can be revealed. I'm thinking about PSK's, CA's, user information... Looking in the backend reveals that the UTM leverages chrooted environments, but I'm still concerned.

Edit: To clarify, my understanding is that anything sitting in memory can be revealed by this attack. This does not mean that the passwords are available in plaintext, but the ciphertext of them may be available. 


Yes it sucks but being secure is inconvenient sometimes.

Changing the certificate is, unfortunately, not always an option. In fact, in big installations, with a lot of tunnels and dial in users, any configuration change may be prohibitively expensive.

I know, security and all, but let's face reality. That makes it all the more important that this patch is delivered quickly.

Changing the certificate is, unfortunately, not always an option.

...


I feel your pain, especially with large-scale networks. I'm only responsible for my own UTM and this has already been a headache. 

 I know, security and all, but let's face reality. That makes it all the more important that this patch is delivered quickly.

I just want to point out though that your comment is worded in such a way that it sounds like you're considering yourself un-compromised. That is a considerable risk given that the attack can be carried out without leaving any traces at all. 

It's your risk to take, but please don't kid yourself into thinking there is no risk. There *is* a real possibility that you've been hacked already and don't/can't even know it. The only way to know for sure is to have a packet capture of your WAN connection, going back to when this was discovered, for packet analysis. 

I know, security and all, but let's face reality

Fair enough, but I do have one remaining question. Do you talk to your superiors about network security so nonchalantly? Food for thought.

...


I feel your pain, especially with large-scale networks. I'm only responsible for my own UTM and this has already been a headache. 



I just want to point out though that your comment is worded in such a way that it sounds like you're considering yourself un-compromised. That is a considerable risk given that the attack can be carried out without leaving any traces at all. 

It's your risk to take, but please don't kid yourself into thinking there is no risk. There *is* a real possibility that you've been hacked already and don't/can't even know it. The only way to know for sure is to have a packet capture of your WAN connection, going back to when this was discovered, for packet analysis. 


Fair enough, but I do have one remaining question. Do you talk to your superiors about network security so nonchalantly? Food for thought.

Don't lecture me on my job please.

We are not dealing in absolutes here. Every system you have will at one time or another be vulnerable to something.
So it's about limiting exposure.

But in the context of your post I find some of the above posts amusing, like "I have migrated my users to IPSEC for the time being" or "you can close those ports with a DNAT rule".
Fat lot of good that will do you, considering this vulnerability probably has been in the wild for some time.

Every time something like this happens, once it comes to light, and the patch for it comes out, it's too late, and you're ****ed, and your internet facing systems are potentially compromised. The only real solution would be to cleanse the whole thing, but you can't do that. Not every time. So how is this one any different?

So how is this one any different?

The difference is actually quite clear. This is different because this attack can be carried out entirely silently, most other attacks leave some kind of trace on the target system's filesystem or logs (which you can export to another server to prevent tampering, but you knew that already didn't you).

And to clarify, I haven't "migrated my users to IPSec", I've disabled SSL VPN.  And using a DNAT rule *does* allow you to block traffic going forward.  

It's called "mitigation". It's what you do to minimize the attack surface before you have access to the patch. It doesn't retroactively prevent you from being hacked, it prevents you from being hacked [via this] in the future. But you knew that too didn't you. [:)]

OK, so I spoke earlier with a customer that knows more than I about this issue (hey Mark!).  It has to do with the UDP keep-alive introduced in OpenSSL 1.1.   This is why it applies to WebAdmin (4444) as well as the other port 443 servers.

I have yet to listen to the Security Now podcast that Mark referenced, but, having taken action with my clients, will do so soon. 

Cheers - Bob

Sorry for any short responses.  Posted from my iPhone.

I watched it live...it's quite revealing..while many times steve downplays many things( he didn't think the nsa was spying much if at all until snowden)..he did adequately talk about the dangers of this.  Krebs On Security also has a good writeup about this issue as well.