Modifying Detection and Mitigation CLI Settings

The default settings that are configured for the rogue AP detection and mitigation features are adequate for most situations. However, many default settings can be changed if your network requires lighter or heavier scanning and/or mitigation services. The following is the list of rogue-ap commands:

controller (config)# rogue‐ap ?

acl                    Add a new rogue AP ACL entry. aging                  Sets the aging of alarms for rogue APs. assigned‐aps           Number of APs assigned for mitigation. blocked                Add a new rogue AP blocked entry. detection              Turn on rogue AP detection. min‐rssi               Sets RSSI Threshold for Mitigation. mitigation             Set the rogue AP mitigation parameters.

mitigation‐frames      Sets the maximum number of mitigation frames sent out per channel.

operational‐time       Sets the APs time on the home channel during scanning. scanning‐channels      Sets the global Rogue AP scanning channels. scanning‐time          Sets the APs per channel scanning time

As a general rule, unless the AP is in dedicated scanning mode, the more time that is spent scanning and mitigating, the less time is spent by the AP in normal WLAN operating services. Some rules determine how service is provided:

• The controller picks the APs that will scan and mitigate; those that mitigate are dependant on their proximity to the rogue AP and the number of mitigating APs that have been set.
• To preserve operational performance, APs will mitigate only the home channel if they have clients that are associated.
• Settings are administered globally; there is no way to set a particular AP to mitigate.
• Mitigation is performed only on clients associated to rogue APs; the rogue APs themselves are not mitigated. It is the network administrator’s responsibility to remove the rogue APs from the network.
• AP mitigation frames are prioritized below QoS frames, but above Best Effort frames.
• To reduce network traffic, you may configure the scanning channels list that contains only the home channels

Changing the Number of Mitigating APs with the CLI

By default, three Mitigating APs are selected by the controller to perform scanning and mitigation. This number can be set to a high of 20 APs or down to 1 AP, depending on the needs of your network. To change the number of mitigating APs to 5:

controller (config)# rogue-ap assigned-aps 5

Changing the Scanning and Mitigation Settings with the CLI

When rogue AP scanning is enabled, for any given period, the AP spends part of the time scanning channels, and part of the time performing normal AP WLAN operations on the home channel. This cycle of scan/operate repeats so quickly that both tasks are performed without noticeable network operation degradation.

If scanning is enabled, the rogue-ap operational-time command sets the number of milliseconds that are spent in operational time, performing normal wireless services, on the home channel. This command is related to the rogue-ap scanning-time command. The channels that are scanned are determined by the rogue-ap scanning channels command. The complete set of default channels are 1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165.

The following command changes the operational time from the default 400 to 2500 milliseconds: controller (config)# rogue-ap operational-time 2500

The following command changes the scanning time from the default 100 to 200 milliseconds: controller (config)# rogue-ap scanning-time 200

The following command sets the scanning channels to 1, 6, 11, 36, 44, 52, 60:

controller (config)# rogue-ap scanning-channels 1,6,11,36,44,52,60 controller (config)# exit

To verify the changes, use the show rogue-ap globals command:

controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : selected

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 5

Number of Mitigating APs               :5

Scanning time in ms                    : 200

Operational time in ms                 : 2500

Max mitigation frames sent per channel : 10

Scanning Channels                      : 1,6,11,36,44,52,60

RSSI Threshold for Mitigation          : ‐100

Changing the Minimum RSSI with the CLI

RSSI is the threshold for which APs attempt to mitigate rogues; if the signal is very week (distant AP), APs won’t try to mitigate it.

The command to change the minimum RSSI (Received Signal Strength Indication) level, over which a station will be mitigated is rogue-ap min-rssi. A level range of 0 of -100 is supported, with -100 being the default setting.

The following command sets the minimum RSSI level to -80:

controller (config)# rogue-ap min-rssi -80 controller (config)#

TABLE 20: CLI Commands for Rogue Mitigation

Rogue Mitigation Command	Action
rogue-ap mitigation all	Sets rogue mitigation for all rogue APs that are not on the access control list.
rogue-ap mitigation selected	Sets rogue mitigation for all rogue APs that are on the blocked list.
rogue-ap mitigation wiredrogue	Sets rogue mitigation for all wired-side rogue APs. If rogue clients on the wired side are added to the blocked ACL list, then only those listed wired-side rogue clients are blocked.
show rogue-ap globals	Displays current rogue data.
rogue-ap mitigation none	Turns off rogue mitigation.

Rogue Mitigation Example

Rogue AP mitigation for APs in the blocked list is enabled and confirmed as follows:

controller# configure terminal controller(config)# rogue‐ap detection controller(config)# rogue-ap mitigation selected controller(config)# exit controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : selected

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 3

Number of Mitigating APs               : 5

Scanning time in ms                    : 100

Operational time in ms                 : 400

Max mitigation frames sent per channel : 10

Scanning Channels                      :

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165 RSSI Threshold for Mitigation          : ‐100

Modify Rogue Detection and Mitigation Settings with the CLI

The default settings that are configured for the rogue AP detection and mitigation features are adequate for most situations. However, many default settings can be changed if your network requires lighter or heavier scanning and/or mitigation services. The following is the list of rogue-ap commands:

controller(config)# rogue‐ap ?

acl                    Add a new rogue AP ACL entry. aging                  Sets the aging of alarms for rogue APs. assigned‐aps           Number of APs assigned for mitigation. blocked                Add a new rogue AP blocked entry. detection              Turn on rogue AP detection.

min‐rssi               Sets RSSI Threshold for Mitigation. mitigation             Set the rogue AP mitigation parameters.

mitigation‐frames      Sets the maximum number of mitigation frames sent out per channel.

operational‐time       Sets the APs time on the home channel during scanning. scanning‐channels      Sets the global Rogue AP scanning channels. scanning‐time          Sets the APs per channel scanning time

As a general rule, unless the AP is in dedicated scanning mode, the more time that is spent scanning and mitigating, the less time is spent by the AP in normal WLAN operating services. Some rules determine how service is provided:

• The controller picks the APs that will scan and mitigate; those that mitigate are dependant on their proximity to the rogue AP and the number of mitigating APs that have been set. To preserve operational performance, APs will mitigate only the home channel if they have clients that are associated.
• Settings are administered globally; there is no way to set a particular AP to mitigate.
• Mitigation is performed only on clients associated to rogue APs; the rogue APs themselves are not mitigated. It is the network administrator’s responsibility to remove the rogue APs from the network.
• AP mitigation frames are prioritized below QoS frames, but above Best Effort frames.
• To reduce network traffic, you can configure the scanning channels list that contains only the home channels.

Changing the Number of Mitigating APs with the CLI

By default, three mitigating APs are selected by the controller to perform scanning and mitigation. This number can be set to a high of 20 APs or down to 1 AP, depending on the needs of your network, although we do not recommend assigning a high number of APs for mitigation because they can interfere with each other while mitigating the rogue. To change the number of mitigating APs to 5: controller(config)# rogue‐ap assigned‐aps 5

Changing the Scanning and Mitigation Settings with the CLI

When rogue AP scanning is enabled, for any given period, the AP spends part of the time scanning channels, and part of the time performing normal AP WLAN operations on the home channel. This cycle of scan/operate repeats so quickly that both tasks are performed without noticeable network operation degradation.

If scanning is enabled, the rogue-ap operational-time command sets the number of milliseconds that are spent in operational time, performing normal wireless services, on the home channel. This command is related to the rogue-ap scanning-time command. The channels that are scanned are determined by the rogue-ap scanning channels command. The complete set of default channels are 1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165.

The following command changes the operational time from the default 400 to 2500 milliseconds: controller(config)# rogue-ap operational-time 2500

The following command changes the scanning time from the default 100 to 200 milliseconds: controller(config)# rogue-ap scanning-time 200

The following command sets the scanning channels to 1, 6, 11, 36, 44, 52, 60:

controller(config)# rogue-ap scanning-channels 1,6,11,36,44,52,60 controller(config)# exit

To verify the changes, use the show rogue-ap globals command:

controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : selected

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 5

Number of Mitigating APs               : 5

Scanning time in ms                    : 200

Operational time in ms                 : 2500

Max mitigation frames sent per channel : 10 Scanning Channels                      : 1,6,11,36,44,52,60

RSSI Threshold for Mitigation          : ‐100

Changing the Minimum RSSI with the CLI

RSSI is the threshold for which APs attempt to mitigate rogues; if the signal is very week (distant AP), APs won’t try to mitigate it.

The command to change the minimum RSSI (Received Signal Strength Indication) level, over which a station will be mitigated is rogue-ap min-rssi. A level range of 0 of -100 is supported, with -100 being the default setting.

The following command sets the minimum RSSI level to -80:

controller(config)# rogue-ap min-rssi -80 controller(config)#

Configure Rogue AP Mitigation with the Web UI

