Traffic Classification Rules

本文介绍了网络流量分类规则,其可根据流量分类类型分配VLAN成员和服务等级。分类类型源于OSI模型的2、3、4层,规则用于提供流量控制、过滤、安全和优先级等功能。还阐述了规则的组成、优先级规则及相关示例。

Traffic Classification Rules


Traffic Classification rules allow you to assign VLAN membership and/or class of service to your network traffic based on the traffic's classification type. Classification types are derived from Layers 2, 3, and 4 of the OSI model, and all network traffic can be classified according to specific layer 2/3/4 information contained in each frame. In Policy Manager, rules are used to provide four key policy features: traffic containment, traffic filtering, traffic security, and traffic prioritization. Examples of how to design rules for each of these features are given below.

A Traffic Classification rule has two main parts: Traffic Description and Actions. The Traffic Description identifies the traffic classification type for the rule. The Actions specify whether traffic matching that classification type will be assigned VLAN membership, class of service, or both. When a frame arrives on a port, the switch checks to see if the frame's classification type matches the type specified in a rule. If it does, then the actions defined in that rule will apply to the frame. Use the Policy Manager's Rule Wizard to quickly and easily create a rule and define its traffic description and actions.

In Policy Manager, rules are created and then grouped together into Services, which are then used to define roles. A role is assigned to each port either through end user authentication or as the port's default role. This means that there can be multiple rules active on a port. When a frame is received on a port, if the frame's classification type matches more than one rule, classification precedence rules are used to determine which rule to use.

The following information is discussed in this file:

Traffic Descriptions

When you create a Traffic Classification rule in Policy Manager, you must define the rule's traffic description. The traffic description identifies the traffic classification type for that rule. You must select a classification type, and then select or enter certain parameters or values for each type.

Classification types are grouped according to Layers 2, 3, and 4 of the OSI model and there are multiple classification types for each layer.

OSI Model
Layer 7 - Application
Layer 6 - Presentation
Layer 5 - Session
Layer 4 - Transport
Layer 3 - Network
Layer 2 - Data Link
Layer 1 - Physical

Specific Layer 2/3/4 information contained in the header of each frame is used to identify the frame's classification type. Each layer uses different information to classify frames.

  • Layer 2 Data Link -- classifies frames based on an exact match of the MAC address or specific protocol type of each frame.
  • Layer 3 Network -- classifies IP or IPX frames based on specific information contained within the Layer 3 header.
  • Layer 4 Transport -- classifies IP frames based on specific Layer 4 TCP or UDP port numbers contained in the header.
For a complete description of Layer 2, 3, and 4 classifications, refer to Classification Types and Their Parameters.

Actions

When you create a Traffic Classification rule in Policy Manager, you must define the actions that the rule will perform. When a frame arrives on a port, the switch checks to see if the frame's classification type matches the type specified in a rule. If it does, then the actions defined in that rule will apply to the frame. Actions specify whether the frame will be assigned VLAN membership, class of service, or both.

VLAN Membership

In your network domains, you can create VLANs (Virtual Local Area Networks) that allow end systems connected to separate ports to send and receive traffic as though they were all connected to the same network segment. Using traffic classification rules, you can classify a frame based on the frame's classification type to have membership in a specific VLAN, providing important traffic containment, filtering, and security for your network.

For example, a network administrator could use rules to separate end-user traffic into VLANs according to protocol, subnet, or application. Rules could also be used to group geographically separate end systems into job specific workgroups.

Top

Priority (Class of Service)

Traffic Classification rules allow you to assign a transmission priority to frames received on a port based on the frame's classification type. For example, a network administrator could use rules to assign priority to one network application over another.

Priority is a value between 0 and 7 assigned to each frame as it is received on a port, with 7 being the highest priority. Frames assigned a higher priority will be transmitted before frames with a lower priority. Each of the priorities is mapped into a specific traffic queue by the switch or router. The insertion of the priority value (0-7) allows all 802.1Q devices in the network to make intelligent forwarding decisions based on its own level of support for prioritization.

The Matrix product line supports four (0-3)or eight (0-7) traffic queues  per port. The number of traffic queues varies by port type. These queues can be serviced based on a strict method, meaning that all frames in Queue 3 will be transmitted before the frames in Queue 0, or based on a fair weighted method. The weighted method allows the network administrator to give a certain percentage or weight to each queue, preventing a lower priority queue from being starved.

Policy Manager enables you to utilize priority by creating classes of service that include an 802.1p priority (rate-limited or not) and/or IP type of service values. You can then assign the class of service as a classification rule action, as part of the definition of an automated service, or as a role default. See How to Define a Bandwidth Rate Limiter and How to Create a Class of Service for more information.

Top

Classification Types and their Parameters

When you define a rule's traffic description, you select a classification type, and then select or enter certain parameters or values for each type. Classification types are grouped according to Layers 2, 3, and 4 of the OSI model and there are multiple classification types for each layer.

Layer 2 -- Data Link Classification Types

Layer 2 classification types allow you to define classification rules based on an exact match of the MAC address or specific protocol type of each frame.

Ethertype
This classification type is based on the specific protocol type of each frame defined in the two-byte Ethertype field. Each protocol has a corresponding classification type address that is automatically entered into the Value field. If you select Other, you must manually enter the value in hexadecimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices. Common Ethertypes and their values:
IP0x0800
ARP0x0806
Reverse ARP0x8035
Novell IPX 10x8137
Novell IPX 20x8138
Banyan0x0bad
AppleTalk0x809b
AppleTalk ARP0x80f3
DECnet Phase 40x6003
DEC MOP Dump/Load0x6001
DEC MOP Remote Console     0x6002
DEC LAT0x6004
DEC Diagnostic Protocol 0x6005
DEC Customer Protocol0x6006
DEC LAVC, SCA0x6007
DEC Unassigned0x6008-0x6009
Other0x0600-0xFFFF
DSAP/SSAP
This classification type is based on the specific protocol type of each frame defined in the DSAP and SSAP fields. Each protocol has a corresponding classification type address that is automatically entered into the Value field. If you select Other, you must manually enter the value in hexadecimal form. You can also enter advanced configurations, however, these are only supported on Matrix N-Series Platinum devices. The DSAP and SSAP values are one byte each, and these values must match. They are combined to create one two-byte value (e.g., a DSAP value of e0 and an SSAP value of e0 are combined to create a two-byte value of e0e0). Common DSAP/SSAP types and their values:
IP0x0606
IPX0xe0e0
NetBIOS0xf0f0
Banyan Vines     0xbcbc
SNA0x0404
Othera two-byte value
MAC Address Source, MAC Address Destination, MAC Address Bilateral
These classification types are based on an exact match of the source, destination, or bilateral (either source or destination) MAC address contained in an Ethernet frame. You can select a mask, however, masking a MAC address is only supported on Matrix N-Series Platinum devices.

Layer 3 -- Network Classification Types

Layer 3 Network classification types allow you to define classification rules based on specific information contained within the Layer 3 header of an IP or IPX frame.
IP Type of Service
This classification type is based on an exact match of the one-byte TOS/DSCP field contained in the IP header of a frame. The TOS (Type of Service) or DSCP (Diffserve Codepoint) value is defined by an 8-bit hexadecimal number between 0 and FF.

Type of Service can be used by applications to indicate priority and Quality of Service for each frame. The level of service is determined by a set of service parameters which provide a three way trade-off between low-delay, high-reliability, and high-throughput. The use of service parameters may increase the cost of service. In many networks, better performance for one of these parameters is coupled with worse performance on another. Except for very unusual cases, at most, two of the parameters should be set.

For a TOS value, the 8-bit hexadecimal number breaks down as follows:

Bits 0-2: Precedence
Bit 3: 0=Normal Delay, 1=Low Delay
Bit 4: 0=Normal Throughput, 1=High Throughput
Bit 5: 0=Normal Reliability, 1=High Reliability
Bits 6-7: Explicit Congestion Notification

The precedence bits (bits 0-2) break down as follows:

111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - Routine

The Network Control precedence designation is intended to be used within a network only. The actual use and control of that designation is up to each network. The Internetwork Control designation is intended for use by gateway originators only.

For a DSCP value, the value represents codepoints for two Differentiated Services (DS) Per-Hop-Behavior (PHB) groups called Expedited Forwarding (EF) and Assured Forwarding (AF). For more information on these PHB groups, refer to RFC 2597 and RFC 2598.

For information on how to automatically generate a TOS or DSCP value, see TOS/DSCP Configuration window.

IP Protocol Type
This classification type is based on the specific protocol type defined in a field contained in the IP header of each frame. Each protocol has a corresponding classification type address that is automatically entered into the Value field. If you select Other, you must manually enter the value in decimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices.
 TIP:You can define a new IP Protocol Type using the Pre-Defined Well-Known IDs window. Once defined, it is available for selection from the list of well-known values when defining the rule's traffic classification type.
Common IP Protocol types and their values:
ICMP     1
IGMP2
IPv641
L2TP115
OSPF89
PIM103
RSVP46
TCP6
UDP17
VRRP112
Other0-255
IP Address Source, IP Address Destination, IP Address Bilateral
These classification types are based on an exact match of the source, destination, or bilateral (either source or destination) IP address information contained within the IP header of each frame. This classification type must also contain a Mask entry along with the specific IP address. This Mask allows a switch to determine whether a classification is based on a specific IP address, IP subnet, or range within an IP subnet. For example, a user could define a rule where all frames from the 129.168.28.x network are classified into the Red VLAN by setting the IP address of 129.168.28.0 with the mask of 255.255.255.0.
IP Fragment
This classification type is based on Layer 4 information in fragmented frames. IP supports frame fragmentation, where large frames are divided into smaller fragments and sent wrapped in the original Layer 3 (IP) header. When a frame is fragmented, information that is Layer 4 and above is only present in the first fragment. For example, the first fragment may be classified to Layer 4, while subsequent fragments will be classified only to Layer 3. The Matrix product line does not support Layer 4 classification for IP frames that have been fragmented, as the Layer 4 information is not present in these frames. Using the IP Fragment classification rule, any frame which is a fragment of a larger frame, is classified according to the information in the original frame. If the first fragment is classified to Layer 4, subsequent fragments will also be classified to Layer 4.
IPX Class of Service
This classification type is based on specific information contained within the Layer 3 header of an IPX frame. This is a one-byte field used for transmission control (hop count) by IPX routers. Enter a valid IPX Class of Service in decimal form, 0-255. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices.
IPX Packet Type
This classification type is based on specific information contained within the Layer 3 header of an IPX frame. Each IPX Packet type has a corresponding classification type address that is automatically entered into the Value field. If you select Other, you must manually enter the value in decimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices. Common IPX Packet types and their values:
Hello/SAP0
RIP1
Echo Packet2
Error Packet3
NetWare 386     4
SeqPackProt5
NetWare 28617
Other0-31
IPX Network Source, IPX Network Destination, IPX Network Bilateral
These classification types are based on specific information contained within the Layer 3 header of an IPX frame. It is a four-byte user-defined value that represents the IPX source, destination, or bilateral (either source or destination) network number. This value must be a valid IPX network address in hexadecimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices.
IPX Socket Source, IPX Socket Destination, IPX Socket Bilateral
These classification types are based on specific information contained within the Layer 3 header of an IPX frame. It is a two-byte, user-defined value that represents the IPX source, destination, or bilateral (either source or destination) socket numbers. This value is used by higher layer protocols to target specific applications running among hosts. Each IPX Socket type has a corresponding classification type address that is automatically entered into the Value field. If you select Other, you must manually enter the value in decimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices. Common IPX Socket types and their values:
NCP1105
SAP1106
RIP1107
NetBIOS1109
Diagnostics     1110
NSLP36865
IPX Wan56868
Other0-65535
ICMP
This classification type is based on an exact match of the ICMP (Internet Control Message Protocol) message contained in the ICMP tag within a frame. Each ICMP message has a corresponding value that is automatically entered in the Value field. If you select Other, you must manually enter the value in decimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices. Common ICMP messages and their values:
Echo Reply0
Destination Unreachable3
Source Quench4
Redirect5
Echo     8
Router Advertisement9
Router Solicitation10
Time Exceeded11
Parameter Problem12
Timestamp13
Timestamp Reply14
Information Request15
Information Reply16
Address Mask Request17
Address Mask Reply18
VLAN ID
This classification type is based on an exact match of the VLAN tag contained within a frame. Select a VLAN ID (VID) from the list of VLANs defined in Policy Manager. If you select Other, you must enter a single VID or specify a range of VIDs in decimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices.
Priority
This classification type is based on an exact match of the Priority tag contained within a frame. Select a Priority value 0 - 7 from the list of well-known values, or select Other and enter a value in decimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices.

Layer 4 -- Application Transport Classification Types

Layer 4 IP classification types allow you to define classification rules based on specific Layer 4 TCP or UDP port numbers contained in the header of an IP frame. You can specify a specific port number or a range of port numbers.

Note: The Matrix product line does not support Layer 4 classification for IP frames that have been fragmented, as the Layer 4 information is not present in these frames. If a Matrix device has an FDDI HSIM installed, Layer 4 classification will not be supported for any frames larger than 1500 bytes. Frames larger than 1500 bytes are fragmented internally in the switch. When creating classification rules based on specific Layer 4 information, using the IP Fragment classification rule will allow fragmented frames to be classified according to the Layer 4 information contained in the original frame.

IP UDP Port Source, IP UDP Port Destination, IP UDP Port Bilateral
These classification types are based on specific Layer 4 UDP port numbers contained within the header of an IP frame. Each UDP type has a corresponding classification type address that is automatically entered into the Value field. If you select Other, you must manually enter the value in decimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices. UDP port numbers are defined in RFC 1700.
 TIP:You can define a new value for a UDP port number using the Pre-Defined Well-Known IDs window. Once defined, it is available for selection from the list of well-known values when defining the rule's traffic classification type.
Common UDP types and their values:
FTP Data20
FTP21
SSH22
Telnet23
SMTP25
TACACS49
DNS53
Bootps67
Bootpc68
TFTP69
Finger79
HTTP80
POP3110
Portmapper111
NNTP119
NTP123
NetBIOS Name Service137
NetBIOS Datagram138
NetBIOS Session Service     139
IMAP2143
SNMP161
IMAP3220
LDAP389
HTTPS443
R-Exec512
R-Login513
R-Shell514
LPR515
SOCKS1080
CITRIX ICA1494
RADIUS1812
RADIUS Accounting1813
NFS2049
Other0-65535
IP TCP Port Source, IP TCP Port Destination, IP TCP Port Bilateral
These classification types are based on specific Layer 4 TCP port numbers contained within the header of an IP frame. Each TCP type has a corresponding classification type address that is automatically entered into the Value field. If you select Other, you must manually enter the value in decimal form. You can enter a range of values, however, range rules are only supported on Matrix N-Series Platinum devices. TCP port numbers are defined in RFC 1700.
 TIP:You can define a new value for a TCP port number using the Pre-Defined Well-Known IDs window. Once defined, it is available for selection from the list of well-known values when defining the rule's traffic classification type.
Common TCP types and their values:
FTP Data20
FTP21
SSH22
Telnet23
SMTP25
TACACS49
DNS53
Bootps67
Bootpc68
TFTP69
Finger79
HTTP80
POP3110
Portmapper111
NNTP119
NTP123
NetBIOS Name Service137
NetBIOS Datagram138
NetBIOS Session Service     139
IMAP2143
SNMP161
IMAP3220
LDAP389
HTTPS443
R-Exec512
R-Login513
R-Shell514
LPR515
SOCKS1080
CITRIX ICA1494
RADIUS1812
RADIUS Accounting1813
NFS2049
Other0-65535
IP UDP Port Source Range, IP UDP Port Destination Range, IP UDP Port Bilateral Range
These classification types are based on Layer 4 UDP port numbers contained within the header of an IP frame. When you select this type, you enter a range of UDP port numbers that the port number in the header will be matched against. Enter the lower and upper range values in decimal form. UDP port numbers are defined in RFC 1700.
IP TCP Port Source Range, IP TCP Port Destination Range, IP TCP Port Bilateral Range
These classification types are based on Layer 4 TCP port numbers contained within the header of an IP frame. When you select this type, you enter a range of TCP port numbers that the port number in the header will be matched against. Enter the lower and upper range values in decimal form. TCP port numbers are defined in RFC 1700.

Examples of How Rules are Used

Traffic Classification rules are used to provide four key policy features: Traffic Containment, Traffic Filtering, Traffic Security, and Traffic Priority.

Traffic Containment

Using classification rules, network administrators can group together users of a given protocol, subnet, or application, and control where their traffic can logically go on the network.

IP Traffic Containment

IP Traffic Containment

The figure above shows a configuration where the network administrator wants to separate end-user traffic into VLANs based on the assigned IP subnet of each department. This can easily be accomplished by creating two Layer 3 classification rules based on the IP subnet range of the respective departments.

Rule 1 - Engineering, which uses the 132.181.28.x subnet, will be assigned to the Red VLAN.

Rule 2 - Sales, which uses the 132.181.29.x subnet, will be assigned to the Blue VLAN.

Based on these two Layer 3 classification rules, the traffic from the Engineering VLAN will be isolated from the Sales VLAN. Since these rules are based on Layer 3 information, an Engineering user could enter the network from a connection in the Sales department, and that user would still be contained in the Engineering VLAN.

Top

Traffic Filtering

Classification rules can also be used to filter specific unwanted traffic. Filter criteria can include things such as broadcast routing protocols, specific IP addresses, or even applications such as HTTP or SMTP.

In filtering operations, the traffic to be filtered is assigned to the Discard VLAN. Since the Discard VLAN is not configured to exit the switch, the traffic will be discarded.

OSPF/RIP Traffic Filtering

OSPF/RIP Traffic Filtering

The figure above shows a common configuration in which a routed backbone is using both RIP and OSPF for its routing protocols. The network administrator does not want the multicast OSPF and broadcast RIP frames propagated to the end stations. The network is designed so that only end users are attached to the Matrix devices.

To implement filtering in this scenario, a Layer 3 rule and a Layer 4 rule will be created.

Rule 1 (Layer 3) - Any frame received with an IP Protocol Type of 89 (OSPF) will be classified into the Discard VLAN.

Rule 2 (Layer 4) - Any frame received with a Bilateral UDP port number of 520 (RIP) will be classified into the Discard VLAN.

Based on this configuration, as long as the Discard VLAN is not configured to exit the switch, all RIP and OSPF frames will be filtered from the end users.

Top

Traffic Security

Traffic Security uses the same concepts as Traffic Filtering. Imagine a scenario where network access is provided to a group of unknown users. There have been problems with these unknown users "hacking" into the router and altering the configuration. A simple classification rule can be put in place that will prevent these types of occurrences.

Router Traffic Security

Router Traffic Security

In the figure above, the network components include a router and a Matrix E7. In this configuration end-users connect to the ports of the Matrix E7.

Since the end-users would never need to communicate directly to the router using the router's IP address, a Layer 3 IP classification rule will be used.

Rule - Any frames received by the switch with a destination IP address of the router (129.168.1.2) will be classified to the Discard VLAN. The Discard VLAN is configured so that it does not exit the switch.

The end result is that any frames from a user trying to "hack" into the router will be discarded before ever reaching the router.

Top

Traffic Prioritization

Classification rules can be used to specify that certain network applications receive the highest transmission priority. For example, a network administrator wants to assign priority to three network applications, SAP R/3, web traffic, and email, in that order.

Prioritization

Prioritization

To accomplish the prioritization goals in this example, there are two main steps required: creating the classification rules, and configuring the Priority-to-Traffic Queue mapping for the switch.

First, create one Layer 3 and two Layer 4 classification rules.

Rule 1, Layer 3 (SAP R/3) - All frames to or from the IP address of the SAP R/3 server will be tagged with a priority indicator of 7 (highest).

Rule 2, Layer 4 (Web) - All frames with a UDP port number of 80 (HTTP) will be tagged with a priority indicator of 5.

Rule 3, Layer 4 (email) - All frames with a UDP port number of 25 (SMTP) will be tagged with a priority indicator of 3.

Note: An IP address classification was selected for Rule 1 because it has been observed that SAP R/3 dynamically negotiates the TCP/UDP port used, so the port number selections vary from session to session. If this was not the case, a Layer 4 UDP classification could be used.

Then, configure the priority-to-traffic queue mappings. Based on the default priority-to-traffic queue mapping (shown in the following table), the priorities assigned above will work out so that each frame classification type will be mapped to the desired traffic queue. This means that no user configuration of the priority-traffic queue mapping would be required. However, this mapping can be configured by the network administrator using local management or NetSight Atlas Console.

This table shows the default Matrix E7 priority-to-queue mappings.

Priority Value Traffic Queue
7 3
6 3
5 2
4 2
3 1
2 0
1 0
0 1

Priority 7 = Highest
Traffic Queue 3 is serviced first

With the classification rules described in Traffic Prioritization, the network traffic would be prioritized as shown in the table below.

Application Classification Type Desired Priority Priority Value SS6000 Traffic Queue
SAP R/3 Bilateral IP High 7 3
Web UDP Port Number Medium 5 2
Email UDP Port Number Low 3 1

Top

Classification Precedence Rules

When there is a role with multiple classification rules assigned to a port, the device must determine which rule takes precedence. The order of precedence is predefined in the device, and is not configurable. Network administrators should have a comprehensive understanding of classification precedence, as it can significantly impact the operation of traffic classification rules. The Device Support Tab (Role) provides rule precedence information for each role.

The device determines the order of precedence based on the classification types. The Precedence Table details the order of precedence with 1 being the highest precedence, and 15 being the lowest.

Classification Precedence
Layer 2
Source MAC Address 1
Destination MAC Address 2
Ethertype Field / DSAP/SSAP Fields 13
Layer 3
IP TOS / IPX COS 11
IP Protocol Type / IPX Packet Type 12
Source IP Address Exact Match / Source IPX Network Number 3
Source IP Address Best Match / Destination IPX Network Number 4
Destination IP Address Exact Match 5
Destination IP Address Best Match 6
IP Fragment 7
Layer 3/4
IPX Socket Source / UDP Source Port / TCP Source Port 8
IPX Socket Destination / UDP Destination Port / TCP Destination Port 9
ICMP 10
VLAN ID14
Priority 15

Exact Match indicates a match of an explicitly defined address.
Best Match indicates a match of an entire subnet, or range within a subnet.

Note: The precedence of a rule based on a bilateral address match is determined frame by frame depending on whether the rule matches the destination or source address in the frame. A bilateral address rule which matches the source address has higher precedence than a rule which matches a destination address (or any other lower precedence rule).

Top

Precedence Scenarios

The following scenarios illustrate the classification precedence rules.
Scenario 1
A network administrator has defined two classification rules:

Rule 1- All frames with a UDP port number of 55(ISI Graphic Language) are assigned to the Red VLAN.

Rule 2- All frames sourced from the 132.181.28.x subnet are assigned to the Blue VLAN.

If a frame is received with a source address of 132.181.28.99 and a UDP port number of 55, the frame will be assigned to the Blue VLAN because as shown in the Precedence Table, a Layer 3 IP Address rule takes precedence over a Layer 4 rule.

Scenario 2
A network administrator defines two classification rules:

Rule 1- All frames with an IP TOS value of AA are assigned a priority of 7.

Rule 2- All frames with a TCP port number of 80 (HTTP) are assigned a priority of 3.

If a frame is received with a TOS value of AA and a TCP port number of 80, the frame will be assigned a priority of 3, because as shown in the Precedence Table, TCP port number classifications take precedence over IP TOS classifications.

Top


Related Information

For information on related tasks: For information on related windows: Top
#-------------------------------------------------- # http://www.snort.org Snort Ruleset # Contact: snort-sigs@lists.sourceforge.net #-------------------------------------------------- # $Id$ # ################################################### # This file contains a sample snort configuration. # You should take the following steps to create your own custom configuration: # # 1) Set the network variables. # 2) Configure the decoder # 3) Configure the base detection engine # 4) Configure dynamic loaded libraries # 5) Configure preprocessors # 6) Configure output plugins # 7) Customize your rule set ################################################### ################################################### # Step #1: Set the network variables. For more information, see README.variables ################################################### # Setup the network addresses you are protecting var HOME_NET 192.168.119.0/24 # Set up the external network addresses. A good start may be "any" var EXTERNAL_NET any # List of DNS servers on your network var DNS_SERVERS $HOME_NET # List of SMTP servers on your network var SMTP_SERVERS $HOME_NET # List of web servers on your network var HTTP_SERVERS $HOME_NET # List of sql servers on your network var SQL_SERVERS $HOME_NET # List of telnet servers on your network var TELNET_SERVERS $HOME_NET # List of ports you run web servers on portvar HTTP_PORTS [80,2301,3128,7777,7779,8000,8008,8028,8080,8180,8888,9999] # List of ports you want to look for SHELLCODE on. portvar SHELLCODE_PORTS !80 # List of ports you might see oracle attacks on portvar ORACLE_PORTS 1521 # other variables, these should not be modified var AIM_SERVERS [64.12.24.0/23,64.12.28.0/23,64.12.161.0/24,64.12.163.0/24,64.12.200.0/24,205.188.3.0/24,205.188.5.0/24,205.188.7.0/24,205.188.9.0/24,205.188.153.0/24,205.188.179.0/24,205.188.248.0/24] # Path to your rules files (this can be a relative path) # Note for Windows users: You are advised to make this an absolute path, # such as: c:\snort\rules var RULE_PATH C:\Snort\rules var SO_RULE_PATH C:\Snort\so_rules var PREPROC_RULE_PATH C:\Snort\preproc_rules ################################################### # Step #2: Configure the decoder. For more information, see README.decode ################################################### # Stop generic decode events: config disable_decode_alerts # Stop Alerts on experimental TCP options config disable_tcpopt_experimental_alerts # Stop Alerts on obsolete TCP options config disable_tcpopt_obsolete_alerts # Stop Alerts on T/TCP alerts config disable_tcpopt_ttcp_alerts # Stop Alerts on all other TCPOption type events: config disable_tcpopt_alerts # Stop Alerts on invalid ip options config disable_ipopt_alerts # Alert if value in length field (IP, TCP, UDP) is greater th elength of the packet # config enable_decode_oversized_alerts # Same as above, but drop packet if in Inline mode (requires enable_decode_oversized_alerts) # config enable_decode_oversized_drops # Configure IP / TCP checksum mode config checksum_mode: all # Configure maximum number of flowbit references. For more information, see README.flowbits # config flowbits_size: 64 # Configure ports to ignore # config ignore_ports: tcp 21 6667:6671 1356 # config ignore_ports: udp 1:17 53 ################################################### # Step #3: Configure the base detection engine. For more information, see README.decode ################################################### # Configure PCRE match limitations config pcre_match_limit: 1500 config pcre_match_limit_recursion: 1500 # Configure the detection engine See the Snort Manual, Configuring Snort - Includes - Config config detection: search-method ac-bnfa max_queue_events 5 # Configure the event queue. For more information, see README.event_queue config event_queue: max_queue 8 log 3 order_events content_length # Configure Inline Resets. See README.INLINE # config layer2resets: 00:06:76:DD:5F:E3 ################################################### # Step #4: Configure dynamic loaded libraries. # For more information, see Snort Manual, Configuring Snort - Dynamic Modules ################################################### # path to dynamic preprocessor libraries #dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/ # path to base preprocessor engine #dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so # path to dynamic rules libraries # dynamicdetection directory /usr/local/lib/snort_dynamicrules # 配置Windows下的动态模块路径 dynamicpreprocessor file C:\Snort\lib\snort_dynamicpreprocessor\sf_dce2.dll dynamicpreprocessor file C:\Snort\lib\snort_dynamicpreprocessor\sf_dns.dll dynamicpreprocessor file C:\Snort\lib\snort_dynamicpreprocessor\sf_ftptelnet.dll dynamicpreprocessor file C:\Snort\lib\snort_dynamicpreprocessor\sf_sdf.dll dynamicpreprocessor file C:\Snort\lib\snort_dynamicpreprocessor\sf_smtp.dll dynamicpreprocessor file C:\Snort\lib\snort_dynamicpreprocessor\sf_ssh.dll dynamicpreprocessor file C:\Snort\lib\snort_dynamicpreprocessor\sf_ssl.dll dynamicengine C:\Snort\lib\snort_dynamicengine\sf_engine.dll ################################################### # Step #5: Configure preprocessors # For more information, see the Snort Manual, Configuring Snort - Preprocessors ################################################### # Target-based IP defragmentation. For more inforation, see README.frag3 preprocessor frag3_global: max_frags 65536 preprocessor frag3_engine: policy windows timeout 180 # Target-Based stateful inspection/stream reassembly. For more inforation, see README.stream5 preprocessor stream5_global: max_tcp 8192, track_tcp yes, track_udp no preprocessor stream5_tcp: policy windows, use_static_footprint_sizes, ports client 21 22 23 25 42 53 79 80 109 110 111 113 119 135 136 137 139 143 110 111 161 445 513 514 691 1433 1521 2100 2301 3128 3306 6665 6666 6667 6668 6669 7000 8000 8080 8180 8888 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779, ports both 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 # preprocessor stream5_udp: ignore_any_rules # performance statistics. For more information, see the Snort Manual, Configuring Snort - Preprocessors - Performance Monitor # preprocessor perfmonitor: time 300 file /var/snort/snort.stats pktcnt 10000 # HTTP normalization and anomaly detection. For more information, see README.http_inspect preprocessor http_inspect: global iis_unicode_map unicode.map 1252 preprocessor http_inspect_server: server default \ apache_whitespace no \ ascii no \ bare_byte no \ chunk_length 500000 \ flow_depth 1460 \ directory no \ double_decode no \ iis_backslash no \ iis_delimiter no \ iis_unicode no \ multi_slash no \ non_strict \ oversize_dir_length 500 \ ports { 80 2301 3128 7777 7779 8000 8008 8028 8080 8180 8888 9999 } \ u_encode yes \ non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \ webroot no # ONC-RPC normalization and anomaly detection. For more information, see the Snort Manual, Configuring Snort - Preprocessors - RPC Decode preprocessor rpc_decode: 111 32770 32771 32772 32773 32774 32775 32776 32777 32778 32779 no_alert_multiple_requests no_alert_large_fragments no_alert_incomplete # Back Orifice detection. preprocessor bo # FTP / Telnet normalization and anomaly detection. For more information, see README.ftptelnet preprocessor ftp_telnet: global encrypted_traffic yes check_encrypted inspection_type stateful preprocessor ftp_telnet_protocol: telnet \ ayt_attack_thresh 20 \ normalize ports { 23 } \ detect_anomalies #preprocessor ftp_telnet_protocol: ftp server default \ # def_max_param_len 100 \ # ports { 21 2100 } \ # ftp_cmds { USER PASS ACCT CWD SDUP SMNT QUIT REIN PORT PASV TYPE STRU MODE } \ # ftp_cmds { RETR STOR STOU APPE ALLO REST RNFR RNTO ABOR DELE RMD MKD PWD } \ # ftp_cmds { LIST NLST SITE SYST STAT HELP NOOP } \ # ftp_cmds { AUTH ADAT PROT PBSZ CONF ENC } \ # ftp_cmds { FEAT OPTS CEL CMD MACB } \ # ftp_cmds { MDTM REST SIZE MLST MLSD } \ # ftp_cmds { XPWD XCWD XCUP XMKD XRMD TEST CLNT } \ # alt_max_param_len 0 { CDUP QUIT REIN PASV STOU ABOR PWD SYST NOOP } \ # alt_max_param_len 100 { MDTM CEL XCWD SITE USER PASS REST DELE RMD SYST TEST STAT MACB EPSV CLNT LPRT } \ # alt_max_param_len 200 { XMKD NLST ALLO STOU APPE RETR STOR CMD RNFR HELP } \ # alt_max_param_len 256 { RNTO CWD } \ # alt_max_param_len 400 { PORT } \ # alt_max_param_len 512 { SIZE } \ # chk_str_fmt { USER PASS ACCT CWD SDUP SMNT PORT TYPE STRU MODE } \ # chk_str_fmt { RETR STOR STOU APPE ALLO REST RNFR RNTO DELE RMD MKD } \ # chk_str_fmt { LIST NLST SITE SYST STAT HELP } \ # chk_str_fmt { AUTH ADAT PROT PBSZ CONF ENC } \ # chk_str_fmt { FEAT OPTS CEL CMD } \ # chk_str_fmt { MDTM REST SIZE MLST MLSD } \ # chk_str_fmt { XPWD XCWD XCUP XMKD XRMD TEST CLNT } \ # cmd_validity MODE < char ASBCZ > \ # cmd_validity STRU < char FRP > \ # cmd_validity ALLO < int [ char R int ] > \ # cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } > \ # cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string > \ # cmd_validity PORT < host_port > #preprocessor ftp_telnet_protocol: ftp client default \ # max_resp_len 256 \ # bounce yes \ # telnet_cmds no # SMTP normalization and anomaly detection. For more information, see README.SMTP #preprocessor smtp: ports { 25 587 691 } \ # inspection_type stateful \ # normalize cmds \ # normalize_cmds { EXPN VRFY RCPT } \ # alt_max_command_line_len 260 { MAIL } \ #alt_max_command_line_len 300 { RCPT } \ # alt_max_command_line_len 500 { HELP HELO ETRN } \ # alt_max_command_line_len 255 { EXPN VRFY } # Portscan detection. For more information, see README.sfportscan # preprocessor sfportscan: proto { all } memcap { 10000000 } sense_level { low } # ARP spoof detection. For more information, see the Snort Manual - Configuring Snort - Preprocessors - ARP Spoof Preprocessor # preprocessor arpspoof # preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00 # SSH anomaly detection. For more information, see README.ssh #preprocessor ssh: server_ports { 22 } \ # max_client_bytes 19600 \ # max_encrypted_packets 20 \ # enable_respoverflow enable_ssh1crc32 \ # enable_srvoverflow enable_protomismatch # SMB / DCE-RPC normalization and anomaly detection. For more information, see README.dcerpc2 #preprocessor dcerpc2: memcap 102400, events [co ] #preprocessor dcerpc2_server: default, policy WinXP, \ # detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \ # autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \ # smb_max_chain 3 # DNS anomaly detection. For more information, see README.dns #preprocessor dns: ports { 53 } enable_rdata_overflow # SSL anomaly detection and traffic bypass. For more information, see README.ssl #preprocessor ssl: ports { 443 465 563 636 989 992 993 994 995 7801 7702 7900 7901 7902 7903 7904 7905 7906 6907 7908 7909 7910 7911 7912 7913 7914 7915 7916 7917 7918 7919 7920 }, trustservers, noinspect_encrypted ################################################### # Step #6: Configure output plugins # For more information, see Snort Manual, Configuring Snort - Output Modules ################################################### # 数据库输出:告警数据存入 snortdb(用户 snort001,密码 kali) output database: alert, mysql, user=snort001 password=kali dbname=snortdb host=localhost # syslog # output alert_syslog: LOG_AUTH LOG_ALERT # pcap # output log_tcpdump: tcpdump.log # database # output database: alert, <db_type>, user=<username> password=<password> test dbname=<name> host=<hostname> # output database: log, <db_type>, user=<username> password=<password> test dbname=<name> host=<hostname> # unified2 output unified2: filename snort.log, limit 128 # prelude # output alert_prelude # metadata reference data. do not modify these lines include classification.config include reference.config ################################################### # Step #7: Customize your rule set # For more information, see Snort Manual, Writing Snort Rules ################################################### # site specific rules include $RULE_PATH/local.rules include $RULE_PATH/community-rules/community.rules include $RULE_PATH/exploit.rules include $RULE_PATH/ftp.rules include $RULE_PATH/telnet.rules include $RULE_PATH/rpc.rules include $RULE_PATH/rservices.rules include $RULE_PATH/dos.rules include $RULE_PATH/ddos.rules include $RULE_PATH/dns.rules include $RULE_PATH/web-cgi.rules include $RULE_PATH/web-coldfusion.rules include $RULE_PATH/web-iis.rules include $RULE_PATH/web-frontpage.rules include $RULE_PATH/web-misc.rules include $RULE_PATH/web-client.rules include $RULE_PATH/web-php.rules include $RULE_PATH/sql.rules include $RULE_PATH/x11.rules include $RULE_PATH/netbios.rules include $RULE_PATH/misc.rules include $RULE_PATH/attack-responses.rules include $RULE_PATH/oracle.rules include $RULE_PATH/mysql.rules include $RULE_PATH/smtp.rules include $RULE_PATH/imap.rules include $RULE_PATH/pop2.rules include $RULE_PATH/pop3.rules include $RULE_PATH/nntp.rules include $RULE_PATH/backdoor.rules # include $RULE_PATH/snmp.rules # include $RULE_PATH/icmp.rules # include $RULE_PATH/tftp.rules # include $RULE_PATH/scan.rules # include $RULE_PATH/finger.rules # include $RULE_PATH/web-attacks.rules # include $RULE_PATH/shellcode.rules # include $RULE_PATH/policy.rules # include $RULE_PATH/info.rules # include $RULE_PATH/icmp-info.rules # include $RULE_PATH/virus.rules # include $RULE_PATH/chat.rules # include $RULE_PATH/multimedia.rules # include $RULE_PATH/p2p.rules # include $RULE_PATH/spyware-put.rules # include $RULE_PATH/specific-threats.rules # include $RULE_PATH/voip.rules # include $RULE_PATH/other-ids.rules # include $RULE_PATH/bad-traffic.rules # decoder and preprocessor event rules # include $PREPROC_RULE_PATH/preprocessor.rules # include $PREPROC_RULE_PATH/decoder.rules # dynamic library rules # include $SO_RULE_PATH/bad-traffic.rules # include $SO_RULE_PATH/chat.rules # include $SO_RULE_PATH/dos.rules # include $SO_RULE_PATH/exploit.rules # include $SO_RULE_PATH/imap.rules # include $SO_RULE_PATH/misc.rules # include $SO_RULE_PATH/multimedia.rules # include $SO_RULE_PATH/netbios.rules # include $SO_RULE_PATH/nntp.rules # include $SO_RULE_PATH/p2p.rules # include $SO_RULE_PATH/smtp.rules # include $SO_RULE_PATH/sql.rules # include $SO_RULE_PATH/web-activex.rules # include $SO_RULE_PATH/web-client.rules # include $SO_RULE_PATH/web-misc.rules # Event thresholding or suppression commands. See threshold.conf include threshold.conf 这是我的snort.conf,你将改好的发我
最新发布
11-06
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值