netsed 1.2       (C) 2010-2012  Julien VdG <julien@silicone.homelinux.org>
  --------------------------------------------------------------------------

  This work is based on the original netsed:
      netsed 0.01c      (C) 2002  Michal Zalewski <lcamtuf@ids.pl>

  Please contact Julien VdG <julien@silicone.homelinux.org> if you encounter
  any problems with this version.
  The changes compared to version 0.01c are related in the NEWS file.

  --------------------------------------------------------------------------

  "When things go well, expect something to explode, erode, collapse or
  just disappear."  -- anonymous

NetSED is small and handful utility designed to alter the contents of
packets forwarded thru your network in real time. It is really useful
for network hackers in following applications:

  * black-box protocol auditing - whenever there are two or more
    propertiary boxes communicating over undocumented protocol (by enforcing 
    changes in ongoing transmissions, you will be able to test if tested 
    application is secure),

  * fuzz-alike experiments, integrity tests - whenever you want to test 
    stability of the application and see how it ensures data integrity,

  * other common applications - fooling other people, content filtering,
    etc etc - choose whatever you want to.

It perfectly fits netgrep, netcat and tcpdump tools suite :P

It has been designed because I was suspicious about Lotus Domino carrying
mailbox path in every packet after authorization. Having no Lotus Domino
client software under Linux, I needed something to install on my bridging
firewall to modify this mailbox path and try to read someone's else
mailbox. Guess what happened?:P

This is release 0.01b, which isn't really effective or stable, and I
wouldn't suggest you putting it nowhere in your production systems ;)
But - well - any suggestions, fixes, comments and ideas are welcome. For
now, only TCP and UDP user-space filtering is possible - no support for
kernel firewalling / routing, raw packets, ICMP and other things.

I bet it won't compile on platforms other than Linux, as I haven't tested
it, but it shouldn't be too difficult to run it on *BSD, IRIX, Solaris
etc.

  Setting up netsed - theory
  --------------------------

There are two possible ways of using netsed. Basic configuration looks this
way:

  ( client software ) --->------+
                                |
                          < local port >
                                |
                         [ netsed engine ]
                                |
                                +-------------> ( remote server )

In this solution, client software has to connect specified port on specified
machine - which is not always possible, and not always expected. So,
there is a second way - which is completely system-dependent. It is called
transparent proxy.

NetSED supports kernel-level transparent proxy. This means you can set up
your gateway machine (firewall, router, ethernet bridge) to transparently
redirect all traffic coming from client software to remote server without
touching anything outside this box. On Linux, you can set up transparent
proxying in pretty easy way:

ipfwadm -I -i accept -S source_ip -D destination_ip port -P protocol -r lport

For example, if you want to redirect all traffic coming from host 
1.2.3.4 to network 5.6.0.0/16 with destination port 12345/tcp, and you
have netsed working on port 10101 on your local machine, you should do
something like:

ipfwadm -I -i accept -S 1.2.3.4 -D 5.6.0.0/16 12345 -P tcp -r 10101

By setting up netsed properly, content will be transparenly modified and
forwarded to the destination:

                                 NetSED
                              ______|______
  ( client software ) --->---| - - -+- - - |--------> ( server host )
                             | transparent |
                             |    proxy    |
                             |_____________|

For more instructions on rules syntax and transparent proxies in general,
refer your OS documentation.

Update for linux 2.4 and later with netfilter:

First you need to make sure LINUX_NETFILTER is defined in source code 
before compiling.
Then the command are as follows:
iptables -t nat -D PREROUTING -s source_ip -d destination_ip -p protocol --dport port -j REDIRECT --to lport

So the previous example becomes:
iptables -t nat -D PREROUTING -s 1.2.3.4 -d 5.6.0.0/16 -p tcp --dport 12345 -j REDIRECT --to 10101

  Setting up netsed - practice
  ----------------------------

Ok, here we are. First of all, you should know how to set up the first
configuration I've been talking about - static, user-space forwarder.
NetSED accepts following parameters:

   netsed proto lport rhost rport rule1 [ rule2 ... ]