To prevent clients of unauthorized APs from accessing your network, enable the options for both scanning for the presence of rogue APs and mitigating the client traffic originating from them. These features are set globally, with the controller managing the lists of allowable and blocked WLAN BSSIDs and coordinating the set of APs (the Mitigating APs) that perform mitigation when a rogue AP is detected.

When rogue AP scanning (detection) is enabled, for any given period, the AP spends part of the time scanning channels (determined by the Scanning time in ms setting), and part of the time performing normal AP WLAN operations on the home channel (determined by the Operational time in ms setting). This cycle of scan/operate repeats so quickly that both tasks are performed without noticeable network operation degradation.

The channels that are scanned by a particular AP are determined by the model of AP. As a result of the channel scan, a list of rogue APs is compiled and sent by the controller to a number of Mitigating APs that are closest to the rogue AP. Mitigating APs send mitigation (deauth) frames to the rogue AP where clients are associated to remove those clients from the network. This presence of the rogue AP generates alarms that are noted on the Web UI monitoring dashboard and via syslog alarm messages so the administrator is aware of the situation and can then remove the offending AP or update the configuration list.

As well, if a rogue device seen on the wired interface of the AP and if the device is in the AP’s discovered list of stations a wired rogue notification will be sent via the Web UI monitoring dashboard and syslog alarm message. If the rogue client is associated with the AP, that client is also classified as a rogue.

Alter the List of Allowed APs with the Web UI

To change the list of allowed APs, follow these steps:

1. From the Web UI, click Configure > Security > Rogue AP > Global settings. The Allowed APs screen appears. See Figure .

Figure 63: Web UI List of Allowed APs

2. To add a BSSID to the list, click Add.

• In the BSSID boxes, type the BSSID, in hexadecimal format, of the permitted access point. • To add the BSSID to the ACL, click OK.

3. To delete a BSSID from the list, select the BSSID, click Delete, then OK.

Alter the List of Blocked APs with the Web UI

To change the list of allowed APs, follow these steps:

1. From the Web UI click Configure > Security > Rogue AP > Blocked APs. The table shows information about access points listed as blocked BSSIDs in the access control list (ACL).
2. To see an updated list of the APs blocked in the WLAN, click Refresh.
3. To add an AP to the blocked list, click Add.
   • In the BSSID box, type the BSSID, in hexadecimal format, of the access point. Add the BSSID to the ACL, by clicking OK.
4. The blocked BSSID now appears on the list with the following information:
   • BSSID The access point’s BSSID.
   • Creation Time The timestamp of when the blocked AP entry was created.
   • Last Reported Time The time the AP was last discovered. If this field is blank, the AP has not been discovered yet.
5. To remove a blocked BSSID from the ACL, select the checkbox of the blocked AP entry you want to delete, click Delete, and then click OK.

Configure Scanning and Mitigation Settings with the Web UI

To configure rogue AP scanning and mitigation settings, follow these steps:

1. From the Web UI click Configuration > Wireless IDS/IPS > Rogue APs.

The Rogue AP screen appears with the Global Settings tab selected. See Figure 62.

Figure 64: Web UI Rogue AP Global Settings

2. In the Detection list, select one of the following:
   • On: Enables scanning for rogue APs.
   • Off: Disables rogue detection.
3. In the Mitigation list, select one of the following:

• No mitigation: No rogue AP mitigation is performed.
• Block all BSSIDs that are not in the ACL: Enables rogue AP mitigation of all detected BSSIDs that are not specified as authorized in the Allowed APs list.
• Block only BSSIDs in blocked list: Enables rogue AP mitigation only for the BSSIDs that are listed in the Blocked APs list.
• Block Clients seen on the wire: Enables rogue mitigation for any rogue station detected on the wired side of the AP (the corporate network, in many cases). When Block clients seen on the wire is selected, clients seen on the corporate network are mitigated. When Block clients seen on the wire is selected and the BSSID of the wired rogue client is entered in the blocked list (see “Alter the List of Blocked APs with the Web UI” on page 310) only listed clients are mitigated.

