SSH brute force and hacking attempts

[sfx2000]

So in your opinion, you suggest to use standard ports? SSH on 22, Wireguard on 51820, etc...?

I'm just saying that moving ssh to another port does not fix the problem - it will still happen, maybe to a lesser degree, but it won't stop someone from rattling the doorknob on a TCP endpoint - doing a TCP port scan doesn't take a lot of time.

If the robot sends a syn packet at a port, and gets the ack, then it starts it's discovery script to find out what's behind that port - ssh reveals much...

wg is udp based, so most robots won't even try as there is no 3-way handshaking going on... it takes a lot longer to scan a host for udp, so most don't waste the time/bandwidth. Not to say that someone would not explicitly look for wg endpoints, that could happen, but that would be someone much more determined to do so...

 

[RMerlin]

I'm just saying that moving ssh to another port does not fix the problem

His actual problem is the fact that robots are scanning port 22, and constantly hitting it. So yes, moving SSH to a non standard port will resolve that particular problem, as the vast majority of bots won`t scan all 65536 ports of every single IP - they will just scan for the usual suspects, which would be 21-23, 80, 443, 1194, 3389, etc...

His goal isn`t to make his network more secure, it`s to reduce the amount of bots hitting his server. Moving to a non-standard port will resolve over 99% of these. The security portion itself would be handled by using key-based authentication, which are very, very unlikely to get brute forced.

Ideally, if possible, I would say to configure the port forward to only forward queries coming from specific subnets if his remote accesses always come from specific subnets. I do that personally for a remote server that needs to remote into my network over ssh to run an rsync backup. I have the port on a non-standard port to reduce door rattling, and I also only forward that port for inbound connections coming from my remote server's IP. Not all routers will allow that however (but Asuswrt does). That would help improving security on top of reducing the amount of bot spam.

it takes a lot longer to scan a host for udp, so most don't waste the time/bandwidth.

It also prevents your server from having tons of open TCP connections during a brute force attack. I've had a customer's OpenVPN server becoming randomly unable to allow employees to remote in, and at first I thought it was an ISP routing issue since it seemed so random. Took me a while to discover that his OpenVPN server was configured to allow a maximum of something like 25 sessions, and for some odd reason OpenVPN even counts an unauthenticated connection within that limit. So when a bot tried to brute force into their server, it prevented employees from connecting in by instantly using all 25 slots. I ended up both switching to a non-standard port and possibly switching from tcp to udp (I can't remember) to take care of that problem.

 

[sfx2000]

I've had a customer's OpenVPN server becoming randomly unable to allow employees to remote in, and at first I thought it was an ISP routing issue since it seemed so random. Took me a while to discover that his OpenVPN server was configured to allow a maximum of something like 25 sessions, and for some odd reason OpenVPN even counts an unauthenticated connection within that limit. So when a bot tried to brute force into their server, it prevented employees from connecting in by instantly using all 25 slots. I ended up both switching to a non-standard port and possibly switching from tcp to udp (I can't remember) to take care of that problem.

Hosting an OpenVPN server - UDP is the preferred path, better performance, and bots can't exhaust resources... TCP, maybe, in certain circumstances, and the option for TCP transport is obviously there.

OP's use case might be better served with a VPN...

I think we'll all have to agree there are different approaches - my position is "just move the port" is insufficient for reasons stated - it stops the noise, but doesn't improve the security one bit...

 

[RMerlin]

Hosting an OpenVPN server - UDP is the preferred path, better performance, and bots can't exhaust resources... TCP, maybe, in certain circumstances, and the option for TCP transport is obviously there.

I recently had one case where a remote developer from overseas had constant connectivity issues that were only resolved by switching the server to TCP tho. So, it's situational.

 

[rush_ad]

Folks, a lot of good information here. Thanks for sharing all your thoughts.

For now, I'm going to keep everything as is. Bot attacks are blocked by AiProtection anyway. It's a great feature to have from Asus.

I would have never known about these bot attacks if I didn't have an Asus router.

My other router, Netgear RAX200, is nice but doesn't have anywhere close to these many features.

 

[RMerlin]

Folks, a lot of good information here. Thanks for sharing all your thoughts.

For now, I'm going to keep everything as is. Bot attacks are blocked by AiProtection anyway. It's a great feature to have from Asus.

I would have never known about these bot attacks if I didn't have an Asus router.

My other router, Netgear RAX200, is nice but doesn't have anywhere close to these many features.

I wouldn't rely too heavily on that however. It will stop some of the brute force attacks it detects, but that doesn't mean that someone won't eventually get in, or that it won't still potentially add an extra load on your connection if the amount of connection attempts gets too high. Also by seeing an open port 22, it might encourage the bot to start checking all your other ports for other available service - in essence, you just announced you were running a public-facing server on that specific IP address of yours.

Moving the port to a different one will at least greatly reduce the number of attempts. The idea is to leave the server on port 22, but change the port forward so it will forward WAN port 55522 (or any other high numbered port of your choice) to your internal port 22. That way, only your remote connection attempts will need to use that other port. Something like that:

As for security, I would also ensure that SSH authentication disallows password logins and only allows key-based authentication if you intend to leave it exposed to the Internet. Otherwise, consider using a VPN (OpenVPN or Asus's Instant Guard).

 

[sfx2000]

I wouldn't rely too heavily on that however. It will stop some of the brute force attacks it detects, but that doesn't mean that someone won't eventually get in, or that it won't still potentially add an extra load on your connection if the amount of connection attempts gets too high. Also by seeing an open port 22, it might encourage the bot to start checking all your other ports for other available service - in essence, you just announced you were running a public-facing server on that specific IP address of yours.

Moving the port to a different one will at least greatly reduce the number of attempts. The idea is to leave the server on port 22, but change the port forward so it will forward WAN port 55522 (or any other high numbered port of your choice) to your internal port 22. That way, only your remote connection attempts will need to use that other port. Something like that:

As for security, I would also ensure that SSH authentication disallows password logins and only allows key-based authentication if you intend to leave it exposed to the Internet. Otherwise, consider using a VPN (OpenVPN or Asus's Instant Guard).

Good advice - changing the port, meh, but the rest is good...

Nobody is going to DDOS port 22/tcp - it will clog their pipes just as much as yours (because of the 3way handshake with TCP), and it's much easier just to point a UDP firehose at the IP and be done with it...

For security - as mentioned, disable password authentication and use certificates - as long as the cert is under close positive control, nobody is getting in except those with the certificate(s).

Only time I recommend changing ports is if the ISP blocks incoming on those ports - then moving them is the only choice...

All told though - running a VPN host (it's super easy to do, and it's built in to AsusWRT) is the right way to do things for inbound - there are issues with ssh that are not commonly considered (reverse tunnels is one if outbound SSH is allowed when inbound SSH is allowed - ssh cuts both ways, and one with the technical skills...)

 

[sfx2000]

I recently had one case where a remote developer from overseas had constant connectivity issues that were only resolved by switching the server to TCP tho. So, it's situational.

I could see that - esp on long distance/high latency links - TCP makes sense there.

 

[dosborne]

Disable all external access except for your inbound VPN. Then you can safely use SSH on your default or non-default port.

With malware, brute force and other attacks on the rise, and not likely to subside any time soon, why would you risk opening anything to the internet except through a VPN?

Hope you have backups!

 

[rush_ad]

I wouldn't rely too heavily on that however. It will stop some of the brute force attacks it detects, but that doesn't mean that someone won't eventually get in, or that it won't still potentially add an extra load on your connection if the amount of connection attempts gets too high. Also by seeing an open port 22, it might encourage the bot to start checking all your other ports for other available service - in essence, you just announced you were running a public-facing server on that specific IP address of yours.

Moving the port to a different one will at least greatly reduce the number of attempts. The idea is to leave the server on port 22, but change the port forward so it will forward WAN port 55522 (or any other high numbered port of your choice) to your internal port 22. That way, only your remote connection attempts will need to use that other port. Something like that:

View attachment 44142

As for security, I would also ensure that SSH authentication disallows password logins and only allows key-based authentication if you intend to leave it exposed to the Internet. Otherwise, consider using a VPN (OpenVPN or Asus's Instant Guard).

That screenshot was perfect, helped a lot. Thanks!

I am not familiar with key-based authentication to replace password. I'll have to read up on that.

 

[zwitterion]

That screenshot was perfect, helped a lot. Thanks!

I am not familiar with key-based authentication to replace password. I'll have to read up on that.

When I setup my first server and left door 22 open on the internet, someone eventually made their way through Asus AI Protection, hacked my password, and infected the server. I've since replaced everything, but figuring out the hard way is what led me to Merlin's firmware and learning how to use SSH keys and limiting open ports to specific IP addresses. Life has been much better. If you can manage it, keep the port closed until you figure out how to use keys and utilizing firewall tools and port configs to reduce the ruckus from Wild Wild Westernet. Sincerely, future you

 

[BreakingDad]

Is it possible to use a TCP wrapper to prevent all IP's except allowed to prevent this?

 

[ColinTaylor]

Is it possible to use a TCP wrapper to prevent all IP's except allowed to prevent this?

"TCP wrapper"? There's already an option in the GUI that restricts access to a list of allowed IP's.

 

[BreakingDad]

"TCP wrapper"? There's already an option in the GUI that restricts access to a list of allowed IP's.

So if he restricted this to only known IPs, would this not solve the issue, even if they brute forced the password, they still couldn't get in the door?

 

[ColinTaylor]

So if he restricted this to only known IPs, would this not solve the issue, even if they brute forced the password, they still couldn't get in the door?

This was already suggested in the post immediately before yours as well as by RMerlin in post #22.

 

[BreakingDad]

This was already suggested in the post immediately before yours as well as by RMerlin in post #22.

My bad, didn't read the whole thread, reason I mentioned it was I have just done similar to make an RPI a bit more secure by means of editing hosts.allow and hosts.deny. Didn't think of doing it through the GUI on the router for the OP, as on RPI it's headless.

 

[sfx2000]

Didn't think of doing it through the GUI, as on RPI it's headless.

Nice thing is Pi's have a free 5-seat license for RealVNC connect, so GUI there is always an option.

(that 5 seat license isn't restricted to running the server on Pi, BTW, but it does limit the number of hosts on the RealVNC connect account to 5 - they can be Pi's, regular Linux, Mac, Windows, etc)

 

[BreakingDad]

Nice thing is Pi's have a free 5-seat license for RealVNC connect, so GUI there is always an option.

(that 5 seat license isn't restricted to running the server on Pi, BTW, but it does limit the number of hosts on the RealVNC connect account to 5 - they can be Pi's, regular Linux, Mac, Windows, etc)

Yes I use realvnc on my adguard pi, but the Minecraft one is headless to save resources.

I'm actually finding the headless one with OSlite really easy to use with filezilla and putty.

5 seat license is interesting.

 

[rush_ad]

I wouldn't rely too heavily on that however. It will stop some of the brute force attacks it detects, but that doesn't mean that someone won't eventually get in, or that it won't still potentially add an extra load on your connection if the amount of connection attempts gets too high. Also by seeing an open port 22, it might encourage the bot to start checking all your other ports for other available service - in essence, you just announced you were running a public-facing server on that specific IP address of yours.

Moving the port to a different one will at least greatly reduce the number of attempts. The idea is to leave the server on port 22, but change the port forward so it will forward WAN port 55522 (or any other high numbered port of your choice) to your internal port 22. That way, only your remote connection attempts will need to use that other port. Something like that:

View attachment 44142

As for security, I would also ensure that SSH authentication disallows password logins and only allows key-based authentication if you intend to leave it exposed to the Internet. Otherwise, consider using a VPN (OpenVPN or Asus's Instant Guard).

Saw a few SSH attacks in AiProtection today. First after using the directions in the screenshot.

Could be a coincident or may be the bots found out which external port number I have open.

 

[sfx2000]

Yes I use realvnc on my adguard pi, but the Minecraft one is headless to save resources.

I'm actually finding the headless one with OSlite really easy to use with filezilla and putty.

5 seat license is interesting.

Cool - if one is running Windows - give this a try...

MobaXterm free Xserver and tabbed SSH client for Windows

The ultimate toolbox for remote computing - includes X server, enhanced SSH client and much more!

mobaxterm.mobatek.net

Nothing against Putty, but MobaXterm is... pretty awesome

Free for personal use, for business, there is a licensing setup that is fairly priced.