Suspicious ssh/sftp login attempts

Since I become a node operator which is just 2 days :slight_smile: I am noticing very frequent ssh login attempts on my NAS.
My setup is on QNAP NAS with storj application deployed on docker container. Everything seem to be working fine I dont see any errors in the log all satellites are able to connect.

I was using noip DNS but then decided to use QNAP own dns mapping service same issue. These ip addresses are some china telecom. These attempts are very frequent every few minutes. any ideas about what’s going on? QNAP has built-in protection that disables these IP addresses for some time.

see screenshot attached.

do you have port forward on router on ssh port to your qnan? if so this is totaly not secure and you shold close it. If not then you shold think about using qnap DNS, looks like it use some vpn til QNAP DNS providor, this make it also unsecure, and someone scanning it and try some paswords time to time.

1 Like

disabled ssh access but would like to know if anyone have any insight as to whats happening.

It is normal when your IP start to be public available.
And you need to protect.
My router was hacked and turned to botnet some year ago, because i not updated it and has Fix IP. After I discovered it took some time to clean the mess.

Thanks yes my I had port forwarding turned-on on port 22. I also have forwarding on 28967 but I think I can turn all forwarding off as I am using QNAP dns. It should work as I dont have to use my public ip address

if you turn off 28967 node will stop working. DNS is just a link to your node, but port forward is access to node.

This has everything to do with port 22 being open. Botnets constantly scan for that port because it’s the easiest way in to systems. This is why it’s always a bad idea to open SSH to the public unless a couple of measures are taken. Using a non-default port is not really protection, but it can help prevent a lot of attempts of lazy bots that just try port 22. But most importantly would be to use certificate based authentication, have something like fail2ban enabled and if possible a second factor.
So you can secure it, but unless you really need it, you just shouldn’t have it exposed to begin with.

As @Vadim said, this is normal and not related to Storj. Any system with any publicly visible ports will get scanned and will get login attempts. That’s not to say that you shouldn’t take that seriously. Just make sure you only open what you need open and you protect what you open. NEVER EVER open telnet, don’t open SSH and don’t tempt spammers by opening SMTP (email) server ports. Those are the most common ones for abuse.

1 Like

Was the router management port accessible via the internet Vadim?

No it was problem with router OS, miktorik.

1 Like

Thanks for the information. I’ve played with them a little but never deployed them to a live site as yet.

disable myqnapcloud as well to be even more safe.

A golden rule in cyber security is to disable all unneeded services. You should never allow inbound Internet ports to your systems unless required. You should disable all ports that are port forwarded except those specifically required for the application such as TCP 28967.

1 Like

Thanks everyone. I turned off all portforwarding.
I have been reading about the payout structure and I do not understand it completely, I have started with 3.5 and can add more in the 2nd bay. To get an idea of how long does it take to fill 3.5TB and how much approx the payout would be for 4TB and corresponding egress and ingress bandwidth?

This should help with that.

if you need to use ssh on your server from another location just change the ssh port on your router when you forward it … what i mean is internal port 22 external port 2222 for example and thats it … 22 is common port for ssh and 24/7 hackers scan range a IP classes on ssh trying to bruteforce, so that happens !

Please don’t JUST do this. This is security through obscurity, which is no security at all. It’s trivial to do a port scan for other open ports and super common for botnets to do that and attempt logins on any exposed port.

If you ever expose SSH publicly you must have either super long random passwords (the type you can’t remember) or preferably certificate based authentication. You will also need to have fail2ban or similar to block IP’s after a number of login attempts.

Just changing the port does nothing except lower the amount of failed logins you’ll see in logs. It’s good to do, but only in addition to the other measures. It does nothing to protect you on its own.


The best way would be a VPN if you need remote access. My favorite right now is Zero Tier.

man, we are in 2021 , openssh-server up-to-date have already enough security and ignore IP after multiple logins failtoban etc (you just need to use a strong password) , nobody will start doing port scan for specific IP … most likely his IP is DHCP to … his problem was a class range scan and happens to everybody who has ssh on 22 open … hackers scan a class IP range all day for example they scan class 80...* if your IP starts with 80 you will get ssh login attempts if your port is 22 ! First thing you should do is change the ssh port if you dont want those issues (this simple shittt is the best move first) … after that add whatever security you wish !

Your message sure sounds like you disagree with something I said. Yet you give the exact same advise. Strong passwords and fail2ban. I think we’re in a heated agreement my friend!

Sure, this is most common. But plenty of botnets look for any open common port and if found follow it up by a quick port scan. If you have SSH open on any other port with an admin/admin login credential, it will get compromised. Just a matter of time. All I said was that changing port alone is not enough.

Yeah VPN is a good option too, but then the credentials and fail2ban advise applies to your VPN login.

a quick search on should show plenty of SSH services running on non-standart port #s. It would only be a matter of time before your non-standard open port ends up listed there as well.

I agree with your mitigation strategy. It’s all a matter of how many holes you want poked open. No matter the mitigation, an open service comes with some risk.