1. For all the mentioned cases, if your firewall blocks incoming packets by default, no one can access it, no matter what is the source of the port being open.

2. You don’t configure it on the docker level, at least if you care about outside connections. If you mean from your local computer to a docker container, by default you cannot connect, unless you expose the port to the system. If you mean from other docker containers, just create your own separate network to run the container in and even docker containers cannot access the ports.

3. I usually use netstat -tulpn, it lists all ports, not only docker, but docker is included. docker ps should also show all exposed ports and their mappings.

In general, all docker containers run on some internal docker network. Either the default or a custom one. The network’s ports don’t interfere with your own, that’s why you can have 20 nginx servers running in a docker container on the same port. When you bind a port in docker, you basically create a bridge from the docker network to your PC’s local network. So now anything that can connect to your PC can also connect to the service. And if you allow connection to the port from outside the network, it will work as well. Note that port forwarding on your router must be set up.

So in conclusion, to actually make a service running in docker visible to the public internet, you need to do quite a few steps!

• bind a port to your local host
• have your local firewall allow connection to the port
• have your router set up to forward connections on the port to your machine

On Linux, local firewall is usually disabled by default, but the other two steps require you to actively change the default config. And you mention that all incoming traffic is dropped using UFW, so all three parts should be covered.

I’m using Proton mail, I like their focus on privacy and e2e (only with other Proton users, though).

We use .lh, short for localhost. For local network services I use service discovery and .local. And for internal stuff we just use a subdomain of our domain.

I personally only turn it off when someone’s visiting over night and the noise disturbs them, otherwise I just leave it on nonstop. Mainly because it would annoy me to try to open whatever and find out I have to turn on the server first. I don’t have a UPS and never even thought about getting one (for the server, I’m thinking of getting one for my 3D printer).

I use Proton Mail for my primary domain and then addy.io for redirects to it. It costs $10 a year or something like that and it’s all I actually need.

Replying to emails is as easy as just hitting reply, the only thing that’s slightly harder is sending entirely new email (as in not replying) but even that can either be remembered, or the special email address copied from the addy.io app.

Avahi basically broadcasts to the whole network “hello there, my name is some-cool-domain.local”. When you request that address, your router checks if someone broadcasts that name and uses their IP if so.

Yes, indeed, it’s your local timezone.

store all of the documents, desktop, downloads, etc. on a couple computers

Why use SSHFS for that? I recommend using Syncthing, it’s great for synchronizing stuff across multiple PCs (local and remote).

You need to host your domain somewhere, meaning some DNS provider needs to be the authority on what gets routed where when someone accesses your domain.

The provider will give you a list of nameservers when you make the domain part of their DNS.

I don’t know if there are any that are free (if you don’t also buy a domain from them), so you’ll have to check on your own. You can also self-host a bind9 server and do your DNS there.

Ah, I’ve only ever seen it in combination with a tunnel, so I assumed it’s part of that.

It makes a tunnel through to you and links to that.

True. But pretty much the same applies for dynamic DNS services, except you have to trust your dynamic DNS provider.

I meant more because people generally don’t have as much time to spend on IT security as companies, but yeah, it works for privacy as well.

My recommendation: host OpenVPN, change the default port and only access your NAS from the internet using your VPN. Also only allow the VPN port on your router firewall.

Note that I only did a brief evaluation of baby buddy, compared to that:

• better looking and less confusing
• snappier user interface
• fully end-to-end encrypted

I don’t know about other features, like sharing etc., but my reason to create this was that I wanted something modern looking without security compromises.

Yep, that’s planned, as it has already been requested.

Well, technically speaking you can use it for that.

I’ll whip up some docker image during the next week!

Well, managing servers is part of my job. So stuff like what you mention doesn’t really make it easier for me and it adds unnecessary overhead.

In theory, though in this particular case you’re giving them to an open source app which you can check the source code of. Of course there is the possibility that I’ve modified the code that I’m hosting, you’re gonna have to trust me that I didn’t.

I’m an author of many open source libraries and apps and I have no need to steal your credentials. Though that of course doesn’t have to mean anything to you.

But if you’re giving your credentials to a mobile app or any other frontend, you’re doing pretty much the same thing. And technically speaking, even trusting your instance admins is the same thing - they might have modified the code to log your credentials.

In general, yes, you should be worried where you put your credentials. In ideal scenario Lemmy would support OAuth or something like that, but that’s not the case currently.