From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexander Koch <ipfire@starkstromkonsument.de>
To: development@lists.ipfire.org
Subject: firewall rules.pl - rules of forwardfw are also beeing added to
 inputfw / outputfw and green/blue are allays accepted on INPUT ????
Date: Sun, 08 Sep 2019 02:09:43 +0200
Message-ID: <93f6410e-ef84-5e16-05df-7e9ad09c2719@starkstromkonsument.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4953587875794697998=="
List-Id: <development.lists.ipfire.org>

--===============4953587875794697998==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

I was wondering why some hosts of my internal nets had access to some ports o=
n my IPFire-Machine that I didn't open for them and I didn't want them to eit=
her ...

Taking a closer look at the raw iptables content, I noticed that nearly all o=
f my forwardings-rules were also added to the inputfw-chain. I tracked this b=
ehaviour 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 fo=
r any network that the firewall itself is part of, we grant/forbid access
507                                                 # for the firewall, too.
508                                                 if ($firewall_is_in_desti=
nation_subnet && ($target ~~ @special_input_targets)) {
509                                                         if ($LOG && !$NAT=
) {
510                                                                 run("$IPT=
ABLES -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_sourc=
e_subnet && ($target ~~ @special_output_targets)) {
517                                                         if ($LOG && !$NAT=
) {
518                                                                 run("$IPT=
ABLES -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 no=
thing I expected to happen. I didn't read anything about it in the wiki eithe=
r. I usually set up different rules for input and forwarding.

After figuring this out, I found some policies completely opening input for g=
reen 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}" =3D "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 n=
etwork. It should not have access to anything but dhcp, dns, ntp etc. on my f=
irewall!

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

Regards, Alex

--===============4953587875794697998==--