Introduction

Initial configuration and deployment of threatER Enforce for Wifi will be performed utilizing the router's console and the cloud-based threatER Portal. We suggest that prior to configuring Enforce, you review this documentation in its entirety and that the security policies specific to your organization are considered. 

If you have any issues configuring Enforce for Wifi, please contact us at support@threater.com. 

Initial Configuration

Configuring Enforce for Wifi via the Console

Connect an ethernet cable to the HIGHEST numbered (labeled port '4') WAN port on the rear of the Lanner NCA-1040SEB. That should be run to your ethernet wall jack or your ISP modem or whatever infrastructure leads to your existing Internet. The router will automatically pull an IP from it via DHCP for the WAN side, and this is how the router will connect to the Internet.

Next, connect the serial console cable to the port labeled CONSOLE on the front of the unit, and then the USB side to your laptop.

Lanner NCA-1040SEB router:

When connecting a laptop to the console port, you can use Putty, a text terminal or terminal emulation program, Screen on Linux, etc. The port settings are: 

• Baud: 38400
• Data Bits: 8
• Parity: None
• Stop Bits: 1

Power on the WiFi Enforcer unit.

You will see the serial port start to display boot-related information. First the BIOS screen stuff, then grub, then it will start the boot messages in the format '[ timestamp] stuff'. Eventually that will slow down/stop at around the 20 second timestamp mark.

At that point, when you hit Enter, you'll see the initial status information, and it will have a few 'pass', 'fail', and 'warn' markers, all of which are NORMAL since this is the first-time config:

You’ll notice you are automatically logged in with root credentials. This is the default behavior during our alpha/beta period. When we go full GA, this will be able to be locked down via a configuration element from within Portal.

You’ll now need to activate your WiFi Enforcer. You do this by running the command enforce_cli license activate from the serial console:

root@Enforcer:~# enforce_cli license activate

You will be asked for the name of the Enforcer as you would like it to appear in Portal, your existing portal username tied to your account, and your existing password for your portal account.

Upon successful entry of the credentials, you will see:

Successfully retrieved new license.

If, on the other hand, you fat-finger your credentials, you might see an error message such as: 

Error activating Enforce: status code: 403, response: AccessDenied (403) : Invalid user account or password

If you get that or another error message, make sure you are using your proper existing Portal username and password when activating. This is a critical step since it is the mechanism used to associate your WiFi Enforcer to your portal account.

Once the license is successfully retrieved, you will be able to see the Enforcer in the portal. In this example, the name E4WT was used during activation so that is how it initially appears in our Portal account:

You’ll notice a few things: there’s a red pip on it, no subscription is attached, and the bridge state reads ‘Not Protected’. 

We must now assign a valid subscription. Click the drop down and assign a valid subscription, then click the Save icon. After a successful save, you will see a green pip and the assigned subscription:

But notice that the bridge state still reads Not Protected. That’s because we haven’t finished the configuration on the WiFi Enforcer side yet to specify the ports we’ll be protecting. Let’s do that now.

Back on the serial port control screen, enter the command enforce_cli status refresh:

root@Enforcer:~# enforce_cli status refresh

This step will refresh the activation of the subscription in the software, which may take a few minutes. After waiting a few minutes, then check the current status using the command enforce_cli status:

You’ll notice that the license and software_bypass settings both now read ‘pass’. This is because we just finished up the license activation to portal and assigned a valid subscription.

But the ‘ports’ entry still shows a red fail, since we haven’t configured the ports we’ll be protecting yet. We’re going to want to protect the full LAN-side bridge, to include the WiFi 5G and 2G networks, but before we can do that, we must enable them. By default, for wireless security reasons, the system will NOT enable the radios on its own. You must enable them yourself when you are ready to enable wireless access.

Once we take the product out of alpha/beta to full GA, you will be able to easily toggle the enabled state of the radios from within Portal. But for now, during the alpha/beta period, you should accomplish this directly from the serial port console command line by issuing the following four commands in order, one after the other:

root@enforcer:~# uci set wireless.radio0.disabled=0
root@enforcer:~# uci set wireless.radio1.disabled=0
root@enforcer:~# uci commit wireless
root@enforcer:~# wifi

After issuing the final wifi command, you’ll see a few messages formatted ‘[ timestamp] stuff’ relating to the WiFi radios being enabled. It will likely resemble messages as shown below (but could differ slightly in your environment):

