3.2.2.4.3.2.6. 2SRA plugins

This section presents 2SRA plugins description and configuration.

To enable plugins, use their corresponding flag and then click on the “engine” icon to open the configuration window.

3.2.2.4.3.2.6.1. ironchipSync

The Ironchip plugin is used as a location-based security 2FA. When a user tries to authenticate, we will add another authorization factor based on the user’s location.

The ironChipSync plugin allows getting information about the user’s location once it tries to authenticate through the OpenNAC Enterprise server. The information about the location should be previously registered in the Iron Chip App, registering some security zones, so once the user tries to connect, we can check if the location is secure, and we can guarantee access.

The following fields must be configured to set up the plugin:

• IronChip Address: IP or domain for Iron Chip Server.

• Enable HTTPS: Enables the HTTP or HTTPS protocol.

• IronChip API Key: The key that will be associated with a secure zone. It is generated through the Iron Chip App.

• Execution order: Determines the order in which sync plugins are executed, with higher priority assigned to lower numerical values (0 being the lowest priority). In situations where multiple plugins share the same execution order value, the execution order will follow an alphabetical arrangement.

3.2.2.4.3.2.6.1.1. Ironchip authorization process

When a user tries to authenticate through OpenNAC, and its authentication matches a policy where the Ironchip Plugin has been enabled, an authorization alert will be sent to the user Ironchip App. Once the user authorizes the petition, the mobile App will scan the location to determine if the user is in one of the secure locations that have been registered previously.

If the user is in a secure location, we will authorize it and give access according to the policy parameters. If the user is in an unsecured area or there has been an error with the parameters, we won’t authorize the user.

About the Timeouts

For the correct functioning of the plugin, we will have to adapt some timeouts to wait until obtaining the validation from the Iron Chip application. The validation process usually takes around 15-30 seconds approximately. For longer times we will consider that there has been no response and we will close the connection. As a consequence, the user will not be verified, and we will deny access. From OpenNAC Enterprise we recommend adjusting the timeouts of the following files to optimize operation:

• /etc/httpd/conf.d/php.conf

We will need to change the timeout that refers to the php execution in the php.conf file. We will have to increment the value from 11 to 31, to give the user enough to execute the verification. If we do not configure this value, the web connection will be closed without receiving any response.

<Proxy "unix:/run/php-fpm/www.sock|fcgi://localhost" timeout=60>
</Proxy>
<Proxy "unix:/run/php-fpm/poleval.sock|fcgi://127.0.0.1" timeout=31>
</Proxy>

• /etc/php-fpm.d/poleval.conf

We will need to change the timeout that refers to the poleval execution In the poleval.conf file. We will have to increment the value from 10 to 30, to give the user enough to execute the verification. If we do not configure this value, if the poleval does not have a response in 10 seconds, it will return an invalid result.

;Custom
listen = /run/php-fpm/poleval.sock
pm.max_requests = 500
pm.status_path = /statuspoleval
slowlog = /var/log/php-fpm/poleval-slow.log
request_terminate_timeout = 30
php_admin_value[memory_limit] = 128M
php_admin_value[error_log] = /var/log/php-fpm/poleval-error.log

• /etc/raddb/mods-available/opennac

In this file, we will configure a parameter that refers to the API calls. If the poleval gets no response due to the apiTimeout, we will discard any information we receive after that time is up, so we will change the acceptWhenPolEvalDiscards parameter to no

# Default result when any issue is produced in openNAC policy evaluation or
# "apiTimeout" is reached
# By default, request is accept and default vlan is assigned
acceptWhenPolEvalDiscards = no;

Also, we will need to configure the timeout to abort the API calls. We will have to increase this timeout to give enough time to wait for the answer from the Iron Chip app.

# Timeout to abort api call (value in seconds)
apiTimeout = 120

3.2.2.4.3.2.6.2. mobileApp2FASync

The mobileApp2FASync plugin is used to generate mobile push notifications through firebase. This notifies the user that he is authenticated on his mobile.

The following fields must be configured to set up the plugin:

• Firebase API key: Firebase API key used by the service.

• Notification title: Title of the notification that will be sent to the user.

• Message: Message that will be sent to the user through the notification.

• TTL: Maximum time the user has to respond to the notification.

• Execution order: Determines the order in which sync plugins are executed, with higher priority assigned to lower numerical values (0 being the lowest priority). In situations where multiple plugins share the same execution order value, the execution order will follow an alphabetical arrangement.

3.2.2.4.3.2.6.3. maxFailedAuthentications

With the maxFailedAuthentications plugin, OTP connections can be managed.

It is in charge of verifying that a user has not tried to authenticate a certain number of times using a wrong OTP code. In case of exceeding a maximum number of attempts, that user will be blocked for a period of time and a new OTP code will be generated.

The following fields must be configured to set up the plugin:

• Period of time in which no more than a maximum number of authentication attempts can be made (in seconds): Period of time in which no more than the maximum number of authentication attempts can occur or the user will be blocked.

• Maximum number of authentication attempts in the same period of time: The maximum number of attempts permitted for each user.

3.2.2.4.3.2.6.4. maxFailedAuthenticationsSync

The maxFailedAuthenticationsSync plugin provides the ability to manage OTP connections.

