firewall rules.pl - rules of forwardfw are also beeing added to inputfw / outputfw and green/blue are allays accepted on INPUT ????

firewall rules.pl - rules of forwardfw are also beeing added to inputfw / outputfw and green/blue are allays accepted on INPUT ????

[Alexander Koch]

[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]

Hi,

I was wondering why some hosts of my internal nets had access to some ports on my IPFire-Machine that I didn't open for them and I didn't want them to either ...

Taking a closer look at the raw iptables content, I noticed that nearly all of my forwardings-rules were also added to the inputfw-chain. I tracked this behaviour down to the following lines in /usr/lib/firewall/rules.pl


503                                         # Handle forwarding rules and add corresponding rules for firewall access.
504                                         if ($chain eq $CHAIN_FORWARD) {
505                                                 # If the firewall is part of the destination subnet and access to the destination network
506                                                 # is granted/forbidden for any network that the firewall itself is part of, we grant/forbid access
507                                                 # for the firewall, too.
508                                                 if ($firewall_is_in_destination_subnet && ($target ~~ @special_input_targets)) {
509                                                         if ($LOG && !$NAT) {
510                                                                 run("$IPTABLES -A $CHAIN_INPUT @options @source_intf_options @log_limit_options -j LOG --log-prefix '$CHAIN_INPUT '");
511                                                         }
512                                                         run("$IPTABLES -A $CHAIN_INPUT @options @source_intf_options -j $target");
513                                                 }
514
515                                                 # Likewise.
516                                                 if ($firewall_is_in_source_subnet && ($target ~~ @special_output_targets)) {
517                                                         if ($LOG && !$NAT) {
518                                                                 run("$IPTABLES -A $CHAIN_OUTPUT @options @destination_intf_options @log_limit_options -j LOG --log-prefix '$CHAIN_OUTPUT '");
519                                                         }
520                                                         run("$IPTABLES -A $CHAIN_OUTPUT @options @destination_intf_options -j $target");
521                                                 }
522                                         }


What is the goal of doing this? I was not aware of this and it's certainly nothing I expected to happen. I didn't read anything about it in the wiki either. I usually set up different rules for input and forwarding.

After figuring this out, I found some policies completely opening input for green and blue in /usr/sbin/firewall-policy

  72 # Allow access from GREEN
  73 if [ -n "${GREEN_DEV}" ]; then
  74         iptables -A POLICYIN -i "${GREEN_DEV}" -j ACCEPT
  75 fi
  76
  77 # Allow access from BLUE
  78 if [ "${HAVE_BLUE}" = "true" ] && [ -n "${BLUE_DEV}" ]; then
  79         iptables -A POLICYIN -i "${BLUE_DEV}" -j ACCEPT
  80 fi

I want to be able to configure this the way I want to too. blue is my guest network. It should not have access to anything but dhcp, dns, ntp etc. on my firewall!

Is this an issue of me misunderstanding the way the firewall is supposed to work or something that should be patched asap? I would like to understand the reason for this being done this way ... thank you!

Regards, Alex

Re: firewall rules.pl - rules of forwardfw are also beeing added to inputfw / outputfw and green/blue are allays accepted on INPUT ????

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4637 bytes --]

Hi,

I do not consider this a bug. It is expected and designed behaviour.

> On 8 Sep 2019, at 01:09, Alexander Koch <ipfire(a)starkstromkonsument.de> wrote:
> 
> Hi,
> 
> I was wondering why some hosts of my internal nets had access to some ports on my IPFire-Machine that I didn't open for them and I didn't want them to either ...
> 
> Taking a closer look at the raw iptables content, I noticed that nearly all of my forwardings-rules were also added to the inputfw-chain. I tracked this behaviour down to the following lines in /usr/lib/firewall/rules.pl
> 
> 
> 503                                         # Handle forwarding rules and add corresponding rules for firewall access.
> 504                                         if ($chain eq $CHAIN_FORWARD) {
> 505                                                 # If the firewall is part of the destination subnet and access to the destination network
> 506                                                 # is granted/forbidden for any network that the firewall itself is part of, we grant/forbid access
> 507                                                 # for the firewall, too.
> 508                                                 if ($firewall_is_in_destination_subnet && ($target ~~ @special_input_targets)) {
> 509                                                         if ($LOG && !$NAT) {
> 510                                                                 run("$IPTABLES -A $CHAIN_INPUT @options @source_intf_options @log_limit_options -j LOG --log-prefix '$CHAIN_INPUT '");
> 511                                                         }
> 512                                                         run("$IPTABLES -A $CHAIN_INPUT @options @source_intf_options -j $target");
> 513                                                 }
> 514
> 515                                                 # Likewise.
> 516                                                 if ($firewall_is_in_source_subnet && ($target ~~ @special_output_targets)) {
> 517                                                         if ($LOG && !$NAT) {
> 518                                                                 run("$IPTABLES -A $CHAIN_OUTPUT @options @destination_intf_options @log_limit_options -j LOG --log-prefix '$CHAIN_OUTPUT '");
> 519                                                         }
> 520                                                         run("$IPTABLES -A $CHAIN_OUTPUT @options @destination_intf_options -j $target");
> 521                                                 }
> 522                                         }

These lines create a FORWARD rule in the INPUT/OUTPUT chains as well when the firewall is in a selected subnet.

Meaning that the “GREEN” network is supposed to reach some resource on a VPN network that is enabled for the firewall as well because it is on the GREEN network, too. Packets are however not processed in the FORWARD in the case, hence the special rules.

> What is the goal of doing this? I was not aware of this and it's certainly nothing I expected to happen. I didn't read anything about it in the wiki either. I usually set up different rules for input and forwarding.
> 
> After figuring this out, I found some policies completely opening input for green and blue in /usr/sbin/firewall-policy
> 
> 72 # Allow access from GREEN
> 73 if [ -n "${GREEN_DEV}" ]; then
> 74         iptables -A POLICYIN -i "${GREEN_DEV}" -j ACCEPT
> 75 fi
> 76
> 77 # Allow access from BLUE
> 78 if [ "${HAVE_BLUE}" = "true" ] && [ -n "${BLUE_DEV}" ]; then
> 79         iptables -A POLICYIN -i "${BLUE_DEV}" -j ACCEPT
> 80 fi

This is the default in the “open” policy. The network should be able to reach all services that are hosted by the firewall (e.g. update accelerator, etc.).

> I want to be able to configure this the way I want to too. blue is my guest network. It should not have access to anything but dhcp, dns, ntp etc. on my firewall!

You can define your custom rules which will always be processed first.

There is only few things that you cannot overwrite:

* The WebUI is *always* reachable from GREEN.
* IPsec & OpenVPN automatically open their ports

> Is this an issue of me misunderstanding the way the firewall is supposed to work or something that should be patched asap? I would like to understand the reason for this being done this way ... thank you!

I don’t know. You let me know if this makes sense or what else you expected the firewall to do. I have no idea what you expected it to do here.

Best,
-Michael

> 
> Regards, Alex