Re: [ANNOUNCE] ipset-5.0 released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Whatever the appropriate place holder is - 'all', '*', '@', '$$$$$$' etc. etc
- as long as it does the job at the end it won't matter.

It does matter. Non-intuitive syntax and notation are bad. Moreover, the notation should be open to handle other protocols too (see below).
What I meant was that whatever the prefix *you* decide to put in, for *me* it won't matter as long as it does its job.

I wasn't aware that there are more than 2 (tcp and udp) protocols on which I
could define/use ports!

sctp, udplite.
I learn something new every day. Then it makes even more sense to store the protocol as a number, not as string for easier matching - useful if you one day decide to apply masking (or other convenient form of searching) against the captured protocol (which could also be a number). ;-)

What are your plans?

Double check and triple check both the kernel and userspace of ipset 5. Get more feedback, especially from uncommon architecture. Submit for kernel inclusion. After that new features can be added.
Fair enough. Any idea when ipset 5.2 will be incorporated into xtables so that I could download it and start testing it? *nudges Jan*

As it stands, I do not have enough information to build the rpm spec file in order to create a complete xtables rpm package to incorporate your version of ipset (without this I cannot distribute it across my test machines easily), so unless I am able to build this rpm the whole thing is a no go from me.

So, in other words 'internally' you store something like (using your example
above) 192.168.0.0 (the IP part), 30 (the prefix), tcp, 80 in the structure,
is that right?

Yes, exactly.

Do you then use the mask of each member of that set (30 and 24 in your example
above) until you get a match? In other words, you 'walk through' every
internally stored element and try their mask and then lookup for a match, is
that how you do it?

Besides the elements, the different prefixes are also stored in the set. So the test set in the example "knows" that the prefixes 30 and 24 occur only and use only those to find a match, starting from the most speficic prefix to the least one.
If I understand you correctly, you keep a separate structure which stores all prefixes used in the target set, walk through that structure and for each element you build start-end range based on the IP address captured and the current prefix. You then create a hash on the calculated start-end range, protocol and port triple and then test that hash against the hash value of the target set triple (IP range, protocol, port). Is that how you do it?

I understand that things are a bit easier with hash:ip,protocol,port as you don't need to store prefixes - you just calculate the hashes and match them against the corresponding hashes of the set triple, right?

However, the problem with iptree(map) is that it's susceptible when used as
a container to block attackers dynamically by the SET target: it's trivial
to mount an attack by which the worst tree structure is forced to be
created.
Could you expand on that bit please? What do you mean?

The iptree(map) sets store the elements in a tree structure which follows the dotted decimal notation of the IPv4 addresses. Let's assume, someone catches attackers by a given match and stores their IP addresses in the iptree type of set called "attackers":

# If some matches are true, it's an attacker, store the address
...... -j SET attackers src
# Drop known attackers
.... -m set attackers src -j DROP

What I referred to was that it's not hard to send forged packets, which create the widest and least filled in (i.e. worst) tree structure. It does not slow down the set but pushes it to the worst memory usage case.
Couldn't the same be said for the hash (or any other?) ipsets as well? I am not using that 'feature' anyway, as I include the ip addresses/ranges manually from script files (though some of them are automatically generated and are based on the geoip database which is downloaded at regular intervals), so that 'vulnerability' does not apply to me.

I regard it as a weakness of the type: an attacker must not be able to trigger any worst case situation of a set type intentionally.
How is that changed in the hash (or bitmap even) ipsets - would that not be the same then: an attacker crafts specifically designed packets to include certain ip/port ranges in a set (*a* set - it could be any set)?

I think the culprit is not the set itself, but the SET target as I find it rather foolish that someone would let an outsider to manipulate a set using this SET target. For example, if I am an attacker and I know that the target machine relies on access to certain IP address, then I could craft a packet in such a way that it triggers this SET target which then includes the IP address/range in the 'attackers' set and therefore disable access to that address on the target machine - job done!

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux