Intrusion detection systems (IDSes) and intrusion prevention systems (IPSes), as the name suggests, are network components that monitor network traffic for malicious activities, or either just detect and alert the user of the malicious traffic in case of IDS, or proactively block them in case of IPS. Similar to firewalls, IDSes and IPSes have gone through various phases, starting from basic packet-based IDS/IPS, which used to look at anomalies at layer 3/layer 4 protocol level and analyze payloads on a per packet basis.

Similar to firewalls, IDSes/IPSes have evolved from layer 2/layer 3 packet-based engines to stateful firewalls at the layer 4 TCP layer, to application engines identifying layer 7 protocols, and then to monitoring applications running on top of layer 7 protocols, such as Facebook. IDSes/IPSes are largely signature driven, although new modules and components have introduced anomaly and machine learning driven big data analysis to detect malicious activities.

We will discuss the basic difference between an IDS and an IPS and later on talk about internal architecture of IDS and IPS . .An IPS operates just like an IDS, except that it sits inline on the network and has the ability to block traffic. While the internal architecture of both remains the same, IDSes and IPSes differ only in the way they are deployed, and how they deal with the packets. An IPS is placed inline on the network; that is, the actual packets are sent through it, which are blocked if found to be malicious. An IDS can also be placed inline on the network, except that it will not block the packets, but just alert them. That’s one way to deploy an IDS. Deploying an IDS this way allows one way to turn it into an IPS, by switching a toggle either in the IDS that can turn it into an IPS, or by switching the format of the rules to not just alert but to drop the packets. An IDS  is usually deployed on a span port. This means a copy of the actual traffic is sent to the IDS:

The preceding diagram shows that an IPS is directly inserted (this is called inline) to intercept traffic, but an IDS only receives the copy of the actual traffic via the span port of a switch.

Snort is a famous open source IDS. Here is the link to the Snort website https://www.snort.org/.

The following diagram explains the internal architecture of IDS and IPS .

Internally, an IDS/IPS is split into several modules as described in the above image(IPS and IDS architecture):

• Receiver: Responsible for collecting the packets received on the network interface. Internally, the receiver uses various mechanisms to listen and collect packets, which can include afpacket, pfring, netmap, dpdk, and even custom drivers and modules.
• Decoder: It decodes the incoming individual packets at layer 2 and layer 3 level.
• TCP Stream Reassembler: TCP protocol works like a stream of bytes that are broken up into smaller-sized chunks and transferred over the network as individual packets. This module is responsible for taking individual TCP payloads in the packets and reassembling them into a stream of bytes.
• Application Layer Parser: The reassembled TCP stream, or the UDP packets, are then passed to the app layer to parse the app protocol and its metadata. An example of this is HTTP, SMTP, IMAP, SMB, and so on.
• Detection: The meta information gathered from the previous layers is run against signatures. Based on these signatures matching, the IDS/IPS can give out a verdict on whether a packet or flow contains malicious traffic or not. While an IDS would just give out an alert, an IPS would also block the packet, if found to be malicious.
• Signatures: In the previous bullet point, we spoke about the detection engine using signatures to match on the packet-related meta information. While signatures are largely pattern driven, there has been researching and push in recent years, where a lot of focus has been put into introducing newer techniques to detect the maliciousness of traffic using machine learning and other general heuristics. In this section, we will briefly discuss signatures written using the well-known snort/suricata IDS/IPS format and describe how it works against a network stream.

In the following, we showcase how suricata's signature engine leverages a rule to carry out inspection on content.

A suricata rule has a format like the following:

 action <protocol> <src_ip_range> <src_ip_port> <direction> <dst_ip_range> <dst_ip_port> (<other_keywords> sid:<signature id integer>;)

Some of the actions are log, alert, pass, and dro . There are other actions as follows:

• action: Defines what action needs to be taken when the IPS detects something suspicious in the traffic. Here are some actions:
  
  • alert: Generate an alert and then log the packet
  • pass: Allow the packet
  • drop: Discard the packet and then log it
  • log: Log the packet
• protocol: Defines the protocol to which the rule is applied.
• src_ip_range: Defines what should be the source IP of packets or who sent the packets.
• src_ip_port: Defines what should be the source port for the packets.
• dst_ip_range: Defines what should be the destination IP of packets or who receives the packets.
• dst_ip_port: Defines what should be the destination port for the packets.
• sid: This is the signature ID and you can use it to assign a unique number to your signature to identify it.

We will write a simple rule here which is used to identify HTTP traffic, regardless of the source and destination IP addresses and ports, and that has a request which has the string localhost among its HTTP headers:

The signature alerts if the content in HTTP protocol is localhost. The source and destination IP and ports can be anything and in any direction. Note that this just an example and not a strong rule.

The following is a pcap analysis of a request from a Necurs malspam script that is downloading a malicious EXE payload. Here is the reference to the payload http://www.malware-traffic-analysis.net/2017/11/09/index.html:

Here, we have a rule that matches the above HTTP request from the malware. The rule matches on the HTTP traffic, regardless of the source and destination IP addresses and ports, and has a URL kjgjhdg4:

alert http any any -> any any (content:"kjgjhdg4"; http_uri; sid:1;)

Although the above signature is not strong enough to be deployed, it showcases how one can write signatures to match the malware traffic.