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?
Thanks!
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?
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.
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...
Try port knocking. I used it to save my router ssh access
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.
"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
Rate limiting does run the risk of DoS, as already pointed out.