Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

IDS on MS-DPC

Configuring IDS Rules on an MS-DPC

IDS rules configured with an MS-DPC identify traffic for which you want the router software to count events. Because IDS is based on stateful firewall properties, you must configure at least one stateful firewall rule and include it in the service set with the IDS rules; for more information, see Configuring Stateful Firewall Rules.

Note:

To configure network attack protection with an MS-MPC, see Configuring Protection Against Network Attacks on an MS-MPC.

To configure an IDS rule, include the rule rule-name statement at the [edit services ids] hierarchy level:

Each IDS rule consists of a set of terms, similar to a filter configured at the [edit firewall] hierarchy level. A term consists of the following:

  • from statement—Specifies the match conditions and applications that are included and excluded.

  • then statement—Specifies the actions and action modifiers to be performed by the router software.

The following sections describe IDS rule content in more detail:

Configuring Match Direction for IDS Rules

Each rule must include a match-direction statement that specifies whether the match is applied on the input or output side of the interface. To configure where the match is applied, include the match-direction (input | input-output | output) statement at the [edit services ids rule rule-name] hierarchy level:

If you configure match-direction input-output, bidirectional rule creation is .

The match direction is used with respect to the traffic flow through the AS or Multiservices PIC. When a packet is sent to the PIC, direction information is carried along with it.

With an interface service set, packet direction is determined by whether a packet is entering or leaving the interface on which the service set is applied.

With a next-hop service set, packet direction is determined by the interface used to route the packet to the AS or Multiservices PIC. If the inside interface is used to route the packet, the packet direction is input. If the outside interface is used to direct the packet to the PIC, the packet direction is output. For more information on inside and outside interfaces, see Configuring Service Sets to be Applied to Services Interfaces.

On the AS or Multiservices PIC, a flow lookup is performed. If no flow is found, rule processing is performed. All rules in the service set are considered. During rule processing, the packet direction is compared against rule directions. Only rules with direction information that match the packet direction are considered.

Configuring Match Conditions in IDS Rules

To configure IDS match conditions, include the from statement at the [edit services ids rule rule-name term term-name] hierarchy level:

If you omit the from statement, the software accepts all events and places them in the IDS cache for processing.

The source address and destination address can be either IPv4 or IPv6. You can use the destination address, a range of destination addresses, a source address, or a range of source addresses as a match condition, in the same way that you would configure a firewall filter; for more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

Alternatively, you can specify a list of source or destination prefixes by including the prefix-list statement at the [edit policy-options] hierarchy level and then including either the destination-prefix-list or source-prefix-list statement in the IDS rule. For an example, see Examples: Configuring Stateful Firewall Rules.

You can also include application protocol definitions that you have configured at the [edit applications] hierarchy level; for more information, see Configuring Application Properties.

  • To apply one or more specific application protocol definitions, include the applications statement at the [edit services ids rule rule-name term term-name from] hierarchy level.

  • To apply one or more sets of application protocol definitions that you have defined, include the application-sets statement at the [edit services ids rule rule-name term term-name from] hierarchy level.

    Note:

    If you include one of the statements that specifies application protocols, the router derives port and protocol information from the corresponding configuration at the [edit applications] hierarchy level; you cannot specify these properties as match conditions.

If a match occurs on an application, the application protocol is displayed separately in the show services ids command output. For more information, see the CLI Explorer.

Configuring Actions in IDS Rules

To configure IDS actions, include the then statement at the [edit services ids rule rule-name term term-name] hierarchy level:

You can configure the following possible actions:

  • aggregation—The router aggregates traffic labeled with the specified source or destination prefixes before passing the events to IDS processing. This is helpful if you want to examine all the traffic connected with a particular source or destination host. To collect traffic with some other marker, such as a particular application or port, configure that value in the match conditions.

    To configure aggregation prefixes, include the aggregation statement at the [edit services ids rule rule-name term term-name then] hierarchy level and specify values for source-prefix, destination-prefix source-prefix-ipv6, or destination-prefix-ipv6:

    The value of source-prefix and destination-prefix must be an integer between 1 and 32. The value of source-prefix-ipv6 and destination-prefix-ipv6 must be an integer between 1 and 128.

  • (force-entry | ignore-entry)—force-entry provides a permanent spot in IDS caches for subsequent events after one event is registered. By default, the IDS software does not record information about “good” packets that do not exhibit suspicious behavior. You can use the force-entry statement to record all traffic from a suspect host, even traffic that would not otherwise be counted.

    ignore-entry ensures that all IDS events are ignored. You can use this statement to disregard all traffic from a host you trust, including any temporary anomalies that IDS would otherwise count as events.

    To configure an entry behavior different from the default, include the force-entry or ignore-entry statement at the [edit services ids rule rule-name term term-name then] hierarchy level:

  • logging—The event is logged in the system log file.

    To configure logging, include the logging statement at the [edit services ids rule rule-name term term-name then] hierarchy level:

    You can optionally include a threshold rate to trigger the generation of system log messages. The threshold rate is specified in events per second. IDS logs are generated once every 60 seconds for each anomaly that is reported. The logs are generated as long as the events continue.

  • session-limit—The router limits open sessions when the specified threshold is reached.

    To configure a threshold, include the session-limit statement at the [edit services ids rule rule-name term term-name then] hierarchy level:

    You configure the thresholds for flow limitation based on traffic direction:

    • To limit the number of outgoing sessions from one internal host or subnet, configure the by-source statement.

    • To limit the number of sessions between a pair of IP addresses, subnets, or applications, configure the by-pair statement.

    • To limit the number of incoming sessions to one external public IP address or subnet, configure the by-destination statement.

    For each direction, you can configure the following threshold values:

    • hold-time seconds—When the rate or packets measurement reaches the threshold value, stop all new flows for the specified number of seconds. Once hold-time is in effect, the traffic is blocked for the specified time even if the rate subsides below the specified limit. By default, hold-time has a value of 0; the range is 0 through 60 seconds.

    • maximum number—Maximum number of open sessions per IP address or subnet per application. The range is 1 through 32,767.

    • packets number—Maximum number of packets per second (pps) per IP address or subnet per application. The range is 4 through 2,147,483,647.

    • rate number—Maximum number of sessions per second per IP address or subnet per application. The range is 4 through 32,767.

      If you include more than one source address in the match conditions configured at the [edit services ids rule rule-name term term-name from] hierarchy level, limits are applied for each source address independently. For example, the following configuration allows 20 connections from each source address (10.1.1.1 and 10.1.1.2), not 20 connections total. The same logic applies to the applications and destination-address match conditions.

      Note:

      IDS limits are applied to packets that are accepted by stateful firewall rules. They are not applied to packets discarded or rejected by stateful firewall rules. For example, if the stateful firewall accepts 75 percent of the incoming traffic and the remaining 25 percent is rejected or discarded, the IDS limit applies only to 75 percent of the traffic.

  • syn-cookie—The router activates SYN-cookie defensive mechanisms.

    To configure SYN-cookie values, include the syn-cookie statement at the [edit services ids rule rule-name term term-name then] hierarchy level:

    If you enable SYN-cookie defenses, you must include both a threshold rate to trigger SYN-cookie activity and a Transmission Control Protocol (TCP) maximum segment size (MSS) value for TCP delayed binding. The threshold rate is specified in SYN attacks per second. By default, the TCP MSS value is 1500; the range is from 128 through 8192.

    Handling of SYN Flood Attacks and SYN Cookie Protection

    The main purpose of a SYN flood attack is to consume all new network connections at a site and thereby prevent authorized and legitimate users from being able to connect to network resources. The SYN (synchronize sequence number) packet is the first request to connect sent to a system. The SYN packet contains an ID to which the receiver is required to respond. If the packet contains an illegal ID, the receiving system does receive a connection acknowledgment when it responds to the intended connection initiator. Eventually, this half-open connection times out and the incoming channel on the receiver becomes available again to normally handle another request. A SYN flood attack sends so many such requests that all incoming connections are continuously tied up waiting for acknowledgments that are never received. This condition causes the server to be unavailable to legal users (except in cases where a user session is established when it is exactly at the moment when one of the tied-up connections times out). A SYN flood attack is a connectionless attack. It does not require a real source IP addresses and, because it uses legitimate destination IP or port addresses, is practically impossible to distinguish from legitimate packets. Therefore, it is very difficult to prevent this type of attack by using only filters or stateful firewall rules. Basically, there are only three methods to protect from this type of attack:

    • Intercept (delayed binding)—The firewall intercepts incoming TCP synchronization requests and establishes a connection with the client on the server’s behalf, and with the server on the client’s behalf. If both connections are successful, the firewall transparently merges the two connections. The firewall usually has aggressive timeouts to prevent its own resources from being consumed by a SYN attack. This the most intensive solution in terms of processing and memory requirements.

    • Watch (SYN defense)—The firewall passively watches half-open connections and actively closes connections on the server after a configurable length of time.

    • SYN cookie—SYN cookies are particular choices for the initial TCP sequence number chosen by the TCP server. A host requesting a connection must answer with the cookie to connect to an open TCP socket while a SYN-flood has been detected as in progress by the IDS.

    Juniper Networks routers support the combination of stateful firewall and IDS mechanisms to support the SYN cookie and watch (SYN defense) methods. The key to the SYN flood attack is the filling of the SYN queue of the victim or the attacked network element. The SYN cookie defense method enables the victim to continue accepting connection requests when the SYN queue is full or, in the case of the firewall or IDS applications, when a certain threshold has been reached. After the threshold is reached, a cryptographic cookie (a 32-bit number) is created from information in the SYN segment and the SYN segment is dropped. The cookie is used as the initial sequence number in the SYN-ACK sent to the client. The cookie (plus one) is returned to the firewall or IDS application as the acknowledgment number in the ACK from a legitimate client. The returned cookie can be validated and the most important parts of the SYN segment can be reconstructed from the cookie, thereby allowing a connection to be established. Because the spoofed clients of the SYN flood never send ACKs, no resources are allocated for them in any state when SYN cookies are in use. It is preferred that you use SYN flood countermeasures only for hosts under attack. The anomaly table can be used for reliable attack recognition or they can be enabled within the stateful firewall. Such a type of configuration also helps prevent the depletion of system resources (especially the flow table) in case of attacks.

    When combining multiple services, the general path is an important factor for consideration in the forward and reverse directions. This is especially true when NAT is deployed to determine whether the pre-NAT or post-NAT address must be used to match a rule. In the forward path from a LAN interface to a WAN interface, IDS and stateful firewall are performed first, then NAT, and finally IPSec. This sequence of processing of services denotes that the stateful firewall must match on a pre-NAT address, whereas the IPSec tunnel matches on the post-NAT address. In the return path, the IPSec packet is processed first, then NAT, and finally the stateful firewall. This order of processing still allows IPSec to match a public address and the stateful firewall to match on a private address. You must separately configure the firewall, NAT, and IDS services. The processing of packets becomes much more complicated when IPSec over GRE is implemented in the router with other services turned on. This behavior occurs because Junos OS treats GRE packets in a unique fashion after GRE encapsulation. After a packet is encapsulated in a GRE packet, it is marked with an input interface as the next-hop outgoing interface. This method of marking causes GRE packets to be blocked if any input filters or input services are that do not allow for this service.

    Junos OS services support a limited set of IDS rules to help detect attacks such as port scanning and anomalies in traffic patterns. It also supports some attack prevention by limiting the number of flows, sessions, and rates. In addition, it protects against SYN attacks by implementing a SYN cookie mechanism. Because the intrusion detection and prevention (IDP) service does not support higher-layer application signatures, an effective approach against attacks is that protection against a SYN attack can be configured. The IDP solution is largely a monitoring tool and not an essential prevention tool. To prevent a SYN attack, the router will operate as a type of SYN “proxy” and utilizes cookie values. When this feature is turned on, the router responds to the initial SYN packet with a SYN-ACK packet that contains a unique cookie value in the sequence number field. If the initiator responds with the same cookie in the sequence field, the TCP flow is accepted; if the responder does not respond or if it responds with the wrong cookie, the flow is dropped. To trigger this defense, you must configure a SYN cookie threshold. To enable the SYN cookie defense, an IDS rule action must contain a threshold that indicates when the feature should be enabled and an MSS value to avoid having the router manage segmented fragments when acting as a SYN proxy:

