Hi there,
i searched around but dont find an answer to this, how to secure luci from brute forcing? I saw some suggestions like using complex/long passwords but at the end no real solution
I want to block access to the login page for a time preiod if someone (ip based?) tries to login several times but failes...so for example if there are 5 failed login attemps, it should block the next attemps for 15 minutes.
Is there a way to archive this?
Kind regards
If you are really concerned about this: after your router is fully setup, remove Luci. Make sure you have access via ssh just in case.
this is a "solution" like using long passwords, using VPN to connect and so on
I meant: people "users" will try to guess admin passwords. Even try to bruteforce it, given the opportunity. If there is no access like that, but only via a SSH, which listens only on a fix (wired) Ethernet port, it doesn't get much more secure than that and still have a reasonable way to access the router yourself.
Using a time delay would work, but would also lock You out for any given time period, even when someone else was doing the attack. For this reason, I am not a big fan of such mechanisms.
@ForumSchlampe - Are you worried about users on the internet (i.e. on the WAN side of the network), or internally on your local network? And you need external access to your router (i.e. from the internet)?
If your concern is external and you only access the router via internal systems, just be sure your firewall rules drop or reject any 'input' into the router itself (specifically for ports related to management such as 22 for ssh and 80 and/or 443 for web). I think the default firewall rules should handle this.
On the internal side, will your users have physical access to the router? You could create 2 VLANs -- one that is a general user network that drops/rejects ssh/http/https traffic into the device, thereby preventing any access to the router management. The other VLAN would be management on a single ethernet port on the router -- this one would have normal access to administer the router, but would require a physical connection. You could make it a bit more stealth by disabling DHCP on that VLAN, requiring some knowledge of the network config to connect to the router (a user would have to manually configure the computer with a static IP in the right subnet, know the address of the router, and know the password). While this last bit is by no means truly stealth for a determined hacker/cracker, it would easily dissuade a casual attempt at gaining access to the router's administration systems. You could probably only allow certain trusted devices (via MAC addresses) to access the router.
See if a bad login generates a log message. If so, set up a cron to grep/add the offending IP into an ipset which has a timeout on it. You could probably adapt some SSH brute force "blockers" for this. Be careful to sanitize your data or you could open a security hole.
However, smart brute forcers do not visit your IP frequently. Instead they guess the same username/password across large portions of the internet at a time and come back a lot later with their next guess So that limits the effectiveness of such a system to dumb brute forcers or people who are only interested in you specifically.
That said, people continue to point out that long/complex passwords are the best way to deal with this because they are. Trust the math, and don't trust anyone who cannot be trusted to use good passwords with creds for your router.
The only absolute way to defeat brute force with passwords is to lock the
account after too many failed logins. Unfortunantly that's not a safe thing to
do with the admin password, so you need to either decide to take the risk (and
try to have a password that's not easily guessable), or you need to not expose
the LUCI login directly, only allow connections to it from a VPN of ssh port
forwarding session (and protect those with certs)
David Lang
This is not for LuCi, but I would suggest everyone to install this 2 awesome protective measures: bearDropper , and sub2BRL.
The first one ( bearDropper ) protects your SSH port from brute force attacks, blocking the attacker's IP for a defined ammount of time. This package WILL NOT warn you if someone is trying to brute force into LuCi, just SSH ( which is far more common ).
The second one ( sub2BRL ) downloads a list of RBL's, and blocks the malicious IP's in those lists ... what's RBL? Taken from the author's ( @robzr ) post :
Real-time Black-hole List - came out of the spam prevention world, the idea being that when end-nodes receive spam (or ssh brute force attempts in this case), they upload the data on where those attacks are coming from to a central server, which then analyzes it, looks for patterns, and then publishes a list of attacker IPs. End-nodes can then download these lists (RBLs) and actively block them before they've even been attacked by them. There is of course a possiblity of false-positive, and once the attackers get effectively blocked they will move onto other IPs, therefore the lists must constantly be updated (that's the Real-time in RBL), as well as expiring the old entries. sub2rbl does all that smile I wrote it with the intention of blocking ssh brute force attacks (since that is what OpenWRT is usually most vulnerable to, as ssh is often the only service hosted on a router), but you can use it to subscribe to any RBL you like, and the default firewall rules block all services, so effectively it can also be used to prevent web or email (or any sort of) attacks as well. The default RBLs in the config file are focused primarily on ssh brute force attacks though.
I need to open Luci from WAN. I already read https://openwrt.org/docs/guide-user/luci/luci.secure but I wonder if there is any package that makes Luci waiting for a timeout after 3 trials. This kind of protection is not that bad against brute force attacks and still usable for people who know the password. Client certificate authentication would be another measure but sometimes too complicated on tiny mobile browsers.
Beside the fact this thread was marked as solved already and a very long time has past. The thread has given information what timeouts will mean:
If others are wasting your trails you are facing the same problem (locked out). You could solve this working with ipset scripts (mentioned already) or with sth. like fail2ban.
Same for ssh key logins. Either "insecure" or more effort.
Beside that the easier way would be creating vlans and separte the attackers from inside. If you need access from outside go with a vpn e. g. wireguard.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.