IP sets: Suggestion: additional value match

IP sets: Suggestion: additional value match

[Rudolf_AT]

Hi,

when working with IP sets, I came up with the following idea:
adding a value match:

  -j SET --add-set set1 flag[,flag]=value
  --match-set set1 flag[,flag]=value

Where value is an integer which is set in the added list element of the 
SET target. The value does not change the dimension of the list. The 
match is true only if the given value is equal to the value stored in 
the found element.

Optionally adding an arbitrary value could help using IP sets in even 
more ways than now, for example easily tracking packets independently of 
other extensions or matches.

For example, instead of using three sets to distinguish between three 
different states:
  -j SET --add-set state1set src,dst,dst
  -j SET --del-set state2set src,dst,dst
  -j SET --del-set state3set src,dst,dst
one would write:
  -j SET --add-set aset1 src,dst,dst=<integer>
Where <integer> resembles state1|state2|state3 then.

Maybe you can think of more uses for this feature.
As a further enhancement bit operators might be useful, too.

Best Regards,
Rudolf

Re: IP sets: Suggestion: additional value match

[Jozsef Kadlecsik]

Hi,

On Thu, 30 Jul 2015, Rudolf_AT wrote:

> when working with IP sets, I came up with the following idea:
> adding a value match:
> 
>  -j SET --add-set set1 flag[,flag]=value
>  --match-set set1 flag[,flag]=value
>
> Where value is an integer which is set in the added list element of the 
> SET target. The value does not change the dimension of the list. The 
> match is true only if the given value is equal to the value stored in 
> the found element.
> 
> Optionally adding an arbitrary value could help using IP sets in even 
> more ways than now, for example easily tracking packets independently of 
> other extensions or matches.
> 
> For example, instead of using three sets to distinguish between three
> different states:
>  -j SET --add-set state1set src,dst,dst
>  -j SET --del-set state2set src,dst,dst
>  -j SET --del-set state3set src,dst,dst
> one would write:
>  -j SET --add-set aset1 src,dst,dst=<integer>
> Where <integer> resembles state1|state2|state3 then.
>
> Maybe you can think of more uses for this feature.
> As a further enhancement bit operators might be useful, too.

The stored value is not a dimension-like parameter, so it should not be 
denoted/matched/updated as a dimension related one.

As far as I see it's quite similar to the "connmark/CONNMARK" match 
and target. Why cannot that simply be used?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
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

Re: IP sets: Suggestion: additional value match

[Rudolf_AT]

Thanks for your reply!

 > As far as I see it's quite similar to the "connmark/CONNMARK" match
 > and target. Why cannot that simply be used?

Yes, it is quite similar to connmark. But - to my knowledge - I think at 
least the following differences apply:

CONNMARK can be used: a) if there are no conflicts with existing use of 
connmark rules - in particular with special firewall/packetfilter 
systems with built-in-rules - and b) if a connection should be 
identified exactly by src/dest IP + src/dest port.

SET can be used without interfering with connection tracking and other 
existing SET rules. Identifying the origin and destination of a packet 
is more flexible by using one or all of src/dest IP + one port.

In particular, I used SET instead of CONNMARK to implement the rules 
described by Jan Engelhardt in "Detecting and deceiving network scans".

Best Regards,
Rudolf

Re: IP sets: Suggestion: additional value match

[Rudolf_AT]

Hi,

Just to let you know, regarding my previous post:
 > In particular, I used SET instead of CONNMARK to implement the rules
 > described by Jan Engelhardt in "Detecting and deceiving network scans".

(Has nothing to do with IP sets.)
As it turns out, some legitimate clients open and close TCP connections 
in a way which makes them behave like connect scans. This makes the 
attempt detecting those scans by the mentioned rules look less appealing.

Best Regards,
Rudolf