[ 1463.473003] br-lan: port 4(phy0-ap0) entered blocking state
[ 1463.489706] br-lan: port 4(phy0-ap0) entered disabled state
[ 1463.506405] mt7915e 0000:0f:00.0 phy0-ap0: entered allmulticast mode
[ 1463.525486] mt7915e 0000:0f:00.0 phy0-ap0: entered promiscuous mode
[ 1463.666407] br-lan: port 4(phy0-ap0) entered blocking state
[ 1463.683099] br-lan: port 4(phy0-ap0) entered forwarding state
[ 1463.923142] br-lan: port 5(phy1-ap0) entered blocking state
[ 1463.939841] br-lan: port 5(phy1-ap0) entered disabled state
[ 1463.956522] mt7915e 0000:0f:00.0 phy1-ap0: entered allmulticast mode
[ 1463.975593] mt7915e 0000:0f:00.0 phy1-ap0: entered promiscuous mode
[ 1463.994403] br-lan: port 5(phy1-ap0) entered blocking state
[ 1464.011068] br-lan: port 5(phy1-ap0) entered forwarding state
[ 1464.478813] br-lan: port 5(phy1-ap0) entered disabled state
[ 1464.495587] br-lan: port 5(phy1-ap0) entered blocking state
[ 1464.512260] br-lan: port 5(phy1-ap0) entered forwarding state

At this point, the WiFi radios are configured to be enabled. We will now use the command enforce_cli port add br-lan to protect the entire LAN bridge. This means that the WiFi 2G radio, 5G radio, and any local hardwired ports you connect across eth0, eth1, and eth2 (physically labeled by Lanner as ports ‘1’, ‘2’ and ‘3’ respectively on the rear of the Lanner NCA-1040SEB) will all be protected:

root@enforcer:~# enforce_cli port add br-lan
Successfully enabled port protection for br-lan

After a few seconds, you can run the following two commands to refresh and retrieve the status:

root@Enforcer:~# enforce_cli status refresh (then wait a few minutes)
root@Enforcer:~# enforce_cli status

You should then see everything is now marked with a green pass mark:

Completing Configuration in the threatER Portal

Confirming Enforcer Connection

To confirm that your Enforcer is connecting to the threatER Portal as expected, click on Enforce in the left menu and then select Enforcers. From here, you should see your newly registered Enforcer with a current last connection time. The connection from the Enforcer to the threatER Portal is refreshed once per minute. For all Enforce for Wifi deployments, you’ll see a WiFi bubble in the Bridge State column on the Enforcer page in portal:

Enforce for Wifi Configuration

Navigate to the Portal > Enforcers > Enforce > select the Enforcer hyperlinked name. Under the Configuration section you can confirm Settings, set up Syslog export, and confirm the NTP server.

Under Settings, you may enter the Hostname for the wifi router. In the Timezone field, change the time zone from UTC to the time zone for the location where Wifi for Enforce will be deployed. 

Syslog exports are an industry-standard and time-proven way of exporting data in a concise, standards-based manner. Our syslog export format is compliant to RFC-5424. This ensures seamless integration alongside any number of external tools, including popular security information and event management (SIEM) tools, such as Splunk and IBM QRadar, as well as popular data analytics tools like Gravwell, and even full open-source tools like syslog-ng.

Under Syslog export, you may configure Enforce for Wifi to export logs to your syslog server, SIEM, or other log storage solution. Unlike a standard Enforce deployment, the logs for Enforce for Wifi are not accessible through a user interface. Therefore, threatER strongly recommends exporting the logs for visibility.

Click the 'New' button to enter the log host address, port, and an option description. For more information on utilizing this feature, please see our documentation on Enforce Syslog Export Configuration and Formats.

Enforce for Wifi uses an NTP server so that the clock on your router is properly synchronized. By default, the software leverages the time.google.com NTP server. 

You also have the option to add your own NTP server by going to New, adding a valid IP or domain host and selecting Create. If you don't have your own NTP server, we recommend using a public NTP such as time.google.com or pool.ntp.org (for your region). 

Confirmation of the sync will be indicated by a green clock alert icon next to NTP Servers title. It might take a few minutes for the server to sync with the Enforce for Wifi.

Configuring Policies and Networks

Reach out to your customer success manager or customersuccess@threater.com to confirm your Polices and Networks. Customers deploying threatER Enforce for the first time will want to verify all configuration steps and set up lists, policies and networks. Our customer support team offers a guided onboarding program including a 1 hour configuration and training call with your customer success manager. 

Configuring Policies

Policies allow users to determine what is allowed through networks or ports. Users can create as many policies as they need to protect each of their networks as there isn't a limit to the number of policies that can be created.

For new customers deploying Enforce for the first time, you will want to create policies in the threatER Portal. Please see our documentation on Configuring Policies before continuing with your configuration. If you have previously created policies, and intend to use the same policies on the Enforcer you are presently configuring, please move to the next step.

Configuring Networks

Enforce inspects Network traffic to determine which packets to block and allow. Policies attached to Networks determine the internet services allowed into your network, as well as those services your local users can access outside the network.

One or more network rules comprise a Network, and each network is identified as a device, asset, or subnet on your network. If the Enforcer receives traffic for the configured IP, then it will allow traffic according to the policy associated with the Network. Each Network configuration includes a protocol and port, or range of ports, so that you may restrict specific policy activity to as granular a level as required.

For new customers deploying Enforce for the first time, you will want to create a Network in the threatER Portal. Please see our documentation on creating Networks before continuing with your configuration. If you have previously configured a Network, and intend to assign this Enforcer to that network, please see our documentation on editing Networks in order to assign the new Enforcer to the existing network.

Deployment

Once you’ve completed the steps above, and allowed any list/policy/network/mapping changes to sync down to the WiFi Enforcer (which usually takes no more than a few minutes), you can safely connect to the WiFi in completely protected fashion.

By default, your endpoint devices (laptops, phones, IoT devices, systems, etc) will be able to see the 5G WiFi network broadcast as SSID Enforcer_5G, and the 2G WiFi network will broadcast as SSID Enforcer_2G:

You’ll notice that by default security is enabled. Both radios are initially configured in the alpha/beta release to use WPA2-PSK with an initial WiFi password of ‘enforce!’ for both SSIDs. In our GA release, these will be modifiable from within Portal. 

For now, during the alpha/beta period, you can adjust the SSID names and the security configurations directly from within OpenWrt if you are so inclined. 

Although detailed OpenWrt configuration is beyond the scope of our standard Onboarding, Appendix A below can be useful for advanced users who need access to lower level OpenWrt implementation details.

Appendix A

To access the stock OpenWrt configuration screens, you simply connect to the WiFi and navigate your browser to the IP of the WiFi router. By default, it comes configured to use 192.168.1.1. If you forget or it gets changed downstream, you can always see its current LAN-side IP in Portal:

Do keep in mind though that you MUST be logged into the WiFi or plugged into one of the bridged LAN ports in order to access the OpenWrt configuration screens by pointing your browser to the proper admin IP with either http or https. 

Note that if you use https, you will need to accept the browser security exception, as initial installations include only a self-signed cert.

When navigating to http://192.168.1.1 or https://192.168.1.1 in this example, you’ll be presented with a login screen. The default username is root and the default password is enforce:

Once authenticated, you will be presented with the standard OpenWrt luci web interface, albeit with a ‘Threater Enforce’ skin applied to it. 

You’ll find that most stock OpenWrt functionality is made available, but you should be cognizant of the intricacies of WiFi routing. In the same way you wouldn’t mess with core switch configurations, you should not make willy-nilly changes to the WiFi router settings unless you are absolutely sure you know what you are doing. If you are not careful, you could conceivably lock out your endpoints from WiFi or Internet access, so tread carefully. 

If you get into an irrecoverable state, all hope is not lost, because you can always do a full reinstall of our WiFi Enforcer via a USB ISO image that can be supplied by our Customer Success team and then you can fully re-Onboard the unit. But obviously this is a last resort only in the case that you’ve inadvertently bricked a unit, and of course it would require you to have physical access to recover a system in that fashion.

Note that OpenWrt has a huge user community and various online help forums such as reddit and stackoverflow.com are great resources for learning about various OpenWrt configuration options. There isn’t much that OpenWrt can’t do.

And layered with Threater Enforce, it’s a seamless way to enjoy protected access for your office environments in a straightforward way, leveraging the exact same portal-managed Threater policies that you’re used to in our traditional datacenter-oriented bump-in-the-wire architectures.