4 ms·

That is unfortunate there's so many Redis instances out there that not only are exposed to the public internet (330,000) and don't have authentication configure

That is unfortunate there's so many Redis instances out there that not only are exposed to the public internet (330,000) and don't have authentication configured (60,000). I'm guessing those folks probably didn't even realize their Redis was public. There are so many tutorials out there for things like Docker Compose that cause people to bind a service to 0.0.0.0 with a port open to the public internet.

cozzyd 1y ago
That sounds like a bigger problem...
c0balt 1y ago
In hindsight, making the default listening address for port forwards in docker(-compose) 0.0.0.0 instead of 127.0.0.1 was/is such a pain point for me. Every time I work with it for servers as almost always it should not be directly exposed (usually services are behind a host-side NGINX rev proxy). It also likely has yielded far too many (unintentionally) open services, especially considering dockers known firewall woes with bypassing of existing rules.
- sureglymop 1y ago
  I agree that it's a bad default. So is their iptables meddling when nftables exists. However, can't you just use e.g. `-p 127.0.0.1:8000:80` since you're aware of the issue? Pretty sure both the CLI and compose support this. What I do is to only use rootless docker/podman and then forward the ports with nftables rules.
  - mkesper 1y ago
    You can but the __default__ should be the safer option.
  - c0balt 1y ago
    Yes, that is also what I apply to compose manifests. The problem is rather that it is always a deviation from defaults and ime can be easily forgotten/ overlooked. It also was at the beginning a bit surprising (listening on 0.0.0.0 and inserting an iptables rule that bypassed my ufw ruleset). Many services listen on on 0.0.0.0 by default but they rarely do it while bypassing the normal host firewall mechanisms.
- vindex10 1y ago
  It's not only docker. ssh forward port forwarding also by default binds to 0.0.0.0, if `<local>` is missing. ``` ssh -L [<local>:]8000:remote:8000 hopping ```
  - cozzyd 1y ago
    ssh doesn't mess with your firewall though
miohtama 1y ago
To make these numbers meaningful, we would need to compare them to a similar software installations in Internet, like SQL databases.

cozzyd 1y ago

That sounds like a bigger problem...

c0balt 1y ago

In hindsight, making the default listening address for port forwards in docker(-compose) 0.0.0.0 instead of 127.0.0.1 was/is such a pain point for me. Every time I work with it for servers as almost always it should not be directly exposed (usually services are behind a host-side NGINX rev proxy). It also likely has yielded far too many (unintentionally) open services, especially considering dockers known firewall woes with bypassing of existing rules.

sureglymop 1y ago
I agree that it's a bad default. So is their iptables meddling when nftables exists. However, can't you just use e.g. `-p 127.0.0.1:8000:80` since you're aware of the issue? Pretty sure both the CLI and compose support this. What I do is to only use rootless docker/podman and then forward the ports with nftables rules.
- mkesper 1y ago
  You can but the __default__ should be the safer option.
- c0balt 1y ago
  Yes, that is also what I apply to compose manifests. The problem is rather that it is always a deviation from defaults and ime can be easily forgotten/ overlooked. It also was at the beginning a bit surprising (listening on 0.0.0.0 and inserting an iptables rule that bypassed my ufw ruleset). Many services listen on on 0.0.0.0 by default but they rarely do it while bypassing the normal host firewall mechanisms.
vindex10 1y ago
It's not only docker. ssh forward port forwarding also by default binds to 0.0.0.0, if `<local>` is missing. ``` ssh -L [<local>:]8000:remote:8000 hopping ```
- cozzyd 1y ago
  ssh doesn't mess with your firewall though

miohtama 1y ago

To make these numbers meaningful, we would need to compare them to a similar software installations in Internet, like SQL databases.