You are expanding the command line port ranges (80-82 in your example above)
to add the underlying elements. Could you not do a similar arrangement for the
protocol as well?
That won't go: tcp and udp are not the possible protocols alone, so by any
reasonable syntax, '*' or 'all' should have to mean all protocols from
/etc/protocols.
Whatever the appropriate place holder is - 'all', '*', '@', '$$$$$$'
etc. etc - as long as it does the job at the end it won't matter.
It is not a perfect solution by any stretch, but at least it will save me the
hassle, as with the introduction of the port ranges, of executing the
statement twice each time I want to include net and port ranges without being
interested in the protocol match.
What I could come up as something similar in effect is to make possible to
use a copy of /etc/services maintained by the administrator of the given
ipset installation and whatever protocols and ports a service name is
resolved to from that file, use those.
I wasn't aware that there are more than 2 (tcp and udp) protocols on
which I could define/use ports!
However such a feature won't be added tomorrow. Nor this year (:-) or the
very near future.
What are your plans?
For the "net" (sub)type of sets the different prefixes in the set is
recorded. When testing (adding/deleting) entries, the IP part of the entry
is masked with the prefixes one by one and looked up until a match is
found or the list is exhausted - that's why the speed is linearly slows
down with the different number of prefixes added to the set. An example:
# ipset create test hash:net
# ipset add test 192.168.0.0/30
# ipset add test 192.168.1.0/24
There are two different prefixes in the set, 30, 24. So when the command
is issued
# ipset test test 192.168.0.1
the address 192.168.0.1 is masked with /30 and the result is looked up
and the match is reported:
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?
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?
Is this slowdown more than when I use iptreemap set for example? How does the
new set (hash) performance compares against the 'old' iptreemap/treemap sets
used in 4.x?
I never measured the speed difference between the two types. A good guess
is that iptreemap is faster.
Thought so!
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?
--
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
