In this clip,
we're going to cover the basic options you need to read a simple
Snort rule and begin detecting target traffic.
We will start with the essential parts of the basic rule and
then cover the rule actions and a few options to better
document details about your rule.
We'll close out this clip with an example of a basic
rule leveraging these options.
Let's start with the essential parts of a basic rule.
To create a basic rule that detects traffic based on IP address and ports,
you'll need five pieces of information.
The first thing you need is the source IP address,
or a variable corresponding to that traffic.
The variables are defined in snort.com, or, if you're using version 3 snort.lua.
For most of these rules in this course,
our source traffic will use the variable corresponding to
external networks or our home network.
Next, you will need the destination IP address or variable,
followed by the port and protocol of the matching traffic.
Once you define your target traffic,
you need the action you want to take and the direction of the traffic flow.
Using this information,
you can create a rule to match traffic based on its port and the
directional flow between the source and destination.
Once matched, you can take one of the next six actions.
The action we will most commonly use through this course is alert.
This action forms the backbone of using Snort as an intrusion detection
system and will alert you if suspicious traffic is detected.
This action will generate an alert and send it to the
console if traffic matches your rule, and it will log the packet.
Log will not generate an alert, and instead, just like the packet like it says.
This is more valuable when you don't want an alert to be
generated every time a rule is matched,
but instead want to be able to trace instances of any rule matches.
Pass ignores packets that match the rule.
It's opposites are drop, reject, and sdrop,
which are variations of blocking the matching packets.
Drop blocks and logs the packet.
Reject takes this a step further by blocking and logging the packet
and then sending a TCP reset for a TCP traffic or an ICMP port
unreachable packet or UDP or ICMP packets.
The last action, sdrop, only blocks the packet and does not log it.
Once you decide on an action for your rule and have the
other essential pieces of information,
there are three more options that we will add that serve
to identify your rule within Snort.
The sid value is used to provide a unique identifier for the rule.
Custom rules you create use values over one million per sid. The Revision,
or rev value, is used to document revisions of a rule.
Our initial value will be 1 and increase each time we make a change to the rule.
The message value is used to display a specific message within the alert and
packet dump generated when a packet matches your rule.
This is valuable for describing the type of traffic so that someone else
seeing your alert can quickly determine the potential impact.
There are four other general rule options that aren't necessary but
can be valuable to configure when creating an alert.
The first is Generator ID, or gid,
and it's used to identify the part of Snort that generates the event.
This value is optional and not recommended by Snort for custom
rules. If not designated, the value is 1.
The classtype is used to classify traffic within a more general attack type.
Default values, along with their description and priority,
are defined in the classification.config file.
You can overwrite these predefined priority values using the priority tag to
define a different integer specific to your organization.
The last of these optional values is metadata,
which can be used to embed additional rule information.
Let's look at two example rules, where we put a few of these options into place.
The first example rule is designed to alert on any
attempted telnet traffic which uses port 23.
The msg option,
is used to specify a message stating that the inbound teknet
traffic was detected. The classtype option classifies this as a
suspicious login. This rule was also assigned a sid of 1000001
and a revision value of 1.
The second example is written to detect any inbound ICMP traffic and uses
the classtype option to classify this as an ICMP event.
The sid is now 1000002, and the revision value is still 1.
Now that we have a basic understanding of how to write rules
with general options, ready for the next demo,
where we'll write a few custom rules based on security goals.