Understanding JUNOS Enforcer Policy Enforcement

Once the SRX Series or J Series device has successfully established itself as the JUNOS Enforcer, it secures traffic as follows:

  1. First, the JUNOS Enforcer uses the appropriate JUNOS security policy to process the traffic. A security policy uses criteria such as the traffic’s source IP address or the time of day that the traffic was received to determine whether or not the traffic should be allowed to pass.
  2. Once it determines that the traffic may pass based on the JUNOS security policy, the JUNOS Enforcer maps the traffic flow to an authentication table entry. The JUNOS Enforcer uses the source IP address of the first packet in the flow to create the mapping.

    An authentication table entry contains the source IP address and user role(s) of a user who has already successfully established a UAC session. A user role identifies a group of users based on criteria such as type (for instance, “Engineering” or “Marketing”) or status (for instance, “Antivirus Running”). The JUNOS Enforcer determines whether to allow or deny the traffic to pass based on the authentication results stored in the appropriate authentication table entry.

    The Infranet Controller pushes authentication table entries to the JUNOS Enforcer when the devices first connect to one another and, as necessary, throughout the session. For example, the Infranet Controller might push updated authentication table entries to the JUNOS Enforcer when the user’s computer becomes noncompliant with endpoint security policies, when you change the configuration of a user’s role, or when you disable all user accounts on the Infranet Controller in response to a security problem such as a virus on the network.

    If the JUNOS Enforcer drops a packet due to a missing authentication table entry, the device sends a message to the Infranet Controller, which in turn may provision a new authentication table entry and send it to the JUNOS Enforcer. This process is called dynamic authentication table provisioning.

  3. Once it determines that the traffic may pass based on the authentication table entries, the JUNOS Enforcer maps the flow to a resource. The JUNOS Enforcer uses the destination IP address specified in the flow to create the mapping. Then the device uses that resource as well as the user role specified in the authentication table entry to map the flow to a resource access policy.

    A resource access policy specifies a particular resource to which you want to control access based on user role. For instance, you might create a resource access policy that allows only users who are members of the Engineering and Antivirus Running user roles access to the Engineering-Only server. Or you might create a resource access policy that allows members of the No Antivirus Running user role access to the Remediation server on which antivirus software is available for download.

    The Infranet Controller pushes resource access policies to the JUNOS Enforcer when the devices first connect to one another and when you modify your resource access policy configurations on the Infranet Controller.

    If the JUNOS Enforcer drops the packet because of a “deny” policy, the JUNOS Enforcer sends a message to the Infranet Controller, which in turn sends a message to the endpoint’s Odyssey Access Client (if available). (The Infranet Controller does not send “deny” messages to the agentless client.)

  4. Once it determines that the traffic may pass based on the resource access policies, the JUNOS Enforcer processes the traffic using the remaining application services defined in the JUNOS policy. The JUNOS Enforcer runs the remaining services in the following order: Intrusion Detection and Prevention (IDP), URL filtering, and Application Layer Gateways (ALGs).

Related Topics