[Snort-sigs] RE: Snort-sigs digest, Vol 1 #57 - 2 msgs

Nelson, James (CC-MIS Plans and Prog) James.Nelson at ...74...
Wed Aug 22 16:48:18 EDT 2001

Brian Caswell
The MITRE Corporation wrote: 

> This is for the .printer attempt.  Its just .printer in a url.  Looking
> for .printer can be bad... but its just recon.  If you  included a dsize
> (looking for an overflow) then you can say that is an admin attempt.

I fully agree that this is attempted recon without doing the validation.
There is nothing more negative to any detection and alerting system than
false alarms.  I fully believe that time a condition exists which could be a
false alarm, the baseline, the signature, or the alarming logic need to be
improved.  Once an IDS system is properly tuned, one should be able to send
the alert message to a security response team pager and take action on them
24/7/365.  Accurate attempted admin tells you who is actively trying to
break in.  I care about both recon and attempting admin, but I tend to care
a whole lot more about attempted admin at 4:00 am than recon.

The key to managing security 24/7/365 successfully doing to be extremely
careful about what you are looking for and the format in which the event is
reported once it is found.  I can't easily tell how hard it would be to
build a better rule that can be assigned to attempted admin instead of
attempted recon, but I do know that someone attempting recon against your
systems is a fact of life when you are connected to a network that you don't
control.  Monitoring who is attempting recon can give you  clues to who is
trying to find out things they are not supposed to know which they may
decide to use later.  

The next problem is that a smart hacker won't try either from their own
system and they won't try either from the same system.  

The thing I see most often in IDS is commercial vendors are too slow to get
rules out and freeware stuff like snort is generally hard to tune and report
on.  The model of commercial vendors for coverage and freeware IDS for
cutting-edge protection against things as they are released has proven to be
successful for some.  Improving the rules on Snort so the logging formats
are consistent and the IDS signatures don't have weak detection measures
causing recon classification of admin attempts will make Snort a better tool
because it will have the best of both worlds-- fast and reliable signatures
release as well as the hooks necessary for solid reporting capabilities.
Turning data in a database or a known format into a report is easy.  Getting
data into a known and useful format so it can be imported into a database or
reported on can be considerably harder.

There is my $0.02 worth.

James Nelson

More information about the Snort-sigs mailing list