3.2.2.4.3.2.3. Segmentation plugins
This section presents Segmentation 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.3.1. fortiGateAccounting
This fortiGateAccounting plugin allows sending session information to a fortiGate firewall. This information is sent through a RADIUS protocol and its port, and PSK (Preshared key) must be exchanged between peers to accept messages. The information includes the username associated and its IP address in the network.
This plugin allows that as soon as the user gains access to the network through OpenNAC Enterprise network access policies, it registers its information in the FortiGate Firewalls to allow access and unified network policies inside the OpenNAC Enterprise management.
For that, a User Group is used. For instance, it can be defined as a fortiGateAccounting_UserGroup, this means that the information is registered in a User Group that belongs to the Fortigate platform. In case the user accessing the network uses a Domain and sends this information in the events is required to be defined.
This plugin allows sending information related to the username associated with an IP address to the FortiGate firewall.
This information is sent by accounting radius protocol based on FortiGate RADIUS Single Sign-On (RSSO), for further information check: https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/85730/radius-single-sign-on-rsso-agent
The following fields must be configured to set up the plugin:
FortiGate Radius IP: IP to send radius accounting messages to FortiGate.
FortiGate Radius Port: Port to send RADIUS accounting messages to FortiGate.
Shared Secret: The shared secret to connect to FortiGate radius.
User Group: Value used to define the default User Group of Radius Single Sign-On (RSSO) type. If it is empty, any user group is used.
User with Domain: It indicates if the username sent to FortiGate has to include the domain name in case it is included in the user request.
Limit IPs or networks to push to Forti (empty all allowed): This parameter defines the range of IPs that can trigger the execution of the plugin. If an event occurs without an IP within the configured range in this field, the plugin will not be executed. On the other hand, if no IPs are configured, the plugin will always run regardless of the IP received in the initiating event.
Custom properties
The fortiGateAccounting plugin allows you to send a custom user group for all users who match the policy, overwriting the default user group specified in general plugin properties.
To provide this custom user group, you have to define a Custom param in the policy. The custom param has to be named fortiGateAccounting_UserGroup and its value has to be the user group associated with all users who match this policy.
To continue the FortiGate NGFW configuration, please read NGFW FortiGate Configurations.
3.2.2.4.3.2.3.1.1. Firewall Autodiscover - fortiGateAccounting feature
The fortiGateAccounting plugin has the Firewall Autodiscover feature that allows you to dynamically relate which Fortinet Firewall is associated to a network device (firewall, switch, AP, etc.) that processes a user event.
When we enable this feature, the system will automatically look for the IP of the firewall that must process a new user event. For this, we must previously have all the network devices (firewall, switch, AP, etc.) registered in the System Data with the tags correctly defined so that the system can make the association.
Firewall Autodiscover: This boolean enables the firewall auto-discover function and defines if the FortiGate Radius IP will be automatically filled in. If we enable this feature the FortiGate Radius IP field will be ignored.
The Firewall Autodiscover flag must be enabled to configure the Network Device TAG Prefix, Firewall autodiscover Brand/Model, and UserGroup TAG prefix fields.
Network Device TAG Prefix (firewall autodiscover): TAG prefix that will be used to perform the association between the network device and the firewall associated.
Firewall autodiscover Brand/Model: Define which brand and model use to locate the firewall (which already has the “NetworkDevice TAG prefix”). Default Fortinet/Generic.
UserGroup TAG prefix (firewall autodiscover): TAG prefix that will be used as userGroup. If the user device in the new event contains a TAG that matches with the defined prefix, we will use it as userGroup (the userGroup must be previously defined on the Firewall).
For example, a new event in OpenNAC Enterprise executes the fortiGateAccounting plugin. This event will have a “switchIP” field with a network device associated. This network device is registered on the System Data and it has some tags associated. Using the field “NetworkDevice TAG prefix” we can find a specific TAG in the network device. Once we find it, we will look for the different firewalls registered on the System Data that match with the specified Brand/Model, and with the tag found on the network device. When the first Fortinet firewall matches these filters, its IP will be used as the ‘FortiGate Radius IP’, and we will send the information related to the event.
Once we have a match with a firewall and the switch, the system will store a TAG with the following format [ICT_FGA_{firewallIP} which means Internal Cache TAG _ FortiGate Accounting _ IP firewall] in the switch. That will indicate which FortiGate Radius IP is associated to the network device. This will help to speed up the process in future events since we will not need to repeat the search.
The “UserGroup TAG prefix” will be used to find a TAG inside the client tags. Once the TAG matches with the defined prefix, it will be used as userGroup and it will be send to the firewall.
Execution flow:
3.2.2.4.3.2.3.2. getADGroup
The getADGroup plugin retrieves the MAC address of the connected device and searches for it as a user in the registered Active Directories. Then, it identifies the group to which the user belongs and adds a corresponding tag to indicate it.
If the device does not belong to any groups, it is labeled as <Tag prefix>_NOT_CONTAINED.
If the device is not defined in any Active Directory, it is labeled as <Tag prefix>_NOT_DEFINED.
Note
The proper functioning of SNMP or COA disconnection is essential for the plugin to operate effectively.
Initially, when the plugin first encounters the MAC address, it will be directed to an access VLAN. Upon execution of the plugin and the addition of tags, it will transition to the service VLAN. This transition necessitates seamless disconnection, underscoring the importance of smooth SNMP or COA disconnection.
Tag prefix: Tag prefix to label the user device configuration in the Active Directory.
Execution TTL: During this period, indicated in minutes, no more executions are done over the same client.
The plugin has to be executed within both the MAB and the Registry policies postconditions. Upon execution, it assigns tags based on the Active Directory groups associated with the MAC address of the connected device.
Following this, policies are configured to consider these tags based on the device’s Active Directory group memberships.
3.2.2.4.3.2.3.3. paloAlto
The paloAlto plugin allows sending information related to a username and IP along with a PA Dynamic Address Group Tag. An internal OpenNAC Tag can be assigned to the device.
To start, you notify the firewall of the username associated with a specific IP address, and this relationship is active until a logout is received or the User Session Timeout (min.) indicated in plugin properties is exceeded( after that time, without a new notify, the relationship expires). Apart from that, you associate the IP address with a Palo Alto dynamic tag, so in the Palo Alto firewall, you can define a Dynamic Address Group and use it in Palo Alto policies.
The following fields must be configured to set up the plugin:
User Name: Administrator user name to connect to Palo Alto Firewall.
Password: Administrator password to connect to Palo Alto Firewall.
IP Palo Alto / Panorama: IP address for Palo Alto Firewall.
User with Domain: It indicates if the user name sent to Palo Alto has to include the domain name in case it is included in the user request.
User Name is required: It indicates if the user name is required to send information to Palo Alto. If it’s required, when a MAB authentication is produced, there could not be a notification to Palo Alto.
User Session Timeout (min.): User session timeout (TTL), indicated in minutes.
PaloAlto Tag: Tag used to notify Palo Alto Dynamic Address Group. If it is empty, the policy name is used.
openNAC Tag: openNAC user device tag, to mark user device when is notified to Palo Alto. If it is empty, no tag is used.
Panorama Device Group Flag: It indicates that we have to send the information to a specific Panorama device group.
Panorama Device Group: Indicates to which Panorama device group we send the information, only if Panorama Device Group Flag is active.
Note
To connect to Palo Alto, only a user with “XML API - User-ID Agent” rights is required, so “Web UI” and “Command Line” rights can be disabled.
PaloAlto NGFW technologies include an API that requires credentials for access.
If Palo Alto is integrated with Active Directory or LDAP servers, it is necessary to specify when using other types of users. This facilitates the exchange of user session information between PaloAlto and openNAC, which can be used to define session timeouts to enforce authentication and also to utilize User Device tags when notifying Palo Alto.
3.2.2.4.3.2.3.4. setVlanSync
The setVlanSync plugin uses the OpenNAC tag engine to give users different access depending on which port of the network device they are connected to. It will read tags from the network device (SVP_PORT_<PORT-NUMBER>_<VLAN-NUMBER> or SVP_GENERAL_<VLAN-NUMBER>) and depending on which port they are connected to, the device will be given access to a VLAN or another.
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 VLAN configured in policy postconditions will only have effect if the network device tags doesn’t affect the connection of the user device.
The two types of tags that can be configured on the network device are the following:
SVP_PORT_<PORT-NUMBER>_<VLAN-NUMBER>: In this case the VLAN <VLAN-NUMBER> will be assigned to the user device if that device is connected to the {PORT-NUMBER} of this network device.
SVP_GENERAL_<VLAN-NUMBER>: In this case the VLAN <VLAN-NUMBER> will be assigned to the user device if the port where the user device is connected on the network device does not have a specific SVP_PORT tag.
Note
If the SVP_GENERAL tag does not exist in the network device and the port has not a specific SVP_PORT tag, the VLAN number configured in the policy will be assigned to the user device.
When a user device matches the policy, the plugin will generate the following status messages in NAC > Sessions depending on the VLAN assigned:
SET VLAN PLUGIN: Port switch VLAN [<VLAN-NUMBER>]: In this case, there is a SVP_PORT tag configured for the connection port on the network device. So the VLAN assigned is the corresponding to the tag SVP_PORT_<PORT-NUMBER>_<VLAN-NUMBER>.
SET VLAN PLUGIN: General switch VLAN VLAN [<VLAN-NUMBER>]: In this case, there is not a SVP_PORT tag configured for the connection port on the network device, but there is a SVP_GENERAL tag on the network device. So the VLAN assigned is the corresponding to the tag SVP_GENERAL_<VLAN-NUMBER>.
SET VLAN PLUGIN: Policy VLAN [<VLAN-NUMBER>]: In this case, there is not a SVP_GENERAL tag on the network device, and there is not a SVP_PORT tag configured for the connection port on the network device, so the policy VLAN configured on the postconditions is assigned to the user device.
3.2.2.4.3.2.3.5. snmpQuarantine
The snmpQuarantine plugin, combined with a correct switch configuration (enabling it in all ports that want to be used with the plugin), allows OpenNAC to communicate with the switch via SNMP to quarantine the port where the quarantined user has been connected. A tag will be added to the user device indicating the switch and port that have been quarantined (SQP_<SWITCH>_<PORT>) and another one to the network device indicating the port that has been quarantined, the MAC that triggered the quarantine and its original VLAN (SQP_<MACADDRESS>_<PORT>_<VLAN>).
The switch must have the general SNMP configuration, and each port that we want to use with the plugin should be configured to use SNMP and with the correct access VLAN. In this example the port 2 will be used with the VLAN number 100, and the switch configured is a Cisco 2960.
configure terminal
snmp-server community public RO
snmp-server community private RW
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps mac-notification change move threshold
snmp-server host 10.10.36.254 version 2c public
interface FastEthernet0/2
switchport access vlan 100
snmp trap mac-notification change added
snmp trap mac-notification change removed
end
mac-address-table notification
end
For this plugin execution we need to configure a Quarantine policy in :ref:` NAC > Policies<policy_plugins>` as the following:
To quarantine a device manually, go to Operate > NAC > Sessions. Select the device checkbox and select the Quarantine option that will appear in the Action row at the bottom of the window. click on Apply to selected to quarantine.
If a user device is in quarantine it will have the SQP_<SWITCH>_<PORT> tag, SQP_<SWITCH>_02 in this case, and if a network device is in quarantine it will have the SQP_<SWITCH>_<PORT>_<VLAN> tag, SQP_<SWITCH>_02_100 in this case.