Configuring IDS Actions
To configure IDS actions, include the
thenstatement at the [edit services ids rulerule-nametermterm-name] hierarchy level:then {aggregation{destination-prefixprefix-value;source-prefixprefix-value;}(force-entry|ignore-entry);logging {syslog;thresholdrate;}session-limit{by-destination{ hold-timeseconds; maximumnumber; packetsnumber; ratenumber; }by-pair{ hold-timeseconds; maximumnumber; packetsnumber; ratenumber; }by-source{ hold-timeseconds; maximumnumber; packetsnumber; ratenumber; } }syn-cookie {mssvalue;thresholdrate;}}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
aggregationstatement at the [edit services ids rulerule-nametermterm-namethen] hierarchy level and specify values forsource-prefixordestination-prefix:aggregation{destination-prefixprefix-value;source-prefixprefix-value;}The value of
source-prefixanddestination-prefixmust be an integer between 1 and 32.
force-entry—The entry is assured a permanent spot in IDS caches 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 theforce-entrystatement to record all traffic from a suspect host, even traffic that would not otherwise be counted.
ignore-entryensures 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-entryorignore-entrystatement at the [edit services ids rulerule-nametermterm-namethen] hierarchy level:(force-entry|ignore-entry);To configure logging, include the
loggingstatement at the [edit services ids rulerule-nametermterm-namethen] hierarchy level:logging {syslog;thresholdrate;}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.
To configure a threshold, include the
session-limitstatement at the [edit services ids rulerule-nametermterm-namethen] hierarchy level:session-limit{by-destination{ hold-timeseconds; maximumnumber; packetsnumber; ratenumber; }by-pair{ hold-timeseconds; maximumnumber; packetsnumber; ratenumber; }by-source{ hold-timeseconds; maximumnumber; packetsnumber; ratenumber; } }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-sourcestatement.- To limit the number of sessions between a pair of IP addresses, subnets, or applications, configure the
by-pairstatement.- To limit the number of incoming sessions to one external public IP address or subnet, configure the
by-destinationstatement.You can configure the following threshold values:
hold-timeseconds—When therateorpacketsmeasurement reaches the threshold value, stop all new flows for the specified number of seconds. Oncehold-timeis in effect, the traffic is blocked for the specified time even if the rate subsides below the specified limit. By default,hold-timehas a value of 0; the range is 0 through 60 seconds.maximumnumber—Maximum number of open sessions per IP address or subnet per application. The range is 1 through 32,767.packetsnumber—Maximum number of packets per second (pps) per IP address or subnet per application. The range is 4 through 2,147,483,647.ratenumber—Maximum number of sessions per second per IP address or subnet per application. The range is 4 through 32,767.If you configure more than one source address at the
[edit services ids rulerule-nametermterm-namefrom]hierarchy level, limits are applied for each source address independently. For example, the following configuration allows 20 connections from each source address, not 20 connections total. The same logic applies todestination-addressandapplicationssettings.[edit services ids rulerule-nametermterm-name]from {source-address10.1.1.1;source-address10.1.1.2;}then {session-limit by-source {maximum 20;}}To configure SYN-cookie values, include the
syn-cookiestatement at the [edit services ids rulerule-nametermterm-namethen] hierarchy level:syn-cookie {mssvalue;thresholdrate;}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.