Timeline for patching SSL vulnerability (Heartbleed Bug)

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. [:)]

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. [:)]