I implemented the use of ipsets for a direct rule in firewalld in 2013. The direct.xml is:
<?xml version="1.0" encoding="utf-8"?> <direct> <!-- IPset Blacklisting --> <chain ipv="ipv4" table="raw" chain="PREROUTING_blacklist"/> <passthrough ipv="ipv4">-t raw -A PREROUTING_blacklist -m limit --limit 3/min -j LOG --log-prefix BLACKLIST_DROP: --log-level 6</passthrough> <passthrough ipv="ipv4">-t raw -A PREROUTING_blacklist -j DROP</passthrough> <passthrough ipv="ipv4">-t raw -A PREROUTING -m set --match-set blacklist src -j PREROUTING_blacklist</passthrough> <chain ipv="ipv6" table="raw" chain="PREROUTING_blacklist"/> <passthrough ipv="ipv6">-t raw -A PREROUTING_blacklist -m limit --limit 3/min -j LOG --log-prefix BLACKLIST_DROP: --log-level 6</passthrough> <passthrough ipv="ipv6">-t raw -A PREROUTING_blacklist -j DROP</passthrough> <passthrough ipv="ipv6">-t raw -A PREROUTING -m set --match-set blacklist src -j PREROUTING_blacklist</passthrough> </direct>
I have several ipsets that are modified outside of firewalld.
blacklist_ipv4_permanent blacklist_ipv4_semipermanent blacklist_ipv4_current blacklist_ipv6_permanent blacklist_ipv6_semipermanent blacklist_ipv6_current
These are members of ipset blacklist:
Name: blacklist Type: list:set Revision: 3 Header: size 8 Size in memory: 368 References: 0 Number of entries: 6 Members: blacklist_ipv4_permanent blacklist_ipv4_semipermanent blacklist_ipv4_current blacklist_ipv6_permanent blacklist_ipv6_semipermanent blacklist_ipv6_current
This was working until I upgraded to Fedora 26 from Fedora 24. Now, even though an IP is in one of the member iplists, blacklist_ipv4_semipermanent or one of the others, firewalld does not block the IP.
I do not know if this is an issue with ipsets or firewalld, nor do I know whether this is a "feature" or a bug.
Since these ipsets are modified dynamically and need to be accessed from bash scripts, using the internal ipset functionality of firewalld is not my desired choice.
Any insight or help in getting the ipsets working again with firewalld would be greatly appreciated.
Thanks.
John
--On Friday, August 18, 2017 12:38 PM -0400 John Griffiths fedora.jrg01@grifent.com wrote:
This was working until I upgraded to Fedora 26 from Fedora 24. Now, even though an IP is in one of the member iplists, blacklist_ipv4_semipermanent or one of the others, firewalld does not block the IP.
I do not know if this is an issue with ipsets or firewalld, nor do I know whether this is a "feature" or a bug.
Since these ipsets are modified dynamically and need to be accessed from bash scripts, using the internal ipset functionality of firewalld is not my desired choice.
Is it acceptable to let firewalld create the ipset, but maintain its contents outside it? Just make sure your management processes are set to start after firewalld starts and creates the ipset.
Instead of a direct rule, create a zone that drops always and specify that zone's source as the ipset.
On 8/19/2017 3:42 AM, Kenneth Porter wrote:
Instead of a direct rule, create a zone that drops always and specify that zone's source as the ipset.
I've discovered a problem with this, and I think it's involved with firewalld's definition of "source".
On my gateway I created an ipset of address blocks that should not be allowed to connect to my gateway and added it as a source to a drop zone. (Outbound connections to those addresses should be allowed.) The firewall is now dropping all packets from internal clients to external clients in this range. Ie. packets in which the destination address, not the source address, is in the ipset!
What does firewalld mean by "source"? Doesn't it mean that the address is only checked in the source field?
I'm using firewalld-0.4.4.4-6.el7.noarch in CentOS 7.
On 8/19/2017 3:42 AM, Kenneth Porter wrote:
Instead of a direct rule, create a zone that drops always and specify that zone's source as the ipset.
I've discovered a problem with this, and I think it's involved with firewalld's definition of "source".
On my gateway I created an ipset of address blocks that should not be allowed to connect to my gateway and added it as a source to a drop zone. (Outbound connections to those addresses should be allowed.) The firewall is now dropping all packets from internal clients to external clients in this range. Ie. packets in which the destination address, not the source address, is in the ipset!
What does firewalld mean by "source"? Doesn't it mean that the address is only checked in the source field?
I'm using firewalld-0.4.4.4-6.el7.noarch in CentOS 7.
On Mon, Dec 18, 2017 at 02:20:25PM -0800, Kenneth Porter wrote:
On 8/19/2017 3:42 AM, Kenneth Porter wrote:
Instead of a direct rule, create a zone that drops always and specify that zone's source as the ipset.
I've discovered a problem with this, and I think it's involved with firewalld's definition of "source".
On my gateway I created an ipset of address blocks that should not be allowed to connect to my gateway and added it as a source to a drop zone. (Outbound connections to those addresses should be allowed.) The firewall is now dropping all packets from internal clients to external clients in this range. Ie. packets in which the destination address, not the source address, is in the ipset!
What does firewalld mean by "source"? Doesn't it mean that the address is only checked in the source field?
It is also checking on the FORWARD chain for both input and output. But for the output it checks the destination and does a goto to the FDO_* chain. It seems unlikely that you would have a drop statement in that chain, but it's worth a look.
# firewall-cmd --add-source=10.10.1.1/24 # iptables -v -n -L |grep 10.10.1 pkts bytes target prot opt in out source destination 0 0 FWDI_public all -- * * 10.10.1.0/24 0.0.0.0/0 [goto] 0 0 FWDO_public all -- * * 0.0.0.0/0 10.10.1.0/24 [goto] 0 0 IN_public all -- * * 10.10.1.0/24 0.0.0.0/0 [goto]
--On Tuesday, December 19, 2017 11:44 AM -0500 Eric Garver egarver@redhat.com wrote:
It is also checking on the FORWARD chain for both input and output. But for the output it checks the destination and does a goto to the FDO_* chain. It seems unlikely that you would have a drop statement in that chain, but it's worth a look.
Thanks. I'm working my way through the chains to try to understand the nesting and the path the packets take. I've done this before with hand-crafted chains but firewalld generates a LOT of empty chains that make the output a bit "noisy" and hard to follow.
firewalld-users@lists.fedorahosted.org
-
Eric Garver -
John Griffiths -
Kenneth Porter