On 1/18/06, Bill Marquette <[EMAIL PROTECTED]> wrote: > Or because IPFW on FreeBSD has divert() and IP Tables in Linux has > netlink. It's a logical question to ask - although a few minutes in > the man page and a few hours groking the PF source would have been > enough.
I don't say this to be arrogant. pf is really good at hiding the details of the packet path through the kernel, among other things, in the config file. But if you know the stack, then it becomes clear why you can do some things (re-write dest IP on inbound packets) but not their logical inverse (re-write dest IP on outbound packets, or perhaps re-write source IP on inbound packets). netfilter doesn't have this layer of abstraction, so users have to deal with FORWARD chains and PREROUTING and such. Knowing what solution he wants will require knowing some of these details, of the capabilities at each layer. Yes, you can drop all packets and use bpf to capture them in userland, and filter/mangle and reinject.... but copying a lot of data across the userland/kernel barrier is not terribly efficient, as you've got the crossing of protection domains, bitblits, and then you've got latency issues since the userland process has scheduling overhead --- we receive a packet at interrupt level, queue it for "top half" kernel, copy it to userland, wait for userland sniffer to be scheduled, it runs, re-injects packet at which point process reverses. It also involves socket coding and manipulating second-class data objects (in C anyway). If you go this route, and it is the easiest solution beyond ftp-proxy, I suggest writing the prototype in a HLL with a libpcap binding. If you know python, Impacket is the best I've seen. If performance isn't enough (that is, if you are dropping unacceptable numbers of packets during load), you may have to resort to C/C++. C in particular has lots of ways to screw this up, and remember that you are handling data created by remote, possibly hostile parties. So one input validation screwup, one buffer overflow, and you're harming your overall security, not helping it. If the drop rate is still too high, pcap/bpf won't work for you. The next solution would be changing how the kernel works. Lots of learning involved, lots of tedious work, lots of testing, lots of kernel panics, probably a lot of changes to please the kernel developers. Many places to go wrong on this path. Will require extensive reading and understanding of kernel source. Fortunately the pf code, at least in openbsd, is remarkably clean. You'll still need to learn how and where the kernel does 'tings. You might want to buy (or borrow) the 4.4 BSD book and read the network stack stuff just to get a big picture on where things were aeons ago, relatively speaking. Then you'll have to read kernel code to come up to speed. Of course the best solution, and probably the most efficient, would be to find some underpaid kernel coder (preferably network stack stuff) and bribe them with beer and pizza. Or you could post a bounty on one of the freelancecoder sites (be careful how you word it, specify how you want it to work and that it must meet openbsd standards, and must not be written in visual basic, php, or .NET). -- "If I could remember the names of these particles, I would have been a botanist" -- Enrico Fermi -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
