recommendations on implementing a custom Netfilter hook to QUEUE packets before their SEQ/ACK and size before fragmentation are known?

recommendations on implementing a custom Netfilter hook to QUEUE packets before their SEQ/ACK and size before fragmentation are known?

[Igor 'Lo' (И.L.)]

Hi all.

What I look for is reimplementing a part of NFQUEUE functionality at
the stage where TCP packet is formed before sending to network.
It seems that NFQUEUE can't just handle expanded (> MTU) packet, and
also want to have control over SEQ/ACK numbers assigned to
both packets and connection structures.

But errr.. where to look for? The sources are too complex and there's
not enough guides.
Actually I have this doc only:
http://www.nsnam.org/wiki/index.php/GSOC2009Netfilter#Callback_Priority

Can anyone point me to correct place in kernel sources to see/attach
with SystemTap and track how SEQs are generated and how outgoing
packets are planned to be fragmented or even dropped? Deliberately
want a good tour.

P.S. There's at least 2 projects that can benefit from such
transparent packet size growing, one is mine and second is StegBox
(steganography based covert channels in traffic)

-- 
cheers,
Igor

Re: recommendations on implementing a custom Netfilter hook to QUEUE packets before their SEQ/ACK and size before fragmentation are known?

[Frank Ch. Eigler]

Hi -

=?KOI8-R?B?SWdvciAnTG8nICjpLkwuKQ==?= <bombsiteunrested@gmail.com> writes:

> What I look for is reimplementing a part of NFQUEUE functionality at
> the stage where TCP packet is formed before sending to network.

I don't know what I'm talking about, but... :
Are you sure NFQUEUE gets involved in outgoing tcp fragmentation?

> It seems that NFQUEUE can't just handle expanded (> MTU) packet, and
> also want to have control over SEQ/ACK numbers assigned to
> both packets and connection structures.

It'd be the TCP layer's job to fragment outgoing packets, considering
the appropriate MSS.  conntrack defragments, as far as I can see,
nfqueue doesn't deal with the issue at all.

> [...]  Can anyone point me to correct place in kernel sources to
> see/attach with SystemTap and track how SEQs are generated and how
> outgoing packets are planned to be fragmented or even dropped?
> Deliberately want a good tour. [...]

For plain ipv4, for recent systemtap versions:

    probe kernel.function("secure_tcp_sequence_number").return {
          printf ("%s -> %d\n", @entry($$parms), $return)
    }

[...]
saddr=0x100007f daddr=0x100007f sport=0xcee1 dport=0x3815 -> 1787682413
saddr=0x100007f daddr=0x100007f sport=0x3815 dport=0xcee1 -> 1793064379
saddr=0x100007f daddr=0x100007f sport=0x75c9 dport=0xf03 -> 1934845113
saddr=0x100007f daddr=0x100007f sport=0xf03 dport=0x75c9 -> 1938803971
[...]

    probe kernel.function("tcp_fragment") {
          println($$parms, " ", @cast(&$skb->cb[0], "tcp_skb_cb")->seq,
                           " ", @cast(&$skb->cb[0], "tcp_skb_cb")->end_seq)
    }

sk=0xffff8805215d4880 skb=0xffff8805125fac00 len=0x500 mss_now=0x5a8 1280 3015968150 3016000006
[...]


- FChE

Re: recommendations on implementing a custom Netfilter hook to QUEUE packets before their SEQ/ACK and size before fragmentation are known?

[Igor 'Lo' (И.L.)]

Hi,
> I don't know what I'm talking about, but... :
> Are you sure NFQUEUE gets involved in outgoing tcp fragmentation?
Well, NFQUEUE receives 100 bytes payload, out of which 20 are IP and 20 TCP.
I shrink payload (adding a valid TCP option, 8 NOPs for example), so
TCP is 28 bytes and the payload size is (100-20-28).
These 8 bytes will get retransmitted over and over, breaking the
transmission and coming from the most unlucky packet that started a
SEQ/ACK war.
Same happens when payload gets larger.

>
>> also want to have control over SEQ/ACK numbers assigned to
>> both packets and connection structures.
>
> It'd be the TCP layer's job to fragment outgoing packets, considering
> the appropriate MSS.  conntrack defragments, as far as I can see,
> nfqueue doesn't deal with the issue at all.

Of course it is.
But, given example - want to modify packet so it's data size (mean,
data == anything after tcphdr data offset) will change. Wasn't NFQUEUE
oriented at doing any kinds of MITM/encryption stuff, not being used
as a drop-in replacement for pcap thus a base for l7-filter only?
What happens then? Retransmission. What happens if I want to send out
a packet which length is bigger than MTU? Partial fragmentation thus
SEQ/ACK flaw leading to constant retransmission of a first fragment.
More, the same happened when trying to capture packet withing mangle
or raw table, which is nonetheless strange.

From looking at the code, guess the only possible workaround is to use
nfq_set_verdict(NF_STOLEN, ...) and reinject the modified packet.
But again, that's not enough to deal with whole connection tracking thing.

>> [...]  Can anyone point me to correct place in kernel sources to
>> see/attach with SystemTap and track how SEQs are generated and how
>> outgoing packets are planned to be fragmented or even dropped?
>> Deliberately want a good tour. [...]
>
> For plain ipv4, for recent systemtap versions:
>
>    probe kernel.function("secure_tcp_sequence_number").return {
>          printf ("%s -> %d\n", @entry($$parms), $return)
>    }

>    probe kernel.function("tcp_fragment") {
>          println($$parms, " ", @cast(&$skb->cb[0], "tcp_skb_cb")->seq,
>                           " ", @cast(&$skb->cb[0], "tcp_skb_cb")->end_seq)
>    }
>
> sk=0xffff8805215d4880 skb=0xffff8805125fac00 len=0x500 mss_now=0x5a8 1280 3015968150 3016000006

Answer accepted. So will running a dump_trace() or similar for
anything called after nfq_set_verdict reveal a call to this functions?

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

Re: recommendations on implementing a custom Netfilter hook to QUEUE packets before their SEQ/ACK and size before fragmentation are known?

[Hassan]

Igor 'Lo' (И.L. <bombsiteunrested <at> gmail.com> writes:

> 
> Hi all.
> 
> What I look for is reimplementing a part of NFQUEUE functionality at
> the stage where TCP packet is formed before sending to network.
> It seems that NFQUEUE can't just handle expanded (> MTU) packet, and
> also want to have control over SEQ/ACK numbers assigned to
> both packets and connection structures.
> 
> But errr.. where to look for? The sources are too complex and there's
> not enough guides.
> Actually I have this doc only:
> http://www.nsnam.org/wiki/index.php/GSOC2009Netfilter#Callback_Priority
> 
> Can anyone point me to correct place in kernel sources to see/attach
> with SystemTap and track how SEQs are generated and how outgoing
> packets are planned to be fragmented or even dropped? Deliberately
> want a good tour.
> 
> P.S. There's at least 2 projects that can benefit from such
> transparent packet size growing, one is mine and second is StegBox
> (steganography based covert channels in traffic)
> 


Hi,
Have you ever got any solution for doing that?
I have been involved a project with this kind of problem.
In my project I need to put 32 byte more in IpOption. I did it and it works for
packet_length < (MTU-32). But for the packet_length > (MTU-32) each packet
should be fragmented with 2 packets. The problem is how can I use
nfq_set_verdict() for both of those packets?



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