Description of problem: Firewalld allows all traffic to be forwarded from untrusted interfaces to trusted ones, basically bypassing any router firewall behavior. Version-Release number of selected component (if applicable): firewalld-0.3.9.3-1.fc20 How reproducible: Always when any interface is setup with as a trusted zone Steps to Reproduce: 1. Setup a host with two interfaces, assign external zone to WAN, trusted to the LAN 2. Attempt to connect to a host connected to the LAN from a host connected to the WAN Actual results: Connection is allowed Expected results: Connection should be rejected, source host is untrusted. Additional info: Looking at the ip6tables-save (same on iptables), the problem appears to be that the FORWARD processing is split into "input-forward" and "output-forward", and the "input-forward" chain isn't dropping unknown packets. The INPUT chain correctly drops any unknown services as the last rule, but because the forwarded connection is routed out of the "trusted" interface, the rule in FWDO_trusted allows all forwarded traffic before it reaching the similar REJECT in the FORWARD chain. The packet should probably be dropped somewhere at the end of the FWDI_external chain. The only workaround I've found is adding some direct rules that drop forwarded packets for each interface I have in zone external... but that doesn't work when external is the default assigned to dynamic (ie USB/card) interfaces. ... and is definitely not secure by default. This is especially risky in ipv6 setups, as LAN hosts are typically assigned global addresses, but also applies to any setup where the host is routing between networks without NAT.
At the moment whether the packet will/won't be forwarded depends on zones of both input and output interface. The path/algorithm is following: (1) check zone of input interface: block, drop -> reject/drop trusted -> accept (i.e. forward) other zones -> depends on output interface, i.e. goto (2) (2) check zone of output interface trusted, external (i.e. zone with masquerade) -> accept (i.e. forward) block, drop -> reject/drop other zones -> reject/drop So in your case of input zone being external and output zone being trusted the result is really accept (i.e. forward). I'm not sure how this is supposed to be actually working so it's question for Thomas. Thomas do you see any problem with the above ?
Of course, this means that the most common router/gateway setup in existence cannot be supported - where the router/gateway is also the firewall for the routed network. external (untrusted) hosts <WAN> <router> <LAN> internal (trusted) hosts Clearly I can't use block,drop on WAN, as then the router cannot support any services at all (since block,drop doesn't allow any to be added). So in the "goto" scenario in (1) above. I want all ports/services available to my LAN (trusted) hosts for incoming connections, but (2) above means trusted networks are also assumed secure and get all packets unconditionally forwarded to them -- this assumes all hosts in my trusted network are running firewalls (which my tivo/thermostat/pool controller and soon refrigerator etc certainly aren't). My router runs a myriad of services, many with dynamic port assignments, so using a stricter zone that disallows forwarding by default would be a pain to bypass. The problem is the idea behind an "external" or untrusted zone designation is to block by default, and whitelist services... there doesn't appear to be any way to apply this concept to forwarding too, putting the entire internal network at risk! (this machine is the firewall in this case). Ideally, I think external should reject by default, but allow forwards using a standard mechanism. For example, I'm ok (in fact desire) SSH connections to be forwarded to my trusted network (any host that supports it at least has some security built in). This could be solved with any of: (a) per-zone direct rules - these are desperately needed already, my direct rules must have interface names in them, so can't be applied to dynamic interfaces (the main purpose of zones). I can then add policy and port allow rules in the FORWARD chain for a zone. (b) new zone config option for service forwards, for example "<service-forward name=xx>" with block by default in FORWARD inbound. (c) some way to target rules to FWDI_external_{allow,deny}, where I could add filtering and policy. I can't find any way to do this now... Am I missing something? I would think <WAN>+<LAN> combinations would be a very common scenario, and I'm surprised it's not something that's "secure" by default...
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
What is the status of this bug? I have similar setup here on CentOS 7 (firewalld-0.3.9-14.el7.noarch) and suspect that people from outside can access my internal-only webserver.
(In reply to Jiri Popelka from comment #1) > At the moment whether the packet will/won't be forwarded depends on zones of > both input and output interface. > > The path/algorithm is following: > > (1) check zone of input interface: > block, drop -> reject/drop > trusted -> accept (i.e. forward) > other zones -> depends on output interface, i.e. goto (2) > > (2) check zone of output interface > trusted, external (i.e. zone with masquerade) -> accept (i.e. forward) > block, drop -> reject/drop > other zones -> reject/drop > > So in your case of input zone being external and output zone being trusted > the result is really accept (i.e. forward). > > I'm not sure how this is supposed to be actually working so it's question > for Thomas. > Thomas do you see any problem with the above ? Please, Jiri and Thomas, what is the status of this bug? I am sure there are lots of setups out there using exactly the same configuration reported by Scott. Does LAN interface set as "internal" instead of "trusted" serve as workaround?
I will have a look at this.
Reopening to track the upstream issue https://github.com/firewalld/firewalld/issues/177
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Well... I've added an post covering my workaround in the upstream bug... guess we can boil this down to a "poor documentation" bug, although I still think adding FWDO_trusted ACCEPT rules is broken! Basically, I'm modifying my "untrusted" (external) zone to have a target=%%REJECT%% so that forwarded packets are blocked in FWDI_external (before the broken FWDO_trusted can whitelist them!). I'd suggest that external and public zones should all have target=%%REJECT%% by default to prevent this kind of issue... but I'll leave that discussion to the upstream thread. Closing