In this demo,
we're going to write our first custom Snort rules to detect specific traffic.
Globomantics would like us to continue refining our Snort
environment by using custom rules to detect remote access
attempts destined for the internal network.
They gave us a few security goals to address.
The first security goal they gave us was to generate an
alert on any inbound SSH traffic.
They would also like us to block any Telnet attempts and reject any
remote desktop traffic from the external network.
Globomantics would also like us to classify this traffic and
assign a higher priority to any Telnet attempts.
Once we configure these rules,
we need to test each of them with the target traffic.
Let's head over to our Snort VM and get started.
Before we begin,
let's take a quick look at the configuration file to verify some of the
variables that we're going to use in these rules.
The variables we are going to use in our rules,
our HOME_NET and EXTERNAL_NET.. In my environment,
HOME_NET is configured as 10.0.0.0/24 and I left EXTERNAL_NET as any.
If you want to fall along with the same variables,
you'll need to configure your home net to your internal network as well.
Now that we know the variables we can use,
let's start writing some rules to detect this traffic.
I'm going to be using the local.rules file for all of our custom rules.
I have it located in this directory.
If you follow the install guide, you should find yours in the same place.
Now we're ready to add some custom rules.
Our first security goal was to generate an alert on all
inbound SSH attempts from the external network.
To accomplish that,
we're going to specify our source as the EXTERNAL_NET
variable and the source port as any.
The directional flow is into our HOME_NET, which is our
destination, and the destination port is 22 for SSH.
This information here forms the header of our rule.
Next,
we can specify additional options within the
parentheses to further refine this rule.
We'll start with the message option and provide a description. I'll
use Inbound SSH traffic detected. We separate our options with a
semicolon and move to the next option we need.
One of the other goals was to classify this traffic, for that, we'll use
class type, and in this case, use the suspicious login value.
We'll finish this using a sid of 1,000,001 and a revision
value of 1. For our next rule, we need to block and log
all inbound Telnet attempts.
For that,
we can use the drop action followed by a TCP Protocol
and the EXTERNAL_NET variable again.
We use any for the source port,
the same directional operator, and HOME_NET as our destination.
This time, we'll specify Port 23 for Telnet and our header is complete.
Next, we need a message.
We'll use a similar one,
but this time state that inbound Telnet traffic is detected.
We use the same class type, suspicious log in.
Finally,
we need to assign this rule a higher priority based on our
security goals so we'll use priority and enter a value of 1.
We'll set our sid to 1,000,002, and again,
a revision value of 1. For the last rule, we need to reject and log
all attempted RDP traffic from the external network.
For that, we'll use the reject action,
followed by the TCP protocol again and the EXTERNAL_NET variable.
We'll use any for the source port and the same direction
operator and HOME_NET will be our destination.
Our destination port for this rule is 3389.
Now we need a message. Again the same format, I'll
use inbound RDP traffic detected.
Our class type will be the same, suspicious‑login, our sid is
now 1,000,003 and the revision is 1 again. And I'll do a quick
walkthrough of the Snort command in case you want to replicate
it in your environment.
The ‑C is used to specify a configuration file.
In my case, that's snort.lua in this directory.
If you're using Snort version 2, this will be the path to
your snort.conf file instead. The next option ‑r specifies
the rules file local.rules.
After that,
there are two interfaces that I want to bridge together, ens38
and ens39, in my environment. You'll want to replace this with
whatever your interface IDs are.
Then I have the alert mode, I chose fast alerts,
and next is the afpacket setting,
which just changes the packet acquisition module
from the default pcap to afpacket.
This is the preferred module for the way I set up this environment.
The last option, ‑q tells Snort to bridge the interfaces and run in inline mode.
Once Snort starts, we're ready to test our rules.
Let's head over to the Kali Linux machine and try to SSH
into the Metasploitable VM. Alright, we've connected.
Now let's check back in with the Snort VM and see if
we generated alerts as we expected.
So our first rule appears to be working,
and it includes the message,
classification, and a priority of 2, which is assigned to this classification.
If you have AppID configured as I do,
you'll also notice that it's detecting the program we're using to connect
OpenSSH. Let's try a Telnet connection now to test our next rule.
You'll notice immediately that our Telnet session is not connecting to the VM,
so our rule might be working as expected.
Let's check back in with Snort and our Telnet rule
successfully dropped the attempted connections.
We have the same classification,
but our custom priority value took effect and it is now
one satisfying that security goal.
Let's test the last rule with a remote desktop attempt.
This session appears to be failing as well.
Let's check our Snort VM,
and there at the bottom is our RDP reset with the
same classification as expected.
So we've successfully configured these rules to detect the traffic
based on the security goals Globomantics gave us.
While these satisfied simple goals of blocking certain types of connections,
there will be many scenarios where blocking all traffic destined to
a particular port is not an acceptable solution.
We'll explore how to further refine our rules to trigger based on
more specific situations in the next module.
For now, let's do a quick recap of what we learned so far in this demo.
We started with setting up our Snort environment by configuring
the HOME_NET and EXTERNAL_NET variables allowing us to write rules
in our test lab that we can easily take to a production network
without making adjustments.
Next, we wrote three custom rules based on security goals Globomantics gave us.
Once we wrote the rules,
we tested them by sending the traffic they were written to
detect and proved that each of our rules alerted,
dropped, or reset the connection as intended.