Re: Proxy 2.0 secure? (AG vs. SPF)

[Bennett Todd <bet () mordor net>]

1998-07-07-13:38:37 Ryan Russell:
> > So, all I have to do is claim that the ``OS'' on my new hyper-spiffo
> > firewall is that nice tight boot loader in BIOS, and that the
> > OpenBSD+IP-Filter+fwtk I load atop it is just the stateful packet filter,
> > and we've solved the problems with SPF. Cool. But is this a useful advance
> > in the state of the art?
>
> I don't think so... I don't know how IP-filter works, but doesn't it use
> the IP code built-in to OpenBSD?

Well, not really, it more plugs in front of it, but you're missing my point:
you claim the only difference between an ``SPF'' and an ``AG'' is that the
latter uses the IP code built in to the ``OS''. So if we just re-define the
``OS'' to be the bootloader (like on a Windows box running FW-1), and call the
entire thing we want to use the ``SPF application'', then we've achieved the
nirvana you're seeking, without having to actually rewrite an entire OS ---
just rename it, and call something else the ``OS''. It's the functionality
that counts, not the name, hence this approach fails to grab me.

> If it uses it's own IP stack, i.e. allocates sockets from the OS, that's
> what I've been calling an AG the entire time, too.  Well, that plus the
> proxy code on top.

If the difference between stateful packet filters and application gateways
were that the former were rewritten OSes by another name, then I don't think
I'd be interested in them. Actually, I don't find them all that interesting in
most settings anyway:-).

> My definition of SPF is indeed far from what products exist today, and I
> can't defend the existing products as they often leave much to be desired. I
> am trying to get to the basic point about what's different betwwen AGs and
> SPFs.

Your definition seems to reduce to, SPFs don't use OS services for networking
--- which means you've just changed the names entirely, and an OS+proxy suite
taken as a whole and renamed would make a fine SPF according to your
definitions. Doesn't work for me.

> I'd be willing to listen to alternative definitions.

Well, a packet filter is a gizmo that filters packets --- lets some through,
blocks others. A stateful packet filter does the same, with a scratchpad so it
can check to see if connections have been established before deciding whether
or not to pass a given packet. NAT is separately implemented, and requires
rewriting some bits of the header and examining the payload looking for PORT
commands to rewrite (unreliably, because a PORT command could in theory
straddle multiple packets). By contrast an application gateway reassembles the
whole data payload, lets a proxy make judgements about the appropriateness of
the content, perhaps rewrites the payload to e.g. strip applets, then
regenerates the packet stream with brand new packet headers with the fresh
payload.

A packet filter is deciding whether to let certain packets go by, and perhaps
dinking with some of their bits. An application gateway is the endpoints of
two separate conversations; it's a hardened host running proxies, where a
proxy is a server that gets it content by turning around and acting like a
client.

> Thomas' definition excluded the ability to modify packets or buffer packets.
> There are products that do that now, so I don't think that's a reasonable
> limitation.

To the degree that they're modifying and rewriting packets, they aren't acting
as packet filters, they've had other features added on. If you want to do the
job of an application gateway, then call the result an application gateway. If
you think you've got a way better architecture for implementing it than
simple, carefully-written proxies atop a good well-hardened OS like BSDI or
OpenBSD or DG's B2 Unix (Hi there!:-) then by all means, have at it. But
hearing you say ``SPFs are better than application gateways. When I say SPFs,
I don't mean anything like any current product, I mean a rewrite of the entire
functionality of the IP stack plus proxies in some new fashion'' --- somewhow
that fails to capture my enthusiasm.

> > > Wouldn't having the IP stack not effectivly running as root be an
> > > improvement?
>
> > Not that I can see. What would the improvement be? Either way, it's the
> > code that can view the network interfaces and pass traffic on to either
> > side, so it'd be doing the work. And a bug there would leave me vulnerable.
>
> Wouldn't your gateway be a little less vulnerable if the compromised process
> ran with few rights?

Not if the gateway has complete control of the networking. The sole job of the
firewall is to own complete control of the networking, so it can enforce
security policy over the traffic between two or more other networks.

> Yes, your process has full control of the NICs, but hopefully it's a little
> harder for the attacker to do anything with them once he gets ahold of a
> machine whose OS can't talk to the NICs.

Why harder? The process he's just compromised is the one that _does_ talk to
the networks, so what you've really done is let him have the whole OS, which
you've renamed to be something else.

If he compromises your complete-rewrite-of-the-entire-OS's-networking-stack
then he can talk to the machines that the firewall is supposed to be
protecting, and hence has bypassed the protection of the firewall, no?

> Do you run your web servers as root, or do you try to lock them down a bit
> more?

I run 'em as non-root on separate machines, with packet filters restricting
what other machines they can talk with on what ports. Of those protections, I
regard non-root as far the least important, and I mostly make sure of it
because http daemon authors count on that lack of privilege as part of their
internal security design.

-Bennett