A couple weeks ago I stumbled on to the fact that Docker pretty much ignores your firewall and manipulates iptables in the background. The way it sets itself up means the firewall has no idea the changes are made and won’t show up when you look at all the firewall policies. You can check iptables itself to see what docker is doing but iptables isn’t easy or simple to work with.

I noticed your list included firewalld but I have some concerns about that. The first is that the firewall backend has changed from iptables to nftables as the default. That means the guide you linked is missing a step to change backends. Also, when changing back ends by editing /etc/firewalld/firewalld.conf there will be a message saying iptables is deprecated and will be removed in the future:

# FirewallBackend
# Selects the firewall backend implementation.
# Choices are:
#	- nftables (default)
#	- iptables (iptables, ip6tables, ebtables and ipset)
# Note: The iptables backend is deprecated. It will be removed in a future
# release.
FirewallBackend=nftables

If following that guide works for other people, it may be okay for now. Although I think finding alternative firewalls for the future may be a thing to strongly consider.

I did stumble across some ways to help deal with opened docker ports. I currently have 3 docker services that all sit behind a docker reverse proxy. In this case I’m using Caddy as a reverse proxy. First thing to do is create a docker network, for example I created one called “reverse_proxy” with the command:

docker network create reverse_proxy

After that I add the following lines to each docker-compose.yml file for all three services plus Caddy.

services:
    networks:
      - reverse_proxy

networks:
  reverse_proxy:
    external: true

This will allow the three services plus Caddy to communicate together. Running the following command brings up all your currently running. The Name of the container will be used in the Caddyfile to set up the reverse proxy.

docker container ls --format "table {{.ID}}\t{{.Names}}\t{{.Ports}}" -a

Then you can add the following to the Caddyfile. Replace any capitalized parts with your own domain name and docker container name. Change #### to the Internal port number for your docker container. If your ports in your docker-compose.yml look like “5000:8000” 5000: is the external port, :8000 is the internal port.

SUBDOMAIN.DOMAINNAME.COM:80 {
        reverse_proxy DOCKER_CONTAINER_NAME:####
}

After starting the Caddy docker container, things should be working as normal, however the three services behind the reverse proxy are still accessible outside the reverse proxy by accessing their ports directly, for example Subdomain.domainname.com:5000 in your browser.

You can add 127.0.0.1: to the service’s external port in docker-compose.yml to force those service containers ports to only be accessible through the localhost machine.

Before:

    ports:
      - 5000:8000

After:

    ports:
      - 127.0.0.1:5000:8000

After restarting the service, the only port that should be accessible from all your services should only be Caddy’s port. You can check what ports are open with the command

netstat -tunpl

Below I’ll leave a working example for Caddy and Kiwix (offline wikipedia)

Caddy: docker-compose.yml

services:
  caddy:
    container_name: caddy
    image: caddy:latest
    restart: unless-stopped
    ports:
      - 80:80
      - 443:443
    networks:
      - reverse_proxy
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

networks:
  reverse_proxy:
    external: true

Caddy: Caddyfile

wiki.Domainname.com:80 {
        reverse_proxy kiwix:8080
}

Kiwix: docker-compose.yml (if you plan to use this setup, you MUST download a .zim file and place it in the /data/ folder. In this case /srv/kiwix/data) Kiwix Library .zim Files

services:
  kiwix:
    image: ghcr.io/kiwix/kiwix-serve
    container_name: kiwix
    ports:
      - 127.0.0.1:8080:8080
    volumes:
      - /srv/kiwix/data:/data
    command: "*.zim"
    restart: unless-stopped
    networks:
      - reverse_proxy

networks:
  reverse_proxy:
    external: true

What I’m interested in from a firewall is something that offers some sort of rate limiting feature. I would like to set it up as a simple last line of defense against DDOS situations. Even with my current setup with Docker and Caddy, I still have no control over the Caddy exposed port so anything done by the firewall will still be completely ignored still.

I may try out podman and see if I can get UFW or Awall to work as I would like it to. Hopefully that’s not to deep or a rabbit hole.