IDP Policies
The Junos OS Intrusion Detection and Prevention (IDP) policy enables you to selectively enforce various attack detection and prevention techniques on network traffic passing through an IDP-enabled device. It allows you to define policy rules to match a section of traffic based on a zone, network, and application, and then take active or passive preventive actions on that traffic.
For more information, see the following topics:
IDP Policies Overview
An IDP policy defines how your device handles the network traffic. It allows you to enforce various attack detection and prevention techniques on traffic traversing your network.
A policy is made up of rule bases, and each rule base contains a set of rules. You define rule parameters, such as traffic match conditions, action, and logging requirements, then add the rules to rule bases. After you create an IDP Policy by adding rules in one or more rule bases, you can select that policy to be the active policy on your device.
Junos OS allows you to configure and apply multiple IDP policies. Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, validation of configurations is done for the IDP policy that is configured as an active policy. You can install the same IDP policy on multiple devices, or you can install a unique IDP policy on each device in your network. A single policy can contain only one instance of any type of rule base.
The IDP feature is enabled by default. No license is required. Custom attacks and custom attack groups in IDP policies can also be configured and installed even when a valid license and signature database are not installed on the device.
Starting in Junos OS Release 18.4R1, when a new IDP policy is loaded, the existing sessions are inspected using the newly loaded policy and the existing sessions not ignored for IDP processing.
The following list described the IDP inspection changes for the existing sessions after a new policy is loaded:
Packet-based signatures - IDP inspection continues for packet-based attacks with the new IDP policy.
Stream-based signatures - IDP inspection continues for stream-based attacks from the new IDP policy with the end offset number less than the number of bytes passed for that flow.
Context-based signatures - IDP inspection continues for context-based attacks created by the detector after a new IDP policy is loaded, with an exception that the new policy that is loaded with the new detector.
The following IDP policies are supported:
DMZ_Services
DNS_Services
File_Server
Getting_Started
IDP_Default
Recommended
Web_Server
You can perform the following tasks to manage IDP policies:
Create new IDP policies starting from scratch. See Example: Defining Rules for an IDP IPS RuleBase.
Create an IDP policy starting with one of the predefined templates provided by Juniper Networks (see Understanding Predefined IDP Policy Templates).
Add or delete rules within a rule base. You can use any of the following IDP objects to create rules:
Zone
Note:You can configure source-address and source-except addresses when from-zone is any, and similarly to have destination-address and destination-except addresses when to-zone is any.
Network objects available in the base system
Predefined service objects provided by Juniper Networks
Custom application objects
Predefined attack objects provided by Juniper Networks
Create custom attack objects (see Example: Configuring IDP Signature-Based Attacks ).
Update the signature database provided by Juniper Networks. This database contains all predefined objects.
Maintain multiple IDP policies. Any one of the policies can be applied to the device.
The IDP policies for each user logical system are compiled together and stored on the data plane memory. To estimate adequate data plane memory for a configuration, consider these two factors:
IDP policies applied to each user logical system are considered unique instances because the ID and zones for each user logical system are different. Estimates need to consider the combined memory requirements for all user logical systems.
As the application database increases, compiled policies requires more memory. Memory usage should be kept below the available data plane memory to allow for database increases.
See Also
Understanding IDP Policy Support for Unified Policies
With the support of IDP policy within unified security policy:
IDP policy is activated using the
set security policies from-zone <zone-name> to-zone <zone-name> policy <policy-name> then permit application-services idp-policy <idp-policy-name>command.With the IDP policy being made available within the unified security policy all the IDP matches will be handled within the unified policy unless explicit source, destination, or application is defined (traditional policy).
You can additionally configure match conditions in IDP to achieve additional inspection granularity.
Configuring source or destination address, source and destination-except, from and to zone, or application is not required with unified policy, as the match happens in the security policy itself.
Layer 7 application might get changed during a session lifetime and this application change might lead to disabling of IDP service for the session.
Initial security policy match might result in single or multiple policy matches. As a part of session interest check IDP will be enabled if IDP policy is present in any of the matched rules.
If you have configured a traditional security policy (with 5-tuples matching condition or dynamic-application configured as none) and an unified policy (with 6-tuple matching condition), the traditional security policy matches the traffic first, prior to the unified policy.
When you configure a unified policy with a dynamic application as one of the matching condition, the configuration eliminates the additional steps involved in IDP policy configuration. All the IDP policy configurations are handled within the unified security policy and simplifies the task of configuring IDP policy to detect any attack or intrusions for a given session.
Understanding Multiple IDP Policies for Unified Policies
When security devices are configured with unified policies, you can configure multiple IDP policies and set one of those policies as the default IDP policy
If multiple IDP policies are configured for a session and when policy conflict occurs, the device applies the default IDP policy for that session and thus resolves any policy conflicts.
If you have configured two or more IDP policies in a unified security policy, then you must configure the default IDP policy.
To configure the IDP policy as the default policy, use the set security idp default-policy policy-name command.
The initial security policy lookup phase, which occurs prior to a dynamic application being identified, might result in multiple potential policy matches. IDP is enabled on the session if at least one of the matched security policies have an IDP policy configured.
If only one IDP policy is configured in the potential policy list, then that IDP policy is applied for the session.
If there are multiple IDP policies configured for a session in the potential policy list, then the device applies the IDP policy that is configured as default the IDP policy.
After dynamic applications are identified for a session, if the final matched policy has IDP polices configured that are different from the default IDP policy, then policy relookup is performed, and the IDP policy configured for the final matched policy is applied.
If the final matched security policy has the same IDP policy that was configured during the initial security policy lookup, then that IDP policy is applied for the session.
If the final matched security policy does not have an IDP policy configured, then IDP processing is disabled for the session.
Benefits of Multiple IDP Policies and Default IDP Policy Configuration for Unified Policies
Provides the flexibility to maintain and use multiple IDP policies.
Handles policy conflicts using the default IDP policy configuration.
IDP Policy Selection for Unified Policies
This topic provides details on IDP policy selection for unified policies.
IDP Policy Selection with a Single IDP Policy
When a security policy is processed for a session, initial security policy match might result in single or multiple policy matches. If application cache is present, policy match will result in single policy match.
As a part of the session interest check, IDP is enabled if an IDP policy is present in any of the matched rules.
After dynamic application identification is performed, policy relookup is performed by the security policy. Layer 7 application services (IDP) are informed to disable themselves, if IDP is not configured on the final matched policy. With the IDP policy being made available within the unified security policy, all the IDP matches are handled within the unified policy unless explicit source, destination, or application is defined (traditional policy). Configuring source or destination address, source and destination-except, from and to zone, or application is not required with unified policy, because the match happens in the security policy itself. Table 1 provides example of IDP policy selection within a security policy.
Figure 1 and Figure 2 provide the workflow details for single and multiple IDP policy selection for unified policies.
| Security Policy | Source Zone | Source Address | Destination Zone | Destination Address | Dynamic Application | Application service | Policies |
|---|---|---|---|---|---|---|---|
P1 |
In |
10.1.1.1 |
Out |
Any |
HTTP |
IDP |
Recommended |
P2 |
In |
10.1.1.1 |
Out |
Any |
GMAIL |
UTM |
utm_policy_1 |
IDP Policy Selection with Multiple IDP Policies
If there are multiple policies present in the potential policy list with different IDP policies, then the device applies the IDP policy that is configured as default IDP policy.
After dynamic applications are identified, if the final matched policy has IDP polices configured that are different from the default IDP policy, then policy re-lookup is performed, and the IDP policy configured for the final matched policy is applied.
If the final matched security policy does not have an IDP policy configured, then IDP processing is disabled for the session.
| Policy | Source Zone | Source Address | Destination Zone | Destination Address | Dynamic Application | Application service | Policies |
|---|---|---|---|---|---|---|---|
P1 |
In |
10.1.1.1 |
Out |
Any |
HTTP |
IDP |
recommended |
P2 |
In |
10.1.1.1 |
Out |
Any |
GMAIL |
UTM |
utm_policy_1 |
P3 |
In |
any |
Out |
Any |
GMAIL |
IDP |
idpengine |
Considering the example security policies configured for a session:
If security policy P1 and policy P3 match for a session
IDP Policy conflict is observed. So, the IDP policy that is configured as default IDP policy is applied in this case.
After the final security policy match, IDP policy re-lookup is performed based on matched IDP policies. If the final matched security policy is policy P1, then IDP policy which is named recommended is applied for the session.
If security policy P1 and policy P2 match for a session
Since there is only one IDP policy configured in the matched security policies, IDP policy which is named recommended is applied for the session.
If the final matched security policy is policy P1 then the session inspection continues to apply IDP policy named recommended. If the final matched security policy is policy P2 then IDP is disabled and ignores the session.
Example: Configuring Multiple IDP Policies and a Default IDP Policy for Unified Security Policies
For transit traffic to pass through IDP inspection, you configure a security policy and enable IDP application services on all traffic that you want to inspect.
This example shows how to configure a security policy to enable IDP services for the first time on traffic flowing on the device.
Requirements
Before you begin, install or verify an IDP feature license.
This example uses the following hardware and software components:
An SRX Series Firewall.
Junos OS Release 18.3R1 and later.
This configuration example was tested using an SRX1500 device running Junos OS Release 18.3R1. However, you can use the same configuration on SRX300 line, SRX550M, SRX4100, SRX4200, and SRX5000 line devices using the latest releases of Junos OS.
Overview
In this example, you configure two security policies to enable IDP services on an SRX1500 device to inspect all traffic from the trust zone to the untrust zone.
As a first step, you must download and install the signature database from the Juniper Networks website. Next, download and install the predefined IDP policy templates and activate the predefined policy “Recommended” as the active policy.
In SRX 18.2 below version, only one IDP policy name can be used for all firewall rules and active-policy works in all security director versions.
As of Junos SRX 18.2, the traditional policy style of using
only one active IDP policy name for all firewall rules via set
security idp active-policy has been deprecated.
Instead the configuration style uses the same for Traditional
Policies as that of Unified policies by referring to IDP policy is
handled in the security policies set security policies from-zone
<zone-name> to-zone <zone-name> policy <policy-name> then
permit application-services idp-policy idp-policy-name command.
Next, you must create two security policies from the trust zone to the untrust zone and specify actions to be taken on the traffic that matches the conditions specified in the policies.
Configuration
Procedure
CLI Quick Configuration
CLI quick configuration is not available for this example, because manual intervention is required during the configuration.
Step-by-Step Procedure
Create two security policies for the traffic from the trust zone to the untrust zone.
Note:Please note the following points:
-
The order of the security policies on the SRX Series Firewall is important because Junos OS performs a policy lookup starting from the top of the list, and when the device finds a match for the traffic received, it stops policy lookup.
-
The SRX Series Firewall allows you to enable IDP processing on a security policy on a rule-by-rule basis, instead of turning on IDP inspection across the device.
A security policy identifies what traffic is to be sent to the IDP engine, and then the IDP engine applies inspection based on the contents of that traffic. Traffic that matches a security policy in which IDP is not enabled completely bypasses IDP processing. Traffic that matches a security policy marked for IDP processing enables the IDP policy that is configured in that particular security policy.
Create a security policy P1 with a dynamic application as the match criteria.
[edit security policies] user@host# set from-zone trust to-zone untrust policy P1 match source-address any user@host# set from-zone trust to-zone untrust policy P1 match destination-address any user@host# set from-zone trust to-zone untrust policy P1 match application junos-defaults user@host# set from-zone trust to-zone untrust policy P1 match dynamic-application junos:HTTP
Create a security policy P2 with a dynamic application as the match criteria.
[edit security policies] user@host# set from-zone trust to-zone untrust policy P2 match source-address any user@host# set from-zone trust to-zone untrust policy P2 match destination-address any user@host# set from-zone trust to-zone untrust policy P2 match application junos-defaults user@host# set from-zone trust to-zone untrust policy P2 match dynamic-application junos:GMAIL
-
Define the IDP policies that you want to configure in security policies.
[edit] user@host# set security idp idp-policy recommended user@host# set security idp idp-policy idpengine
Configure the IDP policies as per steps in IDP Policy Rules and IDP Rule Bases, then configure one of the IDP policies (Recommended) as the default IDP policy.
[edit]user@host# set security idp default-policy recommendedConfirm the default policy configured on your device.
[edit]user@host# show security idp default-policydefault-policy recommended;
Specify the action to be taken on traffic that matches conditions specified in the security policy. The security policy action must be to permit the flow.
[edit security policies] user@host# set from-zone trust to-zone untrust policy P1 then permit application-services idp-policy recommended user@host# set from-zone trust to-zone untrust policy P2 then permit application-services idp-policy idpengine
In SRX 18.3 versions and above, security policies may use different a different IDP policy allowing unique IDP rules processing for each security-policy. When multiple IDP rules are used on security policies an IDP default-policy is required to be configured.
Results
From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]
user@host# show security policies
from-zone trust to-zone untrust {
policy P1 {
match {
source-address any;
destination-address any;
application junos-http;
}
then {
permit {
application-services {
idp-policy recommended;
}
}
}
}
}
from-zone trust to-zone untrust {
policy P2 {
match {
source-address any;
destination-address any;
application junos : GMAIL;
}
then {
permit {
application-services {
idp-policy idpengine;
}
}
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Verifying the IDP Configuration
Purpose
Verify that the IDP configuration is working properly.
Action
From operational mode, enter the show security
idp status command.
user@host> show security idp status detail
PIC : FPC 0 PIC 0:
State of IDP: Default, Up since: 2013-01-22 02:51:15 GMT-8 (2w0d 20:30 ago)
Packets/second: 0 Peak: 0 @ 2013-02-05 23:06:20 GMT-8
KBits/second : 0 Peak: 0 @ 2013-02-05 23:06:20 GMT-8
Latency (microseconds): [min: 0] [max: 0] [avg: 0]
Packet Statistics:
[ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0]
Flow Statistics:
ICMP: [Current: 0] [Max: 0 @ 2013-02-05 23:06:20 GMT-8]
TCP: [Current: 0] [Max: 0 @ 2013-02-05 23:06:20 GMT-8]
UDP: [Current: 0] [Max: 0 @ 2013-02-05 23:06:20 GMT-8]
Other: [Current: 0] [Max: 0 @ 2013-02-05 23:06:20 GMT-8]
Session Statistics:
[ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0]
ID Name Sessions Memory Detector
0 Recommended 0 2233 12.6.160121210
Meaning
The sample output shows the Recommended predefined IDP policy as the active policy.
Example: Enabling IDP in a Traditional Security Policy
As of Junos SRX 18.2, the traditional policy
style of using only one active IDP policy name for all firewall rules
via set security idp active-policy has been deprecated.
Instead the configuration style uses the same for Traditional
Policies as that of Unified policies by referring to IDP policy is
handled in the security policies set security policies from-zone
<zone-name> to-zone <zone-name> policy <policy-name> then
permit application-services idp-policy idp-policy-name command.
This example shows how to configure two security policies to enable IDP services on all HTTP and HTTPS traffic flowing in both directions on a security device. This type of configuration can be used to monitor traffic to and from a secure area of an internal network as an added security measure for confidential communications.
In this example, Zone2 is part of the internal
network.
Requirements
Before you begin:
Configure network interfaces.
Create security zones. See Example: Creating Security Zones.
Configure applications. See Example: Configuring IDP Applications and Services.
Configuring IDP Policies. See IDP Policy Rules and IDP Rule Bases.
Overview
For transit traffic to pass through IDP inspection, you configure a security policy and enable IDP application services on all traffic that you want to inspect. Security policies contain rules defining the types of traffic permitted on the network and the way that the traffic is treated inside the network. Enabling IDP in a security policy directs traffic that matches the specified criteria to be checked against the IDP rulebases.
IDP is enabled by default. No license is required. Custom attacks and custom attack groups in IDP policies can be configured and installed even when a valid license and signature database are not installed on the device.
To allow transit traffic to pass through without IDP inspection, specify a permit action for the rule without enabling the IDP application services. Traffic matching the conditions in this rule passes through the device without IDP inspection.
This example shows how to configure two policies, idp-app-policy-1 and idp-app-policy-2, to enable IDP services on all HTTP and HTTPS traffic flowing in both directions on the device. The idp-app-policy-1 policy directs all HTTP and HTTPS traffic flowing from previously configured Zone1 to Zone2 to be checked against IDP rulebases. The idp-app-policy-2 policy directs all HTTP and HTTPS traffic flowing from Zone2 to Zone1 to be checked against IDP rulebases.
The action set in the security policy action must be permit. You cannot enable IDP for traffic that the device denies or rejects.
If you have configured a traditional security policy (with 5-tuples matching condition or dynamic application configured as none) and an unified policy (with 6-tuple matching condition), the traditional security policy matches the traffic first, prior to the unified policy.
When you configure a unified policy with a dynamic application as one of the matching condition, the configuration eliminates the additional steps of configuring, source and destination address, source destination except, from and to zones, or application. All the IDP policy configurations are handled within the unified security policy and simplifies the task of configuring IDP policy to detect any attack or intrusions for a given session. Configuring source or destination address, source and destination-except, from and to zone, or application is not required with unified policy, as the match happens in the security policy itself.
Configuration
Procedure
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match source-address any set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match destination-address any set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match application junos-http set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match application junos-https set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 then permit application-services idp set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match source-address any set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match destination-address any set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match application junos-http set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match application junos-https set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 then permit application-services idp
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To enable IDP services on all HTTP and HTTPS traffic flowing in both directions on the device:
Create a security policy for traffic flowing from Zone1 to Zone2 that has been identified as junos-http or junos-https application traffic.
user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match source-address any user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match destination-address any user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match application junos-http user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match application junos-https
Specify the action to be taken on Zone1 to Zone2 traffic that matches conditions specified in the policy.
user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 then permit application-services idp
Create another security policy for traffic flowing in the opposite direction that has been identified as junos-http or junos-https application traffic.
user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match source-address any user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match destination-address any user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match application junos-http user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match application junos-https
Specify the action to be taken on traffic that matches the conditions specified in this policy.
user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 then permit application-services idp
Configure the active-policy.
user@host# set security idp active-policy recommended
Results
From configuration mode, confirm your configuration
by entering the show security policies command. If the
output does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@host# show security policies
from-zone Zone1 to-zone Zone2 {
policy idp-app-policy-1 {
match {
source-address any;
destination-address any;
application [junos-http junos-https];
}
then {
permit {
application-services {
idp;
}
}
}
}
}
from-zone Zone2 to-zone Zone1 {
policy idp-app-policy-2 {
match {
source-address any;
destination-address any;
application [junos-http junos-https];
}
then {
permit {
application-services {
idp;
}
}
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verifying the IDP Policy Compilation and Load Status
Purpose
Display the IDP log files to verify the IDP policy load and compilation status. When activating an IDP policy, you can view the IDP logs and verify if the policy is loaded and compiled successfully.
Action
To track the load and compilation progress of an IDP policy, configure either one or both of the following in the CLI:
You can configure a log file, which will be located in
/var/log/, and set trace option flags to record these operations:user@host# set security idp traceoptions file idpd user@host# set security idp traceoptions flag all
You can configure your device to log system log messages to a file in the
/var/logdirectory:user@host# set system syslog file messages any any
After committing the configuration in the CLI, enter either of the following commands from the shell prompt in the UNIX-level shell:
Sample Output
command-name
user@host> start shell user@host% tail -f /var/log/idpd Aug 3 15:46:42 chiron clear-log[2655]: logfile cleared Aug 3 15:47:12 idpd_config_read: called: check: 0 Aug 3 15:47:12 idpd commit in progres ... Aug 3 15:47:13 Entering enable processing. Aug 3 15:47:13 Enable value (default) Aug 3 15:47:13 IDP processing default. Aug 3 15:47:13 idp config knob set to (2) Aug 3 15:47:13 Warning: active policy configured but no application package installed, attack may not be detected! Aug 3 15:47:13 idpd_need_policy_compile:480 Active policy path /var/db/idpd/sets/idpengine.set Aug 3 15:47:13 Active Policy (idpengine) rule base configuration is changed so need to recompile active policy Aug 3 15:47:13 Compiling policy idpengine.... Aug 3 15:47:13 Apply policy configuration, policy ops bitmask = 41 Aug 3 15:47:13 Starting policy(idpengine) compile with compress dfa... Aug 3 15:47:35 policy compilation memory estimate: 82040 Aug 3 15:47:35 ...Passed Aug 3 15:47:35 Starting policy package... Aug 3 15:47:36 ...Policy Packaging Passed Aug 3 15:47:36 [get_secupdate_cb_status] state = 0x1 Aug 3 15:47:36 idpd_policy_apply_config idpd_policy_set_config() Aug 3 15:47:36 Reading sensor config... Aug 3 15:47:36 sensor/idp node does not exist, apply defaults Aug 3 15:47:36 sensor conf saved Aug 3 15:47:36 idpd_dev_add_ipc_connection called... Aug 3 15:47:36 idpd_dev_add_ipc_connection: done. Aug 3 15:47:36 idpd_policy_apply_config: IDP state (2) being set Aug 3 15:47:36 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:36 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:36 Apply policy configuration, policy ops bitmask = 4 Aug 3 15:47:36 Starting policy load... Aug 3 15:47:36 Loading policy(/var/db/idpd/bins/idpengine.bin.gz.v + /var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v + /var/db/idpd/bins/compressed_ai.bin)... Aug 3 15:47:36 idpd_dev_add_ipc_connection called... Aug 3 15:47:36 idpd_dev_add_ipc_connection: done. Aug 3 15:47:37 idpd_policy_load: creating temp tar directory '/var/db/idpd//bins/52b58e5' Aug 3 15:47:37 sc_policy_unpack_tgz: running addver cmd '/usr/bin/addver -r /var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v /var/db/idpd//bins/52b58e5/__temp.tgz > /var/log/idpd.addver' Aug 3 15:47:38 sc_policy_unpack_tgz: running tar cmd '/usr/bin/tar -C /var/db/idpd//bins/52b58e5 -xzf /var/db/idpd//bins/52b58e5/__temp.tgz' Aug 3 15:47:40 idpd_policy_load: running cp cmd 'cp /var/db/idpd//bins/52b58e5/detector4.so /var/db/idpd//bins/detector.so' Aug 3 15:47:43 idpd_policy_load: running chmod cmd 'chmod 755 /var/db/idpd//bins/detector.so' Aug 3 15:47:44 idpd_policy_load: running rm cmd 'rm -fr /var/db/idpd//bins/52b58e5' Aug 3 15:47:45 idpd_policy_load: detector version: 10.3.160100209 Aug 3 15:47:45 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:45 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:45 idp_policy_loader_command: sc_klibs_subs_policy_pre_compile() returned 0 (EOK) Aug 3 15:47:45 idpd_policy_load: IDP_LOADER_POLICY_PRE_COMPILE returned EAGAIN, retrying... after (5) secs Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idp_policy_loader_command: sc_klibs_subs_policy_pre_compile() returned 0 (EOK) Aug 3 15:47:50 idpd_policy_load: idp policy parser pre compile succeeded, after (1) retries Aug 3 15:47:50 idpd_policy_load: policy parser compile subs s0 name /var/db/idpd/bins/idpengine.bin.gz.v.1 buf 0x0 size 0zones 0xee34c7 z_size 136 detector /var/db/idpd//bins/detector.so ai_buf 0x0 ai_size 0 ai /var/db/idpd/bins/compressed_ai.bin Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_policy_load: idp policy parser compile succeeded Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_policy_load: idp policy pre-install succeeded Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_policy_load: idp policy install succeeded Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_policy_load: idp policy post-install succeeded Aug 3 15:47:51 IDP policy[/var/db/idpd/bins/idpengine.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully. Aug 3 15:47:51 Applying sensor configuration Aug 3 15:47:51 idpd_dev_add_ipc_connection called... Aug 3 15:47:51 idpd_dev_add_ipc_connection: done. Aug 3 15:47:51 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:51 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:51 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:51 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:51 ...idpd commit end Aug 3 15:47:51 Returning from commit mode, status = 0. Aug 3 15:47:51 [get_secupdate_cb_status] state = 0x1 Aug 3 15:47:51 Got signal SIGCHLD....
Sample Output
command-name
user@host> start shell user@host% tail -f /var/log/messages Aug 3 15:46:56 chiron mgd[2444]: UI_COMMIT_PROGRESS: Commit operation in progress: no commit script changes Aug 3 15:46:56 chiron mgd[2444]: UI_COMMIT_PROGRESS: Commit operation in progress: no transient commit script changes Aug 3 15:46:56 chiron mgd[2444]: UI_COMMIT_PROGRESS: Commit operation in progress: finished loading commit script changes Aug 3 15:46:56 chiron mgd[2444]: UI_COMMIT_PROGRESS: Commit operation in progress: exporting juniper.conf ..... Aug 3 15:47:51 chiron idpd[2678]: IDP_POLICY_LOAD_SUCCEEDED: IDP policy[/var/db/idpd/bins/idpengine.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully(Regular load). Aug 3 15:47:51 chiron idpd[2678]: IDP_COMMIT_COMPLETED: IDP policy commit is complete. ...... Aug 3 15:47:51 chiron chiron sc_set_flow_max_sessions: max sessions set 16384
Meaning
Displays log messages showing the procedures that run
in the background after you commit the set security idp active-policy command. This sample output shows that the policy compilation, sensor
configuration, and policy load are successful.