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

["Ryan Russell" <ryanr () sybase com>]

> 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.

I see your point.  Obviously, I had something like unix in mind as a
full-blown OS, and was making the assumption the others would
have the same thing in mind.  But, since I've taken similar liberties
with the definition of SPF, it's a fair point to make.  I don't
particularly
want to get into trying to define an OS, but what I have been referring
to is some significant set of other functions on the same machine,
i.e. other things it can do besides send and receive IP packets.
I assumed that people running firewalls would want to have a
somewhat full-function OS undernear to perform maintenance-type
functions.

Certaintly a PC booting from the BIOS a write-protected media
into an IP handler with that is it's own OS would be a more
secure machine.  The ruleset could be modified on a seperate
machine, the software compiled, and then burnt onto a bootable
CD.

In terms of declaring your OS your BIOS, and booting unix on top
of it with it's IP stack and calling that a firewall process... that's a
bit too much extra code to be fair I think.  YMMV.

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

> Well, a packet filter is a gizmo that filters packets --- lets some
through,
> blocks others.

Unmodified.

> 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.

But what about implementations that modify them or buffer them?

> 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).

Yes, and they handle it just fine when it straddles multiple packets
because
they can modify application protocols as a stream, much like an AG.

> 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.

The PIX will also strip applets, using (I believe) SPF mechanisms.  Any
Cisco
developers that want to comment?

> A packet filter is deciding whether to let certain packets go by, and
perhaps
> dinking with some of their bits.

Plain PFs, yes.

> 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.

This glosses over all the details of what it means to be an "endpoint."

> To the degree that they're modifying and rewriting packets, they aren't
acting
> as packet filters, they've had other features added on.

Yes, now they are stateful packet filters.

> If you want to do the
> job of an application gateway, then call the result an application
gateway.

So, you're claiming if the result is the same on the wire, then it's
an AG regardless of the mechanism used to accomplish that?
I've tried making that point before in the past... other folks didn't
care for it.

> 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.

I don't claim they're better.  Given the current "state-of-the-art"
SPF-like
products on the market, they're certainly not.  I claim they are equivalent
in capability (in theory) to AGs, and perhaps slightly more so since they
can be run in a different security context on the OS (OS being a full OS
like unix for my purposes) and perhaps have access to a little more
information,
which might be useful.  It may be useful to argue implementation details,
since that's where you'll get a good or bad product.

> 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.

Sort of.  It's intention is to be a firewall and nothing else, but if
there's
a full OS underneath, I maintain that it's easier to compromise the
box, and once that's been done, to leverage it to cause trouble
for inside machines.

> 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.

Two cases:  Either it's a real OS like unix, and it's harder because the
attacker can't use any unix tools on the gateway to attack the inside
machines, because you've ripped the IP stack out of the OS.  If the
OS consists entirely of the firewall process, and it's much easier to
secure because it's a vastly smaller codebase.

> 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?

Of course.  The issue was how much harder, if any, would that be.

                         Ryan