4. In the Rogue AP Aging box, type the amount of time that passes before the rogue AP alarm is cleared if the controller no longer detects the rogue. The value can be from 60 through 86,400 seconds.
5. In the Number of Mitigating APs text box, enter the number of APs (from 1 to 20) that will perform scanning and mitigation of rogue APs.
6. In the Scanning time in ms text box, enter the amount of time Mitigating APs will scan the scanning channels for rogue APs. This can be from 100 to 500 milliseconds.
7. In the Operational time in ms text box, enter the amount of time Mitigating APs will spend in operational mode on the home channel. This can be from 100 to 5000 milliseconds.
8. In the Max mitigation frames sent per channel text box, enter the maximum number of mitigation frames that will be sent to the detected rogue AP. This can be from 1 to 50 deauth frames.
9. In the Scanning Channels text box, enter the list of channels that will be scanned for rogue APs. Use a comma separated list from 0 to 256 characters. The complete set of default channels are

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165.

10.In the RSSI Threshold for Mitigation text box, enter the minimum threshold level over which stations are mitigated. The range of valid values is from to -100 to 0.

11.Click OK.

If a station that is already present in the discovered station database (learned wirelessly by the AP) is also discovered via DHCP broadcast on the APs wired interface, it implies that the station is connected to the same physical wired network as the AP. Such a station could potentially be a rogue device and is flagged by the controller as a wired rogue, indicating the rogue was identified as being present on the same wired network as the AP. If mitigation is enabled for wired rogue, mitigation action is performed accordingly on the rogue device.

 

Rogue AP Detection and Mitigation

Rogue APs are unauthorized wireless access points. These rogues can be physically connected to the wired network or they can be outside the building in a neighbor’s network or they can be in a hacker’s parked car. Valid network users should not be allowed to connect to the rogue APs because rogues pose a security risk to the corporate network. Rogue APs can appear in an enterprise network for reasons as innocent as users experimenting with WLAN technology, or reasons as dangerous as a malicious attack against an otherwise secure network. Physical security of the building, which is sufficient for wired networks with the correct application of VPN and firewall technologies, is not enough to secure the WLAN. RF propagation inherent in WLANs enables unauthorized users in near proximity of the targeted WLAN (for example, in a parking lot) to gain network access as if they were inside the building.

TABLE 19: Fortinet Support of Rogue Detection and Mitigation

	Rogue Detection	Rogue Mitigation
AP1000	4.1 and later	4.1 and later
AP400	5.0 and later	5.0 and later

Regardless of why a rogue AP exists on a WLAN, it is not subject to the security policies of the rest of the WLAN and is the weak link in an overall security architecture. Even if the person who introduced the rogue AP had no malicious intent, malicious activity can eventually occur. Such malicious activity includes posing as an authorized access point to collect security information that can be used to further exploit the network. Network security mechanisms typically protect the network from unauthorized users but provide no means for users to validate the authenticity of the network itself. A security breach of this type can lead to the collection of personal information, protected file access, attacks to degrade network performance, and attacks to the management of the network.

To prevent clients of unauthorized APs from accessing your network, enable the options for both scanning for the presence of rogue APs and mitigating the client traffic originating from them. These features are set globally from either the CLI or Web UI, with the controller managing the lists of allowable and blocked WLAN BSSIDs and coordinating the set of APs (the mitigating APs) that perform mitigation when a rogue AP is detected.

As a result of the channel scan, a list of rogue APs is compiled and sent by the controller to a number of mitigating APs that are closest to the rogue AP. Mitigating APs send mitigation

307

(deauth) frames to the rogue AP where clients are associated to remove those clients from the network. This presence of the rogue AP generates alarms that are noted on the Web UI monitoring dashboard and via syslog alarm messages so the administrator is aware of the situation and can then remove the offending AP or update the configuration list.

Rogue Scanning can be configured so that it is a dedicated function of a radio on a dual radio AP or a part time function of the same radio that also serves clients. When rogue AP scanning (detection) is enabled, for any given period, an AP spends part of the time scanning channels and part of the time performing normal AP WLAN operations on the home channel. This cycle of scan/operate, which occurs on a designated AP or an AP interface without assigned stations, ensures there is no network operation degradation.

For AP400 and AP1000, each radio is dual band (supports both 2.4GHz and 5.0GHz) and capable of scanning for all channels and all bands when configured as a dedicated scanning radio. As access points are discovered, their BSSID is compared to an AP access control list of BSSIDs. An access point might be known, blocked, or nonexistent on the access control list. A “known” AP is considered authorized because that particular BSSID was entered into the list by the system administrator. A “selected” AP is blocked by the Wireless LAN System as an unauthorized AP. The Fortinet WLAN also reports other APs that are not on the access control list; these APs trigger alerts to the admin console until the AP is designated as known or selected in the access control list. For example, a third party BSS is detected as a rogue unless it is added to the access control list.

Fortinet APs also detect rogue APs by observing traffic either from the access point or from a wireless station associated to a rogue. This enables the system to discover a rogue AP when the rogue is out of range, but one or more of the wireless stations associated to it are within range.

Configuring Rogue AP Mitigation with Web UI

To prevent clients of unauthorized APs from accessing your network, enable the options for both scanning for the presence of rogue APs and mitigating the client traffic originating from them. These features are set globally, with the controller managing the lists of allowable and blocked WLAN BSSIDs and coordinating the set of APs (the Mitigating APs) that perform mitigation when a rogue AP is detected.

Configuring Rogue AP Mitigation with Web UI

You can create a white-list of APs that will perform rogue detection. Other APs that are not added to this white-list will not scan for rogue AP/clients.

When rogue AP scanning (detection) is enabled, for any given period, the AP spends part of the time scanning channels (determined by the setting Scanning time in ms), and part of the time performing normal AP WLAN operations on the home channel (determined by the setting Operational time in ms). This cycle of scan/operate repeats so quickly that both tasks are performed without noticeable network operation degradation.

The channels that are scanned by a particular AP are determined by the model of the AP. As a result of the channel scan, a list of rogue APs is compiled and sent by the controller to a number of Mitigating APs that are closest to the rogue AP. Mitigating APs send mitigation (deauth) frames to the rogue AP where clients are associated to remove those clients from the network. This presence of the rogue AP generates alarms that are noted on the Web UI monitoring dashboard and via syslog alarm messages so the administrator is aware of the situation and can then remove the offending AP or update the configuration list.

As well, if a rogue device seen on the wired interface of the AP and if the device is in the AP’s discovered list of stations a wired rogue notification will be sent via the Web UI monitoring dashboard and syslog alarm message. If the rogue client is associated with the AP, that client is also classified as a rogue.

Alter the List of Allowed APs with the Web UI

To change the list of allowed APs, follow these steps:

1. From the Web UI, Enable rogue detection from Configuration > Security > Rogue APs > Global Settings page.

Configuring Rogue AP Mitigation with Web UI

Alter the List of Blocked APs with the Web UI

To change the list of allowed APs, follow these steps:

Configuring Rogue AP Mitigation with Web UI

1. From the Web UI click Configuration > Security > Rogue APs > Blocked APs. The table shows information about access points listed as blocked BSSIDs in the access control list (ACL).
2. To see an updated list of the APs blocked in the WLAN, click Refresh.
3. To add an AP to the blocked list, click Add.
   • In the BSSID box, type the BSSID, in hexadecimal format, of the access point. Add the BSSID to the ACL, by clicking OK.
4. The blocked BSSID now appears on the list with the following information:
   • BSSID The access point’s BSSID.
   • Creation Time The timestamp of when the blocked AP entry was created.
   • Last Reported Time The time the AP was last discovered. If this field is blank, the AP has not been discovered yet.
5. To remove a blocked BSSID from the ACL, select the checkbox of the blocked AP entry you want to delete, click Delete, and then click OK.

Configure Scanning and Mitigation Settings with the Web UI

To configure rogue AP scanning and mitigation settings, follow these steps:

1. From the Web UI click Configuration > Security > Rogue APs > Global Settings.

The Rogue AP screen appears with the Global Settings tab selected. See Figure 62.

Figure 62: Web UI Rogue AP Global Settings

2. In the Detection list, select one of the following:

Configuring Rogue AP Mitigation with Web UI

• On: Enables scanning for rogue APs. Off: Disables rogue detection.

3. In the Mitigation list, select one of the following:
   • No mitigation: No rogue AP mitigation is performed.
   • Block all BSSIDs that are not in the ACL: Enables rogue AP mitigation of all detected BSSIDs that are not specified as authorized in the Allowed APs list.
   • Block only BSSIDs in blocked list: Enables rogue AP mitigation only for the BSSIDs that are listed in the Blocked APs list.
   • Block Clients seen on the wire: Enables rogue mitigation for any rogue station detected on the wired side of the AP (the corporate network, in many cases). When Block clients seen on the wire is selected, clients seen on the corporate network are mitigated. When Block clients seen on the wire is selected and the BSSID of the wired rogue client is entered in the blocked list (see “Alter the List of Blocked APs with the Web UI” on page 310) only listed clients are mitigated.
