Note that there are some explanatory texts on larger screens.

plurals
  1. POPacket mangling utilities besides iptables?
    text
    copied!<p>I'm looking for a linux utility that can alter the payloads of network packets based on a set of rules. Ideally, I'd use <code>iptables</code> and the <code>netfilter</code> kernel module, but they don't support generic payload mangling: <code>iptables</code> will alter various <em>header</em> fields (addresses, ports, TOS, etc), and it can <em>match</em> arbitrary bytes within a packet, but it apparently is unable to <em>alter</em> arbitrary data within the packet.</p> <p>A kernel module would be a big plus, as efficiency is a concern, but I'm happy to explore any other options that would get the job done.</p> <p>Thanks for your ideas!</p> <hr> <p><strong>Long-overdue Update:</strong></p> <p>We chose to use the <code>NFQUEUE</code> module, which is the latest implementation of the QUEUE modules that Robert Gamble suggested. It appeared to be fairly simple, with a safety bonus for allowing our code to run in user, not kernel, space.</p> <p>The implementation would have been almost trivial if we'd simply wanted to alter the payload without changing its size. In that case, we'd define an <a href="http://netfilter.org/projects/iptables/index.html" rel="noreferrer"><code>iptables</code></a> rule to select the "interesting" packets for us and send them an <code>NFQUEUE</code> target. We'd write a callback function that would inspect the packets from <code>NFQUEUE</code>, modify the data as required, and recalculate the checksums in their TCP and IP headers.</p> <p>However, our use case involves injecting additional characters into the data stream. This has the somewhat obvious side-effect of increasing the corresponding SEQ/ACK numbers in the TCP stream, and the not-so-obvious side-effect of confusing the <a href="http://kalamazoolinux.org/presentations/20010417/conntrack.html" rel="noreferrer"><code>conntrack</code></a> module enough that it breaks NAT entirely. After a <em>lot</em> of research, head-scratching, and experimentation, the most expedient solution was to disable connection tracking for these particular packets (with the <code>NOTRACK</code> target in the <code>raw</code> table) and handle it in our callback. <em>Save your tomatoes and hate mail; I'm not at all proud to let you under the hood, but it was the only way to get a reliable product to the customer before the next Ice Age. And it's a good story. But I truly appreciate, and share, your heartfelt sentiments.</em></p> <p>Version 2 will leverage our newfound enlightenment by replacing our callback and several <code>iptables</code> rules with a custom NAT and/or <a href="http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-4.html#ss4.4" rel="noreferrer"><code>conntrack</code> helper</a>. We're confident that the current exercise has given us enough experience to create a kernel module that will fit organically into the netfilter architecture to solve the problems we encountered.</p> <p>Thanks again for your interest and suggestions!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload