How To Create Intrusion Detection System

Build your own Intrusion Detection System

Intrusion detection systems monitor network traffic in hopes of identifying malicious activity. Often times pre-built solutions are deployed such as Zeek (formerly Bro), Suricata, or Snort — but, how can we build our own?

📸Credit for the photo goes to **Jakob Owens**

Processing Packets with PacketGen

One of the best packet analysis libraries out there is PacketGen. It offers simple — but powerful — ways to generate, send and capture network packets. With a wide variety of supported protocols it provides a wonderful base to build our engine upon.

Since it's written in R u by, a language that makes it easy to craft domain specific languages, we can slap on some syntactic sugar to wrap PacketGen's functionality into a flexible IDS — in less than 25 lines-of-code. Seriously.

⚙️ Engine DSL

The following is all of the required code for our IDS engine (don't feel the need to read it all unless you really want to):

💁‍♀️ Quick explanation of what's going on:

require "packetgen" loads the PacketGen library to use.
class IDS contains our intrusion detection engine.
def initialize is called when we create a .new instance of an IDS object allowing us to do all the required setup necessary, which is basically just loading the rules for our engine and applying them to a live packet capture.
def rule actually registers a new rule in the engine (which will be placed in a key-value pair).
&block is used as an argument to these functions which allows for do...end blocks — also known as closures — to be passed as arguments and evaluated by our engine. This becomes a bit more clear later on when you see how it is used. So, keep an eye out for those do...end blocks in a minute in the example code snippets.

Frankly, if you're not all that familiar with Ruby, the &block stuff might seem a little intimidating — but, as an operator using this library to develop rules you might not need to intimately understand everything in the engine to write rules for it.

In fact, the engine could abstracted away (hidden) from an operator and presented as a command-line application that reads configuration files with a few more lines of code.

For this blog post, we'll just keep it really bare-boned.

✍️ Writing Rules

Now, let's try writing some rules. Without rules/signatures to match against, a signature-based IDS wouldn't do you any good. First we'll manually convert the following snort rule to our engine's syntax as a starting point:

                      alert tcp any any -> any any (content: "cgi-bin/phf"; flags: PA; msg: "CGI-PHF probe";)

The main features of the rule are that it checks both the PSH and ACK TCP flags are set and that packet's payload must contain the string "cgi-bin/phf" .

When converted, it ends up being very readable:

                      rule            'TCP'            do            |packet|
            next unless            packet.tcp.flag_psh?            and            packet.tcp.flag_ack?
            next unless            packet.body.contains?            "cgi-bin/phf"            
            puts            "CGI-PHF probe"            
            end

Perhaps we want to know whenever there's any communication going to Google's DNS server 8.8.8.8:

                      rule            'IP'            do            |packet|
            next unless            packet.ip.dst ==            "            8.8.8.8"            
            puts            "Talking to Google's DNS server"            
            end

We could narrow it down to simply DNS communication:

                      rule            'DNS'            do            |packet|
            next unless            packet.ip.dst ==            "            8.8.8.8"            
            puts            "Talking to Google's DNS server using DNS"            
            end

Or, similarly, just ICMP communication:

                      rule            'ICMP'            do            |packet|
            next unless            packet.ip.dst ==            "            8.8.8.8"            
            puts            "Talking to Google's DNS server using ICMP"            
            end

If we wanted to catch FTP root login attempts (case sensitive match):

                      rule            'TCP'            do            |packet|
            next unless            packet.tcp.dport ==            21            
            next unless            packet.body.include?("USER root")
            puts            "FTP root login attempt"            
            end

The examples could go on-and-on from here. But I think that gives you a pretty good idea of what is possible using this engine.

You can essentially create any rule you can imagine. Moreover, you could run any valid Ruby code which gives you the ability to do centralized logging, e-mail alerting, slack notifications — again, pretty much anything you can imagine.

Conclusion

There are advantages and disadvantages to writing your own solution to a problem. While I don't expect any organization to deploy this exact code in production, I really do love the simplicity of it, especially as a starting point for others interested in this topic.

Until next time, that's all folks!