By Robert Liao, Robustel Technical Support Engineer

Many users may have encountered this problem before – despite repeatedly typing in the correct password, they can’t log in to the router.
Don’t be surprised – the login window has automatically locked down to protect the router from cyber-attacks.

This situation is most commonly found in devices that have a publicly addressable IP. Since Public IP addresses can be visited from any computer, devices on these networks have increasingly become a target for malicious attackers.

They would start by using a tool to scan standard web ports like 80 and 443. Using exhaustive brute force methods, attackers would attempt to login using different passwords, to try and crack the account.

If you were able to access a router through TELNET/SSH, you would see a dialogue window like the image below:

Attempting more than 10 thousand logins doesn’t take long, and the application tool can run automatically day and night, until it finds the correct username and password.

So as mentioned above, in order to prevent the device from being continuously attacked, the system locks the login window.

To users who rely on public IP, it is strongly recommend that you implement a protective strategy, fundamentally to prevent untrusted parties from accessing the device.

The suggestions are as follows:

1.Disable unnecessary remote logins

For example, I usually only use the WebUI to access the device, so with SSH/TELNET/HTTP remote access disabled, the only option left for access is HTTPS.

This reduces login opportunities for unwelcome parties.

2. Set an Allow List (previously called “Whitelist,”) so only trusted people can access the device.

When you set an Allow List address, please note that the IP must be the outbound IP, not your internal host.

In the topology example below, you can see the Allow List approves IP, which is the office’s main IP router used for communicating with a public network, not the host IP

3. Change the web server port to an unknown port. 80 and 443 are the standard web service ports, which attackers usually scan.

By combining this approach with the first step, (only leaving https for accessing, and changing to a port that only trusted people know), the malicious visitor won’t be able to access the device’s web service because they don’t know the port.

For example, it is set it to 47008, when accessing this device. So the address would be https://xx.xx.xx.xx:47008.