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?
https://github.com/fosrl/pangolin
use this instead of tailscale or other corporate options. tailscale is going for IPO, their service cannot survive investor greed.
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 (i.e. test with nmap), and call it a day.
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 as part of a portfolio thing so would like to cover my ass early and not have problems later
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.
Fail2ban ufw nftables
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
Edit: add nftables
This is dangerous advice because docker is well-known for undoing UFW’s iptable rules. It’s mitigated by binding to localhost, but still way too easy for people to shoot themselves in the foot by using the two together.
Do not open those ports hosting is way to cheap now to take that risk!
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.
You shouldn’t suggest UFW at all then. There are other firewall options that can be used just fine with docker.
It does have real potential to cause issues, e.g. if OP were to put their server in DMZ mode on their router and later copy some docker setup instructions that don’t explicitly bind to localhost.
Please tell me more, which firewall would you recommend that plays nice with Docker?
No NAT? Hahaha that’s a big if, and why would you copy paste a docker compose without reading it?
Please tell me more, which firewall would you recommend that plays nice with Docker?
Firewalld
No NAT?
Another user in this thread suggested DMZing, so combine your advice with theirs and boom. It’s not uncommon, and it’s fine if you firewall the box yourself. Most people don’t knowingly choose to use a firewall that they don’t intend to work, like you would.
why would you copy paste a docker compose without reading it?
There’s more than one way to use docker. Spinning up an official mysql image using the official
docker runORdocker composecalls suggested by the docs would start up a server wide open to the entire internet if DMZ’d.@monogram@feddit.nl nftables
Cool! ufw supports nftables too.
@monogram@feddit.nl yes. but I use it without UFW.
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.
Depends on your ISP and where in the world you live.
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.
Cloudflared is such a nice feature, I have seperate tunnels for different services hosted on the one machine.
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).
pangolin?
Pangolin.
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.
