zlacker

You exposed your redis publicly? Why?

Edit: This is the kind of service that you should only expose to your intranet, i.e. a network that is protected through wireguard. NEVER expose this publicly, even if you don't have admin:admin credtials.

>>sva_+(OP)
I actually didn't know I had. At the time I didn't properly know how docker networking worked and I exposed redis to the host so my other containers could access it. And then since this was on a VPS with a dedicated IP, this made it exposed to the whole internet.

I now know better, but there are still a million other pitfalls to fall in to if you are not a full time system admin. So I prefer to just put it all behind a VPN and know that it's safe.

>>Schema+t1
> but there are still a million other pitfalls to fall in to if you are not a full time system admin.

Pro tip: After you configure a new service, review the output of ss -tulpn. This will tell you what ports are open. You should know exactly what each line represents, especially those that bind on 0.0.0.0 or [::] or other public addresses.

The pitfall that you mentioned (Docker automatically punching a hole in the firewall for the services that it manages when an interface isn't specified) is discoverable this way.

>>drnick+U5
Thanks, didn't know about this one.

>>sva_+(OP)
Isn't GP's point inadvertently exposing stuff? Just mention docker networking on HN and you'll get threadfuls of comments on how it helpfully messes with your networking without telling you. Maybe redis does the same?

I mitigate this by having a dedicated machine on the border that only does routing and firewalling, with no random services installed. So anything that helpfully opens ports on internal vms won't automatically be reachable from the outside.