105
Docker security (lemmy.zip)
submitted 8 months ago* (last edited 8 months ago) by jobbies@lemmy.zip to c/selfhosted@lemmy.world
48 comments fedilink hide all child comments

You're probably already aware of this, but if you run Docker on linux and use ufw or firewalld - it will bypass all your firewall rules. It doesn't matter what your defaults are or how strict you are about opening ports; Docker has free reign to send and receive from the host as it pleases.

If you are good at manipulating iptables there is a way around this, but it also affects outgoing traffic and could interfere with the bridge. Unless you're a pointy head with a fetish for iptables this will be a world of pain, so isn't really a solution.

There is a tool called ufw-docker that mitigates this by manipulating iptables for you. I was happy with this as a solution and it used to work well on my rig, but for some unknown reason its no-longer working and Docker is back to doing its own thing.

Am I missing an obvious solution here?

It seems odd for a popular tool like Docker - that is also used by enterprise - not to have a pain-free way around this.

you are viewing a single comment's thread
view the rest of the comments
[-] gerowen@piefed.social 4 points 8 months ago

I just host everything on bare metal and use systemd to lock down/containerize things as necessary, even adding my own custom drop-ins for software that ships its own systemd service file. SystemD is way more powerful than people often realize.

[-] prettybunnys@piefed.social 1 points 8 months ago

When you say you’re using systems to lock down/containerize things as necessary can you explain what you mean?

[-] gerowen@piefed.social 2 points 8 months ago

Systemd has all sorts of options. If a service has certain sandbox settings applied such as private /tmp, private /proc, restricting access to certain folders or devices, restricting available system calls or whatever, then systemd creates a chroot in /proc/PID for that process with all your settings applied and the process runs inside that chroot.

I've found it a little easier than managing a full blown container or VM, at least for the things I host for myself.

If a piece of software provides its own service file that isn't as restricted as you'd like, you can use systemctl edit to add additional options of your choosing to a "drop-in" file that gets loaded and applied at runtime so you don't have to worry about a package update overwriting any changes you make.

And you can even get ideas for settings to apply to a service to increase security with:

systemd-analyze security SERVICENAME

load more comments (1 replies)
load more comments (2 replies)
this post was submitted on 07 Dec 2025
105 points (92.7% liked)

Selfhosted

61734 readers
399 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:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

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

Questions? DM the mods!

founded 3 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
ayyy@sh.itjust.works
curbstickle@anarchist.nexus
curbstickle_lw@lemmy.world