Limiting login attempts (was: Is robzr's bearDropper unmaintained?)

I want to limit the rate of ssh and LUCI login attempts. I thought I'd found a good solution in robzr's bearDropper which is mentioned in the old forums. Sadly, it appears to no longer work and hasn't been updated in a couple years.

Does anyone know if there is a maintained version of bearDropper?
Failing that, what are the other options for blocking repeated attempts at ssh and LUCI logins?


I use a rate limit of SSH to 5 connections in 5 minutes:

config rule
        option src 'wan'
        option name 'SSH_CheckDrop'
        option family 'ipv4'
        option proto 'tcp'
        option dest '*'
        option dest_port '22'
        option target 'DROP'
        option extra '--syn -m recent --name ssh --update --seconds 300 --hitcount 5'

config rule
        option target 'ACCEPT'
        option family 'ipv4'
        option proto 'tcp'
        option src 'wan'
        option dest_port '22'
        option extra '--syn -m recent --name ssh --set''
        option name 'SSH_CheckAccept''
        option dest '*'

That seems reasonable. Why is that not the default? Also, do you have a rule for LUCI?

1 Like
  • Why is what not the default?
  • Are you saying that someone should guess that you want to block traffic?
  • I'm not sure what you mean, that is the rule for LuCI (the UCI configuration interface), if you are afraid of the command line, simply type it in



1 Like

The downside of limiting login attempts is that you can end up suffering a DoS when you need to log in, if anyone else has been trying.

Using non-standard ports will cut down on many hacking attempts based on port scanning and simple scripts. Use RSA key authentication instead of password.

Also LuCI is not considered secure in the first place. Do not ever open it to the Internet or other untrusted users. To log in to LuCI remotely, use a SSH or VPN tunnel.


Five minutes

My bad

60 * 5 == 300

(My old rule was 5 attempts in 3 minutes, I got confused, lol)


I would never open SSH or LuCI to the WAN. But accidents happen and some routers have had bugs that let people on the outside appear to be coming from inside the LAN. I am a belt and suspenders type of guy. If, for whatever reason, these internal services are exposed to the world, I want to be sure that the login attempts are rate limited.

Yes, of course. I had forgotten that's why I don't use plain iptables solutions any more; I did get locked out of a server many years ago and had to go on-site to fix it. Tools like fail2ban and bearDropper, which only deny access to the offending IP addresses, work much better. And bearDropper was the best as it was written specifically for OpenWRT in the ash shell. But now, it appears to be broken; perhaps the format of the log files changed?

I apologize for not being clear. I was wondering why OpenWRT would not be more secure out of the box. Please don't take this as a criticism: I am asking because I assume there's a good reason and I just am ignorant of it.

I understand brute force attacks are only a problem if somebody misconfigures OpenWRT to be available on the WAN or if the device is deployed in a hostile environment, like a coffee shop. Still, such things have been known to happen and I expect the OpenWRT designers have discussed it and decided to not implement such protection by default. Could it be because OpenWRT used to be targeted to 4MB-flash routers and defensive measures, like bearDropper, would have been too large?

Commercial routers I have used in the past slowed down login attempts on the web interface if there were multiple failed attempts. It does not appear that LuCI has that ability, so I was hoping something like bearDropper would solve the problem.

AKAIK, uhttpd and LuCI are not designed to be exposed to public network.
If you need to access OpenWrt from public network, you should use tunneling via SSH at least and via VPN preferable.

  • Can you make this more clear?
  • Are you saying that you want to block access to the web GUI too?

If you are afraid of your LAN devices, you can configure that to your desire using different methods.

No, I just think you're slightly security paranoid. I have a wild thread for you...

1 Like

Try port knocking. I used it to save my router ssh access

1 Like

Yes, I should be clear, look at my rules carefully - they only perform these checks to any traffic to the INTERNAL DESTINATION of 22/tcp from a SRC Interface of WAN.

Therefore, you still have to make an inbound rule to the SSH server that's internal.

I also suggest the options @mk24 and @vgaetera provided.


"One size fits all" doesn't work for two things:
1- shoes
2- ssh login attempts limit


If you’re concerned about SSH-based attacks, I would consider one or more of

  • Chosing OpenSSH or dropbear according to your evaluation of their relative security
  • Only permitting keyed access
  • Changing the name of the 0:0 user
  • Disabling root login over SSH and using sudo with a non-privileged user
  • Rate limiting new connections using the firewall itself

Rate limiting does run the risk of DoS, as already pointed out.

1 Like