First parameter, 'proto', means, obviously, the protocol. You might choose
'tcp' or 'udp'. Then, you have to specify 'lport' - local listening port.
Next argument, 'rhost', is the remote server address where the connection
should be forwarded. ONLY IP ADDRESSES ARE SUPPORTED BY NOW. Then, we
have 'rport' - remote port number, and up to 50 filtering rules.

General replacement rules syntax is: 

   s/pat1/pat2[/expire]

This will replace all occurrences of pat1 with pat2 in matching packets.
An additional parameter (count) can be used to expire rule after 'count'
successful substitutions for a given connection. Eight-bit characters, 
including NULL and '/', can be passed using HTTP-alike hex escape 
sequences (eg. %0a%0d). Single '%' can be reached by using '%%'.
Wildcards are supported by specifying %* and will match any value. Up to 10 wildcards can be used.
Examples:

  's/andrew/mike/1'     - replace 'andrew' with 'mike' (only first time)
  's/andrew/mike'       - replace all occurrences of 'andrew' with 'mike'
  's/start%*end/new'    - replace anything between (and including) 'start' and 'end' with 'new'
  's/andrew/mike%00%00' - replace 'andrew' with 'mike\x00\x00'
                          (manually padding to keep original size)
  's/%%/%2f/20'         - replace the 20 first occurence of '%' with '/'

Rules are not working on cross-packet boundaries and are evaluated from
first to last not expired rule.

Per-rule TTLs (time-to-live) are useful if you want to modify eg. only
the first packet, letting other packets unmodified, or to dynamically
change NetSED functionality. This rule, for example, will change 'Henry'
to 'William' in the first packet, and to 'Mariah' in all other packets:

      s/Henry/William/1 s/Henry/Mariah

So, let's try our first command-line example:

  ./netsed tcp 10101 127.0.0.1 25 s/ehlo/badcommand/1

This should be obvious - connection to local port 10101 will be forwarded
to local smtp service. Take a look:

$ telnet localhost 10101
220 squirrel.tpi.pl ESMTP Sendmail 8.9.3/8.9.3; Fri, 5 Jan 2001 00:15:18 +0100
ehlo
500 Command unrecognized: "badcommand"
ehlo
501 ehlo requires domain address

Apparently, it worked :) Try playing a little with different patterns,
multiple rules etc. Generally, NetSED works by incremental comparsion
of the rules, and then skipping already replaced data. For example:

    Rules: s/degener/devi/
           s/generation/%20and%20sausages/
           s/sausages/chicken/

    Input data: 'degenerationgeneration'

    Init: degenerationgeneration
          ^ (replace pointer)

    Pass 1: deviationgeneration       [degener -> devi]
                ^ (replace pointer)

    Pass 2: deviation and sausages    [generation -> and sausages]
                                  ^
    No futher replacements made - end of input data (so, 'sausages'
    won't be replaced with 'chicken').

Now, I suppose you'd like to know how to setup good-working transparent
configuration. Well - nothing easier :) The configuration described above
should work just fine - set up transparent packet redirection to port
10101 in traffic from one remote host to another and watch the results...

Uhm, right. There's one thing. You might want to divert traffic from
one host to whole network - but you do not know how to configure netcat
to preserver original destination addresses? So, for example, connecting
to 5.6.7.1 and to 5.6.7.2 from 1.2.3.4 (example mentioned above) will
establish working session to existing targets? Nothing easier. Just
set rhost and/or rport parameters to '0' while invoking NetSED to preserve
original destination host and port settings while forwarding the connection
via proxy :)

WARNING: nothing will stop you before setting up forwarding loops - you
can eg. forward connections to port 100 to port 1000 using netsed, and then,
using kernel-space transparent proxy, forward connections to local port 1000
back to port 100. This might lead to ugly DoS attack if you do not have
per-user resource limits set. Sorry. Not a Microsoft product.