Got any security advice for setting up a locally hosted website/external service?

Submitted ⁨⁨2⁩ ⁨days⁩ ago⁩ by ⁨Smokeydope@lemmy.world⁩ to ⁨selfhosted@lemmy.world⁩

cross-posted from: lemmy.world/post/31153014

Setting up a personal site on local hardware has been on my bucket list for along time. I finally bit he bullet and got a basic website running with apache on a Ubuntu based linux distro. I bought a domain name, linked it up to my l ip got SSL via lets encrypt for https and added some header rules until security headers and Mozilla observatory gave it a perfect score.

Am I basically in the clear? What more do I need to do to protect my site and local network? I’m so scared of hackers and shit I do not want to be an easy target.

I would like to make a page about the hardware its running on since I intend to have it be entirely ran off solar power like solar.lowtechmagazine and wanted to share technical specifics. But I heard somewhere that revealing the internal state of your server is a bad idea since it can make exploits easier to find. Am I being stupid for wanting to share details like computer model and software running it?

source

Comments

Sort:hotnew top

SidewaysHighways@lemmy.world ⁨8⁩ ⁨hours⁩ ago
pangolin?

source
- Smokeydope@lemmy.world ⁨7⁩ ⁨hours⁩ ago
  Pangolin.
  
  Image
  
  source
dgdft@lemmy.world ⁨2⁩ ⁨days⁩ ago
No need to cargo-cult security practices here, chief. You’re not gonna get pwned by publishing your hardware specs. If you’re planning to build some kinda webapp for yourself, that’s a different story - but you have to fuck up hard to get hacked while hosting raw HTML.

Use an SSH key, disable password auth, make sure you’re firewalled, and call it a day.

source
- Smokeydope@lemmy.world ⁨2⁩ ⁨days⁩ ago
  Thanks for the input! I do eventually plan on making some scripts and a custom web interface to interact with/expose some local services on my network once I have the basics of HTML covered so would like to cover my ass early and not have problems later
  
  source
  - non_burglar@lemmy.world ⁨2⁩ ⁨days⁩ ago
    The most important thing is to use your common sense, think about it an extra minute before punching holes in your fw, and keep those holes documented and to a minimum.
    
    source
monogram@feddit.nl ⁨1⁩ ⁨day⁩ ago
Fail2ban ufw

port forward only the bare minimum (80 443)

Expose docker ports with 127.0.0.1:8000:8000 then port forward with caddy server on the host

source
- dgdft@lemmy.world ⁨1⁩ ⁨day⁩ ago
  This is dangerous advice because docker is well-known for undoing UFW’s iptable rules.
  
  source
  - NastyNative@mander.xyz ⁨4⁩ ⁨hours⁩ ago
    Do not open those ports hosting is way to cheap now to take that risk!
    
    source
  - monogram@feddit.nl ⁨1⁩ ⁨day⁩ ago
    Docker is going to undo your port iptable rules with or without ufw
    
    Running rm -rf ~ isn’t that hard to do either just don’t do it.
    
    Your router’s NAT should save you if that happens on the wrong port anyway.
    
    source
    -> View More Comments
stardustsystem@lemmy.world ⁨2⁩ ⁨days⁩ ago
You might want to set up dynamic DNS for your domain. If you’re hosting from a residential internet connection then your ISP will change your address eventually. Ddclient can be used to report your current IP to your Registrar regularly, so if it changes the domain moves along with it.

source
- dai@lemmy.world ⁨13⁩ ⁨hours⁩ ago
  Depends on your ISP and where in the world you live.
  
  source
just_another_person@lemmy.world ⁨2⁩ ⁨days⁩ ago
Keep it segregated from your internal network, no password auth, or better yet, install a privatenet client (Tailscale, Zerotier…etc) and don’t open SSH ports at all, consider using a Cloudflare Tunnel or similar…that’s a basic start.

Honestly, if you’re serving a static site, just deploy it on Digitalocean Apps or R2 for free and skip all the worry and get all the Cloudflare protection built-in.

source
- dai@lemmy.world ⁨13⁩ ⁨hours⁩ ago
  Cloudflared is such a nice feature, have seperate tunnels for different services hosted on the one machine.
  
  source
catloaf@lemm.ee ⁨2⁩ ⁨days⁩ ago
Isolate it as much as possible. If you can, put it on a little DMZ subnet with access to nothing else. Don’t run any unnecessary services, and especially expose only the services you need to (HTTP) and none of the ones you don’t (ssh).

source
Coleslaw4145@lemmy.world ⁨1⁩ ⁨day⁩ ago
Use a reverse proxy in a DMZ. You can use something like Bunkerweb + Crowdsec to give you a WAF and dynamic IP blocklist in front of your web service.

source