From vulnerability and attack analysis to NIDS Rule Design

Created:
Article attributes: original
Article submitted: stardust (stardust_at_xfocus.org)

When talking about NIDS, this product is often criticized for a large number of false positives and false negatives. False positives with full screen scrolling make administrators feel numb and bored and lose interest in using it, if an error is reported, the Administrator may doubt the NIDS detection capability. It is clear that the host has been intruded into the NIDS log but no useful clues can be found. For NIDS, there are many causes of false positives and false positives, but the biggest reason is that the detection rules are not strictly defined.

For known network attacks, the current mainstream network intrusion detection and protection systems are mainly rule-based, because of specific attacks, in particular, packets based on specific attack codes can easily extract their packet features for matching. rules can be used to quickly and conveniently expand the detection capability.

The essence of network attacks is to use the design or implementation of the target system. From the perspective of the attacked process, the attack packets are either in the content structure or in the sequence of occurrence, or the attack packets must be malformed and cannot be correctly handled by the service program. Due to the limited length, this article does not discuss more complex attacks related to time series and statistics, but only considers relatively simple single request attacks. In order to successfully complete the attacks, the content and structure of packets under Network Attacks must meet certain necessary conditions. These packet characteristics are used to drive the Attack Process to trigger the vulnerability, we use feature set A to represent the set of necessary packet features.

Attackers can exploit security vulnerabilities by writing attack code, in addition to the features in feature set A, the packets sent by Specific Attack codes generally contain some special features of the attack code, for example, for specific shellcode and specific padding data, we use feature set B to indicate the packet Characteristics of Specific Attack codes.

The rule-based NIDS engine implements a basic detection framework. It provides various matching options and operators as application interfaces. You can combine options and operators to describe the network packet characteristics of interest, generates alarms for packets that meet the matching conditions. The rule Support Department of the NIDS vendor generally traces and analyzes new security vulnerabilities and attack code, extracts features, and compiles the NIDS rules used to detect the attacks, we use feature set C to indicate attack packet characteristics described by rules.

Obviously, the relationship between feature set A and feature set B is as follows:

+ ---------------- +
|
| + ------- + |
| <---- Feature set A: content or structure features required for packets to implement attacks
| |============> The matching feature is increased to reduce the number of packets meeting the condition
|
| + ------- + |
| <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

The feature set C described in the ideal attack detection rule should completely overlap with A. Because the features in feature set A describe the features of all attack code attack packets, therefore, it has nothing to do with the specific attack code, thus avoiding false positives. If we make A correct assumption about the protocol type of the detection object, because each feature in feature set A is necessary to cause an attack, it is indispensable, none of these features can trigger a vulnerability to complete the attack, so there is no possibility of a false positive. The figure is as follows:

+ ---------------- +
|
| + = + |
| "" <---- Feature set A: content required for packets to implement attacks
| "" | Or structural features
| "" <---- Feature set C: the characteristics of the packet content or structure described by the rule
| + = + |
| <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

In fact, due to the limitation of the Rule Description capability, in most cases, the rule cannot completely describe the features necessary for the attack packet content and structure to complete the attack. That is to say, feature set A does not completely overlap feature set C, but has various possible relationships:

If feature set C is A subset of A as shown in the following figure, the rule may cause false positives, but will not generate false negatives:

+ ---------------- +
|
| + ------- + |
| + --- + | <---- Feature set A: content or structure features required for packets to attack
| <------ Feature set C: the characteristics of the packet content or structure described by the rule
| + --- + |
| + ------- + |
| <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

If feature set C contains feature set A as shown in the following figure, the rule may cause false positives, but will not generate false positives:

+ ---------------- +
|
| + ------- + |
| + --- + | <---- Feature set C: the characteristics of the packet content or structure described by the rule
| <------ Feature set A: content or structure features required for packets to implement attacks
| + --- + |
| + ------- + |
| <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

If feature set C does not include A, but there is an intersection, the rule may both generate false positives and possibly cause false negatives:

+ ---------------- +
|
| + ------- + |
| <---- Feature set C: the characteristics of the packet content or structure described by the rule
| + --- + -- + |
| <------ Feature set A: content or structure features required for packets to implement attacks
| + --- + |
|
| + ------ + | <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

If feature set C and A do not mutually exclusive and do not overlap, then the rule itself is only detecting packets sent by specific attack code, but has nothing to do with the attack itself, by simply modifying the attack code, attackers can easily bypass the detection of such rules. If NIDS miss or report a false positive, the attack should be handled by the attacker:

+ ---------------- +
| + ------- + |
|
| <------- Feature set C: Characteristics of the packet content or structure described by the rule
| + ------- + |
| + ------ + |
| <------ Feature set A: content or structure features required for packets to implement attacks
|
| + ------ + | <---- Feature set B: attack packets sent by specific attack Codes
+ ---------------- +

So how can we make the feature set C and A overlap as much as possible? This mainly depends on two aspects: 1. Thoroughly analyzing the causes and utilization conditions of vulnerabilities, aiming to generate an accurate feature set A; 2. Improving the NIDS rule description capability, the features described by it.