Still does nothing when scanning the entire ipv4 address space achievable so quickly. You can also use services like shodan to find vulnerable services on any ports.
Use SSH keys, stay upgraded. Make management services (SSH, RDP, admin services) accessible only via VPN (WireGuard). Only expose 80 and 443 to the internet, if necessary.
Moving ports does help. It is not a sure thing but when used in conjunction with other security mechanism can help get rid the of the low hanging fruit of scriptkiddies and automated scans.
It defends against the lowest level of automation. And if that is a legit threat in your model, you are going to have a bad time.
It’s just going to trip you up at some point
But scriptkiddies and automated scans are not a security threat. If they were a legitimate threat to your server, you have bigger problems.
All it does is reduce log chatter.
Anyone actually wanting in would port scan, then try and connect to each port, and quickly identify an SSH port
Imagine that the xz exploit actually made it into your server, so your sshd was vulnerable. Having it on another port does seem helpful then. In fact i sometimes think of putting mine on a random secret address in the middle of a /64 ipv6 range, but I haven’t done that yet.
it occurs to me, the xz exploit and similar is a good reason not to run the latest software. It affected Debian Sid but not the stable releases. I’m glad I only run the stable ones.
The XZ backdoor was not exploited so it is hard to say what would of been effective.
The important thing to note is changing the defaults on systems. Defaults are bad because it makes it easy to take over a large number of systems easily. Even right now there are bots testing common ports for weaknesses.
Just have 2 ipv4 assigned to your server. Have 1 for all your services, and run ssh on the other allowing root login with the password “admin”.
A random ipv6 in the same subnet as your server is just obscurity.
The XZ exploit would be functionally similar to allowing root login using the password “admin”.
Would doing that on a different port be secure? No? Then a different port is not security, it’s obscurity.
Obscurity is just going to trip you up at some point and reduce log chatter.
And yes, running LTSB/stable is a sensible choice for servers.
I’ve never seen an attack that scans all ports. Normally it just checks open ports and then tries common credentials and exploits. If that fails it moves on to the next IP.
Changing the default port on SSH probably isn’t going to do much as SSH is already pretty secure. However it is a good rule of thumb to change the defaults.
Maybe I’m missing something but how is the host ip known? The server has a maybe-known range of addresses, but I don’t announce which address has an sshd listening. There are 2**64 addresses in the range, so scanning in 1 second doesn’t sound feasible.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
Move services away from known ports and don’t use ports that end with well known port numbers (22,80,443).
Moving ssh from 22 to 2222 or 443 to 10443 does nothing. You have ~65000 ports. Pick something random like 6744 or 2458
Still does nothing when scanning the entire ipv4 address space achievable so quickly. You can also use services like shodan to find vulnerable services on any ports.
Use SSH keys, stay upgraded. Make management services (SSH, RDP, admin services) accessible only via VPN (WireGuard). Only expose 80 and 443 to the internet, if necessary.
Just don’t port forward ssh. There is 0 reason to in 99.99% of home cases
Changing ports does nothing except reduced log chatter.
Security through obscurity is not security
It breaks automation. Same thing for changing any default. Change default names, directories and anything else that’s to predictable
Moving ports does help. It is not a sure thing but when used in conjunction with other security mechanism can help get rid the of the low hanging fruit of scriptkiddies and automated scans.
Security by obscurity is no security.
It is if you are defending against automation.
It defends against the lowest level of automation. And if that is a legit threat in your model, you are going to have a bad time.
It’s just going to trip you up at some point
I’m not saying it should be your only defense. I’m saying that changing defaults is a good idea for secure systems.
For instance, you should change the default WiFi password on your router.
Yes, because a password is security
So is changing the port. It won’t do a lot in terms of security but it will help a tiny bit
But scriptkiddies and automated scans are not a security threat. If they were a legitimate threat to your server, you have bigger problems.
All it does is reduce log chatter.
Anyone actually wanting in would port scan, then try and connect to each port, and quickly identify an SSH port
Automated attacks are a huge threat. Changing defaults shouldn’t be your only security practice but it can significantly help defend a network.
Imagine that the xz exploit actually made it into your server, so your sshd was vulnerable. Having it on another port does seem helpful then. In fact i sometimes think of putting mine on a random secret address in the middle of a /64 ipv6 range, but I haven’t done that yet.
it occurs to me, the xz exploit and similar is a good reason not to run the latest software. It affected Debian Sid but not the stable releases. I’m glad I only run the stable ones.
The XZ backdoor was not exploited so it is hard to say what would of been effective.
The important thing to note is changing the defaults on systems. Defaults are bad because it makes it easy to take over a large number of systems easily. Even right now there are bots testing common ports for weaknesses.
Just have 2 ipv4 assigned to your server. Have 1 for all your services, and run ssh on the other allowing root login with the password “admin”.
A random ipv6 in the same subnet as your server is just obscurity.
The XZ exploit would be functionally similar to allowing root login using the password “admin”.
Would doing that on a different port be secure? No? Then a different port is not security, it’s obscurity.
Obscurity is just going to trip you up at some point and reduce log chatter.
And yes, running LTSB/stable is a sensible choice for servers.
Nope. Your entire server can be scanned in less than a second for an open ssh port.
IPv6 does not change the fact since when your server is attacked the hist IP is already known.
I’ve never seen an attack that scans all ports. Normally it just checks open ports and then tries common credentials and exploits. If that fails it moves on to the next IP.
Changing the default port on SSH probably isn’t going to do much as SSH is already pretty secure. However it is a good rule of thumb to change the defaults.
Maybe I’m missing something but how is the host ip known? The server has a maybe-known range of addresses, but I don’t announce which address has an sshd listening. There are 2**64 addresses in the range, so scanning in 1 second doesn’t sound feasible.