Re: ssh and ids

[Martin Roesch <roesch () sourcefire com>]

On Jun 22, 2004, at 4:31 PM, Peter_Schawacker () NAI com wrote:

> Hi Marty,
>
> Since you were kind enough to mention us :-) I thought I would offer  
> two
> comments about what you wrote regarding SSL "key escrow" (is it really
> "key escrow" when the key isn't handed to a third party?) and IDS/IPS.
> First, remember that storing your web server's private key on an
> external system is something that's done routinely with SSL
> accelerators.  Hardware SSL accelerators are commonplace these days.

SSL accelerators typically provide algorithmic (cryptographic)  
acceleration only, they don't have any service ports to get into nor  
are they performing highly complex stateful analysis of the traffic and  
simulating an entire network stack.   The opportunities are  
probabilistically higher (significantly!) for something going  
disastrously wrong in an IDS engine are a lot higher than they are in a  
hardwired cryptographic MPU.  I certainly wouldn't feel comfortable  
about it, I can't speak for others...

> Second, we fully understand that folks are often squeamish about  
> sharing
> keys, so great care was taken to protect the private keys on the
> IntruShield appliance.  We believe we have found the best possible
> strategy for mitigating private key theft risk while eliminating the
> SSL/NIDS "blind spot".  Through the use of public key cryptography, we
> persist the key in such a way that one would need information that is
> resident only in the sensor, along with information that is resident
> only in the IntruShield Manager in order to recover the key. Having  
> just
> one or the other will not suffice.  I won't bore the list with the
> details, but our implementation is described here:
>
>         
> http://www.nai.com/us/_tier2/products/_media/sniffer/ 
> wp_encr_th_prot.pdf

Looks like the security of the server's private keys is dependent on  
the attacker never getting access to the unencrypted copy you keep in  
your sensor's RAM.  Can you assure people that that scenario can never  
happen with 100% certainty?  I guess it depends on what people are  
using SSL for ultimately, if they want truly secure communications or  
if they just want to have some level of session  
integrity/privacy/nonrepudiation for whatever purpose.

> Should an attacker root your web server, how safe will your private  
> keys
> be?  If your IDS/IPS can't handle TCP/443 to your production web
> servers, you have a blind spot where attackers can operate unseen and
> unhindered.  Which is worse, copying your web servers' private keys to
> your IPS to prevent a web server compromise, or being blind to attacks
> against those same servers?

How about just using a host-based IPS?  Seems to me that a HIPS would  
give you better coverage in all scenarios against compromise without  
sharing your secret key off the system.  After all, a shared secret  
isn't really a secret...

>  Frankly, I can't think of a single IDS/IPS
> product that is less secure than a typical web server.

Oh man, that's a blanket statement if I ever saw one.  How many  
commercial IDS/IPS systems have been through real 3rd party code audits  
where the results are available for inspection by 3rd parties?  We've  
done analysis of some 3rd party commercial IPSes here that have been  
considerably less secure than the a well configured web server.  What's  
the track record of security for a product that's been on the market  
for ~18 months that costs so much that maybe a thousand units are out  
in the field?

To quote Schneier's Law: Anyone can come up with a security system so  
clever that he can't see its flaws. The only way to find the flaws in  
security is to disclose the system's workings and invite public  
feedback.

> Security is all about trade-offs.  This is not a difficult one.

Depends on how serious you are about your crypto.  I personally think a  
HIPS addresses the scenario you outline more appropriately than a NIPS,  
but that's just me.

> You also alluded to the problem of covert channels.  I believe that the
> best protection against covert channels is to stop the attacker before
> the back door is installed.  Failing that, a host based IPS/firewall is
> the last, strongest line of defense.

Sure, if your deterministic detection engine has been tuned to detect  
and prevent it.  If your engine can't recognize things that it hasn't  
been told to look for (or worse yet, isn't deployed in a position where  
it can see the covert channel because it only has visibility into the  
traffic traversing it) then you're not going to be able to do anything  
about it.  The best defense for covert channels is to be able to  
recognize and remediate them whether or not they are the result of an  
attack or of an authorized insider acting contrary to site policy,  
regardless of how they route their traffic to the internet.

     -Marty

--
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Intelligent Security Monitoring
roesch () sourcefire com - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org


---------------------------------------------------------------------------

---------------------------------------------------------------------------