Packet Characteristics
You can write rules that only generate events against packets with specific packet characteristics.
dsize
The
dsize
keyword tests the packet payload size. With it,
you can use the greater than and less than operators (<
and
>
) to specify a range of values. You can use the
following syntax to specify ranges:
>number_of_bytes
<number_of_bytes
number_of_bytes<>number_of_bytes
For example, to indicate a packet size greater than 400 bytes,
use
>400
as the
dtype
value. To indicate a packet size of less than 500
bytes, use
<500
. To specify that the rule trigger against any
packet between 400 and 500 bytes inclusive, use
400<>500
.
Caution | The
|
isdataat
The
isdataat
keyword instructs the rules engine to verify
that data resides at a specific location in the payload.
The following table lists the arguments you can use with the
isdataat
keyword.
Argument |
Type |
Description |
---|---|---|
Offset |
Required |
The specific location in the payload. For example, to test that
data appears at byte 50 in the packet payload, you would specify
You can also use an
existing |
Relative |
Optional |
Makes the location relative to the last successful content
match. If you specify a relative location, note that the counter starts at byte
0, so calculate the location by subtracting 1 from the number of bytes you want
to move forward from the last successful content match. For example, to specify
that the data must appear at the ninth byte after the last successful content
match, you would specify a relative offset of
|
Raw Data |
Optional |
Specifies that the data is located in the original packet payload before decoding or application layer normalization by any Firepower System preprocessor. You can use this argument with Relative if the previous content match was in the raw packet data. |
For example, in a rule searching for the content
foo
, if the value for
isdataat
is specified as the following:
-
Offset = !10
-
Relative = enabled
The system alerts if the rules engine does not detect 10 bytes
after
foo
before the payload ends.
sameip
The
sameip
keyword tests that a packet’s source and
destination IP addresses are the same. It does not take an argument.
fragoffset
The
fragoffset
keyword tests the offset of a fragmented
packet. This is useful because some exploits (such as WinNuke denial-of-service
attacks) use hand-generated packet fragments that have specific offsets.
For example, to test whether the offset of a fragmented packet
is 31337 bytes, specify
31337
as the
fragoffset
value.
You can use the following operators when specifying arguments
for the
fragoffset
keyword.
Operator |
Description |
---|---|
! |
not |
> |
greater than |
< |
less than |
Note that you cannot use the not (!
) operator in
combination with
<
or
>
.
cvs
The
cvs
keyword tests Concurrent Versions System (CVS)
traffic for malformed CVS entries. An attacker can use a malformed entry to
force a heap overflow and execute malicious code on the CVS server. This
keyword can be used to identify attacks against two known CVS vulnerabilities:
CVE-2004-0396 (CVS 1.11.x up to 1.11.15, and 1.12.x up to 1.12.7) and
CVS-2004-0414 (CVS 1.12.x through 1.12.8, and 1.11.x through 1.11.16). The
cvs
keyword checks for a well-formed entry, and
generates alerts when a malformed entry is detected.
Your rule should include the ports where CVS runs. In addition,
any ports where traffic may occur should be added to the list of ports for
stream reassembly in your TCP policies so state can be maintained for CVS
sessions. The TCP ports 2401 (pserver
) and 514
(rsh
) are included in the list of client ports where
stream reassembly occurs. However, note that if your server runs as an
xinetd
server (i.e., pserver), it can run on any TCP
port. Add any non-standard ports to the stream reassembly
Client Ports list.