this post was submitted on 04 Mar 2024
70 points (100.0% liked)

Selfhosted

40198 readers
780 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
70
I'm new to self hosting. How do I monitor security? (lemmy.world)
submitted 8 months ago by sacbuntchris@lemmy.world to c/selfhosted@lemmy.world
28 comments fedilink hide all child comments
 

I'm not great with Docker or networking, so when I picked up an n100 mini pc for self hosting I installed Ubuntu and Tipi to get started.

I used Tipi to install Immich and forwarded my ports, then setup cloudflare tunneling to expose it to the internet. Currently I'm migrating from Google Photos.

But since I'm new to this I'm worried about exposing Immich to the internet without really knowing what I'm doing. Any suggestions on ways to monitor my setup to make sure nothing goes wrong or gets hacked? Ideally any application suggestions would come from the Tipi app store but I'm willing to learn if there's no other option. Thanks!

you are viewing a single comment's thread
view the rest of the comments
[–] ricecake@sh.itjust.works 23 points 8 months ago (1 children)

It's not a simple task, so I won't list many specifics, but more general principles.

First, some specifics:

  • disable remote root login via ssh.
  • disable password login, and only permit ssh keys.
  • run fail2ban to lock people out automatically.

Generally:

  • only expose things you must expose. It's better to do things right and secure than easy. Exposing a webservice requires you to expose port 443 (https). Basically everything else is optional.
  • enable every security system that you don't have reason to disable. Selinux giving you problems? Don't turn it off, learn how to write rules to let your application do the specific things it needs. Only make firewall exceptions where needed, rather than disabling the firewall.
  • give system users the minimum access they require to function.
  • set folder permissions as restrictively as possible. FACLs will help, because it lets you be much more nuanced.
  • automatic updates. If you have to remember to do it, it won't happen. Failure to automate updates means your software is out of date.
  • consider setting up a dedicated authentication setup like authellia or keycloak. Applications tend to, frankly, suck at security. It's not what they're making so it's not as good as a dedicated security service. There are other follow on benefits.
  • if it supports two factor, enable it.

You mentioned using cloud flare, which is good. You might also consider configuring your firewall to disallow outbound connections to your local network. That way if your server gets owned, they can't poke other things on your network.

[–] foggy@lemmy.world 4 points 8 months ago (2 children)

only expose things you must expose. It's better to do things right and secure than easy. Exposing a webservice requires you to expose port 443 (https). Basically everything else is optional.

Not sure if it's always possible but I setup an auth portal via port 443 where I'm using authelia and fail2ban, and using traefik to route authenticated users to other ports from there. So for example Plex 32400 is not exposed, only 443. But you get there via 443 and authentication.

[–] ricecake@sh.itjust.works 3 points 8 months ago

Yup, that's a really good pattern to follow. Not only does it minimize your exposure behind a secured entry, it also makes sure that all of your access is uniformly authenticated.

You have to do some shenanigans to do something similar with other, non-http based services, but it's possible with most of them.

[–] billygoat@catata.fish 1 points 8 months ago

Does that still allow other Plex users the ability to play remotely without having to use Plex relay?