From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: firewall rules.pl - rules of forwardfw are also beeing added to inputfw / outputfw and green/blue are allays accepted on INPUT ???? Date: Mon, 09 Sep 2019 15:56:33 +0100 Message-ID: In-Reply-To: <93f6410e-ef84-5e16-05df-7e9ad09c2719@starkstromkonsument.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5200546033127517430==" List-Id: --===============5200546033127517430== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I do not consider this a bug. It is expected and designed behaviour. > On 8 Sep 2019, at 01:09, Alexander Koch w= rote: >=20 > Hi, >=20 > 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 e= ither ... >=20 > 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 >=20 >=20 > 503 # Handle forwarding rules and a= dd corresponding rules for firewall access. > 504 if ($chain eq $CHAIN_FORWARD) { > 505 # If the firewall is pa= rt 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_des= tination_subnet && ($target ~~ @special_input_targets)) { > 509 if ($LOG && !$N= AT) { > 510 run("$I= PTABLES -A $CHAIN_INPUT @options @source_intf_options @log_limit_options -j L= OG --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_sou= rce_subnet && ($target ~~ @special_output_targets)) { > 517 if ($LOG && !$N= AT) { > 518 run("$I= PTABLES -A $CHAIN_OUTPUT @options @destination_intf_options @log_limit_option= s -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 =E2=80=9CGREEN=E2=80=9D network is supposed to reach some re= source on a VPN network that is enabled for the firewall as well because it i= s 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 eit= her. I usually set up different rules for input and forwarding. >=20 > After figuring this out, I found some policies completely opening input for= green and blue in /usr/sbin/firewall-policy >=20 > 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 This is the default in the =E2=80=9Copen=E2=80=9D policy. The network should = be able to reach all services that are hosted by the firewall (e.g. update ac= celerator, 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 th= e reason for this being done this way ... thank you! I don=E2=80=99t know. You let me know if this makes sense or what else you ex= pected the firewall to do. I have no idea what you expected it to do here. Best, -Michael >=20 > Regards, Alex --===============5200546033127517430==--