4. In the Rogue AP Aging box, type the amount of time that passes before the rogue AP alarm is cleared if the controller no longer detects the rogue. The value can be from 60 through 86,400 seconds.
5. In the Number of Mitigating APs text box, enter the number of APs (from 1 to 20) that will perform scanning and mitigation of rogue APs.
6. In the Scanning time in ms text box, enter the amount of time Mitigating APs will scan the scanning channels for rogue APs. This can be from 100 to 500 milliseconds.
7. In the Operational time in ms text box, enter the amount of time Mitigating APs will spend in operational mode on the home channel. This can be from 100 to 5000 milliseconds.
8. In the Max mitigation frames sent per channel text box, enter the maximum number of mitigation frames that will be sent to the detected rogue AP. This can be from 1 to 50 deauth frames.
9. In the Scanning Channels text box, enter the list of channels that will be scanned for rogue APs. Use a comma separated list from 0 to 256 characters. The complete set of default channels are

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165.

10.In the RSSI Threshold for Mitigation text box, enter the minimum threshold level over which stations are mitigated. The range of valid values is from to -100 to 0.

11.Click OK.

Configuring Rogue AP Detection Using the CLI

These CLI commands configure rogue detection; for a complete explanation of the commands, see the FortiWLC (SD) Command Reference.

Configuring Rogue AP Detection Using the CLI

Adding APs to Scan List

default(15)# configure terminal default(15)(config)# rogue‐ap detection‐ap 1 default(15)(config)# rogue‐ap detection‐ap 3 default(15)(config)# exit

Show Output default(15)# sh rogue‐ap detection‐ap‐list

AP ID

1    

3    

        Rogue Device Detecting APs(2)

Deleting APs from Scan list

default(15)# configure terminal           default(15)(config)# no rogue‐ap detection‐ap 1 default(15)(config)# no rogue‐ap detection‐ap 3 default(15)(config)# end

Show Output default(15)# show rogue‐ap detection‐ap‐list

AP ID

        Rogue Device Detecting APs(No entries)

Configuring the AP Access and Block Lists with the CLI

The feature uses an Access Control List (ACL) containing a list of allowed BSSIDs and a list of Blocked BSSIDs. By default, all Fortinet ESS BSSIDs in the WLAN are automatically included in the allowed ACL. A BSSID cannot appear in both lists.

To add an access point with a BSSID of 00:0e:cd:cb:cb:cb to the access control list as an authorized access point, type the following:

controller (config)# rogue‐ap acl 00:0e:cd:cb:cb:cb controller (config)#

Configuring Rogue AP Detection Using the CLI

To see a listing of all BSSIDs on the authorized list, type the following:

controller# show rogue-ap acl

Allowed APs

BSSID

00:0c:e6:cd:cd:cd 00:0e:cd:cb:cb:cb

A BSSID cannot be on both the blocked list and the access list for rogue AP detection at the same time. Suppose 00:0c:e6:cd:cd:cd is to be placed on the blocked list. If this BSSID is already on the authorized list, you must remove the BSSID from the authorized list, and then add the BSSID to the blocked list, as follows:

controller (config)# no rogue‐ap acl 00:0c:e6:cd:cd:cd controller (config)# controller (config)# rogue‐ap blocked 00:0c:e6:cd:cd:cd                                 controller (config)# exit controller# show rogue-ap acl

Allowed APs

BSSID

00:0e:cd:cb:cb:cb controller# show rogue-ap blocked

BssId               Creation Date   Last Reported

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐   ‐‐‐‐‐‐‐‐‐‐‐‐‐‐  ‐‐‐‐‐‐‐‐‐‐‐‐‐‐

00:0c:e6:cd:cd:cd   11/02 01:05:54   11/02 01:06:20

The commands to enable and confirm the rogue AP detection state are as follows:

controller (config)# rogue‐ap detection controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : none

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 3

Number of Mitigating APs               : 5

Scanning time in ms                    : 100

Operational time in ms                 : 400

Max mitigation frames sent per channel : 10

Scanning Channels                      :

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165 RSSI Threshold for Mitigation          : ‐100

Use the CLI command show rogue-ap-list to display all rogue clients and APs in the network.

Rogue Mitigation Example

Rogue AP mitigation for APs in the blocked list is enabled and confirmed as follows:

Configuring Rogue AP Detection Using the CLI

 

controller# configure terminal controller (config)# rogue‐ap detection controller (config)# rogue-ap mitigation selected controller (config)# exit controller# show rogue-ap globals

Global Settings

Detection                              : on

Mitigation                             : selected

Rogue AP Aging (seconds)               : 60

Number of Candidate APs                : 3

