CentOS - Oct 2018 - PostgreSQL port accessible even though it should be blocked by firewall

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