Intrusion Detection and Protection (IDP) also known as Intrusion Prevention System (IPS) is a system for preventing attacks and exploitation. This post will outline some key topics within IDP/IPS and also demonstrate configuration steps needed to start using the IDP/IPS features.
IDP Definitions & Structure
Attack objects are entities that identifies a specific attack. They can identify attacks using two methods, by detecting protocol anomalies and by searching for a specific signature or pattern. Protocol anomalies are classified as activity which takes place outside of the protocol RFC or manufacturer specification. These are hard coded into the detector engine. Signature detection attempts to identify the configured signature pattern in the traffic to identify the attack. Predefined attack objects are managed by Juniper and can be downloaded if the device has valid IDP licensing. Administrators can create custom objects referencing protocol anomalies and specifying custom signature strings. Using custom attack objects can be done without licensing.
Attack Object Groups
Attack object groups contain one or more attack objects. There are two types of attack object groups, static and dynamic. In static attack groups specific attack objects are configured to be in the group. With dynamic attack object groups specific conditions are set for the group and any attack object meeting that condition is added to the group. Dynamic attack object groups are good because new attack objects that are downloaded will automatically be placed in the correct groups without the administrator having to configure them. Predefined attack object groups are managed and offered by Juniper and can be downloaded if the device has a valid IDP license.
Rules are how attack objects and attack object groups are referenced in the IDP policy. Rules contain two statements, match and then. The match statement includes where to look (source/destination zone, source/destination address/prefix or application) and what to look for (attack objects and/or attack object groups). The then statement specifies actions to do if the match statement condition is met. This includes actions to the traffic (ignor, diffserve, drop, close client and/or server, recommended), IP actions (drop/block, notify) and system actions such as logging. The recommended action specifies to use the action configured within the attack object. IP actions set actions for future traffic.
Rulebases are simply collections of rules. Each rulebase will contain one or more rules. Rules are processed in a top-down fashion. There are two rulebases to understand, the ips-rulebase and the exempt-rulebase. The ips-rulebase contains rules for the IDP engine to detect attacks. The exempt-rulebase is similar to a whitelist in that rules can be placed in this list to ensure IDP/IPS actions are not taken.
An IDP policy is a entity consisting of a ips-rulebase and optionally exempt-rulebase. Although multiple IDP policies can be configured, only one IDP policy can be active at any given time. IDP policies are configured as the 'active' policy under the [security idp] stanza.
Referencing an IDP Policy
IDP policies are referenced within security policies (very similar to UTM policies) under the application-services statement.
Licensing is required to download the current attack objects and policy templates. As mentioned earlier, if you plan to use your own custom attack objects exclusively this can be done without licensing.
The IDP module can run in different modes. Only the High End / Data Centre Series SRX can run all three modes. Brach SRX units can only use the default mode which is 'integrated'.
This is the default mode, all SRX units support integrated mode. In this mode IDP processing is done within the firewall process. On branch SRX units this is done within the NPU. On high end / data centre SRX units this is done on the SPU.
Dedicated Mode (only supported on High End / Data Centre Series SRX)
This mode separates firewall and IDP into separate processes. As the two processes are discreet the firewall process hands traffic marked for IDP inspection off to the IDP engine, after inspection this traffic is handed back to the firewall process. The amount of SPU processing power can be set between firewall and IDP processing. This option allows for resources to be allocated to processes for deterministic processing availability. The downside is that if the resources allocations cannot change to dynamic events/needs.
Inline Tap (only supported on High End / Data Centre Series SRX)
This mode has the same separation of firewall and IDP process however the firewall process does not pass the traffic to the IDP process, instead it sends a copy. This allows the firewall process to complete its processing regardless of IDP processing results. This option ensures that IDP process failure or resource issue will not compromise the firewall forwarding. The downside is that traffic may be forwarded prior to an IDP event being detected.
Configuration - Initial Setup
The following steps outline the initial configuration so that the Juniper created attack objects and attack object groups can be created.
1. Install/Confirm License
The command 'show system license usage' will display all installed licenses. The license name needed for IDP/IPS attack objects, attack object groups and policy templates is idp-sig. The screenshot below displays the output.
2. Download Initial Security Package
The command 'request security idp security-package download status' will display the download progress. The screenshot below outlines that the download is still in progress. The screenshot following this one outlines that the download is complete. It also outlines the object and detector versions along with a time stamp.
3. Install Attack Objects
Now that the objects and detector engine updates have been downloaded they can be installed. The command 'request security idp security-package install' will initiate this installation.
The command 'request security idp security-package install status' will display the installation progress. The next three screenshots outlines that the installation is in progress (each informing of a different portion of the installation).
The fourth screenshot outlines that the installation has completed. Note that the output confirms that the the data plane was not updated. This expected as we do not have any IDP configuration running. If we had an active policy installed and running the updates should also be confirmed as installed on the data plane.
4. Verify Attack Objects & Groups
The command below confirms that the predefined attack objects have been installed by using auto completion on an incomplete set command. The output confirms that the objects have been installed. Note that the screenshot below is a portion of the output.
The command below confirms that the predefined attack object groups have been installed by using auto completion on an incomplete set command. The output confirms that the objects have been installed. Note that the screenshot below is a portion of the output.
5. Download Policy Templates
Policy templates are basically predefined IDP policies. Just like attack objects and attack object groups they can be downloaded from Juniper with a valid IDP license. The command 'request security idp security-package download policy-templates' will initiate the download.
The command 'request security idp security-package download status' can be used to view the progress of the download. The screenshot below confirms that the download is complete and was successful.
6. Install Policy Templates
Installing the policy templates is slightly different than installing attack objects and detector engines. The policy templates file is an xsl file which is basically an XML formatted configuration file. A commit script is used to apply the configuration upon issuing a commit. The command 'request security idp security-package install policy-templates' will initiate the installation, which in this case is really copying the xsl file to the commit scripts folder.
The command 'request security idp security-package install policy-templates status' will show the progress of the installation.
A commit script configuration is configured so that the policy templates are installed when a commit is issued. The screenshot below outlines the command to set the commit script. After this is done a commit can be issued to install the policy templates.
7. Verify IDP Policy Templates
The screenshot below outlines a partial set command using command completion to display the available policy templates. The IDP policies listed in the screenshot below are predefined, this confirms that the commit script installation was successful.
The screenshot below displays the first rule in the predefined IDP policy of Recommended. This was also displayed with a partial set command using command completion.
8. Configure Dynamic Updates
Dynamic updating of the objects and detector engine can be scheduled. The screenshot below outlines a configuration where updates will be checked and if newer than the running will be download every 24 hours starting from November 29th 2012 at midnight.
The next post will be a continuation of the configuration done in this post focusing on configuring an IDP policy.