Hi,
this puzzles me: On one of our developer workstations, all ports with the exception of SSH are closed:
$ firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: services: ssh dhcpv6-client ports: 22/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: $
but still port 5432/tcp (PostgreSQL) is open:
$ nmap -P0 devel-host
Starting Nmap 6.40 ( http://nmap.org ) at 2018-10-29 19:46 CET Nmap scan report for devel-host (xxx.xxx.xxx.xxx) Host is up (0.94s latency). rDNS record for xxx.xxx.xxx.xxx: devel-host.our.domain Not shown: 998 filtered ports PORT STATE SERVICE 22/tcp open ssh 5432/tcp open postgresql
Nmap done: 1 IP address (1 host up) scanned in 57.26 seconds $
PostgreSQL is running in a docker container:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6f11fc41d2f0 postgres "docker-entrypoint..." 4 days ago Up 4 days 0.0.0.0:5432->5432/tcp postgres $
The various docker interfaces and virtual bridges are not assigned to any specific zone.
Why is port 5432/tcp open?
frank
Am 29.10.2018 um 20:03 schrieb Frank Thommen:
PostgreSQL is running in a docker container:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6f11fc41d2f0 postgres "docker-entrypoint..." 4 days ago Up 4 days 0.0.0.0:5432->5432/tcp postgres $
The various docker interfaces and virtual bridges are not assigned to any specific zone.
Why is port 5432/tcp open?
You will see it if you check the netfilter rules with:
iptables -L -n -v --line -t filter iptables -L -n -v --line -t nat
frank
Alexander
On 10/29/2018 08:18 PM, Alexander Dalloz wrote:
Am 29.10.2018 um 20:03 schrieb Frank Thommen:
PostgreSQL is running in a docker container:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6f11fc41d2f0 postgres "docker-entrypoint..." 4 days ago Up 4 days 0.0.0.0:5432->5432/tcp postgres $
The various docker interfaces and virtual bridges are not assigned to any specific zone.
Why is port 5432/tcp open?
You will see it if you check the netfilter rules with:
iptables -L -n -v --line -t filter iptables -L -n -v --line -t nat
In fact these rules forward port 5432 to docker:
$ iptables -L -n -v --line -t filter | grep 5432 1 0 0 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:5432 $ iptables -L -n -v --line -t nat | grep 5432 10 0 0 MASQUERADE tcp -- * * 172.17.0.2 172.17.0.2 tcp dpt:5432 2 0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5432 to:172.17.0.2:5432 $
I am still puzzled that it is possible to circumvent firewalld so easily. Basically it means, that firewalld is not to be trusted as soon as containers with port forwarding are running on a system.
frank
frank
Alexander _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/30/18 8:31 AM, Frank Thommen wrote:
I am still puzzled that it is possible to circumvent firewalld so easily. Basically it means, that firewalld is not to be trusted as soon as containers with port forwarding are running on a system.
It's hard to see this as a security or trust problem. The root user can modify the firewall, which is provided by the kernel. firewalld is just a front-end. Adding rules to the kernel's firewall is not "circumventing" the management front-end.
You do have to bear in mind that the firewall-cmd output reflects the *configuration* and not the *state*. When docker adds rules, it modifies the state, but not the configuration.
On 31/10/18 18:32, Gordon Messmer wrote:
On 10/30/18 8:31 AM, Frank Thommen wrote:
I am still puzzled that it is possible to circumvent firewalld so easily. Basically it means, that firewalld is not to be trusted as soon as containers with port forwarding are running on a system.
It's hard to see this as a security or trust problem. The root user can modify the firewall, which is provided by the kernel. firewalld is just a front-end. Adding rules to the kernel's firewall is not "circumventing" the management front-end.
You do have to bear in mind that the firewall-cmd output reflects the *configuration* and not the *state*. When docker adds rules, it modifies the state, but not the configuration.
I see that (=have learned that :-) now, but for me it means, that firewalld-cmd is not to be trusted (even though it is the recommended tool to manage the local firewall). I'll have to go back and try to understand confusing and hard-to-understand iptables output. :-(
On 2018-10-29, Frank Thommen list.centos@drosera.ch wrote:
PostgreSQL is running in a docker container:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6f11fc41d2f0 postgres "docker-entrypoint..." 4 days ago Up 4 days 0.0.0.0:5432->5432/tcp postgres $
The various docker interfaces and virtual bridges are not assigned to any specific zone.
Why is port 5432/tcp open?
It may be Docker manipulating the iptables rules. If you don't want it open at all, remove the port argument from the docker run command line (or moral equivalent) and recreate the container (make sure you have saved your data first, either with a volume mount or by dumping first).
If you need something more complex, here's some docs on how Docker interacts with iptables, and how you can insert rules into its chains:
https://docs.docker.com/network/iptables/
--keith
On 10/29/2018 08:43 PM, Keith Keller wrote:
On 2018-10-29, Frank Thommen list.centos@drosera.ch wrote:
PostgreSQL is running in a docker container:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6f11fc41d2f0 postgres "docker-entrypoint..." 4 days ago Up 4 days 0.0.0.0:5432->5432/tcp postgres $
The various docker interfaces and virtual bridges are not assigned to any specific zone.
Why is port 5432/tcp open?
It may be Docker manipulating the iptables rules. If you don't want it open at all, remove the port argument from the docker run command line (or moral equivalent) and recreate the container (make sure you have saved your data first, either with a volume mount or by dumping first).
Unfortunately I can't control how users start their containers and I cannot force them not to forward ports. But I will see if I can prevent Docker from manipulating iptables as described in the very helpful link below.
If you need something more complex, here's some docs on how Docker interacts with iptables, and how you can insert rules into its chains:
https://docs.docker.com/network/iptables/
--keith
frank
Frank Thommen wrote:
On 10/29/2018 08:43 PM, Keith Keller wrote:
On 2018-10-29, Frank Thommen list.centos@drosera.ch wrote:
PostgreSQL is running in a docker container:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6f11fc41d2f0 postgres "docker-entrypoint..." 4 days ago Up 4 days 0.0.0.0:5432->5432/tcp postgres $
The various docker interfaces and virtual bridges are not assigned to any specific zone.
Why is port 5432/tcp open?
It may be Docker manipulating the iptables rules. If you don't want it open at all, remove the port argument from the docker run command line (or moral equivalent) and recreate the container (make sure you have saved your data first, either with a volume mount or by dumping first).
Unfortunately I can't control how users start their containers and I cannot force them not to forward ports. But I will see if I can prevent Docker from manipulating iptables as described in the very helpful link below.
<snip> There is a security level, but it would break some user's docker packages.
The more I learn about docker, the more I actively dislike it as a massive security hole.
mark
-
Alexander Dalloz -
Frank Thommen -
Gordon Messmer -
Keith Keller -
mark