Re: u32 question

Re: u32 question

[Don Cohen]

This example doesn't seem to work for me.
Does it work for anyone else out there?  

 $ iptables -A OUTPUT -m u32 --u32 "0>>22&0x3C@12>>26&0x3C@-3&0xFF=0:255"
  -j LOG --log-prefix "TCP with payload *** "
I've tried some examples without the @ and they seem to be working but
I don't get anything in the log when I do this:

 $ iptables -L OUTPUT -n -v
 Chain OUTPUT (policy ACCEPT 17M packets, 1045M bytes)
  pkts bytes target     prot opt in     out     source
 destination         
     0     0 LOG        all  --  *      *       0.0.0.0/0
 0.0.0.0/0           u32
 0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0xfffffffd&0xff=0x0:0xff LOG flags 0
 level 4 prefix `TCP with payload *** ' 

(seems right)

 $ tcpdump -lenX -i wlan0 -c 4
 tcpdump: verbose output suppressed, use -v or -vv for full protocol
 decode
 listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
 13:02:48.661944 00:21:6b:40:06:7e > 00:80:c8:b9:a4:2f, ethertype IPv4
 (0x0800), length 114: 10.0.2.100.33306 > 66.166.0.98.ssh: P
 3799762522:3799762570(48) ack 1707553806 win 1067 <nop,nop,timestamp
 3419089842 694605510>
        0x0000:  4510 0064 6a44 4000 4006 80d4 0a00 0264 E..djD@.@......d
        0x0010:  42a6 0062 821a 0016 e27b c65a 65c7 340e B..b.....{.Ze.4.
        0x0020:  8018 042b 90d1 0000 0101 080a cbcb 2bb2 ...+..........+.
        0x0030:  2966 d6c6 c826 20cd 0b4c 0cf4 39cc 71e0 )f...&...L..9.q.
        0x0040:  ca4a 73c2 1058 d9e4 9cbd deec 0d10 f5f3 .Js..X..........
        0x0050:  0d32                                     .2
 13:02:48.691819 00:80:c8:b9:a4:2f > 00:21:6b:40:06:7e, ethertype IPv4
 (0x0800), length 114: 66.166.0.98.ssh > 10.0.2.100.33306: P 1:49(48)
 ack 48 win 60816 <nop,nop,timestamp 694607611 3419089842>
 ...
several more packets that ought to show up in the log

u32 question

[Don Cohen]

This example doesn't seem to work for me.
Does it work for anyone else out there?  

 $ iptables -A OUTPUT -m u32 --u32 "0>>22&0x3C@12>>26&0x3C@-3&0xFF=0:255"
  -j LOG --log-prefix "TCP with payload *** "
I've tried some examples without the @ and they seem to be working but
I don't get anything in the log when I do this:

 $ iptables -L OUTPUT -n -v
 Chain OUTPUT (policy ACCEPT 17M packets, 1045M bytes)
  pkts bytes target     prot opt in     out     source
 destination         
     0     0 LOG        all  --  *      *       0.0.0.0/0
 0.0.0.0/0           u32
 0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0xfffffffd&0xff=0x0:0xff LOG flags 0
 level 4 prefix `TCP with payload *** ' 

(seems right)

 $ tcpdump -lenX -i wlan0 -c 4
 tcpdump: verbose output suppressed, use -v or -vv for full protocol
 decode
 listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
 13:02:48.661944 00:21:6b:40:06:7e > 00:80:c8:b9:a4:2f, ethertype IPv4
 (0x0800), length 114: 10.0.2.100.33306 > 66.166.0.98.ssh: P
 3799762522:3799762570(48) ack 1707553806 win 1067 <nop,nop,timestamp
 3419089842 694605510>
        0x0000:  4510 0064 6a44 4000 4006 80d4 0a00 0264 E..djD@.@......d
        0x0010:  42a6 0062 821a 0016 e27b c65a 65c7 340e B..b.....{.Ze.4.
        0x0020:  8018 042b 90d1 0000 0101 080a cbcb 2bb2 ...+..........+.
        0x0030:  2966 d6c6 c826 20cd 0b4c 0cf4 39cc 71e0 )f...&...L..9.q.
        0x0040:  ca4a 73c2 1058 d9e4 9cbd deec 0d10 f5f3 .Js..X..........
        0x0050:  0d32                                     .2
 ...
several more packets that ought to show up in the log

u32 question

[Don Cohen]

Don Cohen writes:
 > 
 > This example doesn't seem to work for me.
 > Does it work for anyone else out there?  
 > 
 >  $ iptables -A OUTPUT -m u32 --u32 "0>>22&0x3C@12>>26&0x3C@-3&0xFF=0:255"
 >   -j LOG --log-prefix "TCP with payload *** "
 > I've tried some examples without the @ and they seem to be working but
 > I don't get anything in the log when I do this:

A little more data - this seems to work when I replace the -3 above
with 0.  It now occurs to me that the problem might be that I'm using
a 64 bit machine and the -3 translates to #xfffffffd rather than
#xfffffffffffffffd.

(Mike, are you using a 64 bit machine?)

Re: u32 question

[Michal Soltys]

Don Cohen wrote:
> Don Cohen writes:
>  > 
>  > This example doesn't seem to work for me.
>  > Does it work for anyone else out there?  
>  > 
>  >  $ iptables -A OUTPUT -m u32 --u32 "0>>22&0x3C@12>>26&0x3C@-3&0xFF=0:255"
>  >   -j LOG --log-prefix "TCP with payload *** "
>  > I've tried some examples without the @ and they seem to be working but
>  > I don't get anything in the log when I do this:
> 
> A little more data - this seems to work when I replace the -3 above
> with 0.  It now occurs to me that the problem might be that I'm using
> a 64 bit machine and the -3 translates to #xfffffffd rather than
> #xfffffffffffffffd.
> 
> (Mike, are you using a 64 bit machine?)
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

This match in its current version does plenty of sanity checks, and 
moving back using negative offsets don't work (as negative offsets 
are not allowed and the data is internally treated as big >0 value 
- thus failing the match). You have two options: 

- patch the xt_u32.c to allow earlier behavior
- use match2 from xtables-addons (separate options for matching)

For reference:

http://xtables-addons.sourceforge.net/
http://marc.info/?t=125219819200001&r=1&w=2

Re: u32 question

[Don Cohen]

Michal Soltys writes:

 > This match in its current version does plenty of sanity checks, and 
 > moving back using negative offsets don't work (as negative offsets 
 > are not allowed and the data is internally treated as big >0 value 
 > - thus failing the match). You have two options: 

I thought the original version did plenty of checks and specifically 
DID allow negative offsets, which is intentional because, as we see 
from published examples (that no longer work), that's useful.
Is there any reason that capability shouldn't be restored as the
normal version that appears in linux distributions?

 > - patch the xt_u32.c to allow earlier behavior
 > - use match2 from xtables-addons (separate options for matching)

 > For reference:
 > 
 > http://xtables-addons.sourceforge.net/
 > http://marc.info/?t=125219819200001&r=1&w=2

I see that the patch is available here.  It's just relatively
inconvenient to use it compared to things working as intended out of
the box.  I have to say that it's not all that obvious in EITHER of
the two options just what you have to do in order to fix the problem
on your own machine.  Where can I find such instructions?


BTW, in response to some of the comments I see in the second
reference, 
- I would be very surprised to see frames of 2GB any time in the
foreseeable future
- If you're worried about that I suggest that (at least on a 64 bit
machine) you allow 64 bit offsets so on a 64 bit machine
 -3 => 0xfffffffffffffffd.

Re: u32 question

[Michal Soltys]

Don Cohen wrote:
> Michal Soltys writes:
> 
>  > This match in its current version does plenty of sanity checks, and 
>  > moving back using negative offsets don't work (as negative offsets 
>  > are not allowed and the data is internally treated as big >0 value 
>  > - thus failing the match). You have two options: 
> 
> I thought the original version did plenty of checks and specifically 
> DID allow negative offsets, which is intentional because, as we see 
> from published examples (that no longer work), that's useful.
> Is there any reason that capability shouldn't be restored as the
> normal version that appears in linux distributions?
> 

I'm just reporting - as I can see somebody ran into the same problem as me 
a while ago. I've added netfilter-devel to CC, as it's a better place for 
the discussion.

>  > - patch the xt_u32.c to allow earlier behavior
>  > - use match2 from xtables-addons (separate options for matching)

(I meant length2 - separate options for matching 0 payload packets).

> 
>  > For reference:
>  > 
>  > http://xtables-addons.sourceforge.net/
>  > http://marc.info/?t=125219819200001&r=1&w=2
> 
> I see that the patch is available here.  It's just relatively
> inconvenient to use it compared to things working as intended out of
> the box.  I have to say that it's not all that obvious in EITHER of
> the two options just what you have to do in order to fix the problem
> on your own machine.  Where can I find such instructions?
> 
> 
> BTW, in response to some of the comments I see in the second
> reference, 
> - I would be very surprised to see frames of 2GB any time in the
> foreseeable future
> - If you're worried about that I suggest that (at least on a 64 bit
> machine) you allow 64 bit offsets so on a 64 bit machine
>  -3 => 0xfffffffffffffffd.
> --