[fw-wiz] 1. dirty packet tricks? (Marcus J. Ranum)

From: Boni Bruno (bbruno@dsw.net)
Date: 07/11/02


From: "Boni Bruno" <bbruno@dsw.net>
To: firewall-wizards@honor.icsalabs.com
Date: Thu Jul 11 16:50:47 2002

I have come across your problem before. I opted for a transparent
bridge design to steal or inspect the connection. This was the safest,
fastest, and most reliable scenario I found to be effective.

You basically will need to create two physical segments for the 16.67.32.1
node (as shown in your example) or net and place your security device in
the middle in bridging mode so no NAT or any readdressing is needed - the
network is the same on both sides. You can extend OpenBSD's ethernet bridging
software with ipf to extend link layer bridging with the security features
you described below. You can also add the IPsec support available in OpenBSD,
to allow creation of virtual LANs. The changes necessary to the bridge and
IPsec code for this are fairly minimal.

If you want to be real hard core about it, build your own asic based
appliance. I hope this helps....

Regards,

Boni Bruno
VP of Engineering & Security
Data Systems Worldwide, Inc.

Message: 1
Date: Wed, 10 Jul 2002 10:59:17 -0400
To: firewall-wizards@honor.icsalabs.com
From: "Marcus J. Ranum" <mjr@ranum.com>
Subject: [fw-wiz] dirty packet tricks?

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.



Relevant Pages

  • Re: BlueTooth stacks (WidComm, BroadComm, MS) (peter?)
    ... ports might not be suitable, on most devices you are limited to a single ... devices when you try to establish a connection, ... > B. Delorme EarthMate GPS Bluetooth logger. ... >> both have advantages and disadvantages, the Microsoft stack has a free ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: BT Stack under WM2005
    ... Under WM5.0 (with the Microsoft stack) once you have paired a device you can view it's properties in Settings> Connections> Bluetooth and view the properties, if you check Serial Port and save you can then go to the COM Ports tab of the Bluetooth settings applet and map an outgoing COM port to your device. ... Although there's always one preliminary step I have to take prior to engaging this kind of communication: I've either got to use the built-in GPS manager, which is unfortunately hidden under WM5 by default in order to map COM ports to the incoming data from Picoplug. ... Every time I restart a programme which is attempting to communicate with the Picoplug, connection gets established but only to break down a few seconds later. ...
    (microsoft.public.pocketpc.developer)
  • Re: Socket Programming
    ... Every connection to a server is to ... reason I thought there was a limit on server connections was the way I ... >> thread per connection was running out of stack space. ... > argument was that while it might be possible to actually manage memory ...
    (comp.lang.lisp)
  • Re: goto across functions/isrs?
    ... gracefully detects sudden disconnection before the actual communication ... the connection status at that time. ... You want to goto main line code from an interrupt. ... The interrupt return address is still on the stack. ...
    (comp.arch.embedded)
  • Re: Local variables controversial?
    ... >>locals have been declared, the system must behave as if they have been ... >>removed from the stack. ... > to the data stack. ... They need not be transparent with respect ...
    (comp.lang.forth)