Firewalld Zones Internal Rules Allowing Traffic Through

Linux Gods,

Here is my basic firewalld zones and rules:

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: dhcpv6-client https ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: weave
  sources: 192.168.9.146/32 192.168.8.140/32
  services: dhcpv6-client mdns ssh
  ports: 1-65535/tcp 1-65535/udp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

My intention is to only allow (dhcpv6-client https ssh) through to the backend internal zone blocking everything else keeping internal communications to continue on the backend. In two test labs, it works and traffic in being blocked which I can see when I run nmap against it. But when the sec guys run their Nessus scans from their scanner/nodes, its seeing TCP:10250 (Kubernetes) port as being exposed. I cannot understand why traffic is being allowed through my "public" zone to my "internal" zone (TCP:10250) outside of what I have already specified. Any clarification would be greatly appreciated

Hey

Whatever I say, dont freak out, I have no clue - just trying to learn here something myself.

I'm curious by the internal (active) ports output...
To my understanding it has all ports (udp/tcp) open that are in range of 1 to 65535...

Or does that mean, those ports are closed, but not those for the services of mdns ssh and dhcpv6.client?

Do you have any Kubernetes installed on that device?
If so, I would assume those ports are open, and the only reasons why the other ports did not 'pop up', was because there was no 'listener' to report/answer on/to the port-knocking.
Then again, seems you have ssh, so that should have reported (pop up) as well... ?

No idea, just some thoughts.

Hello Sea,

So my understanding is the internal zone allows TCP/UDP 1-65535 ports to any host within the internal zone with the public zone blocking everything else except whats allowed through (dhcpv6-client https ssh) which has the default ports of TCP:22, 443 etc.

Ok, and the internal zone is defined by the "weave" interface?

Would it not then need the ports required to be in the eth0 defintiion?

EDIT:
So it would block those ports to access the internal part of the 'device'?
As I assume the unwanted connectinos come from eth0 - the outside, not weave, your internal zone.

Please show output of

ip addr show
ip link show
ss -an | grep 10250 | grep LISTEN

Weave as kubernetes CNI, or you just named the interface weave to run kubernetes over it ?
Do you understand encapsulation concept regarding networking in kubernetes such as VXLAN, GRE ?

Also, you might as well have the entire internal zone in target : ACCEPT since you allowed all ports.

Can you put more context regarding your environment ?

Regards
Peasant.

ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.188.8.147/22 brd 192.168.11.255 scope global noprefixroute dynamic eth0
       valid_lft 163119sec preferred_lft 163119sec
    inet6 XXXXXXXX/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 00:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
4: datapath: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 00:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet6 XXXXXXXXXXXXXX/64 scope link
       valid_lft forever preferred_lft forever
6: weave: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UP group default qlen 1000
    link/ether XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet 10.32.0.1/12 brd 10.47.255.255 scope global weave
       valid_lft forever preferred_lft forever
    inet6 XX:XX:XX:XX:XX:XX/64 scope link
       valid_lft forever preferred_lft forever
7: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
9: vethwe-datapath@vethwe-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master datapath state UP group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet6 feXX:XX:XX:XX:XX:XX/64 scope link
       valid_lft forever preferred_lft forever
10: vethwe-bridge@vethwe-datapath: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master weave state UP group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet6 XX:XX:XX:XX:XX:XX/64 scope link
       valid_lft forever preferred_lft forever
146: vxlan-6784: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc noqueue master datapath state UNKNOWN group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet6 feXX:XX:XX:XX:XX:XX/64 scope link
       valid_lft forever preferred_lft forever
148: vethwepl8862a50@if147: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master weave state UP group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 feXX:XX:XX:XX:XX:XX/64 scope link
       valid_lft forever preferred_lft forever
150: vethwepl454bcc9@if149: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master weave state UP group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 feXX:XX:XX:XX:XX:XX/64 scope link
       valid_lft forever preferred_lft forever
152: vethweplf80d15b@if151: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master weave state UP group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 feXX:XX:XX:XX:XX:XX/64 scope link
       valid_lft forever preferred_lft forever

ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: datapath: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: weave: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
7: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
9: vethwe-datapath@vethwe-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master datapath state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
10: vethwe-bridge@vethwe-datapath: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master weave state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
146: vxlan-6784: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc noqueue master datapath state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
148: vethwepl8862a50@if147: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master weave state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff link-netnsid 0
150: vethwepl454bcc9@if149: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master weave state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff link-netnsid 1
152: vethweplf80d15b@if151: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue master weave state UP mode DEFAULT group default
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff link-netnsid 2

ss -an | grep 10250 | grep LISTEN

tcp    LISTEN     0      128    [::]:10250              [::]:*

So what is happening is that our sec guy are flagging untrusted certs, weak ciphers that are being seen from their Nessus scanner. They is also a requirement to have a host based firewall on all of our Linux endpoints. IPtables is installed by default along with firewalld so what I decided to do is take advantage of this requirement and simply block all public access to those ports and only allowing backend systems to talk within the internal zone/network. In a nutshell, our product uses Kubernetes 1.8 (old) Master/Worker multi-nodes to manage pods of containers. The ports that the scanner is seeing are the Kubernetes (Kublet and Kubes API respectively TCP:6443 and 10250) I cant understand what I am doing wrong. Any help would be greatly appreciated