Access restriction to Ubiquiti over IP using Firewall

For the test, I’ll take the airMAX Rocket M5 sector antenna in bridge mode and the airMAX NanoBeam M5 client antenna in router mode.

Restrict access first to the client.
Suppose that it is connected to the sector and has an IP address 192.168.110.40 which looks into the Internet (obtained via DHCP).
The IP of the administrator who should have access to it remotely is 10.10.10.5, the rest must be blocked.

And so, go to the airMAX NanoBeam M5 web interface, open the “NETWORK” tab, next to “Configuration Mode:” select “Advanced”, then more settings will appear.
At the bottom where the “Firewall” tick the “Enable”.

Just below we add a rule specifying:
Target: DROP
Interface: WLAN0
IP Type: TCP
Source: 10.10.10.5 (IP from which it is allowed to connect, as well as be sure to put a tick in front of it under the exclamation mark)
Port: leave empty
Destination: 192.168.110.40 (An antenna IP that looks out)
Port: 22 (This is an SSH port, similarly, other rules are created to restrict access to the HTTP port – TCP 80, HTTPS – TCP 443, Telnet – TCP 23, SNMP – UDP 161, Discovery – UDP 10001)

As you can see, this rule blocks all TCP connections to port 22 of the WLAN0 interface on IP 192.168.110.40, and the set check mark on ! before Source: 10.10.10.5 means that everything except this IP is blocked.

Click “Add”, then “Change” at the bottom and at the top of “Apply” to apply the changes, after that the antenna will restart.

To limit access to the sector antenna that is configured by the bridge, we add the same rules, only where the Interface: we specify ANY (ALL).

Is done.

After adding rules and connecting to a device via SSH in the configuration, you can see the following:

ebtables.status=enabled
ebtables.1.status=enabled
ebtables.1.cmd=-A FIREWALL -p 0x0800 --ip-protocol 6 --ip-src ! 10.10.10.5/32 --ip-dst 192.168.110.40/32 --ip-dport 22 -j DROP
ebtables.1.comment=
ebtables.2.status=enabled
ebtables.2.cmd=-A FIREWALL -p 0x0800 --ip-protocol 6 --ip-src ! 10.10.10.5/32 --ip-dst 192.168.110.40/32 --ip-dport 80 -j DROP
ebtables.2.comment=
ebtables.3.status=enabled
ebtables.3.cmd=-A FIREWALL -p 0x0800 --ip-protocol 6 --ip-src ! 10.10.10.5/32 --ip-dst 192.168.110.40/32 --ip-dport 443 -j DROP
ebtables.3.comment=
ebtables.4.status=enabled
ebtables.4.cmd=-A FIREWALL -p 0x0800 --ip-protocol 17 --ip-src ! 10.10.10.5/32 --ip-dst 192.168.110.40/32 --ip-dport 161 -j DROP
ebtables.4.comment=

See also my article:
Ubiquiti SSH control

Installing UNMS (Ubiquiti Network Management System)

UNMS (Ubiquiti Network Management System) – EdgeMAX®, EdgeSwitch®, airMAX®, UFiber device management system, which includes software updates, configuration backup, real-time performance graphs, notifications, device location maps, etc.

For example, I will install UNMS on Ubuntu Server 18.04 64bit.

First, install the necessary components:

sudo apt-get update
sudo apt-get install curl sudo bash netcat

Download the installation script from the official site to the temporary directory:

curl -fsSL https://unms.com/install > /tmp/unms_inst.sh

Run the downloaded script:

sudo bash /tmp/unms_inst.sh

If it is necessary to change the web ports during the installation:

sudo bash /tmp/unms_inst.sh --http-port 8080 --https-port 8443

By default, UNMS uses Let’s Encrypt when creating SSL certificates for your domain and saves them in /home/unms/data/cert/live.
If you want to use your SSL certificates, then during installation, for example, we specify (UNMS should have read rights in ssl-cert-dir):

sudo bash /tmp/unms_inst.sh --http-port 8080 --https-port 8443 --ssl-cert-dir /etc/certificates --ssl-cert fullchain.pem --ssl-cert-key privkey.pem

UBNT with firmware 6.0 stop working

I once treated Ubiquiti Networks airMAX® M Series devices with firmware 5+ from the exploit and updated the firmware to the latest, at that time it was the version of XM 6.0 and XW 6.0.
See my article – Removing exploits from Ubiquiti devices

In the 6.0 firmware, the vulnerability was removed through which the exploit was accessed, but there were other bugs.

Literally a couple of weeks later I noticed that there are no connected stations on some bridges in the Access Point (AP) mode, power was lost from the station, the station was booted and connected to the AP, but the AP did not show the connected stations and the traffic did not pass, it’s just and there is a bug.

Solve the problem by restarting the AP, in the future, if the power supply was lost again on the station or it was reboot, there was a high probability of a repetition of this problem.

Fortunately, this problem was later eliminated in new firmware, I did not exactly look at which version, but on devices with firmware 6.1+ it was no longer observed.

When is it necessary to activate Long Range PtP Link Mode on airMAX?

In normal mode, airMAX sends a confirmation frame (ACK) after receiving the data frame, but at longer distances, it is better to disable this mechanism by setting the Long Range PtP Link Mode checkbox in the settings.

Depending on the channel width, the distance at which you want to turn on the Long Range PtP Link Mode can be different.

40MHz: 16.5 miles (26.5 km)
20MHz: 35.6 miles (57.3 km)
10MHz: 72.3 miles (116 km)
5MHz: 144.7 miles (232.9 km)

Note: this information does not apply to airOS 7, there is another timeout ACK algorithm.

Monitoring the number of Ubiquiti sector clients by SSH from Zabbix

On the test I’ll give an example of getting the number of clients connected to the usual sectoral antenna Ubiquiti AirMax Rocket M5.
We will receive the data via SSH.

To test once we connect to the device (the first time when connecting, type yes and press enter):

sudo -u zabbix ssh -p 22 admin@192.168.0.55

Now in Zabbix we add the data element to the template or host, for example with the name “Template Ubiquiti Rocket M5 Sector”:

Name: any
Type: SSH agent
Key: ssh.run[clients,,22,utf8]
Authentication method: Password
Username: NAME
Password: PASSWORD
Executed script: the command executed on the device (see below)

Example of the command displayed the number of connected clients:

wstalist |grep "mac" |wc -l

Accordingly, we create a graph for the data element, as well as the trigger:

Name: On the sector antenna {HOST.NAME} > 40 clients
Expression: {Template Ubiquiti Rocket M5 Sector:ssh.run[clients,,22,utff8].last(#1)}>40

See also:
Configuring SSH checks in Zabbix

SNMP MIBs and OIDs for Ubiquiti PowerBeam 5AC

I wrote a template for Ubiquiti PowerBeam 5AC for Zabbix and explored several basic SNMP OIDs for which you need to draw graphics.
OID tested for devices that are configured in Station mode and with firmware v7.1.4 (XC).

You can check the OID from a Linux command, for example:

snmpwalk -v 1 -c public 192.168.1.20 .1

First of all, I looked at what interfaces there are (if you add VLAN, etc. on the device, their number can be shifted):

snmpwalk -v 1 -c public 192.168.1.20 ifDescr

The next MIBs can read incoming and outgoing traffic (I have LAN eth0 under index 4, WLAN ath0 under 10), for example for LAN traffic:

ifInOctets.4
ifOutOctets.4

Average CPU usage per 1min / 5min / 15min:

1.3.6.1.4.1.10002.1.1.1.4.2.1.3.1
1.3.6.1.4.1.10002.1.1.1.4.2.1.3.2
1.3.6.1.4.1.10002.1.1.1.4.2.1.3.3

TX and RX AP in kilobytes can be found by the following OID:

1.3.6.1.4.1.41112.1.4.7.1.17.1.4.24.214
1.3.6.1.4.1.41112.1.4.7.1.18.1.4.24.214

OID noise can be found by:

1.3.6.1.4.1.41112.1.4.7.1.4.1.4.24.214

Signal strength: 1.3.6.1.4.1.41112.1.4.5.1.5.1
Frequency: 1.3.6.1.4.1.41112.1.4.1.1.4.1
SSID: 1.3.6.1.4.1.41112.1.4.5.1.2.1
Uptime: 1.3.6.1.2.1.1.3.0
Free memory: 1.3.6.1.4.1.10002.1.1.1.1.2.0
Total Memory: 1.3.6.1.4.1.10002.1.1.1.1.1.0
MAC address of the access point to which the device is connected: 1.3.6.1.4.1.41112.1.4.5.1.4.1
The IP address of the access point to which the device is connected: 1.3.6.1.4.1.41112.1.4.7.1.10.1.4.24.214.232.12.159
Antenna type: 1.3.6.1.4.1.41112.1.4.1.1.9.1

See also:
SNMP OID and MIB for interfaces

Speed limit on Ubiquiti devices

Suppose we need to limit the speed on the client antenna.
Accordingly, it is in the station mode and is connected to the access point.

For restriction, we go to the web-based antenna management interface, open the Network tab, change the Configuration Mode: to Advanced, which will bring more parameters that you can configure .

At the very bottom, click on Traffic Shaping, check the Enable checkbox and specify the desired speed limit for WLAN0 or LAN0.
For example, you need to limit the reception speed to 5Mb/s and send up to 512Kbps, for reliability, we’ll specify a limit for both network interfaces, where Ingress is specified for WLAN0 5120, and for LAN0 512, respectively, for Egress, vice versa, WLAN0 – 512, and LAN0 – 5120, burst is left unchanged, that is, 0.

To apply the changes click below Change and then above Apply, after which the antenna configuration will reboot.

On the access point, alas, you can not limit the speed for each client, if you do the above settings (in reverse order), then the overall speed for all clients will be limited. In this case, you can cut the speed, for example billing, by turning on the Advanced tab Client Isolation in the Advanced tab so that clients do not see each other on the network and do not exchange traffic.

Done.