![](bg2.png)
We aim to (i) benchmark (M. Ranum, 2001) the
organisation’s network to achieve a better
understanding of the networking traffic experienced
by the Snort sensor; (ii) propose and test (N. Puketza
et al., 1996) a new reduction method and verify their
effectiveness in reducing the false alerts to
acceptable manageable levels.
3 A NEW FALSE ALERT
REDUCTION METHOD
Common practice has to be adopted in order to
effectively navigate through the initial list of
generated alerts. This would prove useful in dealing
with the many new and sometimes highly numerous
alerts which would be encountered later.
We propose the following common, basic practices:
1. Verify the source IP address and subnet
from which the packet has originated from.
In some cases, the source port is also
observed and verified, making sure traffic
of this type is permitted through the given
port on the source host.
2. Apply the same procedure as above to the
destination section of the packet, making
sure traffic of this type is permitted to a
particular destination on a given port.
3. Acknowledge the packet type and its place
in the networking environment.
4. Research the rule definition and what
networking conditions trigger the
particular alert.
5. Understand the rule and how the
subsequent alert definition is triggered by a
packet.
6. Provide an alert summary to justify why
the alert has been triggered.
7. Understand the alert severity.
8. Understand the amount of times the alert
was triggered.
By applying these steps to each rule and then
effectively to groups of likened alerts, it is possible
to systematically work through the ever growing list
of alerts, with the main goal in mind not to miss an
alert which may in fact report an actual happening of
malicious activity.
To conclude each alert, we have to decide whether
the trigger is a false positive or a false negative. As
the system had just been deployed it was expected
that many if not all alerts were false positives. By
analysing each source in depth, we are able to
provide evidence of rule triggering events, which are
unintentional and hence, do not exhibit malicious
intent.
From the alerts database, a common, manual
reduction method is used, which involves locating
the original Snort rule within the Snort rule set and
applying the necessary changes to it. The method
then re-deploys the edited rule back into the Snort
rule set and enabling it for processing.
For example, the following alert:
alert udp $EXTERNAL_NET any -> $HOME_NET
67 (content:"|01|"; offset:0; depth:1;
byte_test:1,>,6,2; classtype:misc-activity;)
can simply be changed to:
alert udp !192.168.1.32/32, 192.168.1.0/24 any ->
$HOME_NET 67 (content:"|01|"; offset:0; depth:1;
byte_test:1,>,6,2; classtype:misc-activity;)
Here, the original rule has been edited so that the
whole subnet of 192.168.1.0/24 is monitored with
exceptions to a single source IP address of
192.168.1.32 where the rule options do not apply.
This effectively bypasses 192.168.1.32 from
matching the rule options and prohibits the false
positives from being generated from this source.
This flexible rule syntax would then allow all rules
within the rule set to be edited this way, reducing the
total number of false positives without having to
terminate network services and resources. However,
in this method, manually searching through the large
Snort rule set to find the rule that requires editing is
extremely time consuming (Y Qiao et al., 2002).
In this paper, we propose a new reduction method,
which involves creating new rules without having to
locate and edit existing rules. These new rules,
called pass rules, are created in a separate rule set
which are then part of the larger Snort rule set. Snort
requires more configuration work in order to utilize
these new pass rules, as it would be pointless to
trigger on a packet and then pass it. Snort would
then be configured to execute the pass rule set first,
after which, would carry out all other rule
processing.
A NEW REDUCTION METHOD OF INTRUSION DETECTION FALSE ALERTS USING SNORT
47