Selfhosted

40183 readers

1087 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

[email protected]

Basic Security for your Website | Loudwhisper (loudwhisper.me)

submitted 3 months ago by [email protected] to c/[email protected]

29 comments fedilink hide all child comments

Hi, recently (ironically, right after sharing some of my posts here on Lemmy) I had a higher (than usual, not high in general) number of "attacks" to my website (I am talking about dumb bots, vulnerability scanners and similar stuff). While all of these are not really critical for my site (which is static and minimal), I decided to take some time and implement some generic measures using (mostly) Crowdsec (fail2ban alternative?) and I made a post about that to help someone who might be in a similar situation.

The whole thing is basic, in the sense that is just a way to reduce noise and filter out the simplest attacks, which is what I argue most of people hosting websites should be mostly concerned with.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 3 months ago* (last edited 3 months ago) (2 children)

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?

[–] [email protected] 1 points 3 months ago

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.

[–] [email protected] 0 points 3 months ago* (last edited 3 months ago)

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.