In this clip, we're going to discuss non‑payload detection rule options,
focusing on five of the available options to detect packet header
values or behavior The five options we'll cover in this course are
ttl, fragbits, dsize, flags, and flow.
Let's go over each of them quickly before we look at some examples.
The first option, ttl,
was originally designed to detect traceroute attempts by
focusing on the time‑to‑live value of each packet.
It can be set to alert based on TTL values or ranges between 0 and 255.
Traceroute works by sending UDP packets with
progressively increasing TTL values,
waiting for an ICMP time exceeded message to indicate the next hop.
Configuring TTL with a low range can be used to detect an alert on a
series of packets with slowly increasing time to live. The next
option, fragbits, can check the IP header to determine if
fragmentation or reserve bits are set.
IP fragmentation is one method of bypassing
intrusion detection systems like Snort,
and the capability is built into network scanning tools like Nmap
specifically for this purpose. We could use fragbits to alert on
this type of traffic so we can begin tracking it to detect scans
or fragmentation attacks.
Dsize is used for the opposite task of detecting abnormally large
packets. Attacks exploiting a program's inability to handle large
packets are also called buffer overflows.
The extra data sent in the packet can contain code,
which the vulnerable machine runs to trigger an exploit.
Large ICMP packets can also be used to attempt denial‑of‑service attacks.
Using dsize with a specific byte range can alert you to the
possibility of these types of attacks.
Flags are used to check for specific TCP flags.
This option can be used to detect unexpected TCP packets used in scans or
attacks that exploit machines that have difficulty handling them.
One example is a Christmas tree attack and the associated Nmap Xmas scan. These
set multiple TCP flags and send the packets to the system to either cause a
denial of service or cause the machine to report something back to Nmap that
indicates a port's state. Finally, flow is used in conjunction with a session
preprocessor in version 2 or the stream TCP module in version 3 to track the
state of a connection.
This allows you to write rules that track specific traffic flow
directions. Using flow, you can configure rules to apply to either
clients or servers within the same network,
allowing you to be more specific with the devices
you track within your home net.
We'll use a few of these in the next demo,
but before we start, let's look at an example rule using the flow option.
This example is a modification of the rawbytes content
rule we saw earlier to detect an attempted back door of
the vulnerable VSFTPD service.
The source network was changed at HOME_NET so we can detect
internal attempts to open the same back door.
We added the flow option to detect traffic with
content destined for the FTP server.
This rule will ignore traffic from the FTP server to any
client that would match our content rule,
since that would not indicate a back door attempt.