You are not logged in.
All,
I tried the arch-general list but got no response. Here is the situation with ipset. I've setup a blocklist (hash:net) a whitelist (hash:ip) and a whitelistnet (hash:net) with ipset. It works quite well added to the stateful firewall. However ipset restore fails:
18:02 valkyrie:~> systemctl status ipset
× ipset.service - Loading IP Sets
Loaded: loaded (/usr/lib/systemd/system/ipset.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Wed 2024-04-10 17:06:05 CDT; 56min ago
Process: 1399 ExecStart=/usr/bin/ipset -f /etc/ipset.conf restore (code=exited, status=2)
Main PID: 1399 (code=exited, status=2)
CPU: 3ms
Apr 10 17:06:05 valkyrie systemd[1]: Starting Loading IP Sets...
Apr 10 17:06:05 valkyrie ipset[1399]: ipset v7.20: No command specified: unknown argument Name:
Apr 10 17:06:05 valkyrie ipset[1399]: Try `ipset help' for more information.
Apr 10 17:06:05 valkyrie systemd[1]: ipset.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Apr 10 17:06:05 valkyrie systemd[1]: ipset.service: Failed with result 'exit-code'.
Apr 10 17:06:05 valkyrie systemd[1]: Failed to start Loading IP Sets.
The sets cannot manually be restored with ipset restore (or ipset restore -file /etc/ipset.conf). It results in the same error:
# ipset restore </etc/ipset.conf
ipset v7.20: No command specified: unknown argument Name:
Try `ipset help' for more information.
As does:
# ipset restore -f /etc/ipset.conf
ipset v7.20: No command specified: unknown argument Name:
Try `ipset help' for more information.
The content of the ipset save > /etc/ipset.conf file is the same as ipset list, and looks fine, e.g.
# cat /etc/ipset.conf
Name: blocklist
Type: hash:net
Revision: 7
Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xf3661058
Size in memory: 8856
References: 0
Number of entries: 194
Members:
167.94.138.0/24
199.45.154.0/23
43.130.0.0/18
43.129.192.0/18
43.157.32.0/24
<snip>
Name: whitelist
Type: hash:ip
Revision: 6
Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xfa0e1f24
Size in memory: 1816
References: 0
Number of entries: 42
Members:
212.187.231.66
93.93.130.214
151.101.129.91
91.193.113.65
87.238.57.227
93.93.130.133
<snip>
Name: whitelistnet
Type: hash:net
Revision: 7
Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xc9e0aa3d
Size in memory: 504
References: 0
Number of entries: 1
Members:
151.101.129.0/24
The bug mentioned in the wiki was not hit. Even though ipset failed to load the sets, iptables started normally. After manually re-creating the tables and restoring the iptables rules, iptables is again using the sets:
# iptables -nvL --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 match-set whitelistnet src
2 0 0 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 match-set whitelist src
3 0 0 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0 match-set blocklist src
4 0 0 f2b-dovecot 6 -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 110,995,143,993,587,465,4190
<snip>
I've followed the wiki and the man-page (and help) command to restore the files manually, but nothing seems to work. Any ideas what is going on? I'm brand new to ipset, so I don't have much experience to draw from. Any ideas why ipset isn't being restored on startup by ipset.service?
David C. Rankin, J.D.,P.E.
Offline
After some fiddling around I found the culprit. ipset has several (four) output modes and the default for "ipset list" is "list" mode and for "ipset save" the "save" mode - but it doesn't work. "ipset save" outputs are in the "list" mode too.
Despite looking slightly stupid this should work:
ipset -o save save > /etc/ipset.conf
BTW: Have you thought about switching to nftables? It has powerful native sets, should work with fail2ban too and can even replace it.
Last edited by -thc (2024-04-11 12:21:40)
Offline
Thank you, thank you! I knew I wasn't going crazy. I have had several discussions on the list about nftables, but have not waded in far enough to give it a try yet. iptables has served me well, but the sledgehammer approach to blocking the IP blocks for the worst offenders has become unmanageable as cloud has moved services around the globe. Fail2ban is still great, but its effectiveness has dramatically been reduced by the bad guys using proxy lists to rotate IPs for brute-force attempts.
I'll read more on nftables. Right now I'll just be grateful to be able to reload ipset on reboot. I'll give it a shot and let you know if I run into any problems.
Is this something that needs an issue opened on gitlab, or is it going to be worked without the need?
Success Load After Reboot
Updated to kernel 6.8.5-arch1-1 and rebooted. ipset and iptables came up just fine load all 3 ipsets. Thank you again for your help.
Last edited by drankinatty (2024-04-12 08:02:02)
David C. Rankin, J.D.,P.E.
Offline
Is this something that needs an issue opened on gitlab, or is it going to be worked without the need?
I consider this to be a bug.
Offline
Opened ipset enabled fails to restore /etc/ipset.conf We will see if that is what is needed or if we also need upstream. Thank you again. ipset -o save save > /etc/ipset.conf does work fine.
David C. Rankin, J.D.,P.E.
Offline