rules.sample

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

##############################################################################
# PLEASE REFER TO http://www.snort.org/snort_rules.html FOR THE
# OFFICIAL SNORT RULES WRITING DOCUMENT, THIS DOCUMENT IS NOW DEPRECATED!
#
# As of version 0.99rc6, there are completely new rule options, your old rules
# will no longer work with this new version
#
# A RULE MUST ONLY BE ON A SINGLE LINE, THE PARSER WILL NOT WORK ON MULTI-
# LINE RULES!
#
# You can use "#" for comments
#
# USE NUMBERS FOR ALL IP ADDRESSES AND PORTS, THIS SYSTEM DOESN'T DO
# LOOKUPS 
#
# The format of a rule is:
# func proto src_ip/mask src_port_range -> dst_ip/mask dst_port_range (options)
#
# Use "any" for an IP address wildcard or port wildcard.  
#
# As of version 1.2.1, you may use a "!" on the source or dest IP addresses to
# indicate an exception case.  This will allow logging by exception for IP 
# addresses and networks without having to use Pass rules.  See the end of this
# file for usage examples!
#
# As of version 1.3 you can use the negation operator (!) on source and dest 
# TCP/UDP ports.  This will allow you to do things like avoiding looking at
# traffic coming from your DNS server, etc.
#
# Bidirectional rules were added in version 1.3.1.  These allow a rule's 
# address/port pairs to be considered from either "side" of the direction
# indicator in the rule with a "<>" operator between the source and
# destination information.
#
# As of version 1.5 you can specify include files and substitution variables
# in Snort rules files.  See the 1.5 modifications section for more 
# information on this cool new functionality from Christian Lademann.
#
# The rules are applied to traffic in the following order:
# Alert Rules
# Pass Rules
# Log Rules
#
# The new rule options are enclosed in parenthesis and seperated by semi colons
#
# Valid rule options are:
#   msg => message to output in the alert/log files
#   flags => TCP flags, use 0 for no flags at all
#   ttl => the TTL value you want to key on (nice for catching traceroutes)
#   content => the packet application layer, look for buffer overflows here
#   itype => the NUMBER of the ICMP type 
#   icode => the NUMBER of the ICMP code
#   minfrag => minimum fragment payload size
#   seq => tcp sequence number
#   ack => tcp ack number
#   id => IP header fragment ID number
#   logto => file to log specific alerts to
#   dsize => match on the packet payload size
#   offset => start a content search <offset> bytes into the payload
#   depth => only search <depth> bytes into the payload for a pattern match
#   session => record the session traffic from clear text protocols like
#              ftp or telnet
#   ipopts => check for a specific IP option
##############################################################################
#
# Here are some examples:
#

##############################################################################
# This rule logs telnet traffic from any computer on any network to a specific 
# IP address on your (notional) network

log tcp any any -> 192.168.1.1/32 23



##############################################################################
# To log the data in both directions, you need to use the "bidirectional 
# operator":

log tcp any any <> 192.168.1.1/32 23

# Note the new (as of version 1.3) bidirectional rule operator "<>".  This 
# tells Snort to apply the rule in both "directions", trying the source
# address as the destination address and vice versa when it attempts a rule
# match if the initial straight match doesn't work



##############################################################################
# This one logs all ICMP traffic to your local class C address.  Notice
# the port wildcards, even ICMP traffic needs to have something entered for 
# ports so the rules parser doesn't get confused.

log icmp any any -> 192.168.1.0/24 any

##############################################################################
# this rule will pass all outgoing web browsing done by your site 
# bidirectionally.  

pass tcp any 80 <> 192.168.1.0/24 any

##############################################################################
# This example shows what an alert rule looks like, with a "rule option" added
# at the end of the rule:

alert tcp 192.168.1.0/24 any -> any 111 (msg:"Portmapper call";)

##############################################################################
# We will now take a look at how port ranges are specified
# This one logs all TCP traffic from anywhere to the local class C coming from
# and going to ports below 1024 (inclusive)

log tcp any :1024 -> 192.168.1.0/24 :1024

##############################################################################
# This one monitors a port range (X Windows) from any computer to your class C

log tcp any 6000:6010 -> 192.168.1.0/24 6000:6010

##############################################################################
# This one passes traffic to/from ports greater than 1024

pass udp any 1024: -> 192.168.1.0/24 1024:

##############################################################################
# These next rules get into the options section of the rules
# TCP flags can be searched on 
# Flag values are as follows: 
#             S = SYN
#             F = FIN
#             A = ACK
#             U = URG
#             P = PSH
#             R = RST
#             0 = NULL
#             1 = Reserved bit 1
#             2 = Reserved bit 2

# This rule will find SYN FIN scans

alert tcp any any -> 192.168.1.0/24 any (msg:"SYN-FIN scan!"; flags: SF;)

# This one will find TCP NULL scans

alert tcp any any -> 192.168.1.0/24 any (msg:"Null scan!"; flags: 0;)

# This one will find Queso OS fingerprinting attempts
# You can watch the reserved bits in the flag field of TCP packets.  This 
# allows you to detect things like Queso scans.  The new bits are specified
# with a "1" and "2".  See the TCP example above for usage.

alert tcp any any -> 192.168.1.0/24 any (msg:"Queso fingerprint";flags: S12;)

##############################################################################
# Here is an example of content based alerting

alert tcp any any -> 192.168.1.0/24 143 (msg:"IMAP Buffer overflow!"; content:"|90E8 C0FF FFFF|/bin/sh";)

# The content string will be matched against data contained in the packet 
# payload.  This string can be either binary or text, with the binary section 
# denoted by the pipe "|" symbol.  The actual "binary" code is written using 
# hex notation.  If you want to put a pipe symbol into the content match string,
# just use "\|" and that will put a single "|" into the pattern buffer.

##############################################################################
# here's an example of PHF attack detection where just a straight text string
# is searched for in the app layer

alert tcp any any -> 192.168.1.0/24 80 (msg:"PHF attempt"; content:"/cgi-bin/phf";)

##############################################################################
# here's an example of straight binary code (of an external mountd access 
# attempt) in the application layer

alert tcp any any -> 192.168.1.0/24 111 (msg:"External mountd access"; content:"|00 01 86 A5|";)

##############################################################################
# here's an example of how to detect a traceroute using 99rc6's new ttl 
# option capability

alert udp any any -> 192.168.1.0/24 any (msg:"Traceroute"; ttl:1;)

##############################################################################
# here's an example of using the new itype and icode detection capability
# this one will detect pings coming to your network from the outside 
# (presumably)

alert icmp any any -> 10.1.1.0/24 any (msg:"Being Pinged"; itype: 8;) 

# this next one will detect ICMP host unreachables, which may be of interest in
# certain situations

alert icmp any any -> any any (msg:"Port Unreachable"; itype: 3; icode: 1;)


##############################################################################
# NEW IN VERSION 1.1
#
# New rule option: logto
# This option allows packets matching the rule to be logged to a special user
# specified log file.  For example:

log tcp any any -> 192.168.1.0/24 23 (logto:"telnets";)

# would capture all inbound telnet traffic and put it in a file called telnets 
# in the log directory

##############################################################################
# New rule option: ack
# This option watches the ack field of TCP packets for the user specified 
# value.  For example, nmap TCP "pings" have the TCP ACK flag set and the
# acknowledge field set to 0.  A Snort rule can now be written to detect this:

alert tcp any any -> 192.168.1.0/24 any (flags: A; ack: 0; msg:"NMAP TCP ping!";)

##############################################################################
# New rule option: seq
# This one checks the sequence number of a TCP packet.  So far I don't have an
# application for this rule thought up, but it's in there for the sake of 
# completeness.  

##############################################################################
# New rule option: id
# This rule looks at the ID field of the IP header.  Some attack/probe programs
# set this value to something cute or, at least, "fingerprintable" value such
# as 31337 or 262 or whatever.  This option field can be used to search out 
# packets using predictable numbers.

##############################################################################
# Synthesis
# Putting all these rules together to form a neat-o complete-o package can be
# fun for the whole family.  For example, check this out:

alert tcp any any -> 192.168.1.0/24 any (flags: A; ack: 0; msg:"NMAP TCP ping!"; logto:"nmap_probes";)

alert tcp any any -> 192.168.1.0/24 any (msg:"Probable NMAP fingerprint attempt";flags: SFPU; logto:"nmap_probes";)

# These two rules would both log their output to an nmap_probes file in the log
# directory, allowing centralized collection of all detected nmap activity.
# Other rule option types can be linked together like this to form specific
# traffic type logging, such as port scans, CGI scans, etc.

# Now you just need some imagination to figure out how you want to log things.