Re: ssh and ids
From: Martin Roesch (roesch_at_sourcefire.com)
Date: 06/23/04
- Previous message: Drew Simonis: "Re: Anomaly Based Network IDS"
- In reply to: Peter_Schawacker_at_NAI.com: "RE: ssh and ids"
- Next in thread: Drew Copley: "RE: ssh and ids"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 22 Jun 2004 18:09:30 -0400 To: Peter_Schawacker@NAI.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 --------------------------------------------------------------------------- ---------------------------------------------------------------------------
- Previous message: Drew Simonis: "Re: Anomaly Based Network IDS"
- In reply to: Peter_Schawacker_at_NAI.com: "RE: ssh and ids"
- Next in thread: Drew Copley: "RE: ssh and ids"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
