Re: What's the fuss about string matching ?

[Andreas Östling <andreaso () it su se>]

On Mon, 27 May 2002, Pawel Rogocz wrote:

> I have troubles seeing any use of string matching in IDS because of two
> factors:

Short answer: It really works.
Seriously, you are making a lot of assumptions here.


> 1. Lots of traffic is encrypted these days.

I would not agree on that one, unfortunately.

But even if the traffic is encrypted - does that make string matching IDS
completely useless? If your answer was "yes", you'd better think again.

- Watching for cleartext strings in protocols that should be encrypted can
  actually be an excellent way of finding anomalies.

- For many encrypted protocols, the most complex part (i.e. likely to
  contain bugs) is the initial connection/authentication phase where the
  encrypted channel is perhaps not yet completely established, and the
  exploit will be sent in cleartext.

- Even if the exploit itself is sent encrypted, it doesn't
  automatically mean the possible response is.

For example, many people said string matching on SSH traffic was
totally useless. Then the CRC compensation attacks showed up, where
most (all?) the exploits including their responses were sent in the clear
and easily detected by using simple string matching. (How often should you
normally see "uid=0(root)" going out from port 22/tcp from a host on your
network?)
I hardly think this was the last bug of this kind.


> 2. What's the point in watching for a known vulnerability, if you know
> your system is not vulnerable ? Do you want to be woken up at 3 a.m.
> because someone sent you a malformed packet ? Given the fact that all
> alerts in snort are based on known vulnerabiliies, you should patch your
> systems or take them off-line.

Not entirely true. Many of the Snort signatures are designed to be
more generic than just watching for the exact pattern of a publicy known
exploit. I of course agree that all systems should be patched though, but
we all know that's not the case, even though yours and mine hopefully are.
One big problem here is that many peoply watch very large networks where
they don't have control over every single host.

And even if you think your system is patched, you (or your updating
software) can always make misstakes. I've seen several skilled
system administrators' hosts being cracked even though they were
absolutely sure they had the latest security patches installed. And if
physical security of a host isn't good, someone may locally install
backdoors or remove security patches etc, and then go home and continue
his/her work. Point is that there are endless reasons to watch for
suspicious traffic from/to a patched system. (This is of course not
limited to string matching.)

It's also quite useful to get an idea of what attackers are trying to do
with your hosts, even though you are not vulnerable.


> Generally string matching is waste of CPU cycles, better used somewhere
> else. How about detecting (D)DOS ?

I think you're making one big misstake here.
Why use only ONE intrusion detection method?
Just because we love Snort (or other string matching capable proggies)
doesn't mean we think it's the right tool or method for everything.
DDoS bots can sometimes be found by string matching and also by bandwidth
monitoring, so why not use both?

The most important point here is that string matching is just a part of
the whole picture. Sometimes it's extremely useful and sometimes it's not.


> It would be more effective for an IDS to alert when a succesful intrusion
> was detected, but in many environments this can easily be done
> with a sniffer like tcpdump.

Sure, but on large and fast networks it's nice to get a little extra help.


Regards,
Andreas Östling


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users