On Sat, May 9, 2020 at 5:59 PM Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
I haven't done much testing, but this does not seem to be quite
right. After
creating and adding the ipset, iptables -n -L still shows me:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 ctstate
RELATED,ESTABLISHED,DNAT
and
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all – 0.0.0.0/0 0.0.0.0/0 ctstate
RELATED,ESTABLISHED,DNAT
It should be "iptables -n -t raw -L". By default the *filter* table is
displayed which is where the connection states are taken into account,
which we wanted to avoid.
So, if the packet is already for an established connection, looks
like it
will be accepted or forwarded right off the bat.
I mistakenly assumed that firewalld handles the dropping in the *raw*
or *mangle* table, but while the ipset seem to be matched for in those
tables by firewalld, every packet for the zone *drop* seems to be
dropped in the *filter* chain where the connection state matching
takes place (for RELATED,ESTABLISHED,DNAT). We want to drop packets
/before/ that.
To fix this, a direct rule inside the *raw* table for matching the
ipset should suffice.
I did some testing this time and came up with the following:
firewall-cmd --permanent --new-ipset=test --type=hash:ip --option=family=inet
firewall-cmd --permanent --direct --add-rule ipv4 raw PREROUTING 0 -m
set --match-set test src -j DROP
firewall-cmd --reload
Then either directly via:
ipset add test 1.2.3.4
or via firewall-cmd which survives a reboot:
firewall-cmd --permanent --ipset=test --add-entry=1.2.3.4
firewall-cmd --reload
Both variants immediately dropped my active ssh session when tested
with my own IP.