In this demo,
we're going to leverage non‑payload detection rule options
to generate alerts on suspicious traffic.
These traffic types may indicate potential network reconnaissance attempts,
IDS evasion techniques or possible Denial of Service attempts.
You will need to address the following security goals.
Globomantics would like an alert generated on traceroute attempts.
They would also like you to drop any ICMP packets over 1 KB in size and
generate an alert on any attempted Xmas scan using Nmap.
As usual, you'll need to test your rules using the targeted traffic.
This demo will cover the rule‑writing portion, and we'll
test each of the rules in the next demo.
Let's head over to our Snort VM and get started writing some rules. For
this scenario, we're going to write four different rules,
each one addressing one of our security goals.
To ensure our false positives are minimized,
we're going to need to use the non‑payload detection
options, TTL, dsize, and flags.
Our first security goal is to detect possible traceroute attempts.
Traceroute from a Linux or Unix‑based machine sends UDP packets
incrementing the TTL value by 1 with each packet.
These are designed to be routed to the destination, but fail along
the path due to the TTL value, and cause each device in the path to
send an ICMP time exceeded message, which will identify the device
to the traceroute program.
Windows machines follow the same process, but use ICMP packets instead of UDP.
This is a great troubleshooting tool, but also a method for
conducting network reconnaissance and identifying devices on
the path to our internal network.
Globomantics would like us to be alerted to this type of activity to
track it as it relates to possible further network reconnaissance
attempts. We can use two rules that leverage the TTL option to
accomplish this. We'll start with the UDP rule.
For this,
we will use an alert action, followed by udp for the protocol and the
EXTERNAL_NET any as a source. Our HOME_NET any will act as the
destination. For a message, we will use Traceroute detected. Now we need
the TTL value. Values less than 3 will be sufficient to generate an alert
for this type of traffic, and will rarely alert on legitimate traffic
destined for our internal devices.
We'll use a classtype of network‑scan,
a sid of 1000005, and a revision value of 1.
Our Windows rule is going to follow the same general format,
but we'll use ICMP as the protocol instead of UDP due to the
difference between the way the Linux traceroute program and the
Windows tracert programs accomplish this task. We use the same
message, ttl value, and classtype.
Our sid for this rule would be 1000006, and a revision value of 1 again.
Alright, now that we have our traceroute detection rules in place,
our next security goal is to detect large ICMP packets.
The typical ICMP ping size from a Windows host is 32 bytes,
and a Linux host sends 56 bytes of data. With a simple command line switch,
pings can be sent up to a maximum of 65535 bytes. Since this could be used by
numerous devices to attempt a Denial of Service attack,
Globomantics would like us to drop any ICMP packets at 1KB, which is equal
to 1,024 bytes, or larger up to the maximum size. We can use the dsize
option to construct a rule that accomplishes this. For this rule, we'll
use drop as our action, icmp as the protocol, and EXTERNAL_NET any as the
source. Our destination will again be HOME_NET any. I will set the message
for this rule to be Large ICMP packets detected, possible Denial of
Service.
Next,
we'll use dsize and configure it to detect packets
with 1023 bytes as the minimum,
one less than the 1 KB goal, and a maximum set to the
largest ICMP packet size 65535.
We'll use a classtype of attempted‑dos,
a sid of 1000007, and a revision value of 1 again.
Our last security goal is to generate an alert on Nmap Xmas scans. The Nmap
Xmas scan sends packets with the FIN, PUSH, and URG bits set.
This is used by Nmap to determine port states based on the response
or lack of response from a machine to the packet.
More important for us,
this is a scan method that can be used to evade
inbound packet filtering firewall rules.
To detect these scans,
we can use the flags option and configure it to alert if these three
bits are set. For this rule, we'll use the alert action, tcp as the
protocol, and EXTERNAL_NET any as the source.
Our destination will be HOME_NET any again.
The message for this one will be Nmap Xmas scan detected. To
configure the flags option, we'll enter flags followed by the
specific flags we want to detect, in this case,
F,P, and U, corresponding to the FIN, PUSH, and URG bits.
We'll assign a classtype of network‑scan, a sid of 1000008, and
a revision value of 1. Alright, now we have a rule set
addressing each of the security goals.
It's time to test each of them and see if we generate alerts.
We'll conduct the tests in the next demo.