Peplink and Pepwave routers can block IP addresses that have had multiple failed login attempts.
Why?
This can mitigate brute force type attacks on the router’s web admin login.
How?
No configuration is necessary. The router immediately suspends all web admin access after 5 invalid attempts and remains in a suspended state for 5 minutes.
During this time, no authentication will take place from the offending IP address, even with the correct username and password.
The lockout applies whether you’ve entered the incorrect credentials from the LAN, or from the WAN side.
The entire event is captured in the router’s event log like so:
Any way that you can lock this down to a specific IP address instead of locking everyone out? I can see a DOS attack succeeding if the router is inaccessible to legitimate clients. Perhaps add a “super admin” type of account that is tied to a specific source IP address. Locking everyone out is scary. The way you have implemented it gives the offending party a higher likelihood of causing problems.
It would be better to give a “dummy” UI page to the person that tried 5 times and failed. This way, they think they are successful; but in reality - they are looking at static HTML that means absolutely nothing to the router. Give them some buttons that make fart noises or something.
Remember, the point of a DOS attack is to prevent legitimate use of an application or device – by locking EVERYONE out for 5 minutes after 5 failed logon attempts – you basically give the intruder an easy win. I think it would be better to only lock out only the offending IP address. If you see 5 different IPs all failing 5 times, that is when you can assume an attack and lock it down to the offending network. Another idea would be to make the lockout time be variable – otherwise, they can just put a sleep command for 5 minutes and try again. I can see how they would completely hose an admin if they really wanted to.
I think this is a very bad idea. An attacker only needs run a script which attempts 5 failed authentications in 4 minutes, run on a 4 minute interval and they will effectively render the administration console inoperable. Because these are edge devices, the only mitigation in a WAN based attack will be taking the unit offline to clear the 5 minute timeout. A LAN based attack could be mitigated by a disconnect further downstream, though this would still be problematic in a router-on-a-stick network, especially one which is remotely administered.
This really should be locked to the source IP for both WAN and LAN based attacks. This allows an administrator access to the web console from a non-compromised IP during the attack, and doesn’t require physical downtime to mitigate. Furthermore this really should be a configurable choice to enable/disable the lockout protection.
