Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

agnos.is Forums

  1. Home
  2. Selfhosted
  3. What steps do you take to secure your server and your selfhosted services?

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

Scheduled Pinned Locked Moved Selfhosted
selfhosted
58 Posts 32 Posters 470 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • akatsukilevi@lemmy.worldA [email protected]

    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)

    R This user is from outside of this forum
    R This user is from outside of this forum
    [email protected]
    wrote on last edited by
    #22

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

    this one haven't failed me....yet.

    PS: please don't pentest me

    1 Reply Last reply
    0
    • kratoz29@lemm.eeK [email protected]

      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.

      L This user is from outside of this forum
      L This user is from outside of this forum
      [email protected]
      wrote on last edited by
      #23

      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.

      1 Reply Last reply
      0
      • akatsukilevi@lemmy.worldA [email protected]

        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)

        justenoughducks@feddit.nlJ This user is from outside of this forum
        justenoughducks@feddit.nlJ This user is from outside of this forum
        [email protected]
        wrote on last edited by
        #24

        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: https://github.com/imthenachoman/How-To-Secure-A-Linux-Server

        1 Reply Last reply
        0
        • O [email protected]

          Inspired by this comment to try to learn what I'm missing.

          • Cloudflare proxy
          • Reverse Proxy
          • Fail2ban
          • Docker containers on their own networks
          irmadlad@lemmy.worldI This user is from outside of this forum
          irmadlad@lemmy.worldI This user is from outside of this forum
          [email protected]
          wrote on last edited by
          #25
          • 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
          1 Reply Last reply
          0
          • O [email protected]

            Inspired by this comment to try to learn what I'm missing.

            • Cloudflare proxy
            • Reverse Proxy
            • Fail2ban
            • Docker containers on their own networks
            D This user is from outside of this forum
            D This user is from outside of this forum
            [email protected]
            wrote on last edited by
            #26

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

            1 Reply Last reply
            0
            • G [email protected]

              My new strategy is to block EVERY port except WireGuard. This doesn't work for things you want to host publicly ofc, like a website, but for most self host stuff I don't see anything better than that.

              irmadlad@lemmy.worldI This user is from outside of this forum
              irmadlad@lemmy.worldI This user is from outside of this forum
              [email protected]
              wrote on last edited by
              #27

              My new strategy is to block EVERY port

              Wow! All 65535 +/-, in and out? That's one way to skin a cat.

              G 1 Reply Last reply
              0
              • irmadlad@lemmy.worldI [email protected]

                My new strategy is to block EVERY port

                Wow! All 65535 +/-, in and out? That's one way to skin a cat.

                G This user is from outside of this forum
                G This user is from outside of this forum
                [email protected]
                wrote on last edited by
                #28

                ez pz:

                #!/usr/sbin/nft -f
                table inet filter {
                    chain input {
                        type filter hook input priority raw; policy accept;
                        iif "lo" accept
                        ct state established,related accept
                        iif "enp1s0" udp dport 51820 accept
                        iif "enp1s0" drop
                    }
                
                    chain forward {
                        type filter hook forward priority raw; policy accept;
                        iif "lo" accept
                        ct state established,related accept
                        iif "enp1s0" udp dport 51820 accept
                        iif "enp1s0" drop
                    }
                
                    chain output {
                        type filter hook output priority raw; policy accept;
                    }
                }
                
                irmadlad@lemmy.worldI 1 Reply Last reply
                0
                • G [email protected]

                  ez pz:

                  #!/usr/sbin/nft -f
                  table inet filter {
                      chain input {
                          type filter hook input priority raw; policy accept;
                          iif "lo" accept
                          ct state established,related accept
                          iif "enp1s0" udp dport 51820 accept
                          iif "enp1s0" drop
                      }
                  
                      chain forward {
                          type filter hook forward priority raw; policy accept;
                          iif "lo" accept
                          ct state established,related accept
                          iif "enp1s0" udp dport 51820 accept
                          iif "enp1s0" drop
                      }
                  
                      chain output {
                          type filter hook output priority raw; policy accept;
                      }
                  }
                  
                  irmadlad@lemmy.worldI This user is from outside of this forum
                  irmadlad@lemmy.worldI This user is from outside of this forum
                  [email protected]
                  wrote on last edited by
                  #29

                  I've seen it done as such:

                  1 Reply Last reply
                  0
                  • O [email protected]

                    Inspired by this comment to try to learn what I'm missing.

                    • Cloudflare proxy
                    • Reverse Proxy
                    • Fail2ban
                    • Docker containers on their own networks
                    H This user is from outside of this forum
                    H This user is from outside of this forum
                    [email protected]
                    wrote on last edited by
                    #30

                    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.

                    C O 2 Replies Last reply
                    0
                    • O [email protected]

                      Inspired by this comment to try to learn what I'm missing.

                      • Cloudflare proxy
                      • Reverse Proxy
                      • Fail2ban
                      • Docker containers on their own networks
                      S This user is from outside of this forum
                      S This user is from outside of this forum
                      [email protected]
                      wrote on last edited by
                      #31

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

                      O 1 Reply Last reply
                      0
                      • H [email protected]

                        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.

                        C This user is from outside of this forum
                        C This user is from outside of this forum
                        [email protected]
                        wrote on last edited by
                        #32

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

                        O 1 Reply Last reply
                        0
                        • O [email protected]

                          Inspired by this comment to try to learn what I'm missing.

                          • Cloudflare proxy
                          • Reverse Proxy
                          • Fail2ban
                          • Docker containers on their own networks
                          C This user is from outside of this forum
                          C This user is from outside of this forum
                          [email protected]
                          wrote on last edited by
                          #33

                          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, ...)
                          ikidd@lemmy.worldI O 2 Replies Last reply
                          0
                          • O [email protected]

                            Inspired by this comment to try to learn what I'm missing.

                            • Cloudflare proxy
                            • Reverse Proxy
                            • Fail2ban
                            • Docker containers on their own networks
                            Q This user is from outside of this forum
                            Q This user is from outside of this forum
                            [email protected]
                            wrote on last edited by
                            #34

                            Fail2ban config can 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.

                            1 Reply Last reply
                            0
                            • S [email protected]

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

                              O This user is from outside of this forum
                              O This user is from outside of this forum
                              [email protected]
                              wrote on last edited by
                              #35

                              How has that been going?

                              ikidd@lemmy.worldI 1 Reply Last reply
                              0
                              • O [email protected]

                                How has that been going?

                                ikidd@lemmy.worldI This user is from outside of this forum
                                ikidd@lemmy.worldI This user is from outside of this forum
                                [email protected]
                                wrote on last edited by
                                #36

                                "All your containers are belong to us."

                                1 Reply Last reply
                                0
                                • C [email protected]

                                  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, ...)
                                  ikidd@lemmy.worldI This user is from outside of this forum
                                  ikidd@lemmy.worldI This user is from outside of this forum
                                  [email protected]
                                  wrote on last edited by
                                  #37

                                  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.

                                  mangopenguin@lemmy.blahaj.zoneM C 2 Replies Last reply
                                  0
                                  • akatsukilevi@lemmy.worldA [email protected]

                                    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)

                                    ? Offline
                                    ? Offline
                                    Guest
                                    wrote on last edited by
                                    #38

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

                                    1 Reply Last reply
                                    0
                                    • shimitar@downonthestreet.euS [email protected]

                                      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

                                      ? Offline
                                      ? Offline
                                      Guest
                                      wrote on last edited by
                                      #39

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

                                      shimitar@downonthestreet.euS 1 Reply Last reply
                                      0
                                      • O [email protected]

                                        Inspired by this comment to try to learn what I'm missing.

                                        • Cloudflare proxy
                                        • Reverse Proxy
                                        • Fail2ban
                                        • Docker containers on their own networks
                                        mangopenguin@lemmy.blahaj.zoneM This user is from outside of this forum
                                        mangopenguin@lemmy.blahaj.zoneM This user is from outside of this forum
                                        [email protected]
                                        wrote on last edited by
                                        #40

                                        They aren't on the internet mainly.

                                        1 Reply Last reply
                                        0
                                        • ikidd@lemmy.worldI [email protected]

                                          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.

                                          mangopenguin@lemmy.blahaj.zoneM This user is from outside of this forum
                                          mangopenguin@lemmy.blahaj.zoneM This user is from outside of this forum
                                          [email protected]
                                          wrote on last edited by
                                          #41

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

                                          ikidd@lemmy.worldI 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups