[fw-wiz] dirty packet tricks?

From: Marcus J. Ranum (mjr@ranum.com)
Date: 07/10/02 

To: firewall-wizards@honor.icsalabs.com
From: "Marcus J. Ranum" <mjr@ranum.com>
Date: Wed Jul 10 12:51:01 2002

Hi, I'm a bit out of date on the latest/greatest dirty packet-flogging
tricks; perhaps someone can point me in the right direction...

Back a zillion years ago we implemented "proxy transparency" type
things in BSD firewalls by whacking the code in the IP stack so that
the firewall would ARP for (basically) anything that was not internal,
then convince its IP stack that it was the destination, allow a
connection to occur in user-space, then connect out and relay traffic.
It was gross but it worked. Are there better ways of doing that
nowadays?

I'm somewhat restricted from using stuff like arpd and arp spoofing,
because the application in question will be in a location where I
want to grab the traffic when it won't ever be on the destination
subnet. For example - consider:
1) our network is 10.10.10.0/24
2) our "target" machine is 16.67.32.1/32 port 23
3) there is a router/firewall on the edge of 10.10.10.0 that blocks all
        traffic to 16.67.32.1
4) the router/firewall _allows_ traffic from one machine (our mystery
        box) to the target 16.67.32.1 port 23
5) all machines on network 10 that try to talk to 16.67.32.1 port 23
        should get the connection "stolen" from our machine, which
        should connect to the _real_ 16.67.32.1 and get packets back
        and forth

I was thinking of using bpf to vacuum up packets into user space
then push them down into the stack using /dev/tun driver. Once it
was in the stack, I could probably get most of the dirty work done
with NATting that traffic to an internal process on the machine based
on whether it came in or out of /dev/tun.
Getting traffic back out would follow (presumably) the reverse path.
Fortunately, the traffic I want to grab is relatively low bandwidth.

The other alternative appears to be to just do user-mode TCP by
sucking the packets up using bpf, passing them to a process that
connects to the target, and simulates tcp on the other side. Kind
of like honeyd does.

Or is there a better way? I figured I'd better ask because if I just
start whaling away at solving the problem I could work for months and
have someone hand me a manpage and say "DUH!" ;)

mjr. 

---
Marcus J. Ranum				http://www.ranum.com
Computer and Communications Security	mjr@ranum.com

Relevant Pages

  • Re: syslog server, RH ES 4, large amounts of UDP loss. please help
    ... 26 packets to unknown port received. ... Below I see no recieve errors, but netstat reports recieve ... stats are only looking at the Ethernet level errors in the stack. ... the higher levels on the receiving system stack are tripping over themselves. ...
    (comp.os.linux.networking)
  • Re: Selecting optimum block sizes for data transmission
    ... socket up with data until it either tells you you can't send any more ... Once you've make a call to send data, the TCP/IP stack does a huge ... Maintains a congestion window to limit data flow in the face of long ... Attempts to avoid wasteful sends of very small packets, ...
    (comp.lang.pascal.delphi.misc)
  • Re: virtual END and ARP processing
    ... I added a "snarf protocol". ... to reach the TCP/IP stack, while most packets was to be ... etherInputHookAdd I am presently using VxWorks 5.4 ...
    (comp.os.vxworks)
  • Re: do_IRQ: stack overflow: 872..
    ... I don't think it's recursing -- I think the stack trace is just a bit ... This happens when you're bridging packets received in an interrupt while ... One option might be to make br_dev_xmitjust queue the packet rather ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: problem with NdisReturnPackets ( )
    ... appear on the stack anywhere. ... > It does not happen on other vmware versions and physical NICs. ... > I use separate pools for send and receive packets. ...
    (microsoft.public.development.device.drivers)