Number of Mitigating APs               : 5

Scanning time in ms                    : 100

Operational time in ms                 : 400

Max mitigation frames sent per channel : 10

Scanning Channels                      :

1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64,149,153,157,161,165 RSSI Threshold for Mitigation          : ‐100

Social Authentication Support

The captive portal authentication process now supports Fortinet Presence as an external CP authentication server that allows users to authentication using social media accounts like Facebook or Gmail OAuth.

Supported APs: AP122, AP822, AP832, OAP832, FAP-U421EV and FAP-U423EV.

Before proceeding, note the following:

• Enable location service in the controller(See “Configuring FortiPresence API” on page 86. for more details).
• Assign the AP in the data analytics store.
• Not supported in “Bridge mode”.

To enable social authentication support, do the following:

1. Create captive portal exemptions profile
2. Configure captive portal profile to use Fortinet Presence
3. Enable this captive portal profile in security profile and add this security profile in the ESS profile.

Social Authentication Support

Create Captive Portal Exemptions Profile

To enable social login, create a profile with the list of exempted URLs and in the captive portal profile and select FortiPresence as the external authentication server.

1. Go to Configuration > Security > Captive Portal > Captive Portal Exemptions.
2. Click the Add button to create a profile with the list of URLs that will be allowed for social authentications. To add multiple URLs to a profile, enter a space after each URL entry. You can add up to 32 URLs

Social Authentication Support

Configure Captive Portal Profile to use Fortinet Presence

1. Go to Configuration > Security > Captive Portal > Captive Portal Profiles page
2. Create a captive portal profile with local or radius as authentication type.
   • If Authentication type is Local, then create a guest user with the following credentials: username: gooduser
   • password:good. If Authentication type is RADIUS, then in that RADIUS server, create a user with the following credentials: • username: gooduser
   • password:good.
3. Make the following changes to External Portal Settings:
4. Select Fortinet-Presence as the external server (1).
5. Select the profile (2) created with the exempted URLs.
6. Enter http://socialwifi.fortipresence.com/wifi.html?login as URL (3) in the external portal

URL.

Social Authentication Support

For Fortinet Presence server configuration and account, see the FortiPresence configuration guide: http://docs.fortinet.com/d/fortipresence-analytics-configuration-guide

Enable this captive portal profile in security and ESS profiles

Enable the captive portal profile in the security profile and map the security profile in the ESS Profile.  In the security profile, make the following changes to the CAPTIVE PORTAL SETTINGS section:

1. Set Captive Portal to Webauth.
2. Select the captive portal created for enabling social wifi login.
3. Set Captive Portal Authentication Method as External.

 

OAuth Authentication Support

FortiWLC (SD) along with Fortinet Connect (MCT) 14.10.0.2 supports OAuth authentication for captive portal users. In a typical scenario if a user (for example: a hotel guest) tries to access an external web site, they are re-directed to a captive portal page for authentication. In

OAuth Authentication Support

the captive portal page, the user must register with a username, password, e-mail etc and complete the authentication process after receiving confirmation from the hotel captive portal.

• OAuth support must be enabled in the Fortinet Connect
• Only wireless clients that access SSL3 enabled (HTTPS) destination can use this feature
• If the wireless client uses a proxy server located on the wired network, then the client will be granted access to the internet till the login timeout expires.
• Supported only for ESS profiles in tunneled mode.
• Supported only for IPv4 clients.

By enabling OAuth, users can use any of the social media (Facebook, Google, Twitter, OpenID, etc) login credentials that support OAuth for captive portal authentication. For your users, this alleviates the need to spend time to register or remember passwords for repeated authentication.

Configure a RADIUS Server for Captive Portal Authentication

Configure a RADIUS Server with Web UI for Captive Portal Authentication

You can, for authentication purposes, set up the identity and secret for the RADIUS server. This takes precedence over any configured User IDs but if RADIUS accounting fails over, the local authentication guest user IDs are used. To do this, follow these steps:

1. Click Configuration > Security > RADIUS to access the RADIUS Profile Table.
2. Click Add.
3. Provide the RADIUS server information.
4. Save the configuration by clicking OK.
5. Enable a security profile for use with a Captive Portal login page by clicking Configuration > Security > RADIUS > Add.
6. Provide the required information, such as the name of the RADIUS profile. L2MODE must be clear to use Captive Portal. Set the Captive Portal to WebAuth and adjust any other parameters as required.

The identity and secret are now configured.

Configure a RADIUS Server with CLI for Captive Portal Authentication

The CLI command ssl-server captive-portal authentication-type configures the controller to use either local authentication, RADIUS authentication, or both. If both is selected, local authentication is tried first; if that doesn’t work, RADIUS authentication is attempted.

Controller(config)# ssl‐server captive‐portal authentication‐type ? local                  Set Authentication Type to local. local‐radius           Set Authentication Type to Local and RADIUS. radius                 Set Authentication Type to RADIUS.

The following example configures an authentication RADIUS profile named radius-auth-pri.

/* RADIUS PROFILE FOR AUTHENTICATION */ default# configure terminal

default(config)# radius‐profile radius‐auth‐pri default(config‐radius)# ip‐address 172.27.172.3 default(config‐radius)# key sept20002 default(config‐radius)# mac‐delimiter hyphen default(config‐radius)# password‐type shared‐secret default(config‐radius)# port 1812 default(config‐radius)# end

Configure a RADIUS Server for Captive Portal Authentication

default#

default# sh radius‐profile radius‐auth‐pri

RADIUS Profile Table

RADIUS Profile Name   : radius‐auth‐pri

Description           :

RADIUS IP             : 172.27.172.3

RADIUS Secret         : *****

RADIUS Port           : 1812

MAC Address Delimiter : hyphen

Password Type         : shared‐secret

The following example configures a security RADIUS profile named radius-auth-sec.

default# configure terminal default(config)# radius‐profile radius‐auth‐sec default(config‐radius)# ip‐address 172.27.172.4 default(config‐radius)# key sept20002 default(config‐radius)# mac‐delimiter hyphen default(config‐radius)# password‐type shared‐secret default(config‐radius)# port 1812 default(config‐radius)# end default#

default# sh radius‐profile radius‐auth‐sec

RADIUS Profile Table

RADIUS Profile Name   : radius‐auth‐pri

Description           :

RADIUS IP             : 172.27.172.4

RADIUS Secret         : *****

RADIUS Port           : 1812

MAC Address Delimiter : hyphen Password Type         : shared‐secret

Third-Party Captive Portal Solutions

Instead of using the Fortinet Captive Portal solution, you can use a third-party solution; you cannot use both. Companies such as Bradford, Avenda, and CloudPath all provide Captive Portal solutions that work with FortiWLC (SD) 4.1 and later. There are two places that you need to indicate a third-party captive portal solution, in the corresponding Security Profile and in the Captive Portal configuration.

Configure Third-Party Captive Portal With the Web UI

Indicate that a third-party Captive Portal solution will be used in the Security Profile by setting Captive Portal Authentication Method to external. For complete directions, see Configure a Security Profile With the Web UI.

Indicate that a third-party Captive Portal solution will be used in the Captive Portal configuration by setting Captive Portal External URL to the URL of the Captive Portal box:

Third-Party Captive Portal Solutions

1. Click Configuration > Security > Captive Portal.
2. Change the value for CaptivePortal External URL to the URL of the third-party box.
3. Click OK.

Configure Third-Party Captive Portal With the CLI

Configure an SSL server before configuring third-party captive portal in the security profile. For example, example of SSL server configuration:

controller1# show ssl‐server Captive Portal

Name                                         : Captive Portal

Server Port                                  : 10101

User Authentication Protocol                 : None

Server Lifetime                              : 100

Server IP                                    : 172.18.37.223

Certificate                                  :

Authentication Type                          : radius Primary Profile                              : IDAU1721946201

Secondary Profile                            :

Primary Profile                              : IDAC1721946201 Secondary Profile                            :

Accounting Interim Interval (seconds)        : 60

CaptivePortalSessionTimeout                  : 0 CaptivePortalActivityTimeout                 : 0 Protocol                                     : https

Portal URL                                   :

CaptivePortal External URL                   : https://172.19.46.201/portal/

172.18.37.223?meruInitialRedirect

CaptivePortal External IP                    : 172.18.37.223

L3 User Session Timeout(mins)                : 1

Apple Captive Network Assistant (CNA) Bypass : on Example of configuring SSID with external captive portal:

controller1# configure terminal  controller1(config)# security‐profile CPExternal

controller1(config‐security)# captive‐portal‐auth‐method external controller1(config‐security)# passthrough‐firewall‐filter‐id IDMAUTH controller1(config)# essid CaptivePortal‐External

controller1(config‐essid)# security‐profile CaptivePortal‐External controller1(config‐essid)# end

Third-Party Captive Portal Solutions