It is in charge of verifying that a user has not tried to authenticate a certain number of times using a wrong OTP code. In case of exceeding a maximum number of attempts, that user will be blocked for a period of time and a new OTP code will be generated.

The following fields must be configured to set up the plugin:

• Period of time in which no more than a maximum number of authentication attempts can be made (in seconds): Period of time in which no more than the maximum number of authentication attempts can occur or the user will be blocked.

• Maximum number of authentication attempts in the same period of time: The maximum number of attempts permitted for each user.

• Period of time in which the user will be blocked once the maximum limit of authentication attempts has been exceeded (in seconds): Period of time in which the user will be blocked once the maximum limit of authentication attempts has been exceeded (in seconds).

• Execution order: Determines the order in which sync plugins are executed, with higher priority assigned to lower numerical values (0 being the lowest priority). In situations where multiple plugins share the same execution order value, the execution order will follow an alphabetical arrangement.

3.2.2.4.3.2.6.5. mobileIron

The mobileIron plugin checks if the client device exists within the MobileIron MDM, if it exists, this device is considered valid. This plugin also validates if the device is compliant. If the device is registered in the MobileIron database, it will allow the connection and assign the ID_XXXX Tag with the id received by MobileIron to the device. The tag MOBILEIRON will also be added to identify the type of verification.

The following fields must be configured to set up the plugin:

• Mobile Iron Service Address: MobileIron service address where inquiries will be made.

• Admin Device Space ID: Admin Device Space ID of the user to query the MobileIron service.

• Mobile Iron Username: MobileIron platform user.

• Mobile Iron Password: MobileIron platform user password.

• Check compliance: If compliance is checked, the plugin will verify if the device is compliant in MobileIron, if it is, the COMPLIANCE tag will be assigned and, if it is not, the NO_COMPLIANCE tag. If this flag is disabled, the plugin will remove the compliance tags and will not validate this feature.

• Execution TTL (m.): During this period, indicated in minutes, no more executions are done over the same client.

3.2.2.4.3.2.6.6. mobileIronSync

The mobileIronSync plugin checks if the client device exists within the MobileIron MDM, if it exists, this device is considered valid. This plugin also validates if the device is compliant. If the device is registered in the MobileIron database, it will allow the connection and assign the ID_XXXX Tag with the id received by MobileIron to the device. The tag MOBILEIRON will also be added to identify the type of verification.

The following fields must be configured to set up the plugin:

• Mobile Iron Service Address: MobileIron service address where inquiries will be made.

• Admin Device Space ID: Admin Device Space ID of the user to query the MobileIron service.

• Mobile Iron Username: MobileIron platform user.

• Mobile Iron Password: MobileIron platform user password.

• Quarantine VLAN: VLAN to assign if the device is rejected.

• Check compliance: If compliance is checked, the plugin will verify if the device is compliance in MobileIron, if it is, the COMPLIANCE tag will be assigned and, if it is not, the NO_COMPLIANCE tag. If this flag is disabled, the plugin will remove the compliance tags and will not validate this feature.

• Execution order: Determines the order in which sync plugins are executed, with higher priority assigned to lower numerical values (0 being the lowest priority). In situations where multiple plugins share the same execution order value, the execution order will follow an alphabetical arrangement.

3.2.2.4.3.2.6.7. radius2FASync

The radius2FASync plugin is related to a Symantec system, which uses a second radius that acts as 2FA and is in charge of managing the process of obtaining this second factor. The plugin will be used to validate VPN connections with or without OTP, adding a double authentication factor to improve security.

The following fields must be configured to set up the plugin:

• Radius IP: IP to send radius authentication messages.

• Radius Port: Port to send radius authentication messages.

• Radius Secret: Shared secret to connect to RADIUS.

• Push Keyword: Keyword that will be sent to RADIUS to ask for push.

• Execution order: Determines the order in which sync plugins are executed, with higher priority assigned to lower numerical values (0 being the lowest priority). In situations where multiple plugins share the same execution order value, the execution order will follow an alphabetical arrangement.

The following diagram shows the plugin flow:

1. First, the plugin checks if there are no empty values in its configuration. If true, it will send a login request to that second radius that will manage the 2FA.

2. The plugin will wait for a response from the login request sent, and it may be rejected, timeout, or accepted.

   • In the case it is accepted, the VLAN configured in the policy used by the plugin will be assigned to the user’s device.

   • In the case that it is not accepted, the VLAN of access denied will be assigned.

3. During the execution process of the radius2FA plugin, an application is used for the user to validate the connection or enter the OTP. This is not processed by the plugin itself, since the radius configured for this 2FA process is in charge.

3.2.2.4.3.2.6.8. wireGuardSync

The wireGuardSync plugin enables communication with VPN Gateway FW to manage and receive information about VPN users in the corporate network. It can be used along with the policy engine in order to isolate users in different ‘dynamic zones’. It also generates events for the disconnection of multiplatform agent users from the Business Profiles section.

The following fields must be configured to set up the plugin:

• TTL: The duration of the connection’s activity.

• VPNGW-Role: Dynamic zone name.

• Execution order: Determines the order in which sync plugins are executed, with higher priority assigned to lower numerical values (0 being the lowest priority). In situations where multiple plugins share the same execution order value, the execution order will follow an alphabetical arrangement.

It is important to ensure the WireGuard configuration is set up correctly. You can do check this in the Configure > VPN section.