We'll restrict access to the HTTP(S) GUI to the Management network so only IT staff plugged into that network can access it. We'll also disable older crypto ciphers that now have documented vulnerabilities and available exploits. The same will happen with SSH. We'll leave NTP running, assuming it's being used as the branch office's NTP time source, but restrict it on the WAN port so it can't be used in NTP DDoS attacks.

First set the HTTP(S) GUI to only listen for connections on the Management (eth4) interface, then disable older, vulnerable ciphers:

set service gui listen-address 192.168.61.1 set service gui older-ciphers disable

Once those changes are committed and saved only hosts on the Management network will be allowed to reach the device's web interface. We'll restrict SSH now in the same way, and also require that SSH v2 be used for all connections. Once the following commands are passed and committed you won't be able to access the device unless you're in the Management network.

set service ssh listen-address 192.168.61.1 set service ssh protocol-version v2

Credentials

The Ubiquiti factory-default username and password combination of "ubnt" and "ubnt" is widely known and publicly available, and many compliance and security scanners like Tenable's Nessus check for factory default credentials. Compliance standards like PCI-DSS and HIPAA strictly forbid the use of factory-default credentials. In keeping with that spirit we will set up our own credentials, and remove the factory-default set. First, I'll create an admin user for myself:

set system login user tyler set system login user tyler full-name "Tyler Hart" set system login user tyler authentication plaintext-password 1234 set system login user tyler level admin

In place of the "1234" password you should use a suitably secure password that meets your organization's security and compliance requirements. Although the command setting the password uses the phrase "plaintext-password", the system will encrypt it for you. Only after setting my full name and a strong password do I pass the final command, giving myself "admin"-level privileges. Commit and save the new credentials, log out of the default "ubnt" user, and log in with your own admin-level credentials. Logged in as yourself, delete the built-in "ubnt" user so that it can't ever be used to breach the router:

delete system login user ubnt

If you're not comfortable deleting the built-in "ubnt" user you must set a complex password, because port scanners will attempt to login with factory credentials given the opportunity. Each device administrator should have their own credentials, so it's possible to see who changed what and when on the device. If all admins log in as the same user there is no non-repudiation, and no way to tell who may have made a malicious configuration change.

Neighbor Discovery

Ubiquiti routers come with neighbor discovery turned on by default, which is great for convenience but not great for security. It runs on UDP port 10001, and allows administrators to easily see what devices are on the network and how they are addressed. Unfortunately it can also allow attackers to easily fingerprint a network, and can help them discover soft targets faster than they might otherwise. Having neighbor discovery turned on can also make attackers aware of other devices they may not have seen otherwise because of network segmentation. We'll shut off neighbor discovery to start with:

set service ubnt-discover disable

This disables the neighbor discovery service on all ports, both physical and virtual. It also ensures that any new virtual interfaces won't run neighbor discovery when they are created. If you'd like to use neighbor discovery, you should disable it on all ports except those you want it running on. This could mean adding a lot more configuration lines, but that is the current state of things. Best practice says that you should run neighbor discovery protocols like CDP, LLDP, etc only on management interfaces.

Firewalls

Firewalling is a complex topic, but there are basic rules that can be put in place to secure a device from port scanners, malicious login attempts, and other probes from the WAN. We'll create a firewall rule specifically for inbound traffic on the WAN, and give it a good description:

set firewall name WAN_In set firewall name WAN_In description "Block WAN Probes"

Once the rule is created and described we'll set the default action that the rule should take for matching packets. With this rule being on the inbound side of our WAN, port scanners and others will be hitting it, so the default action should be to "drop":

set firewall name WAN_In default-action drop

If traffic doesn't match the rules we'll create in just a moment, then the default action takes place and that traffic gets dropped. You may be tempted to use the "reject" action instead of "drop", but even rejected packets can help a port scanner fingerprint your router. The best option is to just silently "drop" the packets, and this is required for PCI-DSS.

The first rule in "WAN_In" will allow any connections through the firewall with states of either "Established" or "Related". This is authorized traffic that originated properly, and should be quickly allowed through the firewall:

set firewall name WAN_In rule 1 action accept set firewall name WAN_In rule 1 description "Allow Established / Related Traffic" set firewall name WAN_In rule 1 state established enable set firewall name WAN_In rule 1 state related enable

Next we'll define an Address Group of trusted external IPs. We'll allow remote connections to the router via the WAN, but only from those trusted IPs. First, create the Address Group, then set a description:

set firewall group address-group Trusted_IPs set firewall group address-group Trusted_IPs description "External Trusted IPs"

Add any trusted external IP addresses you have to this list. This could be for a site-to-site VPN, ICMP echos to check if the device is up, SNMP monitoring traffic, or anything else. I'll use 1.1.1.1 and 2.2.2.2 just as examples:

set firewall group address-group Trusted_IPs address 1.1.1.1 set firewall group address-group Trusted_IPs address 2.2.2.2

Now we'll create a firewall rule in WAN_In and reference the address group created above:

set firewall name WAN_In rule 2 action accept set firewall name WAN_In rule 2 description "Allow Trusted IPs" set firewall name WAN_In rule 2 source group address-group Trusted_IPs

By default Ubiquiti devices accept all ICMP requests, including echo requests or "pings". We only want the WAN interface responding to pings from our trusted IPs, so there are two options. The first is to disable all ICMP replies globally:

set firewall all-ping disable

This is quick and easy, but it also removes the use of ICMP as a troubleshooting tool. The second option is to create a third firewall rule for WAN_In, specifically dropping ICMP and echo replies but letting it run elsewhere:

set firewall name WAN_In rule 3 action drop set firewall name WAN_In rule 3 description "Drop ICMP" set firewall name WAN_In rule 3 protocol icmp set firewall name WAN_In rule 3 icmp type 8

At this point we're ready to apply the rule on the inbound side of the WAN (Eth0) interface. Traffic that has a state of "Established" or "Related", and traffic from IPs in the Trusted_IPs list will be allowed. Everything else (port scans, login attempts, pings, etc) will be dropped by the default action. We've created the firewall entry, added rules to it, now we'll apply it:

set interfaces ethernet eth0 firewall in name WAN_In set interfaces ethernet eth0 firewall local name WAN_In

We'll commit and save the configuration, then run another port scan like before. You can see the results below, scanning both TCP and UDP: