If there were easy answers to this question, NIDS/HIDS would already
have taken them into account. However, generally, in my experience, the
most common false positives are things that are not ever really
"attacks" in the first place. For example, DNS Zone transfers can be
seen as recon, so we alert on them by default, probably giving you some
false alarms from legitimate transfers. But, once you enter the IP
addresses of the servers on your network that are allowed to do DNS Zone
transfers, these go away. Another example of a common false alarm, that
most IDS's have already accounted for, are snmpwalks. Commonly, when
you first install a Network IDS, snmpwalks may trigger from your network
management servers, which commonly contact large amounts of hosts in a
small period of time using a variety of snmp names and methods. So,
once you tell the IDS to ignore those IPs (for snmpwalk alerts), that
one goes away. This list goes on and on and on and on and... get it?

Matt brings up the point of alerts to things that didn't have any
affect. This is also something that only the person tuning the NID can
accomplish. For example, if your getting NIMDA all day long, you
probably don't want to see it anymore, because you're patched. So, you
can choose to turn off NIMDA alerts, and only alert on successful NIMDA
(using a stateful IDS). Or you can choose to ignore NIMDA scans coming
inbound, and only watch them going outbound. Or, you can choose (with a
statefu IDS), to only alert on NIMDA scans against IIS servers (useful
if you have no IIS servers at all). In either case, you've probably
solved 90% of the alerts you'll see on an external facing NID.
Internally, you're more likely to see network management systems as the
most common false positive.

Also, depending on what IDS system you're using, you will probably be
susceptible to different kinds of false alerts. For example, when SNOT
was first introduced, it wreaked havoc on non-stateful IDS's. Stateful
IDS systems didn't have as much of a problem, because we could see that
it was just garbage on the wire. On the other hand, stateful IDS
systems may fall prey to stateful evasion techniques, such as ttl
insertion, to try to create a false negative. As always, there are
trade-offs. Most of these trade-offs can be balanced during
implementation.

False alarms will always exist on any good IDS when you first install
it. If you don't get some false alerts when you first install an IDS on
a busy network, then your IDS _probably_ isn't working. An attack on
one network, might be a tool an another. It's simply a matter of using
the mechanisms provided by the vendor to tune those alarms out. If
you're not sure of the best way to tune out false positives during your
initial installation, you should contact your vendor. I'm sure they'd
be happy to help. If you're using NFR, feel free to contact me
directly, and I'll help in whatever ways I can, or forward you to the
appropriate people.

-dave

"Matthew L. McGuirl" wrote:
>
> The answer to that question will vary from network to network. An attack aimed at a target (OS, service or application) that is not present on your network is, for most people, largely meaningless.
>
> Matt
>
> Matt McGuirl
> Software Support Engineer
> Lucid Security Corporation
> Email: mmcguirllucidsecurity.com
> AIM: MattAtLucid
> Voice: 215-371-3300 ext. 371
> Fax: 215-371-1753
>
> -----Original Message-----
> From: xzan [mailto:xzansei.xjtu.edu.cn]
> Sent: Thursday, September 19, 2002 4:53 AM
> To: focus-idssecurityfocus.com; focus-idssecurityfocus.com
> Subject: which attacks will generate false positive or false negative?
>
> hello , everyone
> I think all of us know that false alarms is one of main problems of current IDSs.
> but Who can tell us which types or some attacks will generate false positive or false
> negative ? and why they will do it? I think it's very important and primary for reducing
> false alarm rate.I hope everyone will give me a detail answer.
>
>
> 　　
>
> 　　　　　　　
>
> 　　　　　　　　　　　　　　xzan
> 　　　　　　　　　　　　　　xzansei.xjtu.edu.cn
> 　　　　　　　　　　　　　　　　　2002-09-19
>
> ------------------------------------------------------------------------
> Name: smime.p7s
> smime.p7s Type: PKCS7 Signature (application/x-pkcs7-signature)
> Encoding: base64

-- 
David W. Goodrum
Senior Systems Engineer
NFR Security
Mobile: 703.731.3765
Office: 240.747.3425

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]