What steps do you take to secure your server and your selfhosted services?

Comments

• AkatsukiLevi@lemmy.world ⁨4⁩ ⁨days⁩ ago

  Disable password authentication on SSH

  Enable firewall and block all ports you’re not using(most firewalls do this by default)

  Switch to a LTS kernel(not security related, but it keeps things going smooth… Technically it is safer since it gets updated less often so it is a bit more battle tested? Never investigated whenever a LTS kernel is safer than a standard one)

  Use Caddy to proxy to services instead of directly exposing them out

  HTTPS for web stuff(Caddy does it automatically)

  source

  • ZonenRanslite@feddit.org ⁨4⁩ ⁨days⁩ ago

    This and fail2ban

    source

    • ocean@lemmy.selfhostcat.com ⁨4⁩ ⁨days⁩ ago

      Anything else?

      source

      • -> View More Comments
  • Shimitar@downonthestreet.eu ⁨4⁩ ⁨days⁩ ago

    This, but I prefer nginx.

    And no real need for tailscale or cloudflare. If you do not like to depend on a third party service, either port forward and ddns or an external vps+wire guard if you have gcnat

    source

    • szszl@sh.itjust.works ⁨2⁩ ⁨days⁩ ago

      This is a valid solution but honestly how is using VPS not depending on third party?

      source

      • -> View More Comments
  • JustEnoughDucks@feddit.nl ⁨3⁩ ⁨days⁩ ago

    Dropping instead of blocking might technically be better because it wastes a bit more bot time and they see it as “it doesn’t exist” rather than an obsticle to try exploits on. Not sure if that is true though.

    For me:

    • ssh server only with keys

    • absolutely no ssh forwarding, only available to local network via firewall rules

    • docker socket proxy for everything that needs socket access

    • drop non-used ports, limit IPs for local-only services (e.g. paperless)

    • crowdsec on traefik for the rest (sadly it blocks my VPN IPs also)

    • Authelia over everything that doesn’t break the native apps (jellyfin and home assistant are the two that it breaks so far, and HA was very intermittent so I made a separate authelia rule and mobile DNS entry for slightly reduced rules)

    • proper umask rules on all docker directories (or as much as possible)

    • main drive FDE with a separate boot drive with FDE keyfile on a dongle that is removed except for updates and booting to make snatch-and-grabs useless and compromising bootloader impractical

    • full disk encryption with passworded data drives, so even if a smash and grab happens when I leave the dongle in, the sensitive data is still encrypted and the keys aren’t in memory (makes a startup script with a password needed, so no automated startups for me)

    For more info, I followed a lot of stuff on: github.com/…/How-To-Secure-A-Linux-Server

    source
  • szszl@sh.itjust.works ⁨2⁩ ⁨days⁩ ago

    Caddy or any other (reputable) reverse proxy. I think Nginx Proxy Manager would be best for beginner thanks to GUI.

    source
• SplashJackson@lemmy.ca ⁨3⁩ ⁨days⁩ ago

  I put up a sign that says, “No hackers allowed plz”

  source

  • ocean@lemmy.selfhostcat.com ⁨3⁩ ⁨days⁩ ago

    How has that been going?

    source

    • ikidd@lemmy.world ⁨2⁩ ⁨days⁩ ago

      “All your containers are belong to us.”

      source
• catloaf@lemm.ee ⁨4⁩ ⁨days⁩ ago

  I don’t put it on the Internet.

  I have automatic updates enabled and once in a while I scan with Nessus. Also I have backups. Stuff dying or me breaking it is a much greater risk than getting hacked.

  source

  • woodsb02@lemmy.ml ⁨4⁩ ⁨days⁩ ago

    I agree - I don’t expose anything to the internet other than the WireGuard endpoint.

    I’m only hosting services that my immediate family need to access, so I just set up WireGuard on their devices, and only expose the services on the LAN.

    I used to expose services to the internet, until one of my #saltstack clients was exploited through a very recent vulnerability I hadn’t yet patched (only a week or so since it was announced). I was fortunate that the exploit failed due to the server running FreeBSD, so the crontab entry to download the next mailicious payload failed because wget wasn’t available on the server.

    That’s when I realised - minimise the attack surface - if you’re not hosting services for anyone in the world to access, don’t expose them to everyone in the world to exploit.

    source

    • rockstarmode@lemmy.world ⁨4⁩ ⁨days⁩ ago

      I don’t expose anything to the internet other than the WireGuard endpoint.

      This is the way

      source
    • captainjaneway@lemmy.world ⁨4⁩ ⁨days⁩ ago

      TBF if you want, you can have a bastion server which is solely whitelisted by IP to stream your content from your local server. It’s obviously a pivot point for hackers, but it’s the level of effort that 99% of hackers would ignore unless they really wanted to target you. And if you’re that high value of a target, you probably shouldn’t be opening any ports on your network, which brings us back to your original solution.

      I, too, don’t expose things to the public because I cannot afford the more safe/obfuscated solutions. But I do think there are reasonable measures that can be taken to expose your content to a wider audience if you wanted.

      source
  • NarrativeBear@lemmy.world ⁨4⁩ ⁨days⁩ ago

    Is Nessus free for personal use?

    source

    • catloaf@lemm.ee ⁨4⁩ ⁨days⁩ ago

      For up to 16 endpoints or something like that, yes.

      source
• MangoPenguin@lemmy.blahaj.zone ⁨2⁩ ⁨days⁩ ago

  They aren’t on the internet mainly.

  source
• Chewy7324@discuss.tchncs.de ⁨3⁩ ⁨days⁩ ago

  Some I haven’t yet found in this thread:

  • rootless podman
  • container port mapping to localhost (e.g. 127.0.0.1:8080:8080)
  • systemd services with many of its sandboxing features (PrivateTmp, …)

  source

  • ocean@lemmy.selfhostcat.com ⁨2⁩ ⁨days⁩ ago

    Does adding 127.0.0.1 make it so only that server can access it or what? I’ve seen that but not understand

    source

    • Chewy7324@discuss.tchncs.de ⁨17⁩ ⁨hours⁩ ago

      127.0.0.0 is the localhost. This is the IP the container is listening on. Even if there was no firewall it wouldn’t allow any connection except from the host. If it’s set to 0.0.0.0 it means it’ll allow connections from any IP (which might not be an issue depending on your setup).

      The reverse proxy runs on localhost anyway, so any other IPs have no reason to ever have access.

      source
  • ikidd@lemmy.world ⁨2⁩ ⁨days⁩ ago

    I assume #2 is just to keep containers/stacks able to talk to each other without piercing the firewall for ports that aren’t to be exposed to the outside? It wouldn’t prevent anything if one of the containers on that host were compromised, afaik.

    source

    • MangoPenguin@lemmy.blahaj.zone ⁨2⁩ ⁨days⁩ ago

      Containers can talk to each other without any ports exposed at all, they just need to be added to the same docker network.

      source

      • -> View More Comments
    • Chewy7324@discuss.tchncs.de ⁨2⁩ ⁨days⁩ ago

      It’s mostly to allow the reverse proxy on localhost to connect to the container/service, while blocking all other hosts/IPs.

      This is especially important when using docker as it messes with iptables and can circumvent firewall like e.g. ufw.

      You’re right that it doesn’t increase security on case of a compromised container. It’s just about outside connections.

      source

      • -> View More Comments
• irmadlad@lemmy.world ⁨3⁩ ⁨days⁩ ago

  • Fail2ban
  • UFW
  • Reverse Proxy
  • IPtraf (monitor)
  • Lynis (Audit)
  • OpenVas (Audit)
  • Nessus (Audit)
  • Non standard SSH port
  • CrowdSec + Appsec
  • No root logins
  • SSH keys
  • Tailscale
  • RKHunter

  source
• MTK@lemmy.world ⁨3⁩ ⁨days⁩ ago

  Just tailscale really.

  My services are only exposed to the tailscale network, so I don’t have to worry about otger devices on my LAN.

  A good VPN with MFA is all you really need if you are the only user.

  source
• hperrin@lemmy.ca ⁨3⁩ ⁨days⁩ ago

  One thing I do is instead of having an open SSH port, I have an OpenVPN server that I’ll connect to, then SSH to the host from within the network. Then, if someone hacks into the network, they still won’t have SSH access.

  source

  • ocean@lemmy.selfhostcat.com ⁨1⁩ ⁨day⁩ ago

    Thanks :)

    source
  • Chewy7324@discuss.tchncs.de ⁨3⁩ ⁨days⁩ ago

    I do the same, but with Wireguard instead of OpenVPN. The performance is much better in my experience and it sucks way less battery life on my phone.

    source

    • ocean@lemmy.selfhostcat.com ⁨1⁩ ⁨day⁩ ago

      I’ve been meaning to learn how to make my own

      source

      • -> View More Comments
• xcutie@linux.community ⁨2⁩ ⁨days⁩ ago

  To add some points, that I do:

  • Proper logging: So I could realize something unusual is going on
  • rootless podman container: harder to escalate privileges and gain root
  • Apparmor: same, plus it could trigger suspicious log entries

  source
• Oderus@lemmy.world ⁨2⁩ ⁨days⁩ ago

  NPM, Nginx

  If I need remote access, I just log into NPM and I have certain URL’s created for Plex, or Sonarr, Radarr etc. No issues so far.

  source
• MTK@lemmy.world ⁨3⁩ ⁨days⁩ ago

  in the context of the comment you referenced:

  Definitely have the server on its own VLAN. It shouldn’t have any access to other devices that are not related to the services and I would also add some sort of security software.

  If you have a public service that you expect to have multiple users on you definitely should have some level of monitoring whether it is just the application logs from the forum that you want to host or further have some sort of EDR on the server.

  Things I would do if I was hosting a public forum:

  • Reverse proxy
  • fail2ban
  • dedicated server that does not have any personal data or other services that are sensitive
  • complete network isolation with VLAN
  • send application logs to ELK
  • clamAV

  And if the user base grows I would also add:

  • EDR such as velociraptor
  • an external firewall / ips
  • possibly move from docker to VM for further isolation (not likely)

  source
• DannyBoy@sh.itjust.works ⁨3⁩ ⁨days⁩ ago

  Tailscale and being at my house is the only two ways in so I feel those are pretty good for me.

  source
• melfie@lemmings.world ⁨2⁩ ⁨days⁩ ago

  As many others have said, not allowing inbound WAN connections into my LAN is an important step. I also run k3s on my server with Calico as the CNI and make heavy use of network policies to keep anything I’m running from misbehaving. I use OpenWRT on my router and force certain devices to run through a VPN and block other devices from the internet entirely.

  source
• qjkxbmwvz@startrek.website ⁨3⁩ ⁨days⁩ ago

  Fail2ban config imcan get fairly involved in my experience. I’m probably not doing it the right way, as I wrote a bunch of web server ban rules — anyone trying to access wpadmin gets banned, for instance (I don’t use WordPress, and if I did, it wouldn’t be accessible from my public facing reverse proxy).

  I just skimmed my nginx logs and looked for anything funky and put that in a ban rule, basically.

  source

  • ocean@lemmy.selfhostcat.com ⁨1⁩ ⁨day⁩ ago

    Thanks!

    Here’s the setup I followed. It seems like it might take away some manual work for you: m.youtube.com/watch?v=Ha8NIAOsNvo&t=1294s&pp=ygUI…

    source
• jimmy90@lemmy.world ⁨3⁩ ⁨days⁩ ago

  use a cheap vlan switch to make an actual vlan DMZ with the services’ router

  use non-root containers everywhere. segment services in different containers

  source
• ace@lemmy.ananace.dev ⁨3⁩ ⁨days⁩ ago

  Default block for incoming traffic is always a good starting point.
  I’m personally using crowdsec to good results, but still need to add some more to it as I keep seeing failed attacks that should be blocked much quicker.

  source
• kratoz29@lemm.ee ⁨3⁩ ⁨days⁩ ago

  I expose some stuff through IPv6 only with my Synology NAS (I am CGNATED) and I have always wondered if I still need to use fail2ban in that environment…

  My Synology has an auto block feature that from my understanding is essentially fail2ban, what I don’t know is if such a feature works for all my exposed services but Synology’s.

  source

  • lorentz@feddit.it ⁨3⁩ ⁨days⁩ ago

    My Synology has an auto block feature that from my understanding is essentially fail2ban, what I don’t know is if such a feature works for all my exposed services but Synology’s

    I’d be surprised if it works for custom services. Fail2ban has to know what’s running and haw to have access to its log file to know what is a failed authentication request. The best you can do without log access is to rate limit new tcp connections. But still you should know what’s the service behind because 5 new SSH sessions per minute and IP can be reasonable 5 new http1.0 connections likely cannot load a single html page.

    source