Description

This document explains how alarms are triggered when packets are dropped because of a policy violation. By default no security alarm is triggered. A policy violation occurs when a packet matches a reject or deny policy.

Symptoms

Security alarms are checked with the following CLI command: 

root>show security alarms detail

If no alarms are configured, the following error is displayed even if traffic gets dropped due to policy violation:

root> show security alarms detail
The security alarm subsystem is not enabled

Solution


A policy violation alarm is generated when the system detects any of the following events:

  • Number of a policy violation by a source network identifier within a specific period

  • Number of a policy violation to a destination network identifier within a specific period

  • Number of a policy violation to an application within a specific period

  • Policy rule or group of violations within a specific period

Here is an example of a security alarm configuration for an alarm to be triggered when the traffic from an unwanted source comes more than twice in a interval of 500 seconds:


security {
alarms {
potential-violation {
policy {
source-ip {
threshold 2;
duration 500;
}
}
}
}
policies {
from-zone untrust to-zone trust {
policy p1 {
match {
source-address ad1;
destination-address ad2;
application any;
}
then {
permit;
}
}
policy test {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
}
}
}

}
zones {
security-zone untrust {
address-book {
address ad1 2.2.2.0/24;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0;
}
}
security-zone trust {
address-book {
address ad2 3.3.3.0/24;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/0.0;
}
}
}
}

As per the above configuration, traffic from zone untrust to trust should be with a source in 2.2.2.0/24 and destination in 3.3.3.0/24, so that the traffic will be permitted by policy p1. As long as this is the situation the security alarms will not be triggered.

When the traffic is coming from zone untrust to trust with a source outside 2.2.2.0/24, such as 6.6.6.1/24, then the traffic will hit the policy test and be denied, triggering a security alarm.

Verification:

The triggered security alarm can be viewed with the following command:

root>show security alarms detail

If the traffic comes from 6.6.6.1/24 to 3.3.3.1/24 comes more than twice in the interval of 500 seconds, a security alarm is triggered.


root>show security alarms detail
Alarm ID : 1
Alarm Type : policy
Time : 2013-08-20 05:51:24 UTC
Message : Source ip 6.6.6.1 policy violation occurred 2 times within 500 seconds
Process : RT_FLOW
Severity : notice

Alarm ID : 2
Alarm Type : policy
Time : 2013-08-20 05:59:44 UTC
Message : Source ip 6.6.6.1 policy violation occurred 2 times within 500 seconds
Process : RT_FLOW
Severity : notice

Alarm ID : 3
Alarm Type : policy
Time : 2013-08-20 06:08:05 UTC
Message : Source ip 6.6.6.1 policy violation occurred 2 times within 500 seconds
Process : RT_FLOW
Severity : notice

Alarm ID : 4
Alarm Type : policy
Time : 2013-08-20 06:16:25 UTC
Message : Source ip 6.6.6.1 policy violation occurred 2 times within 500 seconds
Process : RT_FLOW
Severity : notice

Alarm ID : 5
Alarm Type : policy
Time : 2013-08-20 06:24:45 UTC
Message : Source ip 6.6.6.1 policy violation occurred 2 times within 500 seconds
Process : RT_FLOW
Severity : notice

Output fields Description:

  • Alarm ID - Identification number of the alarm
  • Time - Date and time the alarm was triggered
  • Message - Information about the alarm including alarm type,username,ip address and port number
  • Process - System process
  • Severity - Severity level of the alarm.

Related Information