Configuring IDS Rule Sets on an MS-DPC

You can use rule-set statement to define a collection of IDS rules that determine what actions the router software performs on packets in the data stream. This is supported on the MS-DPC multiservices card. (To configure network attack protection with an MS-MPC, see Configuring Protection Against Network Attacks on an MS-MPC.)

You define each rule by specifying a rule name and configuring terms. Then, you specify the order of the rules by including the rule-set statement at the [edit services ids] hierarchy level with a rule statement for each rule:

The router software processes the rules in the order in which you specify them in the configuration. If a term in a rule matches the packet, the router performs the corresponding action and the rule processing stops. If no term in a rule matches the packet, processing continues to the next rule in the rule set. If none of the rules matches the packet, the packet is dropped by default.

Examples: Configuring IDS Rules on an MS-DPC

The following configuration adds a permanent entry to the IDS anomaly table when it encounters a flow with the destination address 10.410.6.2. This example is supported on the MS-DPC multiservices card. (To configure network attack protection with an MS-MPC, see Configuring Protection Against Network Attacks on an MS-MPC.)

The IDS configuration works in conjunction with the stateful firewall mechanism and relies heavily on the anomalies reported by the stateful firewall. The following configuration example shows this relationship:

The stateful firewall or NAT service is used to generate the input data for the IDS application. When you enable and configure an IDS service, you must also enable stateful firewall with at least one rule (accept or discard all traffic). When the system is under an attack, the stateful firewall sends the correct and complete list of attack events to the IDS system. In your network environment, you can ensure that the system is wholly protected against a whole range of attacks so that the IDS system reports all such attacks. You must exercise caution when you configure the system to be protected from all attacks and unauthenticated access scenarios so that the traffic bandwidth that the system handles is not burdened. It is also important to verify the correlation between the firewall syslog messages corresponding to the attacks and IDS tables. The IDS tables must have the same or slightly less number of anomalies or errors compared to the firewall-based syslog messages. You can use the appropriate show commands are used to display the IDS tables.

A default stateful firewall rule can be as simple as only allowing connection initiation from the inside interface to the outside interface and discarding all other packets. However, in a real-word network environment, rules are generally more complex, such as configuring only a certain tributary unit ports are to be opened, using application layer gateways (ALGs) for complicated protocols, and using NAT for both outgoing connections and inside hosts such as HTTP servers. Therefore, it is necessary to also configure the system as needed to interwork with simple and complicated rules. For example, if a SYN attack is directed towards an inside address that is simply discarded, no anomalies need to be reported to the IDS system. But if the SYN attack is directed towards the real HTTP server, anomalies must be reported. The IDS system can mitigate SYN attacks by using the TCP SYN cookie defense capability. You can enable the SYN cookie protection methodology by setting a threshold for SYNs per second for a given host and also a maximum segment size (MSS). Because the IDS system uses the stateful firewall, a firewall rule must be defined in the service-set. If you do not configure the from statement in a stateful firewall (rule term match condition) at the [edit services service-set service-set-name stateful-firewall-rules rule-name term term-name] hierarchy level, it signifies that all events are placed into the IDS cache.

The following example shows configuration of flow limits: