rules.sample

来自「入侵检测系统.linux下与MySql连用的例子」· SAMPLE 代码 · 共 488 行 · 第 1/2 页

##############################################################################
# NEW IN VERSION 1.2.1
# You can now specify the negation operator for source and dest IP addresses
# in a rule.  For example:

alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 143 (flags: S; msg: "External IMAP access attempt!";)

# This rule would generate alerts for all traffic that DOES NOT originate from
# the "local" network and is headed for the local net on port 143 with the SYN
# flag set.  This is a really nice capability to detect activity that
# originates outside of a given address range, or that is headed to a range
# you aren't interested in.  Thanks to Ron Snyder for this patch!


##############################################################################
# NEW IN VERSION 1.3
# The negation operator is now available for use in port specifications.  Check
# it out:

alert udp any !53 -> 192.168.1.0/24 31337 (msg: "Back Orifice";)

# This would alert on any UDP traffic going to port 31337 that doesn't 
# originate at port 53.

##############################################################################
# NEW KEYWORD: dsize
# This keyword checks the size of the packet payload (application layer) for 
# a match.  For example, if you were searching for packets where the length of
# the payload you were interested in was 80 bytes, you could write something
# like this:

alert tcp any any -> 192.168.1.0/24 any (msg:"80-byte packet!"; dsize: 80;)

# This can be useful in combination with other option keywords.  Additionally, 
# as of version 1.3.1 you can specify greater-than and less-than keywords.  
# For example:

alert tcp any any -> 192.168.1.0/24 any (msg:"80+ byte packet!"; dsize: >80;)

# This rule will alert on all packets with a size greater than 80 bytes

##############################################################################
# NEW KEYWORD: offset
# If you know what you're searching for in a packet payload a little more 
# specifically, you can specify the starting offset and narrow down the amount
# of data to search (and the amount of time required to do a search).

alert tcp any any -> 192.168.1.0/24 80 (content: "cgi-bin/phf"; offset: 4; msg:"PHF probe/attack!";)

# This rule will start the search for the string 4-bytes into the packet 
# payload.  Generally this is useful for this case since the expected
# string will look something like "GET /cgi-bin/phf...".  The only downside to
# this is that you have to be careful to avoid tuning your rules too tightly
# and allow for variations in how things may show up on the wire.  Be careful
# with this one!

##############################################################################
# NEW KEYWORD: depth
# This rule will instruct the content matcher to only examine <depth> bytes of
# the payload.  It is used to good effect with the offset rule, for example:

alert tcp any any -> 192.168.1.0/24 80 (content:"cgi-bin/phf"; offset: 4; depth: 12; msg: "PHF Probe/attack";)

# This rule will begin searching the payload for the content string 4 bytes
# into the payload and search the first 12 bytes.  You can save a lot of time
# (and boost performance) by specifying appropriate rules like this, but don't
# overdo it!  If you set your parameters too tightly, you won't detect
# anything!


#################
# NEW IN VERSION 1.5
#################

#################
# NEW CAPABILITY: include
#################
# You can now include other rules files with another rules file using the 
# "include" capability.  For instance, if you wanted to keep all of your 
# CGI probe rules in a separate file from your main rules file you can now
# simply integrate all of its rules into another file.  The format of the 
# command is simply "include <filename", where <filename> is the name of the
# rules file.

include web-lib

#################
# NEW CAPABILITY: var
#################
# With the addition of the "var" keyword, substitution variables can now be
# added to Snort rules files.  This is a capability that gives you great
# flexibility in setting up rules files!  The base format is simple:

var HOME_NET 192.168.1.0/24

# which is then referenced in rules like this:

alert tcp any any -> $HOME_NET 32771 (msg: "SUNRPC highport access!";)

# But wait, there's more!  You can define meta-variables using the "$"
# operator.  These can be used with the variable modifier operators, "?" and 
# "-". 

# $var - define meta variable 
# $(var) - replace with the contents of variable "var" 
# $(var:-default) - replace with the contents of the variable "var" or with
#                  "default" if "var" is undefined. 
# $(var:?message) - replace with the contents of variable "var" or print out
#                   the error message "message" and exit 

# For example:

var MY_NET $(MY_NET:-192.168.1.0/24) 

log tcp any any -> $(MY_NET:?MY_NET is undefined!) 23 (session: printable;)

#################
# NEW KEYWORD: session
#################
# This keyword will cause the payloads of the packets which match the rule
# to be logged to a session file.  There are two arguments for this keyword, 
# "printable" and "all".  The "printable" argument will cause only printable
# characters to be recorded.  The "all" argument will cause all printable and
# non-printable characters to be stored in the session file.  Non-printable
# characters are represented by "\XX" type values, where the XX is the 
# hexidecimal value of the non-printable character.  The names of the files 
# that the sessions are recorded in use the format "SESSION:<hi>-<lo>" where
# "<hi>" is the high port number of the connection, and "<lo>" is the low port
# number.

log tcp any any <> 192.168.1.0/24 23 (session: printable;)

# the above rule will record any telnet session's printable characters 
# bidirectionally in real-time.  If you want to see what the person is typing
# on the connection, simply "tail -f" the session file.  Pretty nifty, eh?

#################
# NEW KEYWORD: ipopts
#################
# Checks the IP options in packets that contain them for the specified type.  
# This is really great for looking for things like source routing.  Valid
# option arguments include: rr, eol, nop, ts, sec, lsrr, lsrre, satid, ssrr.

alert tcp any any -> any any (ipopts: lsrr; msg: "Source Routed packet!";)

#################
# NEW FEATURE: multiple "content" strings per rule
#################
# You can now put multiple content keywords in a single rule specification, 
# which enables searching for multiple patterns per packet payload.  This
# can be used to increase the graularity and accuracy of the packet payload
# matching rules.  For example, you can now search for a buffer overflow's
# NOP codes, as well as the "exec" opcodes:

alert tcp any any -> $HOME_NET 143 (content:"|9090 9090 9090 9090|"; content:"|E8 C0FF FFFF|"; msg:"IMAP Buffer Overflow!";)

# note that if "depth" and "offset" keywords that are included in instances
# where multiple content strings are being searched for, they must be grouped
# with their own content keyword.  In other words, if there are two content
# keywords in a rule and they both use depth and offset keywords, the first
# set of depth and offset keywords must be in the rule *after* the first 
# content string, but *before* the second one.  For example:

alert tcp any any -> $HOME_NET 143 (content:"|9090 9090 9090 9090|"; depth: 16; offset: 5; content:"|E8 C0FF FFFF|"; depth: 10; offset: 200; msg:"IMAP Buffer Overflow!";)

# It's just that easy. :)


#################
# NEW PREPROCESSOR: http_decode
#################

# http_decode "normalizes" web traffic, converting "escaped" characters back 
# to their ASCII representation.  For example, a %20 converts to a space, etc.
# Attackers and newer web scanners (like whisker.pl) attempt to hide their 
# attacks from ID systems by obfuscating their probes/attacks with these
# character substitutions, and this preprocessor defeats those attempts.

# The preprocessor takes the port numbers that it's going to analyze as
# arguments in the rules file.  In most cases, this will just be port 80,
# but some places will have web servers running on multiple ports like in 
# the example below

# The preprocessor internally checks for the IIS unicode and the CGI NULL
# byte attack. This can be disabled by providing "-unicode" or "-cginull"
# arguments to the preprocessor.

preprocessor http_decode: 80 443 8080


#################
# NEW PREPROCESSOR: minfrag
#################

# This preprocessor simply inspects fragmented traffic for "tiny fragments"
# which is usually a sign that something fishy is going on.  The only argument
# to this preprocessor is the threshold size of the fragments that an alert
# will be generated on.  The example size of 128 bytes (below) is probably a 
# pretty good size to stick with.

preprocessor minfrag: 128


##################
# NEW KEYWORD: tos
##################

#
# This keyword plugin intorduces `tos' keyword which checks against IP tos headers.
#

alert tcp $EXTERNAL any -> $INTERNAL any (tos: 201; msg: "Bubonic attack";)


#########################
# New in version 1.7
#########################

##########################
# NEW PREDEFINED VARIABLE: <interface_name>_ADDRESS
##########################
#
#  variable <intname>_ADDRESS will be intialised to IP address/mask of the network
#  which is configured on interface. Please note that snort has to be running on
#  this interface.
#

var MY_NET $eth0_ADDRESS

###############
# NEW SYNTAXIS: definition of multiple networks per variable
###############
#
#  you can define multiple networks in single variable (or use them directly in rules)
#

var MY_NET [10.1.1.0/24,10.1.2.0/24,192.168.1.0/24]

alert tcp $MY_NET any -> any any (msg: "TCP taffic from MY_NET";)
alert tcp [10.2.2.0/24,10.2.21/0/24] any -> any any (msg: "TCP traffic from some other network";)