IDP Signature Database Overview
Signature-based IDP monitors packets in the Network and compares with pre-configured and pre-determined attack patterns known as signatures.
For more information, see the following topics:
Understanding the IDP Signature Database
The signature database is one of the major components of Intrusion Detection and Prevention (IDP). It contains definitions of different objects—such as attack objects, application signatures objects, and service objects—that are used in defining IDP policy rules. As a response to new vulnerabilities, Juniper Networks periodically provides a file containing attack database updates on the Juniper website. You can download this file to protect your network from new threats.
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.
The IDP signature database is stored on the IDP enabled device and contains definitions of predefined attack objects and groups. These attack objects and groups are designed to detect known attack patterns and protocol anomalies within the network traffic. You can configure attack objects and groups as match conditions in IDP policy rules.
You must install the IDP signature-database-update license key on your device for downloading and installing daily signature database updates provided by Juniper Networks. The IDP signature license key does not provide grace period support. For license details, see Junos OS Feature License Keys.
Starting in Junos OS Release 18.3R1, you can download IDP security package through an explicit proxy server. To download the IDP security package that hosts on an external server, you need to configure a proxy profile and use the proxy host and port details that are configured in the proxy profile. This feature allows you to use a deployed Web proxy server on your device for access and authentication for HTTP(S) outbound sessions for your overall security solution.
You can perform the following tasks to manage the IDP signature database:
Update the signature database—Download the attack database updates available on the Juniper Networks website. New attacks are discovered daily, so it is important to keep your signature database up to date.
Verify the signature database version—Each signature database has a different version number with the latest database having the highest number. You can use the CLI to display the signature database version number.
Update the protocol detector engine—You can download the protocol detector engine updates along with downloading the signature database. The IDP protocol detector contains Application Layer protocol decoders. The detector is coupled with the IDP policy and is updated together. It is always needed at policy update time, even if there is no change in the detector.
Schedule signature database updates—You can configure the IDP-enabled device to automatically update the signature database after a set interval.
Updating the IDP Signature Database Overview
Juniper Networks regularly updates the predefined attack database and makes it available on the Juniper Networks website. This database includes attack object groups that you can use in IDP policies to match traffic against known attacks. Although you cannot create, edit, or delete predefined attack objects, you can use the CLI to update the list of attack objects that you can use in IDP policies.
To update the signature database, you download a security package from the Juniper Networks website or through an explicit Web proxy server. The security package consists of the following IDP components:
Attack objects
Attack object groups
Application objects
Updates to the IDP Detector Engine
IDP Policy templates. Policy templates are downloaded independently. See Understanding Predefined IDP Policy Templates.)
By default, when you download the security package, you download
the following components into a Staging folder in your device: the
latest version of the complete attack object groups table, application
objects table, and the updates to the IDP Detector Engine. Because
the attack objects table is typically of a large size, by default
the system downloads only updates to the attack objects table. However,
you can download the complete attack objects table by using the full-update
configuration option.
After downloading the security package, you must install the package to update the security database with the newly downloaded updates from the Staging folder in your device.
After installing a security package, when you commit the configuration, all policies are checked for their syntax (not only the active policy). This checking is the same as a commit check. If an attack configured in any of the existing policies is removed from the new signature database that you download, the commit check fails.
When you update the IDP signature database, attacks configured
in policies are not updated automatically. For example, suppose you
configure a policy to include an attack FTP:USER:ROOT
that
is available in the signature database version 1200 on your system.
Then, you download signature database version 1201, which no longer
includes the attack FTP:USER:ROOT
. Because an attack configured
in your policy is missing from the newly downloaded database, the
commit check in the CLI fails. To successfully commit your configuration,
you must remove the attack (FTP:USER:ROOT
) from your policy
configuration.
IDP signature updates might fail if a new IDP policy load fails for any reason. When a new IDP policy load fails, the last known good IDP policy is loaded. Once the issue with the new policy load is resolved, and the new valid policy is active, signature updates will work properly.
IDP Signature Package Improvements
We’ve made enhancements to reduce the outage risks and to control the effect of integrity issues during security package updates.
IDP signals AppID to install the applications package when the security package is installed. After the AppID package is installed, the IDP security package is installed in the following sequence:
The attack database is created using the signatures that are downloaded.
The configured policy is updated with the information in the newly installed database.
The updated policy is loaded onto the Packet Forwarding Engine.
The traffic is inspected using the newly loaded policy in the Packet Forwarding Engine.
Service outage does not occur when a problem or core dump happens in steps 1 to 3. A service outage is caused if a core dump occurs while inspecting traffic.
Similarly, rolling back of the security package is not required if the problem occurs while the attack database is being created or while the configured policy is being updated. However, when a problem occurs while loading the updated policy or while traffic is being inspected, the roll back process is triggered. A signature package fails the integrity check if there is any disconnection from the Packet Forwarding Engine or the flow process (flowd) based on predefined criteria.
With the enhancements, the signature package is rolled back automatically when the security package installation is not successful. This can occur when a package that failed the integrity check is detected or due to low memory.
If a signature package is not installed when memory is low, the signature package is not marked as failing the integrity check and roll back is triggered only for IDP.
If auto-rollback is triggered after a new signature pack installation fails, the installed version and manual rollback version is unchanged.
The following are the roll back scenarios when the security package installations fail:
Security Package Installation |
Description |
---|---|
Security package installation on a factory state device |
Roll back database does not exist. If installation fails or if a package that failed integrity check is detected, there is no roll back. If the installation is successful, a new rollback database is created. |
Security package installation on a non-factory-state device |
If the installation fails in the Routing Engine, no roll back is done. The Packet Forwarding Engine inspects traffic using the policy that is already loaded. If the signature package is determined to be a package that failed the integrity check after loading to the Packet Forwarding Engine, then the roll back process is triggered, and the Packet Forwarding Engine has the security package that is installed previously. |
A new status message is displayed when auto-rollback is triggered. You can check the message using the following command:
root@host> request security idp security-package install status
Security-package validation failed, triggered auto rollback of the security-package.
IDP is rolled back if a signature package is found to be a package that failed the integrity check. IDP sends a signal to AppID to roll back, but IDP does not wait for the AppID rollback status.
You can check the status of the roll back using the following command:
root@host> request security idp security-package rollback status
The status of the roll back is displayed as auto-rollback failed or completed successfully. The rolled back version is displayed.
You can use the following command to check the details of the signature pack that failed during data plane validation.
root@host> show security idp security-package-version detail
Attack database version:3550(Thu Dec 1 14:20:50 2022 UTC) Detector version :12.6.180220128 Policy template version :3598 Rollback Attack database version :3550(Thu Dec 1 14:20:50 2022 UTC) Rollback Detector version: 12.6.180220128 Last known security-package-version which failed in data plane validation: 3650(Thu Nov 9 14:08:04 2023 UTC) Last known security-package- detector-version which failed in data plane validation : 12.6.180230313
Rollback in a Multi-SPC/PIC SRX Series Firewall
Currently, when a security package is installed on a multi-SPC or multi-PIC device such as an SRX5000 Series Firewall, the security package is installed and loaded on all the PICs simultaneously. If the data plane goes down on one PIC, the chassis process (chassisd) ensures that all the other PICs go offline. Installing the signature pack on one PIC at a time does not work. Also, when the PICs come back online, they face the same traffic and data plane issues, which might lead to repeated outages.
When a core dump is caused after a signature pack is installed, the security package is rolled back once the PIC comes back online, thus limiting the potential damage.
A new status message is added in the status command output after the security package is installed and the policy is loaded to the Packet Forwarding Engine, while being validated for integrity check of the signature package.
root@host> request security idp security-package install status
Security-package validation is in progress…
Security Package Installation in a High Availability Environment
In a High Availability scenario, the security package installation is triggered on the primary and secondary nodes simultaneously. When the srxpfe process fails due to a problem in the security package, a failover occurs, and the secondary node takes over.
To avoid failovers happening in a loop as the same security package is installed on the secondary node, the integrity check validation is done at the primary node installation stage. The security package is installed on the secondary node only after the package passes the integrity check. Installation on the secondary node is not allowed until you download another version of the signature package.
root@host> request security idp security-package install status
node0: -------------------------------------------------------------------------- In progress:performing DB update for an xml (groups.xml) node1: -------------------------------------------------------------------------- Waiting for primary node to finish installation and validation of the security-package.
During signature package installation, after the install command is run and when integrity check validation is completed, if any failover or switchover occurs, auto-rollback is triggered on the old primary node and installation is aborted on the old secondary node.
root@host> request security idp security-package install status
node0: -------------------------------------------------------------------------- Done;Security-package installation aborted due to node failover node1: -------------------------------------------------------------------------- Done;Security-package installation failed due to node failover;Successfully Rolled back to 3656
If installation fails on the primary node, then rollback occurs on the primary node and installation is aborted on the secondary node.
root@host> request security idp security-package install status
node0: -------------------------------------------------------------------------- Done;Security-package installation failed;Successfully Rolled back to 3550 node1: -------------------------------------------------------------------------- Done;Security-package installation aborted due to failure in the primary node installation
The following changes are observed when the security package is installed on a High Availability device after the enhancements:
Security Package Installation |
Description |
---|---|
Security package installation on both nodes (default) |
The security package installation starts on the primary node. Installation of the signature pack on the secondary node starts only after the signature package integrity validation check is passed on the primary node. Rollback of the signature package is triggered on the primary node if the package fails the integrity check. The package is not installed on the secondary node. If the security package installation fails on the secondary node, rollback is triggered only on the secondary node and a minor alarm is raised as the security package versions do not match. |
Security package installation on primary node only |
If installation fails, then rollback happens only on the primary node. |
The signature package integrity validation check is not performed on the secondary node. A signature package that fails the integrity check at the primary node is also marked failed at the secondary node. A minor alarm is raised when different signature package versions are installed on primary and secondary node.
Disallow Download or Installation of a Package that Failed the Integrity Check
You will not be able to download or install a signature package that failed the integrity check on a standalone or a High Availability setup. A warning is displayed. The signature package that failed the integrity check exists even after rebooting.
If a signature package fails the integrity check for AppID, it is also considered to have failed for IDP.
You can use the following command to verify the status:
root@host> request security idp security-package install status
Done;AI installation failed (failed in data plane validation)
A signature package that is marked as having failed the integrity check at the primary node is also marked as such at the secondary node. When you try to download a security package that has failed the integrity check and you verify the status, the following status message is displayed:
root@host> request security idp security-package download status
Requested security-package 3501 failed data plane validation. Please download another version.
When you try to install a security package that has failed the integrity check and you verify the status, the following message is displayed:
Requested security-package 3501 failed data plane validation. Please install another version.
When you attempt to download the security package that failed the integrity check offline, the same message is displayed.
Rollback of a Signature Package on Loading Last Good Policy after Installation
IDP policies must be compiled when the IDP-policy process restarts when there is a change in configuration requiring compilation, or when a signature pack is installed. After the policy is compiled, the Routing Engine tries to load the policy after taking a backup of the policy that is currently loaded. This policy is named as last-good-policy. If a policy that is just compiled fails to load due to a reason such as memory limitations, then the Routing Engine attempts to load the last good policy.
Thus, when a policy is compiled after installation of a signature pack and the policy loading fails, the Routing Engine tries to load the last good policy. However, after the last good policy is loaded, the Routing Engine and Packet Forwarding Engine have different signature package versions. The signature package in the Routing Engine is rolled back to maintain consistency.
IDP Server-Side Signature Package Improvements
Previously, when you installed an IDP signature package on an SRX Series Firewall and the signature package did not pass integrity checks, the occurrence was noted on the device, but it was not reported to the server.
The Intrusion Detection and Prevention system now reports the installation status to the server. The decision to mark the sigpack as having failed the integrity check globally is based on the information that is sent from multiple devices to the Signature server. If the sigpack is marked as not passing integrity checks globally, it is not available for future downloads.
The signature package consists of IDP signatures, IDP detector, and AppID protobundle. There are two types of signature package updates now on the server side:
Signature Package Update Type | Description |
---|---|
Minor |
Regular sigpack IDP signature updates on Wednesdays and Fridays with no changes in IDP Detector and AppID Protobundle
Emergency sigpacks
Update released as hotfix on a released AppID Protobundle |
Major |
IDP Detector or AppID Protobundle release
|
IDP Detector releases are always classified as major for IDP, and a security package is major for IDP if there is a change in Detector or change in Protobundle. A security package is major for AppID only if there is a change in the Protobundle.
The signature package immediately following a IDP or AppID release is considered as major. If the latest sigpack is identified as not passing integrity checks, the previous sigpack is also marked as failing.
Send Installation Status to Sigpack ServerWhen you install the sigpack on the SRX Series Firewall, the installation status is also sent to the sigpack server. The installation status contains information about the integrity issue checks.
The installation status for a High Availability setup is sent only for the primary node.
When a security package installation fails due to integrity check issues, the installation status is sent to the server after auto-rollback is performed.
Identification of Integrity Check FailureThe device validates for integrity check failure only for major security package types. The device sends the installation status via HTTPS request to the sigpack server after the major type sigpack is installed.
A sigpack is determined to be failing the integrity check based on certain calculations. When a sigpack has failed integrity checks, the previous stable sigpack is marked as the latest sigpack.
If a sigpack passes integrity checks and six hours have elapsed since the sigpack release, the sigpack is released to Security Director and for offline download.
After the sigpack is released to via the various modes, if it is identified as not passing integrity checks, we prevent the downloading of such a sigpack only from the CLI.
You can use the following command to download only minor updates for auto-downloads.
set services
application-identification download automatic minor-only
For manual sigpack updates, you can use the following to request for minor-only update if required.
request security idp security-package download
minor-only
The download status command output indicates whether the downloaded version is major or minor after a sigpack is downloaded successfully.
The sigpack type information is available in the manifest.xml file. The device fetches this information and displays it in the output. The following is an example of an XML manifest file:
<manifest> <version>3655</version> <ExportDate>Tue Nov 28 15:29:28 2023 UTC</ExportDate> <SigpackType>Major</SigpackType> <entry> <id>application_groups.xml.gz</id> <type>systable</type> <version>3655</version> <location>application_groups.xml</location> <checksum>4483d9d4c63fe2fb99725e8218494b44</checksum> <url>https://signatures.juniper.net/xmlupdate/282/ApplicationGroups/3655/application_groups.xml.gz</url> </entry> </manifest>
The following are examples of the output:
user@host> request
security idp security-package download status
Done;Successfully downloaded from(https://signatures.juniper.net/cgi-bin/index.cgi). Version info:3653(Major, Tue Nov 21 14:09:20 2023 UTC, Detector=12.6.180230313)
user@host>
request security idp security-package download
status
Done;Successfully downloaded from(https://signatures.juniper.net/cgi-bin/index.cgi. Version info:3654(Minor, Tue Nov 21 14:09:20 2023 UTC, Detector=12.6.180230313)
When a sigpack is installed successfully, the install status command output indicates whether that installed version is minor or major.
Done;Attack DB update : successful - [UpdateNumber=3653, Major, ExportDate=Tue Nov 21 14:09:20 2023 UTC,Detector=12.6.180230313] Updating control-plane with new detector : successful Updating data-plane with new attack or detector : successful
Done;Attack DB update : successful - [UpdateNumber=3654, Minor, ExportDate=Tue Nov 21 14:09:20 2023 UTC,Detector=12.6.180230313] Updating control-plane with new detector : successful Updating data-plane with new attack or detector : successful
When a sigpack is installed successfully, the installation status command output indicates whether the installed version is minor or major. This is also indicated for security-package-version, recent-security-package-versions, and check-server outputs.
If a major sigpack is identified as not passing the integrity checks, it is not
displayed in the security-package-version
command output.
For example, the major sigpack 3653 has not passed the integrity checks and it is not displayed in the output.
user@host>show security idp
security-package-versions
Attack database version: 3652 (Minor) Attack database version: 3651 (Minor) Attack database version: 3650 (Minor) Attack database version: 3649 (Minor) Attack database version: 3648 (Minor) Attack database version: 3647 (Minor) Attack database version: 3646 (Minor) Attack database version: 3645 (Minor)
See Also
Downloading the Junos OS IDP Signature Package through an Explicit Proxy Server Overview
Starting in Junos OS Release 18.3R1, you can download IDP security package through an explicit proxy server. To download the IDP security package that hosts on an external server, you need to configure a proxy profile and use the proxy host and port details that are configured in the proxy profile. This feature allows you to use a deployed Web proxy server on your device for access and authentication for HTTP(S) outbound sessions.
You need to configure the proxy profile option of security package
download to connect to the external server through a specified proxy
server. The proxy profile is configured under [edit services
proxy]
hierarchy.
You can configure more than one proxy profile under [edit
services proxy]
hierarchy. IDP can utilize only one proxy profile.
Multiple proxy profiles are not supported for use under IDP simultaneously.
When a proxy profile is configured under [security idp security-package]
hierarchy, the idpd process connects to the proxy host instead of
the signature pack download server. The proxy host then communicates
with the download server and provides the response back to the idpd
process. The idpd process is notified every time there is a change
made at the [edit services proxy]
hierarchy.
You can disable the proxy server for downloading IDP signature package when not required.
To disable the proxy server for IDP signature download use the delete security idp security-package proxy-profile proxy-profile
The IDP Web proxy support is dependent on the proxy profile
configured at the system level. To use the web proxy server for downloading,
you must configure a proxy profile with host and port details of the
proxy server, and apply the proxy profile in the [security idp
security-package]
hierarchy.
Example: Updating the Signature Database Automatically
This example shows how to download signature database updates automatically.
Requirements
Before you begin, configure network interfaces.
Overview
Juniper Networks regularly updates the predefined attack database and makes it available as a security package on the Juniper Networks website. This database includes attack objects and attack object groups that you can use in IDP policies to match traffic against known attacks. You can configure your device to automatically download the signature database updates at specified intervals.
In this example, you download the security package with the complete table of attack objects and attack object groups every 48 hours, starting at 11:59 p.m. on December 10. You also enable an automatic download and update of the security package.
Configuration
Procedure
Step-by-Step Procedure
To download and update the predefined attack objects:
Specify the URL for the security package.
[edit] user@host# set security idp security-package url https://signatures.juniper.net/cgi-bin/index.cgi
Note:By default it will take URL as https://signatures.juniper.net/cgi-bin/index.cgi.
Specify the time and interval value for the download.
[edit] user@host# set security idp security-package automatic interval 48 start-time 2009-12-10.23:59:00
Enable the automatic download and update of the security package.
[edit] user@host# set security idp security-package automatic enable
If you are done configuring the device, commit the configuration.
[edit] user@host# commit
Updating the IDP Signature Database Manually Overview
Juniper Networks regularly updates the predefined attack database and makes it available on the Juniper Networks website. This database includes attack object groups that you can use in Intrusion Detection and Prevention (IDP) policies to match traffic against known attacks. Although you cannot create, edit, or delete predefined attack objects, you can use the CLI to update the list of attack objects that you can use in IDP policies. After downloading the security package, you must install the package to update the security database with the newly downloaded updates from the Staging folder in your device.
Example: Updating the IDP Signature Database Manually
This example shows how to update the IDP signature database manually.
Requirements
Before you begin, configure network interfaces.
Overview
Juniper Networks regularly updates the predefined attack database and makes it available as a security package on the Juniper Networks website. This database includes attack object and attack object groups that you can use in IDP policies to match traffic against known attacks.
In this example, you download the security package with the complete table of attack objects and attack object groups. Once the installation is completed, the attack objects and attack object groups are available in the CLI under the predefined-attack-groups and predefined-attacks configuration statements at the [edit security idp idp-policy] hierarchy level. You create a policy and specify the new policy as the active policy. You also download only the updates that Juniper Networks has recently uploaded and then update the attack database, the running policy, and the detector with these new updates.
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
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 manually download and update the signature database:
Specify the URL for the security package.
[edit] user@host#set security idp security-package url https://signatures.juniper.net/cgi-bin/index.cgi
Note:By default it will take URL as https://signatures.juniper.net/cgi-bin/index.cgi.
Commit the configuration.
[edit] user@host# commit
Switch to operational mode.
[edit] user@host# exit
Download the security package.
user@host>request security idp security-package download full-update
Note:You can perform an offline signature package download on your device. You can download the signature package and copy the package to any common location in the device and download the package offline using the
request security idp security-package offline-download
command.The signature package installation remains the same and will be a full-update always.
Check the security package download status.
user@host>request security idp security-package download status
Update the attack database using the install command.
user@host>request security idp security-package install
Check the attack database update status with the following command (the command output displays information about the downloaded and installed versions of the attack database versions):
user@host>request security idp security-package install status
Switch to configuration mode.
user@host>configure
Create an IDP policy.
[edit ] user@host#edit security idp idp-policy policy1
Associate attack objects or attack object groups with the policy.
[edit security idp idp-policy policy1] user@host#set rulebase-ips rule rule1 match attacks predefined-attack-groups “Response_Critical”
Set action.
[edit security idp idp-policy policy1] user@host#set rulebase-ips rule rule1 then action no-action
Activate the policy.
[edit] user@host#set security idp active-policy policy1
Commit the configuration.
[edit] user@host# commit
After a week, download only the updates that Juniper Networks has recently uploaded.
user@host>request security idp security-package download
Check the security package download status.
user@host>request security idp security-package download status
Update the attack database, the active policy, and the detector with the new changes.
user@host>request security idp security-package install
Check the attack database, the active policy and the detector using install status.
user@host>request security idp security-package install status
Note:It is possible that an attack might be removed from the new version of an attack database. If this attack is used in an existing policy on your device, the installation of the new database will fail. An installation status message identifies the attack that is no longer valid. To update the database successfully, remove all references to the deleted attack from your existing policies and groups, and rerun the install command.
Results
From configuration mode, confirm your configuration
by entering the show security idp
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 idp
idp-policy policy1 {
rulebase-ips {
rule rule1 {
match {
attacks {
predefined-attack-groups Response_Critical;
}
}
then {
action {
no-action;
}
}
}
}
}
If you are done configuring the device, enter commit
from configuration mode.
Example: Downloading and Installing the IDP Security Packages in Chassis Cluster Mode
This example shows how to download and install the IDP signature database to a device operating in chassis cluster mode.
Requirements
Before you begin, set the chassis cluster node ID and cluster ID. See Example: Setting the Node ID and Cluster ID for Security Devices in a Chassis Cluster .
Overview
The security package for Intrusion Detection and Prevention (IDP) contains a database of predefined IDP attack objects and IDP attack object groups that you can use in IDP policies to match traffic against known and unknown attacks. Juniper Networks regularly updates the predefined attack objects and groups with newly discovered attack patterns.
To update the signature database, you must download a security package from the Juniper Networks website. After downloading the security package, you must install the package to update the security database with the newly downloaded updates from the Staging folder in your device.
On all branch SRX Series Firewalls, if your device memory utilization is high on the control plane, loading a large IDP policy might cause the device to run out of memory. This can trigger a system reboot during the IDP security package update.
For more details, see Understanding the IDP Signature Database.
When you download the IDP security package on a device operating in chassis cluster mode, the security package is downloaded to the primary node and then synchronized to the secondary node. This synchronization helps maintain the same version of the security package on both the primary node and the secondary node.
Downloading and Installing the IDP Signature Database
Procedure
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.
Specify the URL for the security package.
[edit] user@host# set security idp security-package url https://signatures.juniper.net/cgi-bin/index.cgi
Switch to operational mode.
[edit] user@host# exit
Download the IDP security package to the primary node (downloads in the var/db/idpd/sec-download folder.
{primary:node0}[edit] user@host> request security idp security-package download
The following message is displayed.
node0: -------------------------------------------------------------------------- Will be processed in async mode. Check the status using the status checking CLI
Check the security package download status.
{primary:node0}[edit] user@host> request security idp security-package download status
On a successful download, the following message is displayed.
node0: -------------------------------------------------------------------------- Done;Successfully downloaded from (https://signatures.juniper.net/cgi-bin/index.cgi) and synchronized to backup. Version info:1871(Mon Mar 7 09:05:30 2011, Detector=11.4.140110223)
Update the attack database using the
install
command.user@host> request security idp security-package install
Check the attack database update status. The command output displays information about the downloaded and installed versions of the attack database.
{primary:node0}[edit] user@host> request security idp security-package install status
node0: -------------------------------------------------------------------------- Done;Attack DB update : successful - [UpdateNumber=2011,ExportDate=Mon Oct 17 15:13:06 2011,Detector=11.6.140110920] Updating control-plane with new detector : successful Updating data-plane with new attack or detector : not performed due to no existing running policy found. node1: -------------------------------------------------------------------------- Done;Attack DB update : successful - [UpdateNumber=2011,ExportDate=Mon Oct 17 15:13:06 2011,Detector=11.6.140110920] Updating control-plane with new detector : successful Updating data-plane with new attack or detector : not performed due to no existing running policy found.
Note:You must download the IDP signature package into the primary node. This way, the security package is synchronized on the secondary node. Attempts to download the signature package to the secondary node will fail.
If you have configured a scheduled download for the security packages, the signature package files are automatically synchronized from the primary node to the backup node.
Downloading the Junos OS IDP Signature Package through an Explicit Proxy Server
This example shows how to create a proxy profile and use it for downloading the IDP signature package through an explicit proxy server.
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,
and then enter commit from configuration
mode.
set services proxy profile test_idp_proxy1 protocol http set services proxy profile test_idp_proxy1 protocol http host 10.209.97.254 set services proxy profile test_idp_proxy1 protocol http port 3128 set security idp security-package proxy-profile test_idp_proxy1 request security idp security-package download full-update
Configuration
Step-by-Step Procedure
Proxy profile for the proxy server is created and then this profile is referred by the idpd process for downloading the IDP signature package through the proxy server.
-
Specify the proxy host IP address.
[edit]
user@host#
set services proxy profile test_idp_proxy1 protocol http host 10.209.97.254 Specify the port number used by the proxy server.
[edit]
user@host#
set services proxy profile test_idp_proxy1 protocol http port 3128Specify the proxy profile that has to be referred for the security package download.
[edit] user@host# set security idp security-package proxy-profile test_idp_proxy1
Commit the configuration.
[edit] user@host# commit
Switch to operational mode.
[edit] user@host# exit
Download the IDP security package.
user@host> request security idp security-package download full-update
Note:The option to perform an offline IDP signature package download and install from the Juniper website is still available. To download and install the IDP signature package offline, run the
request security idp security-package offline-download
CLI command. The installation process remains the same for both download commands.
Requirements
This example uses the following hardware and software components:
This configuration example is tested on SRX Series Firewall with Junos OS Release 18.3R1 or later.
Overview
Juniper Networks regularly updates the predefined attack database and makes it available as a security package on the Juniper Networks Website. This database includes attack object and attack object groups that you can use in IDP policies to match traffic against known attacks.
Starting from Junos OS Release 18.3R1, you can download the IDP signature package using a proxy server. Proxy profile configuration is available only for HTTP connections.
In this example, the SRX Series Firewall downloads and installs the IDP security package, with the complete table of attack objects and attack object groups that is available on an external server, utilizing the proxy profile configured.
Once the installation is complete all the downloaded and installed
IDP attack objects and attack groups are available to be configured
in an IDP policy or policies. These attack objects and attack object
are then utilized in the security rules under the set security
policies from-zone zone-name to-zone zone-name policy policy-name
then permit application-services idp-policy idp-policy-name
hierarchy. You create a policy and specify the new policy
as the active policy. You can download only the updates that Juniper
Networks has recently uploaded and then update the attack database,
the running policy, and the detector with these updates.
To enable downloading the IDP signature package through an explicit proxy server:
Configure a profile with host and port details of the proxy server using the
set services proxy profile
command.Use the
set security idp security-package proxy-profile profile-name
command to connect to the proxy server and download the IDP signature package.
When you download the IDP signature package, the request is sent through the proxy host to the actual server that hosts the signature package. The proxy host then sends the response back from the actual host. The IDP signature package is then received from the Juniper Networks security website https://signatures.juniper.net/cgi-bin/index.cgi.
In this example, you create a proxy profile, and refer the profile when you download the IDP signature package from the external host. Table 3 provides the details of the parameters used in this example.
Parameter |
Name |
---|---|
Profile Name |
test_idp_proxy1 |
IP address of the proxy server |
10.209.97.254 |
Port number of the proxy server |
3128 |
Verification
Verifying IDP Signature Download through Proxy Server
Purpose
Display the details for the IDP signature package download through a proxy server.
Action
From operational mode, enter the show security
idp security-package proxy-profile
command to view IDP specific
proxy details.
Proxy details : Security package proxy profile name :test_idp_proxy1 Protocol used :HTTP Ip address of proxy server :10.209.97.254 Port of proxy server :3128
Meaning
In the output, you can find the IDP specific proxy
profile details in Proxy Profile
and Proxy Address
fields.
Verifying IDP Signature Download Status
Purpose
Check the IDP signature package download status.
Action
Check the security package download status.
From operational mode, enter the request security idp security-package
download status
command.
user@host> request security idp security-package download status
Done;Successfully downloaded from(https://signatures.juniper.net/cgi-bin/index.cgi). Version info:3083(Tue Jul 17 13:23:36 2018 UTC, Detector=12.6.130180509)
Meaning
The output displays the IDP signature package download status.
Understanding the IDP Signature Database Version
New attack objects are added to the signature database server frequently; downloading these updates and installing them on your managed devices regularly ensures that your network is effectively protected against the latest threats. As new attack objects are added to the signature database server, the version number of the database is updated with the latest database version number. Each signature database has a different version number with the latest database having the highest number.
When updating the signature database, the signature database update client connects to the Juniper Networks website and obtains the update using an HTTPS connection. This update—difference between the existing signature database and latest signature database—is calculated based on the version number that is assigned to each signature database. After you download the updates, the updated information is merged with the existing signature database and the version number is set to that of the latest signature database.
See Also
Verifying the IDP Signature Database Version
Purpose
Display the signature database version.
Action
From the operational mode in the CLI, enter show
security idp security-package-version
.
Sample Output
command-name
user@host> show security idp security-package-version Attack database version:31(Wed Apr 16 15:53:46 2008) Detector version :9.1.140080400 Policy template version :N/A
Meaning
The output displays the version numbers for the signature database, protocol detector, and the policy template on the IDP-enabled device. Verify the following information:
Attack database version
—On April 16, 2008, the version of the signature database active on the device is31
.Detector version
—Displays the version number of the IDP protocol detector currently running on the device.Policy template version
—Displays the version of the policy template that is installed in the/var/db/scripts/commit
directory when you run therequest security idp security-package install policy-templates
configuration statement in the CLI.
For a complete description of output, see the show security idp security-package-version description.
See Also
Understanding Snort IPS Signatures
Juniper Networks IDP supports Snort IPS signatures. You can convert the Snort IPS rules into Juniper IDP custom attack signatures using the Juniper Integration of Snort Tool (JIST). These Snort IPS rules help detect malicious attacks.
IDP secures your network by using signatures that help to detect attacks. Snort is an open-source intrusion prevention system (IPS).
Starting in Junos OS Release 21.1R1, Juniper Networks IDP supports Snort IPS signatures. You can convert the Snort IPS rules into Juniper IDP custom attack signatures using the Juniper Integration of Snort Tool (JIST). These Snort IPS rules help detect malicious attacks.
- JIST is included in Junos OS by default. The tool supports Snort version 2 and version 3 rules.
- JIST converts the Snort rules with snort-ids into equivalent custom attack signatures on Junos OS with respective snort-ids as the custom attack names.
- When you run the
request
command with Snort IPS rules, JIST generatesset
commands equivalent to the Snort IPS rules. Use therequest security idp jist-conversion
command to generate theset
commands as CLI output. To load theset
commands, use theload set terminal
statement or copy and paste the commands in the configuration mode, and then commit. You can then configure the existing IDP policy with the converted custom attack signatures. - All the Snort IPS rule files that didn’t get converted are written to /tmp/jist-failed.rules. The error log files generated during the conversion are written to /tmp/jist-error.log.
- To view the jist-package version, use the
show security idp jist-package-version
command.
Benefits of Snort IPS Signatures
- Help detect malicious attacks.