[ILUG] Firewall Overhead.

[Smelly Pooh]

In reply to Paul Jakma's flatulent wordings, 
> > That means copying massive chunks of routing code that would usually
> > be done at the IP stack level.  You can fake route in a few firewall
> > packages already, but even when they're kernel firewalls they stress
> > the importance of not doing so because of the massive performance (and
> > possible stability) implications of circumventing the kernel routing.
> 
> indeed.
> 
> so in the more realistic case where the filter just decides policy and
> tells the kernel "to there/yon/bit bucket", then you say that a failure of
> the userspace filter will cause the kernel to forward everything.

Well, that is the realistic case, and the real world case even with kernel
space packet filters.  Think about it, if you were firing up ipchains or some
such on a firewall between 2 networks, wouldn't you still need to enable
ip_forwarding (assuming you're not using ipchains just to block traffic
directly to the server itself), your kernel does the routing.  So assuming
your kernel packet filter went down (even if its default policy was to deny
all packets), your kernel will start routing everything again, you can test
this by compiling your firewall as a kernel module and removing it I guess.
Important thing is that I've never seen this happening to a packet filter
without an explicit rmmod or the kernel going down.  A user space app. would
be more susceptible to going down, in which case the kernel will have to
forward everything unless the user app was doing the forwarding.

On a side note, I guess you can say that application proxies are doing all the
forwarding themselves, seeing as they just copy data coming in on a connection
from one interface, and sent it out on another (even if underneath it all the
kernel routing handles that part), but then again application proxies won't be
handling every single IP packet going through your machine.

> i've never worked with this stuff, you seem to know it better, so:
> 
> a) how do these packet/interfaces work in concept?
> (headers passed to userland for approval/processing? can the app select a
> specific interface/ set of interfaces)

Depends on the implementation, with BPF (the method used by *BSD) install a
filter module in kernel (not module in the usual sense of the word) and that
filter will only return matching packets to the user space program, this means
in kernel you can already filter by device, protocol (IP, NetBios and higher
protocols such as TCP or ARP), addresses, ports and so on (multiple frames are
buffered aswell for extra efficiency)

The linux way as of 2.2 (and this is why it's so bad) is to open a socket from
a program of type SOCK_PACKET, the most you can specify that you want to
receive is a protocol such as IP or ARP and so on.  Now every packet of that
type that passes through your Linux machine (you're in even more trouble if
you're in promiscuous mode) is returned by this socket.  That means every IP
packet is copied from the kernel into userspace and handled by your program,
even if all you want is say TCP port 25.  And every packet you read is a
separate syscall and copy to userspace (BSD buffering means after filtering
the matching packets are still copied in chunks).

Unix Network Programming 2nd edition volume 1 has a decent coverage on this,
including a lot of libpcap stuff (which is the library most people use to
portably access all this stuff).  Now I'm quite certain that Linux 2.4 will
not be userland packetting using this method, but I hope from the above
explanation everybody can tell why anybody who uses Linux seriously for
userland packet handling bitches about it so much.

> b) if the intended application was a secure userland firewall, then
> wouldn't it be possible to make it so that the default kernel behaviour
> was to /not/ forward unless the app approved it? (eg if app is down, then
> no kernel forwarding?)

Well, for starters, that isn't compatible with any existing interface that I
know of (a userland hook to determine yay or nay to packet forwarding).
Assuming that there is such an interface, there is still the abysmal
performance of copying every single packet going through your machine into
userspace, and then having to make a separate syscall to say what to do with
the packet, what to send back to the originator the packet and so on.  We're
looking maybe 2 or 3 times the performance problems that Linux's userland
packet handling already suffers.  If you're thinking about the BSD way of
doing it... well most of that is handled in kernel anyway :)