74
Basic Security for your Website | Loudwhisper
(loudwhisper.me)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 Jul 2024
74 points (98.7% liked)
Selfhosted
40199 readers
282 users here now
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).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
Good read.
I would just like to add some additional information that favors changing your SSH port to something other than the default. When crawlers are going around the internet looking for vulnerable SSH servers, they're more than likely going to have an IP range and specifically look for port 22.
Now can they go through and scan your IP and all of its ports to look for the SSH service? Yes. But you will statistically have less interactions with bad actors this way since they might specifically be looking for port 22.
As a side note, don't be cute and pick port 221 or 2222 or 22022 or whatever that's got "22" in it.
I know that sounds silly but the slightly less stupid bots are written by people who understand people do things like that and account for them, and thus port 2222 isn't actually better than 22, or whatever.
imho - never expose that shit anyways, and VPN into your local network first. Only thing I ever expose to the internet is 80/443.
At the very least, if you're going to expose an SSH session to the internet, set up some sort of port-knocking. It's security by obscurity, sure - but it will keep all but the most ardent intruders out.
Agreed, but sometimes you have to expose things you'd rather not; I just figured I'd mention that almost everyone's immediate urge to just go 'port 2222! that'll do it!' isn't exactly better than doing nothing anymore.
Thanks! I did mention this briefly, although I belong to the school that "since I am anyway banning IPs that fail authentication a few times, it's not worth changing the port". I think that it's a valid thing especially if you ingest logs somewhere, but if you do don't choose 2222! I have added a link to shodan in the post, which shows that almost everybody who changes port, changes to 2222!
Yeah, I just left my SSH port as 22 since I only use key-based authentication so there's really no security risk. Plus, it's funny going through the logs and looking at all the login attempts.
Yep I agree. Especially looking at all the usernames that are tried. I do the same and the only risk come from SSH vulnerabilities. Since nobody would burn a 0-day for SSH (priceless) on my server, unattended upgrades solve this problem too for the most part.
I mean we just had https://nvd.nist.gov/vuln/detail/CVE-2024-6387 -- so my guess is that you're updating quite often to be so confident in your unattended upgrades.
Yeah I know (I mentioned it myself in the post), but realistically there is no much you can do besides upgrading. Unattended upgrades kick in once a day and you will install the security patches ASAP. There are also virtual patches (crowdsec has a virtual patch for that CVE), but they might not be very effective.
I argue that VPN software is a smaller attack surface, but the problem still exists (CVEs) for everything you expose.
There is one neat trick: don't expose SSH.
There is still not a reason anyone has been able to give for 99% of self-hosters to expose SSH.
If you need to access your machine via ssh while on the go. Wireguard to your local network, use SSH. Done. Unless you are running an always-up public facing site, the amount of times you have to access your machine that can't wait until after work is very low anyway.
Bots will scan all ports. That is just how it works. Less than 22, but you will still get spammed. Why force your computer to go through the fail2ban loop and take up resources when it is simply not needed at all and you can block it on another machine?
Comfort is the main reason, I suppose. If I mess up Wireguard config, even to debug the tunnel I need to go to the KVM console. It also means that if I go to a different place and I have to SSH into the box I can't plug my Yubikey and SSH from there. It's a rare occurrence, but still...
Ultimately I do understand both point of view. The thing is, SSH bots pose no threats after the bare minimum hardening for SSH has been done. The resource consumption is negligible, so it has no real impact.
To me the tradeoff is slight inconvenience vs slightly bigger attack surface (in case of CVEs). Ultimately everyone can decide which compromise is acceptable for them, but I would say that the choice is not really a big one.
This blog is specifically for websites that are public facing. Sure, you can wireguard into your local network, but you can also SSH into your local network. Either way you have to poke a hole.