NIDPS ⚔️
A Network Intrusion Detection and Prevention System (IDPS) represents the intersection between intrusion detection and intrusion prevention. It monitors and analyzes network traffic for suspicious or abnormal activity. Identifying a potential threat is based on a combination of deep learning and predefined rules.
Sometimes, this might involve sending an alert to a network administrator. The IDPS might block traffic from the source address or even engage other cybersecurity solutions to mitigate a potential attack. Some IDPS solutions can even neuter attacks by removing malicious software or code.
The general block level of any NIDPS solution has a total of six different modules:
- Packet Capturing Module → It is the first building block in any NIDPS solution which is used for packet acquisition from the network. The module can be used in two configurations: inline mode for NIDPS or passive mode (port mirroring based) for NIDS (no support for prevention). In passive mode (NIDS) packets could be temporarily stored in buffers while awaiting processing but in the inline mode, packets have to be processed in real-time which limits the performance of NIDPS.
- Packet Decoder Module → Packet Capturing module is then fol- lowed by Packet Decoder which applies protocol-specific rules to decode contents and further establish packets conformance with standards. As an example for packet sizes different than the predefined standards, this module would drop such malicious packets while generating an alert.
- Preprocessor Module → This module provides support for both low-level and high-level protocols-based packet preprocessing. At the lower level packets are processed for defragmentation, re- assembly, and session conformance; while, the high-level plugins validate packets with respect to the various application protocols (HTTP, FTP, etc.).
- Detection Engine Module → The Detection Engine is the most important part of any NIDPS solution where rules are applied to compare incoming packets to identified malicious patterns. There are three types of detection engines: signature-based (misuse detection), which uses a static rule set to identify malicious flows, anomaly-based, which aims to identify deviations from normal behavior, and hybrid systems based on a combination of the previous.
- Alerting Module → The detection engine is followed by Alerting module that generates an alert when a rule matches with the content of a packet. This is the module that logs all the alerts to a specific folder. In the case of IDS, this module only generates an alert whereas in the IPS mode it actively blocks the malicious packets after generating alerts.
- Output Module → It is the last module in the building block of the NIDPS solution. The output module generates statistics regarding the packets traversing the NIDPS solution. For the open-source solutions, the output module is normally based on Command Line Interface.
Every module in the pipeline is dependent on the performance of the prior module
Now that we know what NIDPS is, we can talk about open source NIDPS solutions. We will talk about the three most well-known ones: Suricata, Snort and Zeek.
These open source products are widely used to protect networks and support both IDS and IPS modes (except Zeek, which only supports IDS mode).
As a result of some performance evaluation studies: It turned out that Suricata outperforms Snort and Zeek solutions in both IDS and IPS modes. Let’s examine it in detail…
SNORT
Snort is one of the most widely used signature-based IDPS solutions which support both IDS and IPS mode. It can monitor traffic in the network, compare the received packets against signatures, log attacks, and is also able to present attack statistics on the console if the rules are matched.
Snort only uses misuse detection and does not support anomaly-based detection by default. In IDS mode, it only generates alerts based on detection; while, it blocks the malicious packets in IPS mode. The last component is the output block which simply generates a text file for the user to view later. Snort lacks Graphical User Interface, but it can be overcome by using open-source visualization tools such as Snorby and Base.
Snort uses Libpcap as default for the packet capturing stage, which is then followed by the decoder to decode packets.
SURICATA
Suricata is a very strong alternative NIDPS. Suricata supports multiple detection engines due to multi-threading; thereby, it can handle more network traffic in comparison with Snort which only supports a single detection engine. In terms of signature- based detection, Suricata uses the same format as employed by Snort for rules declaration and also has similar detection algorithms. Similar to Snort, Suricata also supports both the IDS and IPS modes; while, at the output stage the alerts can be stored either in a simple text file or can be stored in JSON format.
ZEEK
Zeek is another open source NIDS tool that only supports IDS mode. In the Zeek framework, agents called workers are deployed on network devices and these workers send their logs to the administrator. Zeek manager basically has two components; The event engine (or kernel) reduces the incoming packet stream into a series of higher-level events. These events reflect network activity in a policy-independent manner; That is, it explains what is seen, but not why or whether it is important.
It is derived from Zeek’s second major component, the script interpreter, which runs a set of event handlers written in Zeek’s proprietary scripting language. These scripts can express a site’s security policy, such as what actions to take when the monitor detects different types of activity.
Theoretically, we can explain the solutions this way. But you will agree that in practice this does not happen the same way. For this reason, I would like to talk about the practical demonstrations of all 3 solutions.
For now, I leave the Snort and Try Hack Me solution link. Here you can also see what the Yara rule is.
Stay tuned for more details (possibly an annotated cheat sheet).
Enjoy your work ✌︎ ……….
