PostgreSQL Port Accessible Even Though It Should Be Blocked By Firewall

Home » CentOS » PostgreSQL Port Accessible Even Though It Should Be Blocked By Firewall
CentOS 7 Comments

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

7 thoughts on - PostgreSQL Port Accessible Even Though It Should Be Blocked By Firewall

  • Am 29.10.2018 um 20:03 schrieb Frank Thommen:

    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

    Alexander

  • 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

  • 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

  • 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.

    frank

  • Frank Thommen wrote:

    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

  • 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. :-(