Friday 16 May 2014

Juniper SRX: IF-MAP, source-identity and restrict-source-identity-lookup

The terms for the uninitiated:

IF-MAP, at its core, is a user identity propagation mechanism and protocol. Juniper's implementation allows you to attach 'roles' to a specific user, and create policies that permit or deny traffic based upon said role. In the case of the SRX, the firewall itself does not participate directly in the IF-MAP Federation; It relies on a proprietary communications channel over SSL (JUEP) to an Infranet Controller (IC) to request/receive user identity information.

source-identity is a (but not the only - see UAC) policy match term you can use to leverage IF-MAP on the SRX. The term was introduced in 12.1, and relies on a 'first-packet-drop-lookup' mechanism to handle packets that match the policy. Basically, if a new connection matches a policy with source-identity as a match condition, the firewall will proceed to drop the packet and query the local IC for the user identity/role information of the source IP address, assuming there is not already an entry in it's local database. Depending on the response from the IC, the firewall will then match the user's role to the policy and permit the flow, or, if the user identity does not contain the required role for the policy in question, it will continue doing policy lookups until a terminal match is found further down in the rulebase. IE: These policies are not terminal.

restrict-source-identity-lookup is a hidden feature/command within the 'unified-access-control' stanza that was added into the 12.1X44D30.4 release which is meant to significantly increase the performance of a device leveraging the source-identity feature. What this command does is quite simple; It makes any rule with source-identity terminal. If a flow matches a policy with source-identity while restrict-source-identity-lookup is configured and the user does not have the required role, the session will be denied. As such, it is generally adviseable to place these policies at or near the bottom of the rulebase to avoid issues with unauthenticated (server-to-server) traffic that may share similar source/destination/application information.

To enable the feature, run:
set services unified-access-control restrict-source-identity-lookup

To successfully use the feature in the rulebase however, the security policies themselves get quite a bit more complex. For every policy that utilizes source-identity matching, you must have a 'clone' policy (placed adjacently) that mirrors the match conditions, while using the source-identity of 'unauthenticated-user' AND 'application-services uac-policy'. The second policy with 'unauthenticated-user' is meant to catch an (you guessed it!) unauthenticated user from an unknown source IP and perform a 'first-packet-drop-lookup' to gather their information. Thus, once the source IP address is known, the flow will come back down through the rulebase and match the first source-identity policy with the required role, and either be permitted or outright denied, based on the received information.

To put this in practice, I've made a policy below which will look for users that have the HR_Management role while using restrict-source-identity-lookup:

set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH match source-address any
set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH match destination-address any
set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH match application junos-https
set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH match source-identity unauthenticated-user
set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH then permit application-services uac-policy

set security policies from-zone Outside to-zone DMZ policy HR_Management match source-address any
set security policies from-zone Outside to-zone DMZ policy HR_Management match destination-address any
set security policies from-zone Outside to-zone DMZ policy HR_Management match application junos-https
set security policies from-zone Outside to-zone DMZ policy HR_Management match source-identity HR_Management
set security policies from-zone Outside to-zone DMZ policy HR_Management then permit

Some additional 'useful' operational commands when dealing with IF-MAP and SRX are:

View the available roles on the Enforcer (SRX):
show services unified-access-control roles

View all users currently active on the device: 
show services unified-access-control authentication-table

View connectivity between the SRX and the IC (state should be 'connected'):
show services unified-access-control status

View available information and roles for a specific IP address:
show services unified-access-control authentication-table ip x.x.x.x detail

View available information and roles for a specific user:
show services unified-access-control authentication-table user username detail

Thursday 27 March 2014

Juniper SRX - PKI - Certificate-based VPNs - Part 03 - SRX Configuration

Continuing on with Part 03 of this series (Part 02 found here), we'll finish the SRX configuration and bring up the tunnel:

set security ike proposal CERT_PROP authentication-method rsa-signatures
set security ike proposal CERT_PROP dh-group group2
set security ike proposal CERT_PROP authentication-algorithm sha1
set security ike proposal CERT_PROP encryption-algorithm aes-128-cbc
set security ike proposal CERT_PROP lifetime-seconds 86400

set security ike policy vSRX_02_CERT mode main
set security ike policy vSRX_02_CERT proposals CERT_PROP
set security ike policy vSRX_02_CERT certificate local-certificate SRX210_key_01
set security ike policy vSRX_02_CERT certificate peer-certificate-type x509-signature

set security ike gateway vSRX_02 ike-policy vSRX_02_CERT
set security ike gateway vSRX_02 address 10.0.0.102
set security ike gateway vSRX_02 external-interface reth2.0
set security ike gateway vSRX_02 local-identity user-at-hostname "your.email@domain.com"
set security ike gateway vSRX_02 remote-identity user-at-hostname "your.email@domain.com"

root@SRX210_A# run show security ike sa 10.0.0.102 detail
node0:
--------------------------------------------------------------------------
IKE peer 10.0.0.102, Index 1917721, Gateway Name: vSRX_02
  Role: Responder, State: UP
  Initiator cookie: 1bb59a819ce8e2df, Responder cookie: 4daa2c9906f66705
  Exchange type: Main, Authentication method: RSA-signatures
  Local: 192.168.0.211:500, Remote: 10.0.0.102:500
  Lifetime: Expires in 86381 seconds
  Peer ike-id: your.email@domain.com
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes128-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                 2516
   Output bytes  :                 2296
   Input  packets:                    5
   Output packets:                    4
  Flags: IKE SA is created
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 192.168.0.211:500, Remote: 10.0.0.102:500
    Local identity: your.email@domain.com
    Remote identity: your.email@domain.com
    Flags: IKE SA is created