Hi, On Tue, 20 Aug 2019, G.W. Haywood wrote: > Debian provides more or less everything I'm using here, including the > kernel and the ipset binary: > > mail6:/etc/mail# >>> uname -a > Linux mail6 3.16.0-6-amd64 #1 SMP Debian 3.16.56-1+deb8u1 (2018-05-08) x86_64 > GNU/Linux > > mail6:/etc/mail# >>> ipset version > ipset v6.23, protocol version: 6 That's a quite old ipset version - since then there has been 19 releases with a lot of bugfixes, corrections. If you can send me a testcase by which either of the problems can be reproduced, I'll run it against the most recent version to verify that the problems you reported have indeed be fixed. Nice usage! :-) Best regards, Jozsef > This is a mail server. I'm running a homebrew Sendmail milter which > can write rules into a file, for a cron job to insert into the kernel > at some later time using iptables and ipset. > > The rules may for example block all the CIDRs listed by the GeoIP2 > database as belonging to some AS number with the same ISO country > code as the country code for the IP that just tried to spam us. > > The numbers of CIDRs can be well into the thousands, perhaps even 10k. > > First issue: > > When it's a very large number (several thousand), while adding rules > using ipset 6.23 the kernel sometimes crashes. I seem to have worked > around this by inserting a sleep of some seconds between adding > batches of 10 rules. > > Now I seem to have worked around the issue doesn't it concern me, but > I wonder if it's something you know about/would like more information? > > > Second issue: > > The rules have attached comments. I use the comments to check that > the milter is doing what I think it's doing. For a time I thought > that it wasn't, because I thought I was seeing CIDRs which should be > located in Britain being blocked when they were not supposed to be. > > So I did what I always do at a time like this - more logging. > > Unfortunately I deleted all the rules which I thought were incorrect > before restarting with additional logging so I don't now know if the > rules were in fact correct and simply had incorrect comments. But I > was surprised to find that one CIDR which is allocated to Ukraine > appeared to be commented in my ipset rules as belonging to Britain. > > My logging proves to me that the rule was added with a comment which > indicates that the CIDR is in Ukraine. The timeout was initialised > to 2147483 seconds, at 2019/08/17 19:32:39, together with a comment > giving a timestamp for the rule addition, the GeoIP country location, > the DNSBL 'score' (the score is a weighted total of several DNSBLs) > which in this case is 15 (well into REJECT territory) and the ASnum: > > /sbin/ipset -exist add BLOCKSET22 109.251.180.0 timeout 2147483 comment > "20190817193239 UA 15 AS31148" > > No other rule was subsequently added for this CIDR. > > Today I see the same CIDR has a timeout value consistent with being > initialised at the stated time, *but* the comment has been changed! > > 109.251.180.0 timeout 1886346 packets 0 bytes 0 comment "20190819173347 GB 05 > AS16276" > > The comment is in fact associated with another set of CIDRs which was > added two days later. No rule for 109.x.x.x was added in this set. > Here's an example from the set: > > /sbin/ipset -exist add BLOCKSET22 51.68.196.0 timeout 2147483 comment > "20190819173347 GB 05 AS16276" > > The current timeouts for the same set are consistent: > > 51.68.196.0 timeout 2052047 packets 0 bytes 0 comment "20190819173347 GB 05 > AS16276" > > I looked at the changelog for the latest 6.xx but I didn't see > anything which might describe this issue. Is it new? > > -- > > 73, > Ged. > - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
