Re: ssh and ids
From: Adam Powers (apowers_at_lancope.com)
Date: 06/22/04
- Previous message: Peter_Schawacker_at_NAI.com: "RE: ssh and ids"
- In reply to: Martin Roesch: "Re: ssh and ids"
- Next in thread: Martin Roesch: "Re: ssh and ids"
- Reply: Martin Roesch: "Re: ssh and ids"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 22 Jun 2004 09:56:47 -0400 To: Martin Roesch <roesch@sourcefire.com>, "Runion Mark A FGA DOIM WEBMASTER(ctr)" <mark.runion@us.army.mil>
Regarding: "Hacker busts into your network and sets
up an SSH server, RNA picks it up and can let you know that it detected
a new service and logs the flow data, etc."
But you can't stop with simple "port profiling". StealthWatch has had this
technology for years and we've found that the same problems you run into
with IDS alerting is seen when attempting to truly profile and react to each
new service entering the network. StealthWatch even takes it a step further
and allows you profile outbound "client" traffic if you wish (in addition to
server ports). Still, this is a classic "needle in a haystack" problem.
Sure, the data that identifies the attack is there, but it's useless because
you can't find it.
Port profiling has to be augmented with other more intelligent techniques to
expose the important data.
Sure, StealthWatch can be configured to alarm when a new port shows up, but
the real power of the port profiling is seen during the flow analysis
process. StealthWatch uses the port profile data to determine how network
traffic should be analyzed. An example includes a DNS related ICMP Port
Unreachables. When StealthWatch recognizes a host as being a DNS server, it
immediately begins applying flow analysis algorithms that are suitable for
analysis of DNS traffic. The algorithms expect large numbers of small
packet, many of which will elicit ICMP type 3 code 3 responses from the
client resolver (Windows 2000's resolver often sends 2 or more packets from
the same source port to different servers, causing both servers to respond;
one packet gets used to fulfill the query, the second packet get rejected
with a Port Unreachable). Without port profiling data, StealthWatch would
misconstrue the Port Unreachables as UDP scanning behavior.
On 6/18/04 8:53 PM, "Martin Roesch" <roesch@sourcefire.com> wrote:
> Hey Mark,
>
> VENDOR ALERT: I'm a vendor and I'm going to talk about my technology.
> Please take my comments with an appropriate amount of sodium chloride.
>
> Sourcefire's RNA product is capable of isolating/identifying layer-7
> protocols (including encrypted protocols) and tracking the flows. For
> example, if you wanted to find SSH/SSL traffic that it being initiated
> from outside your network to inside, setting up a query (or automated
> reporting) is pretty trivial. Hacker busts into your network and sets
> up an SSH server, RNA picks it up and can let you know that it detected
> a new service and logs the flow data, etc. Anyway, if you're
> interested in seeing a demo or talking more, let me know.
>
> As far as IDS being able to do much with encrypted traffic, there's
> generally not much to do once the session goes encrypted. You can
> setup rules in a system like Snort to differentiate between "allowed"
> and "everyone else" hosts talking to machines on your network pretty
> easily (and you can query RNA's flow data for the info too).
>
> I know the NAI guys just released a mod to their sensors that allow
> them to do real-time SSL decryption if you're willing to escrow the
> private crypto keys on the box (shudder). There's been talk of
> implementing the same sort of thing in Snort (ala ssldump) for a while,
> but it's never come together...
>
> -Marty
>
>
> On Jun 18, 2004, at 2:18 PM, Runion Mark A FGA DOIM WEBMASTER(ctr)
> wrote:
>
>> Lets suppose the attacker is mildly sophisticated, and after making the
>> initial assault roots the box and installs a secure backdoor or two.
>> Is
>> there any IDS capable of isolating data it cannot read, except to
>> monitor
>> authorized port usage of a system or group of systems? Not to
>> complicate
>> the question, but when the attacker is using portal gates and all
>> communications traffic is encrypted in normal channels how can an IDS
>> participate? Monitoring normal traffic patterns seems a bit slow for
>> detection.
>>
>> -
>> Mark Runion
>>
>>
>> -----------------------------------------------------------------------
>> ----
>>
>> -----------------------------------------------------------------------
>> ----
>>
>>
-- Adam Powers Senior Security Engineer Advanced Technology Group c. 678.725.1028 o. 770.225.6521 f. 770.225.6501 e. apowers@lancope.com AOL IM: adampowers22 StealthWatch by Lancope - Security through network intelligence --------------------------------------------------------------------------- ---------------------------------------------------------------------------
- Previous message: Peter_Schawacker_at_NAI.com: "RE: ssh and ids"
- In reply to: Martin Roesch: "Re: ssh and ids"
- Next in thread: Martin Roesch: "Re: ssh and ids"
- Reply: Martin Roesch: "Re: ssh and ids"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
