New Linux malware brute forces SSH

LuCI was never intended to be secure enough to leave open to the Internet. If you want to access LuCI remotely, always use a SSH tunnel or VPN.

A ssh tunnel is configured by adding -L 8080:localhost:80 to your CLI ssh login. Then leave the ssh session open and go to your web browser where http://localhost:8080 (your localhost) is now linked to the remote LuCI (port 80 on that localhost).

Also note that https protects the client user from certain security risks, it does nothing to protect the server from a third party brute-force or other intrusion. So LuCI with https is not less risky than without.

5 Likes

I tried this but failed. Can you please help

In terminal from a laptop I did:

ssh root@192.168.1.1 -L 8080:localhost:80

What is 'localhost' supposed to be there?

and then put in my passphrase for SSH key

But when I went to my browser, the old 192.168.1.1 went to Luci login screen (I didn't need 8080)

Appreciate any guidance

You need to reread what @mk24 wrote, and the tunnel doesn't stop the regular 192 access, unless you tell uhttpd to only bind to localhost.

Yes I've read a few times with no luck.

Can you help with how to do this please

As has been stated multiple times, unspecified listening interface does not actually mean that ssh is open on the WAN. The firewall is what is responsible for allowing or prohibiting access, and in the case of the WAN, it is prohibited unless the user adds a rule to allow ssh access from WAN.

1 Like

read [SOLVED] Disable http access to LuCi - #4 by jow

Thanks for the tip to tell uhttpd to only bind to localhost. Done

But I had already done this: "Then leave the ssh session open and go to your web browser where http://localhost:8080"

Nothing is coming up.

Should I disable https in Luci first or is that irrelevant? I had enabled redirecting http to https before

Yes, it still works that way. So it doesn't make sense to generate a password which has more bits than the hash. As far as I can count, the password in that screenshot has 39 characters, and a character is somewhere between 6 and 7 bits. So lets say this password is 256 bits.
To my surprise the hash in OpenWrt is md5 (unless that is somehow inherited from older installations, but I changed my password and it's still md5) which is 128 bits.
So that password isn't as hard to brute force as it seems. (Yet 128 bits is still enough to outlive the sun, assuming you are bruteforcing it)

2 Likes

Won't bite until restarted, I assume you've done it.

As for the ssh it should work, never actually done it on Linux, only Putty, but the syntax seems correct.
If you do telnet localhost 8080, does it open a session, or does it time out?
I also assume you're browsing (and telneting) from the same computer as your open ssh session ?

Yes same computer. I will do the telnet.

But do I leave it as "127.0.0.1.." as in that link you sent (for uci set uhttpd.main.listen_http='127.0.0.1:80')

Or change that to the IP address 192.168.1.1 of my OpenWrt RPi3?

Maybe that's where I stuffed up

It should be localhost/127.0.0.1.

1 Like

Having a public web server online for many years already, fail2ban prevented any intrusion on port 22 and several others, i.e. 25 or 110. All relevant ports using password login, only, because I hate fiddling around with certs.

Ok, as per my hunch I had to un-tick this below and now http://localhost:8080 works !

Is that normal? I thought https is covered by "uci set uhttpd.main.listen_https='127.0.0.1:443'" @mk24 ?

There's no way to make https://localhost:8080 work?

Thanks for all the tips @frollic

image

Replace the :80 with :443 in the ssh command,
or add an additional tunnel for the 443 port.

2 Likes

Ah that did the trick! Thanks again!

Now that it works, what is the difference between using 192.168.1.1:443 IP address and 127.0.0.1:443 ? for uci set uhttpd.main.listen_ ?

In terms of security / advantages ?

I guess it means the IP address is not used / revealed to access web page of Luci ? That's the main advantage ?

If it only listens to localhost/127.0.0.1, you can't access it from outside the router, since it's not listening to any externally accessible IPs.

Hence the need of the port forward/tunnel through ssh.

1 Like

in theory the "advantage" is that 127.0.0.1 only lives on the router itself and accessible only on the router. so you need to run the client accessing the web server (uhttpd) on the router itself. the trick here is that you create an SSH tunnel, so from your laptop the traffic is sent through the SSH session and it looks like the web browser is on the router too, so web server accepts the connection.

but this give no real security benefit imho. because:

  • connecting from wan you are by default protected,
  • if you are the admin connecting from lan it is a pita to create a cheap vpn like connection, when you can disable/enable uhttpd and/or change the configuration as you wish,
  • if you are not the admin and connecting from lan, you don't / should not know the root password anyhow,
  • if you are not connecting from lan but from another internal network (e.g. guest) you should rather use the firewall to only allow predefined router access (input traffic)
1 Like

I thought I'd try

uci set uhttpd.main.listen_http=‘localhost:80’
uci set uhttpd.main.listen_https=‘localhost:443’
uci commit uhttpd
service uhttpd restart

But it doesn't work. The active SSH window has messages popping up shows "connect failed: Connection refused" each time I try to access https://localhost:8080

But this works fine:

uci set uhttpd.main.listen_http='127.0.0.1:80'
uci set uhttpd.main.listen_https='127.0.0.1:443'
uci commit uhttpd
service uhttpd restart

In general use SSH keys please and disable WAN access if you don't need it.

Also if you want to make local services accessible without port forwards or VPN, Tor may be an option.
There is even a tor-hs package which makes this easy! https://github.com/openwrt/packages/pull/11659

do Tailscale and zero-tier provide same benefits?