SSH brute force and hacking attempts

[AndreiV]

Seeing a very big increase in SSH login attempts caught in Turris Honeypot.

This IP has made 5000+ attempts today : 104.248.89.194

This session by 104.244.76.203 is more interesting as you'll see a string of 45 commands issued .

>> Honeypot session. <<

 

[sfx2000]

This session by 104.244.76.203 is more interesting as you'll see a string of 45 commands issued .

Honeypot aside - exposed SSH ports should use certs vs user/pass, along with disabling rootlogin which applies to both OpenSSH and dropbear...

 

[rush_ad]

I have a similar problem recently. I am seeing increased SSH Brute Force Login attempts from different IPs.
192.168.50.2 is my internal PiVPN and Pi-Hole server. It is running on an Orange Pi setup.

This is a recent issue for me. I've been running this setup for over a year but only recently these attacks started to occur. The only change I can think of is moving from Asus DDNS to No-IP (ddns.net).

Anything I can do to prevent?

 

[ColinTaylor]

Anything I can do to prevent?

Change the port you're exposing to the internet to be a random and non-obvious number between 5001 to 32767.

 

[rush_ad]

Change the port you're exposing to the internet to be a random and non-obvious number between 5001 to 32767.

Is it possible to know which port is under attack?

Currently I've got SSH (22), Wireguard (51820), and VNC (5901) exposed.

 

[ColinTaylor]

Well the message says it's SSH.

 

[rush_ad]

Change the port you're exposing to the internet to be a random and non-obvious number between 5001 to 32767.

I changed SSH port to 5022 and 22022 to try out. However I cannot SSH into my server using anything other than port 22.

SSH starts working as soon as I change back to 22.

Am I missing something?

 

[ColinTaylor]

Am I missing something?

Probably. You'll have to explain exactly what you're doing, what you're changing, how you're testing and from where (i.e. inside your LAN or outside).

 

[rush_ad]

Probably. You'll have to explain exactly what you're doing, what you're changing, how you're testing and from where (i.e. inside your LAN or outside).

My bad about the brevity.

The purpose is for me to SSH into my server at home from outside of my home network. From my phone or work or elsewhere.

Inside my LAN, everything works because I don't need to port foward anyway. I can SSH directly to 192.168.50.2 which is my LAN IP of the server.

Currently, I forward port 22 so that I can SSH into my home server.

If I change port to anything other than 22, I cannot SSH into my server from outside of my home network.

Hope that clarified the issue.

To bring the talk back on topic, the real issue is that I'm getting SSH brute force attacks per AiProtection. Ultimately that's what I'm trying to resolve. My current setup works for everything I need it except for getting SSH brute force attacks.

 

[ColinTaylor]

So you leave the SSH server's port the same as it was, i.e. 22. Then you change the port forwarding rule on the router so that the external port is 22022 but the internal port (on 192.168.50.2) is still 22. Then, when connecting from outside your LAN you change your SSH client to use port 22022 instead of port 22.

 

[sfx2000]

Change the port you're exposing to the internet to be a random and non-obvious number between 5001 to 32767.

That's not really a fix, and bad security advice - there is no security in obscurity...

 

[ColinTaylor]

That's not really a fix, and bad security advice - there is no security in obscurity...

Oh give it a rest. We've been through this with you before.

 

[sfx2000]

To bring the talk back on topic, the real issue is that I'm getting SSH brute force attacks per AiProtection. Ultimately that's what I'm trying to resolve. My current setup works for everything I need it except for getting SSH brute force attacks.

It's internet background noise - as long as your device is secure (certificates only is a very good step here).

on your server that you've port forwarded - fail2ban goes a long way towards quieting that noise, and you might consider using a firmware on that host - ufw is in most debian/ubuntu distro's (including the excellent Armbian for SBC's) and you can set ssh to limit, which is a brute force throttle mechanism...

 

[sfx2000]

Oh give it a rest. We've been through this with you before.

No, I won't - it's bad advice...

 

[sfx2000]

I changed SSH port to 5022 and 22022 to try out. However I cannot SSH into my server using anything other than port 22.

If you have mapped the ports (internet 5022, lan 22) and saved the host as a profile, that's where you are getting tripped on on the hairpin.

Save one profile for internet with the 5022, and a lan profile based on the host IP for port 22, and you should be good...

I'm using 22 (ssh) as an example for this thread, but it would apply to an mapping scenario, such as www, where one might have 8080 for internet, and 80 for internal (as many ISP's don't allow inbound http)

 

[ColinTaylor]

No, I won't - it's bad advice...

You're still missing the point, just as you did before.

 

[sfx2000]

You're still missing the point, just as you did before.

the point being?

 

[rush_ad]

It's internet background noise - as long as your device is secure (certificates only is a very good step here).

on your server that you've port forwarded - fail2ban goes a long way towards quieting that noise, and you might consider using a firmware on that host - ufw is in most debian/ubuntu distro's (including the excellent Armbian for SBC's) and you can set ssh to limit, which is a brute force throttle mechanism...

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

 

[rush_ad]

the point being?

Folks, let's just stay on the topic please.

Like everything else in life, there are pros and cons for all choices. May be you guys can help pros and cons of these two distinct suggestions.

 

[ColinTaylor]

May be you guys can help pros and cons of these two distinct suggestions.

Nothing sfx said addresses the actual question you asked. If you want to change the question and ask about security and/or remote access I would suggest you disable remote SSH access completely and instead connect via a VPN server. But then I have no knowledge of your use case.