SSH getting pounded even though it's disabled

[akahan]

I feel I must be missing something obvoius.
In Control Panel / Terminal & SNMP I have SSH disabled.
I have rsync enabled, but the SSH encryption port is set to a high obscure number.
My connection log in Log Center shows a constant barrage of "User [root] from [random constantly changing IP address] failed to log in via [SSH] due to authorization failure."

How is the attacker even getting to the point of an authorization failure if SSH is disabled?

The machine, which is in a colocation center, must be open to the internet to some extent, as it's running a mail server, and because my NAS's at home back up to it using hyperbackup.

Is there anything I can do to stop these login attempts via SSH? Or am I misunderstanding what's going on?

 

[Rusty]

I have rsync enabled, but the SSH encryption port is set to a high obscure number

So you do have ssh enabled. Even if its on a high port, obviously you can detect any ports what protocol is behind it as long as the service is alive. Once you have the identification of it, you can start to brute-force it.

You could sort any rule on the router level or IDS/IPS device to prevent such requests ever reaching the NAS.

 

[fredbert]

Do you have SFTP enabled? That defaults to port 22 too.

 

[akahan]

SFTP is not enabled.
Hm, so if they found my rsync SSH port, how would I block that at the router, without also blocking rsync/hyperbackup/shared folder sync?

 

[Rusty]

SFTP is not enabled.
Hm, so if they found my rsync SSH port, how would I block that at the router, without also blocking rsync/hyperbackup/shared folder sync?

By allowing only traffic for specific network IPs or subnets, rest attempts are dropped.

 

[akahan]

Got it,,, unfortunately the source IP addresses vary, but perhaps I can do something with IP ranges. Thanks!

 

[Rusty]

Got it,,, unfortunately the source IP addresses vary, but perhaps I can do something with IP ranges. Thanks!

Best to allow for subnets that you want, and make a new rule after that one that will deny traffic for all on the same port.

 

[akahan]

Selective permission of subnets seems to be working. Thanks!

 

[Coop777]

have you tried port redirection at the router level?

 

[akahan]

Since it's in a colocation center, I don't have access to the router, unfortunately.

 

[Gerard]

Since it's in a colocation center, I don't have access to the router, unfortunately.

What type of router is it?

 

[akahan]

What type of router is it?

I have no idea, since I have no access to it, but most likely a Cisco.

 

[Gerard]

I have no idea, since I have no access to it, but most likely a Cisco.

Some routers may have the ability to use a domain name/ddns as a source rather than ip. Idk Cisco, and with you not having access that posses an obstacle.

*although wouldn’t the rule sit on your local router in which the nas is connected to? What type of router do you have?

I utilize this method on my router, in which even though my remote site has a dynamic ip address the router conducts a name lookup using the ddns name every x amt of seconds and will only allow that ip in. This has worked great for us.

 

[akahan]

Gerard, I think you're not understanding the situation. The NAS sits in a colocation center, a room the size of a warehouse, on a rack with hundreds of other services owned by other customers of the colocation center, and many hundreds of domain names among them. The router serves all of these hundreds of servers, and is owned by the colocation center.

Obviously, if the NAS were in my home or office, I'd have control of the router, but that's not the environment I'm working with. In any event, I was able to follow Rusty's solid advice and set the NAS's own firewall appropriately to let rsync/SSH packets through only from known subnets.

 

[Gerard]

The machine, which is in a colocation center, must be open to the internet to some extent, as it's running a mail server, and because my NAS's at home back up to it using hyperbackup.

Didn’t you say here, “my nas’s at home?”
I was going off this line in which a machine that runs a mail server (type of machine not specified is in a colo) and your nas at home backs up to it.

Anyway use the subnetting method that would work

 

[akahan]

I have several NAS's at home. They back up to the one in the colocation center. The one in the colocation center is the one that's getting pounded.

 

[fredbert]

You could contact the co-lo service provider and ask what perimeter security they apply, what restrictions to ports, if you have dedicated Internet IP, can it be tailored for your situation etc. This is in no way a criticism of their service but would then allow you to understand their edge security and how it applied to your device. You can then adapt, as best you can, your security features to reduce the exposure to unwanted sources.

You should also ask about internal separation between hosted devices.

Would it be possible to set up VPN Server on the hosted NAS and VPN client tunnels from the source NASs? Then use these to minimise the exposed ports to just VPN Server. Though I'd test that the configuration is robust before switch to VPN-only access, maybe some restricted access enabled for emergencies with 2FA

 

[akahan]

You could contact the co-lo service provider and ask what perimeter security they apply, what restrictions to ports, if you have dedicated Internet IP, can it be tailored for your situation etc. This is in no way a criticism of their service but would then allow you to understand their edge security and how it applied to your device. You can then adapt, as best you can, your security features to reduce the exposure to unwanted sources.

You should also ask about internal separation between hosted devices.

Would it be possible to set up VPN Server on the hosted NAS and VPN client tunnels from the source NASs? Then use these to minimise the exposed ports to just VPN Server. Though I'd test that the configuration is robust before switch to VPN-only access, maybe some restricted access enabled for emergencies with 2FA

These are good thoughts; they are able to restrict access to my server to certain IP addresses, but not on a port by port basis, so that does me no good, as one of the NAS's functions is "mail server," so it has to be open to all. (This is also why I can't limit access to VPN-only). And, in any event, I would prefer not to trust my security to the colocation provider.

 

[itsjasper]

Tailscale may be a better option than Synology VPN.