Usage

Aoandon NIDS is the selective ignoring or alerting of data packets as they pass through its network interface. The criteria that it uses when inspecting packets are based on the Layer 3 (IPv4 and IPv6) and Layer 4 (TCP, UDP) headers. The most often used criteria are source and destination address, source and destination port, and protocol.

Rules specify the criteria that a packet must match and the resulting action, either pass or alert, that is taken when a match is found. Rules are evaluated in sequential order, first to last. Unless the packet matches a rule containing the quick keyword, the packet will be evaluated against all rules before the final action is taken. The last rule to match is the winner and will dictate what action to take on the packet. There is an implicit pass all at the beginning of a ruleset meaning that if a packet does not match any rule the resulting action will be pass.

Both static and dynamic ruleset can be applied to packets.

Static ruleset

Aoandon NIDS reads its configuration rules from config/rules.yml at boot time. In order to be able to load rules, this JSON/YAML file must have at least a rules key.

Rule syntax

The general syntax for static rules is:

action

context

options

Where action can use as a logger level such as INFO or ERROR that indicate alerts' importance. Note: the pass action will ignore the packet back to the kernel for further processing while any other action will react.

Every context params are evaluated for analysis to determine whether a given package matches.

The last part, options, can be:

log: specifies that the packet should be logged.

quick: if a packet matches a rule specifying quick, then that rule is considered the last matching rule and the specified action is taken.

msg: tells the alerting engine the message to print to an alert.

Default alert

The recommended practice when setting up a NIDS is to take a "default alert" approach. That is, to alert everything and then selectively allow certain traffic through the interface. This approach is recommended because it errs on the side of caution and also makes writing a ruleset easier.

To create a default alert sniffer policy, the first rules should be:

[ info, {}, {log: true, msg: "Suspected packet!"} ]

This will alert all traffic on the given interface in either direction from anywhere to anywhere.

The quick keyword

As indicated earlier, each packet is evaluated against the sniffer ruleset from top to bottom. By default, the packet is marked for passage, which can be changed by any rule, and could be changed back and forth several times before the end of the sniffer rules. The last matching rule wins. There is an exception to this: the quick option on a sniffing rule has the effect of canceling any further rule processing and causes the specified action to be taken. Let's look at a couple examples: