Tuesday, 22 January 2013

SRX IPSec VPN - Policy Based

In this post a policy-based IPSec VPN will be configured. This exercise assumes all other device configuration including routing has already be completed. The 192.168.1.0/24 subnet will simulate the internet. The diagram outlines the lab topology.


Configure BRANCH-A SRX
1. Create Phase 1 Proposal
The phase 1 proposal defines authentication and encryption standards to use. JunOS does contain predefined proposals which can be used. They are basic, compatible and standard. In this example we created a custom defined proposal and did not use the predefined options. See the screenshot below for details. 

2. Create Phase 1 Policy
The phase 1 policy defines the VPN mode (which can be main or aggressive), the proposal (the predefined or custom phase 1 proposal), and authentication key (in this case is a password). See the screenshot below for configuration steps.

3. Create Gateway
The gateway defines the remote/far-end device. The external interface and remote side IP address are configured along with the phase 1 policy. See the screenshot below for details.

4. Create Phase 2 Proposal
In step 1 we created a proposal for Phase 1 negotiations, in this step we are creating a proposal for Phase 2 negotiations. There are also predefined proposals that can be used for Phase 2 proposals, in this example we will create a custom Phase 2 proposal. See the screenshot below for details.

5. Create Phase 2 Policy
In this step the Phase 2 policy is defined by specifying the Phase 2 proposal. Optionally perfect forward secrecy can be used. This forces the VPN to go through Phase 1 negotiations again once the secure Phase 2 channel is set up. In this example we configured perfect forward secrecy.

6. Create VPN
In this step the VPN is created by specifying the gateway and Phase 2 policy. See the screenshot below for details.

7. Create Address Book Entries
Address book entries are created so that these objects can be referenced in the policy that will be created in the next step.

8. Create Security Policy
A security policy is needed to force traffic across the tunnel (as this is a policy based VPN). The 'permit tunnel' statement provides the logic so that traffic will be encapsulated in the VPN tunnel. A second policy is also created for the reverse direction. This will allow either side to initiate a connection. The statement 'pair-policy' is used so both rules can be linked to the same VPN.




Configure HUB SRX
The configuration steps for the second device (HUB SRX) are almost identical except for device specific information such as IP addresses/networks etc. The following steps outline the configuration steps that were completed on HUB SRX.

1. Create Phase 1 Proposal

2. Create Phase 1 Policy

3. Create Gateway

4. Create Phase 2 Proposal

5. Create Phase 2 Policy

6. Create VPN

7. Create Address Book Entries

8. Create Security Policy



Verify IPSec Status
1. Verify Phase 1 Security Associations
The command 'show security ike security-associations' outlines the Phase 1 negotiations, in this example Phase 1 negotiations are up.

2. Verify Phase 2 Security Associations
The command 'show security ipsec security-associations' outlines the Phase 2 negotiations, in this example Phase 2 negotiations are up.

3. Verify VPN Statistics
The command 'show security ipsec statistics' outlines byte and packet counters and is a good indicator that actual traffic is passing through the VPN.

4. Verify Phase 1 Security Associations in Detail
The command 'show security ike security-associations detail' provides an expanded output of Phase 1 negotiations.

4. Verify Phase 2 Security Associations in Detail
The command 'show security ipsec security-associations detail' provides an expanded output of Phase 2 negotiations.




Conclusion
The next post will focus on basic route based IPSec VPNs. Also as part of this category I hope to complete point to multipoint IPSec VPNs and certificate based IPSec VPNs.


Tuesday, 15 January 2013

SRX IDP - Custom Policy & Attack Objects

This post will demonstrate the configuration of a custom Attack Object and custom IDP Policy. For demonstration purposes the custom IDP policy will only contain the single custom attack object. In reality complex IDP policies could contain many custom and predefined attack objects and groups. Please refer to the previous post SRX IDP - Overview & Initial Setup for licensing information and initial IDP configuration and setup.


Configuration
1. Create Custom Attack Object
In this step a signature based custom attack object name 'custom-ftp' is created. This custom attack object is configured to match on a pattern of 'anonymous' within the ftp username context. We will test this later in the post by attempting to log into an FTP site with the username anonymous. See the screenshot below for configuration commands.

2. Create Custom IDP Policy
In this step an IDP Policy is created. A name is defined for the IDP policy and rules are created. In this example only one rule is created using the custom attack object created in step 1. See below for command details.

3. Set Active IDP Policy
Although multiple policies can be configured on the SRX, only one IDP policy can be active on the device at any given time. This step configures the IDP policy created in previous step as the active policy. See the screenshot below for details.

4. Enable IDP Policy on Security Policy
Security policies are used to enable IDP processing on traffic. In this example the policy is enabled on the security policy 'OUTBOUND-INTERNET-ACCESS'. See the screenshot below for details.

5. Create local log file for IDP events (optional)
To log IDP events the syslog match statement 'RT_IDP' can be used. In the screenshot below a local file of idp-log is created and events which match 'RT_IDP' will be written to this file.


Verification & Testing
1. Show Status
The command show security idp status can be used to display current running IDP statistics such as processing rates and IDP detector versions. See the screenshot below for details.

2. Show Commit Status
The IDP policy can take longer to commit than the configuration. To check the commit status on the IDP policy the command 'show security idp policy-commit-status' can be used. I ran this command immediately after a commit to get some examples of various output. See the screenshots below for examples.


3. Test IDP Policy
The custom attack object was created to match the pattern 'anonymous' in the ftp-username context. To test this custom attack object and IDP policy we can simply access an FTP server on the internet and attempt to login with the username 'anonymous'. The screenshot below outlines this login attempt (which was unsuccessful).

The command 'show security idp attack table' confirms that a match (hit) was made.

The command 'show log idp-log' can be used to show the contents of the log file that was created to log IDP events. The screenshot below outlines the format of the log and confirms the event was blocked.


Conclusion
This concludes my posts on IDP. If anyone has questions, comments, or wants to dig deeper into any sub topics of IDP please leave comments.

For next topics I am thinking IPSEC/VPNs or expand on the Chassis Cluster/HA section to include a post with Dual Active/Active ISPs.


Tuesday, 8 January 2013

SRX IDP - Policy Templates

This post will demonstrate the configuration of an IDP policy on the SRX device using Policy Templates. Policy templates are predefined IDP policies that can be downloaded from Juniper with a valid IDP subscription. Please refer to the previous post SRX IDP - Overview & Initial Setup for licensing information and initial IDP configuration and setup.

**In the configuration demonstration I will be configuring this IDP policy on a general outbound internet rule. In reality these IDP policies would be configured on inbound rules which protect servers and applications.**

Predefined IDP Policy Templates
The following is a list of the policy templates provided by Juniper;
DMZ_Services [designed to be used to protect a typical DMZ environment]
DNS_Service [designed to protect DNS services. Use this template as a starting point to customize your desired level of protection]
File_Server [designed to provide protection to various file sharing services such as AMB, NFS, FTP, and others]
Getting_Started [a good starting point for learning how to create IDP policies]
IDP_Default [a good blend of security and performance. Use this template for "in-line" mode]
Recommended [covers the most important vulnerabilities. Use this template as a base line]
Web_Server [designed to protect commonly used HTTP servers from remote attacks]


Configuration - Recommended Policy Template
1. Set Active IDP Policy
As mentioned in the previous post, multiple IDP policies can be configured on the SRX device, however only one can be active. This step sets the pre-defined policy template of 'Recommended' as the active IDP policy

2. Enable IDP on Security Policy
Security policies are used to enable IDP processing on traffic. The active policy can be configured on multiple policies. In the screenshot below the active policy 'Recommended' is enabled on the security policy 'OUTBOUND-INTERNET'.

3. Create local log file for IDP events (optional)
To log IDP events the syslog match statement 'RT_IDP' can be used. In the screenshot below a local file of idp-log is created and events which match 'RT_IDP' will be written to this file.


Verification
1. Show Status
The command show security idp status can be used to display current running IDP statistics such as processing rates and IDP detector versions. See the screenshot below for details.

2. Show Memory Usage
The command show security idp memory can be used to display memory in use by IDP process and the remaining amount of memory. See the screenshot below for details.

3. Show IDP Package Version
The command show idp package version can be used to display the attack database to confirm if it up to date. See the screenshot below for details.


Conclusion
This post focused on creating a IDP policy using Juniper provided Policy Templates. The next post will focus on using a custom created policy.

Thursday, 3 January 2013

SRX IDP - Overview & Initial Setup


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
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.

IDP/IPS Rules
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.

IDP/IPS Rulebases
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.

IDP Policy
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
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.



IDP Modes
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'.

Integrated Mode
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 full-update' will initiate a download of attack objects, attack object groups and detection engine.

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.



Conclusion
The next post will be a continuation of the configuration done in this post focusing on configuring an IDP policy.