Would like the ability to add something like this: firewall-cmd --permanent --add-port=4713/tcp --add-source 192.168.1.0/23 # PulseAudio Most of my rules I only want to open ports to specific IP ranges. -A INPUT -m state --state NEW -m tcp -p tcp --dport 4713 -s 192.168.1.0/23 -j ACCEPT
*** Bug 901818 has been marked as a duplicate of this bug. ***
*** Bug 909614 has been marked as a duplicate of this bug. ***
I am also looking for similar functionality within FirewallD. All I want to do is "block" a specific IP or IP range within FirewallD. Something like: firewall-cmd --permanent --zone=(block|drop) --add-sourceip=11.22.33.44.55(/mask) Forcing the firewall to block or drop packets from sourceip.
With the new firewalld version in rawhide/F-19 support for rules with a source address has been added, also support to bind a source address or an interface permanently to a zone. There is only support for this in the configuration files and no command line tool and D-Bus interface up to now. This will be added shortly. For rules with a source address please have a look at: https://fedoraproject.org/wiki/Features/FirewalldRichLanguage For binding a source address or an interface permanently to a zone add the following to the zone configuration file in /etc/firewalld/zones: <zone> <interface name="foobar"/> <source family="ipv4" address="192.168.0.1"/> <source family="ipv6" address="1:2:3:4::"/> ... </zone>
(In reply to Thomas Woerner from comment #4) > For binding a source address or an interface permanently to a zone add the > following to the zone configuration file in /etc/firewalld/zones: > > <zone> > <interface name="foobar"/> > <source family="ipv4" address="192.168.0.1"/> > <source family="ipv6" address="1:2:3:4::"/> > ... > </zone> I'm encountering issues with the above suggestion, and have read [1]. I have the following configuration: # interface p2p1 in the following "special_dmz.xml" zone: <?xml version="1.0" encoding="utf-8"?> <zone> <short>Special DMZ</short> <description>For interfaces that are publicly-accessible via IPv6 with limited access to your internal network. Only selected incoming connections are accepted.</description> <service name="mdns"/> <service name="dhcpv6-client"/> </zone> # additional "special_internal.xml" configured for "internal" IP addrs: <?xml version="1.0" encoding="utf-8"?> <zone> <short>Special Internal</short> <description>For use on internal networks. Only incoming connections from specified IP source address ranges to specified services are accepted.</description> <source family="ipv4" address="10.1.1.0/24"/> <source family="ipv4" address="10.2.2.0/24"/> <source family="ipv6" address="1:2:3:4::/64"/> <service name="ssh"/> </zone> Unfortunately, while I expect to see the special_dmz zone "fall through" to the "special_internal" zone for the specified addrs, it does not and all processing seems to stop. I'm *NOT* an IPTables expert, but based on what I can tell of the difference between -g (GOTO) and -j (JUMP), it appears that with the following ruleset (created by firewalld from the above zones), traffic seems to stop processing at the -j (JUMP) to IN_ZONE_special_dmz_allow since it doesn't return to IN_ZONE_special_dmz and match the source. (I could be way wrong, but either way, the source binding doesn't seem to do what I think it does). # Just the IPv4 portion below (IPv6 shows the same behavior) -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES -A INPUT -p icmp -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A INPUT_ZONES -i p2p1 -g IN_ZONE_special_dmz -A INPUT_ZONES -s 10.1.1.0/24 -j IN_ZONE_special_internal -A INPUT_ZONES -s 10.2.2.0/24 -j IN_ZONE_special_internal -A IN_ZONE_special_dmz -j IN_ZONE_special_dmz_log -A IN_ZONE_special_dmz -j IN_ZONE_special_dmz_deny -A IN_ZONE_special_dmz -j IN_ZONE_special_dmz_allow -A IN_ZONE_special_dmz_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW -j ACCEPT -A IN_ZONE_special_internal -j IN_ZONE_special_internal_log -A IN_ZONE_special_internal -j IN_ZONE_special_internal_deny -A IN_ZONE_special_internal -j IN_ZONE_special_internal_allow -A IN_ZONE_special_internal_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT [1] https://lists.fedorahosted.org/pipermail/firewalld-users/2013-June/000066.html
After some testing (manually editing the freshly created firewalld rules), it appears that modifying the following from Comment #5 seems to allow processing to continue as expected: In the INPUT_ZONES chain, the first rule containing the input interface -A INPUT_ZONES -i p2p1 -g IN_ZONE_special_dmz needs to be changed from -g (GOTO) to -j (JUMP) to allow the return to INPUT_ZONES, rather than all the way back to INPUT, as follows -A INPUT_ZONES -i p2p1 -j IN_ZONE_special_dmz I am not certain if this will create problems for other things, but it corrected the problem described in Comment #5.
(In reply to Anthony Messina from comment #6) > I am not certain if this will create problems for other things, but it > corrected the problem described in Comment #5. The "-g" seems to be added as a part of Bug 912782.
(In reply to Anthony Messina from comment #5) > Unfortunately, while I expect to see the special_dmz zone "fall through" to > the "special_internal" zone for the specified addrs, it does not and all > processing seems to stop. I think you're building on a false assumption. The zones are not supposed to interfere/follow each other.
(In reply to Jiri Popelka from comment #8) > I think you're building on a false assumption. > The zones are not supposed to interfere/follow each other. Thanks, Jiri, but I think the issue is that packets that match the interface will never get to the rules that match the source as the interface target is called with GOTO: -A INPUT -j INPUT_ZONES -A INPUT -p icmp -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A INPUT_ZONES -i p2p1 -g IN_ZONE_special_dmz -A INPUT_ZONES -s 10.1.1.0/24 -j IN_ZONE_special_internal From the ipatables man page for -g, --goto chain "Unlike the --jump option return will not continue processing in this chain but instead in the chain that called us via --jump." So packets that come in on p2p1, if not matched in "IN_ZONE_special_dmz" will return to "INPUT_ZONES", since it was the last match that called the JUMP. With this logic, I can't see how the binding of source addresses actually does anything, since the packets won't hit the rule--they match the rule/zone which is bound to the interface. If not matched in "-A INPUT_ZONES -i p2p1 -g IN_ZONE_special_dmz", the next rule they match is "-A INPUT -j REJECT --reject-with icmp-host-prohibited".
With https://git.fedorahosted.org/cgit/firewalld.git/commit/?h=sources&id=b582b315ce185639c991820f958d30f30c3e6e90 we create following chains/rules -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -j REJECT --reject-with icmp-host-prohibited -A INPUT_ZONES_SOURCE -s 1.2.3.0/24 -g IN_ZONE_home -A INPUT_ZONES_SOURCE -s 6.6.6.0/23 -g IN_ZONE_work -A INPUT_ZONES -i em1 -g IN_ZONE_home -A INPUT_ZONES -g IN_ZONE_public Scratch-build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5652546 > [18:46] <twoerner> there is currently a bug in firewalld that the source binds do not have a higher priority than interface binds As i understand it this 'bug' should be fixed with the above commit/chains/rules.
(In reply to Jiri Popelka from comment #10) > With > https://git.fedorahosted.org/cgit/firewalld.git/commit/ > ?h=sources&id=b582b315ce185639c991820f958d30f30c3e6e90 > > we create following chains/rules > > -A INPUT -j INPUT_ZONES_SOURCE > -A INPUT -j INPUT_ZONES > -A INPUT -j REJECT --reject-with icmp-host-prohibited > > -A INPUT_ZONES_SOURCE -s 1.2.3.0/24 -g IN_ZONE_home > -A INPUT_ZONES_SOURCE -s 6.6.6.0/23 -g IN_ZONE_work > -A INPUT_ZONES -i em1 -g IN_ZONE_home > -A INPUT_ZONES -g IN_ZONE_public > > Scratch-build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5652546 > > > [18:46] <twoerner> there is currently a bug in firewalld that the source binds do not have a higher priority than interface binds > > As i understand it this 'bug' should be fixed with the above > commit/chains/rules. I can confirm that the above "fixes" this issue completely (and allows for perfect failover from INPUT_ZONES_SOURCE to INPUT_ZONES)! This is exactly what I would expect it to do. Thank you!
OK, merged to master, the commit is now https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=b582b315ce185639c991820f958d30f30c3e6e90
FYI, using firewalld-0.3.3-3.fc19.noarch, I am able to solve the problems listed in the bug report to this point, however, I get the following error when adding services to a "sources" based zone. It appears that the local config is not able to override a default template placed in /usr/lib/firewalld/zones 1. Install "/usr/lib/firewalld/zones/special_internal.xml": <?xml version="1.0" encoding="utf-8"?> <zone> <short>Special Internal</short> <description>For use on internal networks. Only incoming connections from specified IP source address ranges to specified services are accepted.</description> <source family="ipv4" address="10.1.1.0/24"/> <source family="ipv6" address="1:2:3:4::/64"/> <service name="ssh"/> </zone> 2. Now add another service to the special_internal zone: firewall-cmd --zone special_internal --add-service ipp-client, so the resulting updated zone file in "/etc/firewalld/zones/special_internal.xml" looks like: <?xml version="1.0" encoding="utf-8"?> <zone> <short>Special Internal</short> <description>For use on internal networks. Only incoming connections from specified IP source address ranges to specified services are accepted.</description> <source family="ipv4" address="10.1.1.0/24"/> <source family="ipv6" address="1:2:3:4::/64"/> <service name="ssh"/> <service name="ipp-client"/> </zone> 3. Observe the following error at system boot or firewall-cmd --reload firewalld[276]: 2013-07-25 21:30:20 ERROR: Failed to load zone file '/etc/firewalld/zones/special_internal.xml':
These should fix it. https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=43ea096febc6dfa31ec20c4f067b0abfdbc560c4 https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=23e4e351b2588031b0f298537e750b260374d7c1 https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=fde205298e2dfaf39289ee0372ce947a6b599ea5 We'll hopefully make a new release soon so you can continue testing.
Thanks. I'd welcome the new release as it really makes a difference for complex server support in firewalld.
firewalld-0.3.4-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/firewalld-0.3.4-1.fc19
Package firewalld-0.3.4-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing firewalld-0.3.4-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-14046/firewalld-0.3.4-1.fc19 then log in and leave karma (feedback).
firewalld-0.3.4-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.