2.3.2. Policies
Before going into this section, it is important to understand the Policy concept.
To create, remove, modify, or apply Network Access Control Policies go to ON NAC -> Policies. From this component, it is possible to manage Network Access Control Policies and their objects.
Note
Before creating any policy, we have to mention that there are two implicit policies in the policy engine. These policies will match if no policy has ever matched:
The first one, defines sending all the traffic to register VLAN by default.
The second one is an implicit rule that is created when the user device is sent to quarantine manually (quarantine VLAN must be defined on the infrastructure).
Security Behavior:
Any network access request will be processed by the security policy from top to bottom. As soon as a policy is matched the access is granted or denied. At that moment other rules processes will be stopped. If no policy is matched, it will enter the Default policy.
Note
We strongly recommend creating a final policy to match all events that did not match any of the previous policies. This way, you can know which events are out of your policy scope.
OpenNAC includes a policy engine that allows managing and operating the security policy in a very intuitive way. The options are:
Add new: To add a new policy.
Edit: To edit a selected policy.
Clone: To simplify rules operation you can clone an existing rule/policy.
Delete: To remove a selected policy.
Refresh: To refresh the page.
Export data: To export the policy rules in JSON format.
Import data: To import data from a JSON or XML file.
2.3.2.1. Filters
In the upper right part of the window, we can find three buttons that allow us to classify the policies in different ways.
To help us navigate and find the different policies that we have configured, we can use different filters, create sections, and graphically see the plugins that are configured in the different policies.
The first section button allows us to filter the different policies -after configuring the “Sections” field in the policies.
The second button allows us to visually see all the plugins that we have enabled in the different policies.
The third button allows us to filter the policies by parameters like Name, Tags of User Device, Section, etc.
2.3.2.2. Contextual menu
If we right-click on a policy, the following menu will be displayed:
Clone: Allows cloning the policy selected.
Import XML file: To import data from an XML file.
Refresh: To refresh the page.
Enable: To enable the policy if it is disabled.
Disable: To disable the policy if it is enabled.
Add new: To add a new policy.
Edit: To edit the selected policy.
Delete: To remove the selected policy.
Export data: To export the policy rules in JSON format.
Import JSON file: To import data from a JSON file.
Move policy: Allows moving the policy from its current position.
2.3.2.3. Add new policy
To create a new policy, we have to understand the main sections that are included in a policy evaluation process. Each section will be detailed below.
The first section named General allows us to add a policy name and a policy comment. There you can also enable or disable the policy or select the predefined section.
The second section named Preconditions allows us to add conditions before the authentication happens:
Time of the connection
Session
Users
User devices
Network devices evolved
Sources (type of authentication)
The third section named Postconditions allows to add conditions after that authentication happens: VLAN assignment, Security Profiles or ACLS at an ingress port, and plugins and their parameters or notifications.
The fourth section named Other allows us to define a message for network access requests, learn user devices automatically, and assign them a TAG each time they match the policy -which could be useful.
The policy engine has two main principles that we have to consider to avoid mistakes and unexpected behavior.
Principle 1: Vertical components act as a logic “AND” during policy evaluation. For instance, if you set “Preconditions: Users” and “Preconditions: Sources” both must match with the user device event to match with that policy.
Principle 2: Different source in “Preconditions: Sources” will act as a logic “OR” because each event only has one source. This will allow the user to create an unique policy for more than one source event. “Precondition: Users”, “Precondition: User devices” and “Precondition: Network devices” only allow to set one of the options. For instance, if we try to add an user and after an user group in “Precondition: Users” in the same policy, user group will overwrite the user condition.
2.3.2.3.1. General
This section allows us to define a policy name.
We can also add a policy comment. This comment is related to the policy itself, and including as much detail as possible will improve future policy reviews. For instance, it can include additional information such as a change number, date of policy creation, technical reasons for denying or allowing access, and many others.
The policy can be enabled and disabled.
When creating a new policy, we can also select the policies to group by Section.
2.3.2.3.2. Preconditions
Preconditions allow us to add conditions before the authentication happens. These preconditions can be the Time of the connection, Users, User and Network Devices evolved, and Type of Authentication (Sources).
See all precondition types detailed below:
2.3.2.3.2.1. Time
One policy component that can be used by the policy engine is the Preconditions: Time. It allows selecting at what hours the policy is enabled and at what hours users can have network access. You can select time ranges.
2.3.2.3.2.2. Session
The Preconditions: Session allows us to introduce an expression to filter session data.
An example of session data expression could be the following:
(&,('==','userGroups','cn=VPN,ou=Groups,dc=opencloudfactory,dc=com'),('==','userGroups','cn=storage,ou=Groups,dc=opencloudfactory,dc=com'))
In this case, it will only match when the session user is in VPN user group and in storage user group.
Another example:
(&,('!=', 'email' , '.*@acme.net' ))
In this case, this will match session users whose email does not finish with @acme.net.
2.3.2.3.2.3. Users
As for the Preconditions: Users we can select users’ identities to allow or deny their network access.
With the Set User option, we can select a single user from the user’s local database. Local users are stored in an internal CMDB along with all the NAC Assets, OpenNAC Enterprise CMDB is located at ON Core.
We can use User Data Sources or UDS by clicking on Set User Data Source. UDS is the identity repository that can be used by the policy engine. Many UDS can be configured (Active Directory, LDAP Server, Database, and many others), also is possible to search over them:
User Data Source allows us to choose where we want to get users’ identities from. We can add new sources, edit them in order to enable or disable them, and more.
Another available option on Preconditions: Users are the LDAP Filters:
Once we have the authentication selected (UDS), we have to select the conditions that must be met so the asset can be allowed in. In other words, LDAP Filters do the authorization process during policy evaluation.
To have full integration with the Active Directory, the first step will be to add the ON Core into the domain -there is a wizard available for that in Configuration -> Wizards -> Join domain wizard. With that integration, we allow the RADIUS server to use the AD as an authenticator server, only for authentication.
Set User Data Source allows us to select the binding connection with the Active Directory. The LDAP Filter allows us to choose which LDAP attributes are used for authorization processes, such as “MemberOf” in the LDAP filter.
It is called LDAP filter because we use common LDAP Filters that are compatible with LDAPsearch and its filters. In the figure, we can see the LDAP filter used is “MemberOf”, which means that if the user tries to access the network, they must be part of the Active Directory Group that belongs to the specific organization unit, etc.
To summarize, if the user has a valid credential and belongs to the proper Active Directory group, the policy evaluation works as expected. We can use any LDAP Filter used by the LDAP search tool. For instance, “MemberOf” or a user that has an Active Directory attribute, or as simple as a user that belongs to the Active Directory.
2.3.2.3.2.4. User Devices
With Preconditions: User Devices, the users’ devices registered in the OpenNAC Enterprise CMDB can be selected by the policy.
You can select a list of users’ devices by clicking on Set User Device.
We can also use Tags of User Device at the bottom of the section. It allows us to add a tag to match the precondition. If we click on Change mode the view changes from Simple Mode to Advanced Mode.
In Tags of User Device we can write and check regular expressions to filter by sharing characteristics or security postures attributes. Typically, we will use concrete expressions or tags instead of a user. It is easier to maintain it globally, reserving the user selection part for troubleshooting or very specific situations.
Tags are part of the CMDB database. We have many tags created by default, other dynamic based on events, and also those that can be created by OpenNAC Enterprise administrator following a simple procedure at ON CMDB -> Tags.
Remember that OpenNAC Enterprise has a common standard for Tag naming, using 3 letters for prefixes. For reviewing some available tags see the Tags table.
2.3.2.3.2.5. Network Devices
Preconditions: Network devices is one of the Preconditions that can be used by the police engine.
You can select a list of network devices by clicking on Set Network Device.
We can also use Tags of Network Device at the bottom of the section. It allows us to add a tag to match the precondition. If we click on Change mode the view changes from Simple Mode to Advanced Mode.
In Tags of Network Device we can write and check regular expressions to filter by sharing characteristics or security postures attributes. Typically, we will use concrete expressions or tags instead of a user. It is easier to maintain it globally, reserving the user selection part for troubleshooting or very specific situations.
Tags are part of the CMDB database. We have many tags created by default, other dynamic based on events, and also those that can be created by OpenNAC Enterprise administrator following a simple procedure at ON CMDB -> Tags.
Remember that OpenNAC Enterprise has a common standard for Tag naming, using 3 letters for prefixes. For reviewing some available tags see the Tags table.
We can also define the name of a SID on which the devices match this policy. This field admits regular expression in pecl format.
2.3.2.3.2.6. Sources
The Preconditions: Sources allows us to define the authentication method to be used during network access requests. It is not recommended to use all at the same time, with the tuned policy we can ensure better policy results and avoid mistakes.
MAB: Mac Address Bypass method is an emulation of 802.1x. In the case there is no 802.1x supplicant listened by the switch port, the switch sends the MAC as the authentication method. It depends on the switch order authentication configuration that is assigned to the port. PRINTER, PHONES, and OTHER DEVICES that don’t have a supplicant 802.1x commonly use this authentication method.
Supplicant User: Enabling it, allows authenticated 802.1x supplicants, a common scenario may be a supplicant configured with EAP-MSchapv2. It is common to use a username and password credentials. This type of authentication could use a server certificate and be issued by a supplicant user trusted by a Certification Authority (recommended).
Supplicant Host: When enabling this type of authentication method, we allow the authentication of the workstations using the computer account. If this account is an Active Directory, the workstation account must be registered in the Active Directory domain to be used. A common scenario could be a support team that needs corporate devices to gain access to the network to provide a remote connection with user logon.
In case you don’t have a Supplicant Host configured you will not get network access until the user and password are introduced. Only users with cached credentials can access the network.
A common practice is to create a TAG when the authentication comes from a Supplicant host. We tag all the authentication attempts that come from this type of authentication to identify which workstation is part of the Active Directory domain and which part comes from a Corporate account. With that tag, we can reevaluate our policy actions.
VPN: Enabling this authentication method, we allow commercial VPN servers to be authenticated. Remember that OpenNAC Enterprise technologies allow using 2FA. We can use OTP using Google Authenticator OTP + Password. We have to define the IPS of the VPNS Gateway at the RADIUS level. Juniper, Cisco, Fortigate, Viapps, Checkpoint, or other commonly used VPN Gateway are easy to be integrated. The communication protocol between OpenNAC Enterprise technologies and VPNs is RADIUS protocol.
Visibility: Enabling the visibility source we allow the ON Core to process events that come from ON Sensor. OpenNAC Enterprise technologies include ON Core, Analytics, and Sensor components. For instance and as a use case, devices learned by ON Sensor are sent to ON Core adding a TAG such us SRC Sensor.
MAC discover: By enabling the MAC discover source, we allow the match of devices with known MAC addresses
Supplicant User Certificate: By enabling this type of authentication method, we allow the use of a user digital certificate, EAP-TLS adapts to this authentication method.
Supplicant Host Certificate: By enabling this type of authentication method, we allow the use of a host digital certificate, EAP-TLS adapts to this authentication method.
User: By enabling it, user connection and then authentication attempts through applications are allowed. Administrators of Network devices such as Switches, routers, and VPNs could be a common example. This means that we can use OpenNAC Enterprise to authenticate access to network devices. We can also create authorizations. For instance, in a common authorization scheme, Cisco Switches include different authorization profiles (Privileges Levels) which allow defining a command available for every privilege level. It is also possible to map privileges with Active Directory Groups, for that implementation we use RADIUS attributes.
SNMP Trap: Enabling the SNMP TRAP source allows the ON Core to process events that come from SNMP TRAP sent by a network device. This trap must be in version 1 or 2 and include the MAC address of the end point device.
2.3.2.3.3. Postconditions
This topic we will explain the Postconditions section features:
Firstly, on Set VLAN we can assign VLANs dynamically (Logical segmentation) and we have three important aspects to be considered:
VLAN XXX: For example, VLAN 533 (Provide VLAN). This is an example to define a service VLAN -any VLAN ID can be used.
VLAN 0 (Provide switch default VLAN): This is the value that needs to be used to use Switch Default VLANs. This means that the switch will assign the default VLAN configured on the switch port.
VLAN 4095 (Wrong VLAN): This is the value that needs to be sent to deny the Network access attempts. 4095 is out of valid VLAN scopes, and for that matter, by sending this value the network device will deny access.
Warning
Using a reject VLAN, like VLAN 4095, will not execute the plugins selected.
We can also configure compatibility with Voices VLANs.
We can define the Security Profiles. These can be set as dynamic or static. For further information read ON CMDB –> Security Profiles.
On Plugins, we ca activate plugins and its parameters. For more information about plugins, you can read Configuration -> Plugins
We can decide whether to send a Log error through a syslog. By default, this option is disabled.
If we have enabled the Send email option, every time a rule is matched an email will be sent. This can be really useful to send important security notifications to Security Operation Centers.
You can configure the Agent Profile in this section. They are configured in ON Agent -> Agent Profiles.
It is also possible to add Custom params. Custom params permit to change plugin parameters and return extra information to the polevals.
Type: Type of custom parameter:
Free text: Creates a new parameter to return.
Plugin configuration: Permits editing a plugin parameter before executing it.
Name: The name of the parameter to configure.
Value: The value of the parameter configured.
In the value field, we can use variables that come from the poleval response. The variables we can use are:
RULENUM -> Number of the policy where the device match
RULENAME -> Name of the policy where the device match
MAC -> MAC of the device
DATE -> When the event has been done
USERID -> ID of the user
SWITCHIP -> IP of the switch
SWITCHPORT -> Port of the switch
SWITCHPORTID -> ID of the port of the switch
IP -> IP of the device
VSA -> Vendor Specific Attributes
VLAN -> VLAN where the device is assigned
To use this parameters we need to add it with the format %VAR% -It needs to be in uppercase. An example of this can be the following:
Finally, it is also possible to add Extra Radius params. Vendor radius dictionaries (attributes and its values) must be considered and sometimes imported. For instance, modifying session timeouts, assigning pool IP, applying policies based on identities, and many others.
For adding a new Extra Radius params we need the following:
Vendor: Vendor of the network device.
Name: Name of the radius parameter to set.
Value: Value for the radius parameter.
In the value field, we can use variables that come from the poleval response. They are same as in Custom Params.
Note
The custom fields added to the user devices will also be taken.
2.3.2.3.4. Other
In the last section Other we find the last options.
Auto Learn of User Devices: Allows OpenNAC Enterprise to add the unknown devices that access this policy to the database.
Tags to add to Autolearned: Add tags in the devices that openNAC has self-learned. It only works when “Auto Learn of User Devices” is activated.
User Message:: OpenNAC Enterprise can send a message to the devices with ON Agent installed. it will appear in a pop-up window at the connection time. a message using the captive portal can be used as well.