Score:0

Addresses not always added to set (iptables)

be flag

We use iptables with ipset lists on our network boundary. Generally this works well. I have updated the rules to catch more activity and found that a rule to update a set does not always seem to successfully update the set. The rule is in the PREROUTING chain of the mangle table.

This is the rule (from iptables -L -nv -t mangle):

SET all -- * * 0.0.0.0/0 0.0.0.0/0 match-set BlackHoleTargets dst ! match-set PrivateNets src add-set blackholescanners src

where BlackHoleTargets is a hash:ip set listing ip addresses that should not be published; PrivateNets is a hash:net set listing internally used (non-routable) subnets and blackholescanners is a hash:ip set to capture the addresses of machines probing the unpublished addresses.

I had thought this was working well - after flushing the blackholescanners list it starts to fill rapidly. It has a 12h timout and typically holds ~ 22k addresses. Currently the maximum size of this set is 65536 elements.

As part of a revision of rules we introduced a new rule specific to RDP servers with the intent of only allowing a dynamic list of authorised clients to connect. As part of this we have a rule to catch the RDP sessions which are not authoirsed with this rule in the filter table FORWARD chain (output from iptables -L -nv):

SET tcp -- * * 0.0.0.0/0 xxx.xxx.xxx.0/24 tcp dpt:3389 multiport sports 1024:65535 add-set UnrecognisedRDP src,dst

where xxx.xxx.xxx.0/24 is a range within our network and UnrecognisedRDP is a hash:net,net set to track these sessions.

I am seeing entries in the UnrecognisedRDP table where the destination address is listed in BlackHoleTargets - I would expect that the source address should be in blackholescanners but it's not, and it doesn't match the PrivateNets list either.

For example we have multiple entries in the UnrecognisedRDP table (for different destination addresses) for an address starting 192.241.217 (full IP Address withheld). The source address doesn't match the PrivateNet set (which contains these subnets: 10.0.128.0/20; 10.1.0.0/16; 10.0.0.0/20; 10.0.16.0/24; 10.192.0.0/10; 10.2.0.0/24; 10.129.1.0/24) so I would expect the source address in the UnrecognisedRDP list to be in the blackholescanners set but it isn't. The blackholescanners list is not full (number of entries: 19356 maxelem 65536).

I have tried adding a duplicate rule into the filter table FORWARD chain immediately above the rule that adds the addresses to the UnrecognisedRDP table. After flushing the UnrecognisedRDP set I have still found entries that have been added to the UnrecognisedRDP set which have not been added to the blackholescanners set. The packet counters show both rules have fired.

So my question is: Why doesn't the rule with -j SET --add-set blackholescanners src successfully update the set?

cn flag
Bob
The maximum size of an [ipset](https://ipset.netfilter.org/ipset.man.html) hash table is defined on creation, is that maximum reached and could additional entries beyond that maximum simply be discarded?
Rob Lambden avatar
be flag
Thanks @Bob but in this scenario the set is not full - I will update the question to include this crucial piece of information!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.