Preparing SRX branch IDP

The Juniper SRX110h-va has some delicious features. It has been the darling of quite a few posts and whilst I have some free time it will be part of a few more. This post is number two in a small series that will explore the feature rich IDP set. We are going to look at the IDP features that the JUNOS platform is capable of. The first post will handle the install and download of the signature set and the policy templates.

It is important to understand when it comes to Juniper and IDP there are some differences. As many of you are aware, Juniper divide their SRX platforms into two high level functional groups. Branch and Data Center. This allows clear definition of product placement for most cases. In regards to IDP and how it operates this differs a little. There are three modes in which IDP operates.

Integrated Mode performs IDP functions inside the firewall process. Whilst DC SRX’s use a dedicated SPU for this, branch SRX’s leverage the NPU. This is the default mode for all platforms and the only mode for my SRX110.

Inline taps are supported on Data Center SRXs only. This mode separates the firewall and IDP processes. This mode enables the firewall process to send a copy of the traffic to the IDP process. The firewall process acts independently and will not be interrupted by the IDS. There is a possibility that traffic may be forwarded before detected.

The final mode is Dedicated mode. Supported only on Data Center SRX’s, this mode separates the functions as previously discussed. How this mode operates is that it takes marked traffic from the firewall and punts it to the IDP process. This is then run through a signature set then passed back to the firewall process if successful.

Licensing is required to download daily from Juniper. These downloads include current attack objects, policy templates, and a peace of mind. The piece of mind comes from daily updates to the signature database and attack object groups. These groups are predefined templates for deployment in various areas of the network. They provide a proven and tried groupings of signatures that affect common services. Some examples of these groupings are DNS, DMZ, or WEB Services. Talk to your Juniper SE about pricing but I have been told the price sits under 400 USD annually for the subscription for the SRX110. After this little series and what we will learn, I believe it to be a well priced feature.

The hierarchy of the IDP structure is important to understand. As per objects and object groups with firewalls such as ASA, or application sets in JUNOS, IDP follows the same notion. Attack Objects define a signature or a pattern and can be grouped with other Attack Objects into an Attack Object Group. By detecting protocol anomalies the detector engine can identify deviations in a protocol that can be construed as an attack. Attack Objects can be placed into Attack Object groups which can have static and dynamic entries. Static entries are manually configured into a group. Dynamic entries are automatically added to relevant Attack Object Groups every time an update is received.

The above format is the same for IDP/IPS Rules. Each rule stands alone and can be grouped into IDP/IPS Rule-bases. Rule-bases are created to establish what to do with the traffic. The ips-rule-base contains rules that the IDP engine will use to detect an attack. The other is your white list  This is known as the exempt-rule-base and it will ensure that anything match in such a list will not be processed by the IDP engine.

Prepare the SRX for higher functions.

To begin lets install the licensed package.

[email protected]> request security idp security-package download full-update
Will be processed in async mode. Check the status using the status checking CLI
[email protected]> request security idp security-package download status
 In progress: Downloading ...
[email protected]> request security idp security-package download status
 Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi).
 Version info:2255(Wed Apr 17 18:12:32 2013 UTC, Detector=12.6.160130325)

Alright. Let us now install the downloaded package. This will load the previously downloaded update to our SRX.

[email protected]> request security idp security-package install
 Will be processed in async mode. Check the status using the status checking CLI
[email protected]> request security idp security-package install status
 In progress:Installing AI ...
[email protected]> request security idp security-package install status
 In progress:performing DB update for an xml (SignatureUpdate.xml)

Alright. We have installed our IDP update. Now to download and install our policy-templates. These templates will be applied via an .XSL script and added to the configuration.

[email protected]> request security idp security-package download policy-templates
 Will be processed in async mode. Check the status using the status checking CLI

[email protected]> request security idp security-package install policy-templates
Will be processed in async mode. Check the status using the status checking CLI

[email protected]> request security idp security-package install status
 Done;policy-templates has been successfully updated into internal repository
 (=>/var/db/scripts/commit/templates.xsl)!

Awesome. Now we have installed our entire IDP functionality with the latest update from Juniper. We are getting there. We just need to execute the system script to merge the new configuration in. This is a low impact merge though I would recommend creating a backup or rescue config. I created a rescue configuration before the IDP was installed. This is to ensure I have a fast rollback due to it being my primary home device.

set system scripts commit files template.xsl

Note – can take a long time to commit and this can be worrisome. It took about 90 seconds for this to happen. Now, let us check some of the predefined policy templates. These will let us confirm the well-known policy templates are installed and in fact our script did work correctly.

[email protected]# show security idp idp-policy ?
 Possible completions:
  IDP policy name
 DMZ_Services IDP policy name
 DNS_Service IDP policy name
 File_Server IDP policy name
 Getting_Started IDP policy name
 IDP_Default IDP policy name
 Recommended IDP policy name
 Web_Server IDP policy name

There we go! Happy days. Now we have all our information loaded onto our SRX we can start to think about where we need to inspect and what we want to match and not match. Once you start to piece together how the system works, the hierarchy, and the order of operations you find that it gets easier to work with. Have a think about where you would place yours