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

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

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

> Meanwhile, the rest of us will continue using the term as the vendors of
the
> currently-available stateful packet filters --- notably the PIX and the
FW-1
> --- use it, where "SPF" stands for "Stateful Packet Filter", which is to
say
> a packet filter that uses a state table to keep some notes about what
packets
> have been seen in the past, to help decide which packets (or fragments of
> packets) to pass or reject.

That's just it, they don't only do only as you've described.  They also
change packets
as they go by, can strip out java code, etc..I think parts of PIX don't use
state
code to do it's work.

> And when we get a box that analyzes the packet headers with its own IP
stack,
> scrutinizes the traffic with its own application proxies, and then
generates
> new fresh healthy packet streams containing sanitized application
payloads,
> we'll call that an ``Application Gateway'', rather than a ``Ryan Russell
> definition of a proper SPF''. It's shorter, and it seems to be more common
> usage.

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.

> It may be what I'm reading isn't what you are writing, or isn't what
> you're intending to convey. If so, I'm sorry, 'cause I know I hate it when
> other people do that. But what I'm coming away with ends up like ``SPF
> could be implemented with other mechanisms than state tables, could buffer
> as much traffic as necessary to perform application-level analysis, and
> could re-write as much of the headers and payload as necessary to provide
> comparable protection to an application gateway. And since an SPF would be
a
> security-minded rewrite, it might be more secure.''

Ideally.  Some of them do some of those things now.

> I think you've succeeded
> in redefining SPF to the point where it's not a useful word anymore; it
> isn't descriptive of current "SPF" or "SMLI" products, and it disclaims
the
> architectural structure that distinguishes them. What exactly is the goal
of
> this redefinition?

SMLI is a Checkpoint-ism.  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.  I'd be willing to listen
to alternative definitions.  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.

> > 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
> I'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?  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.  Do you run your web servers
as root, or do you try to lock them down a bit more?

> Useful for an IDS system sure, which is why IDS systems use lower-level
> interfaces. I thought we were talking about firewalls? For a firewall, no,
I
> don't care about the lower-level information that gets tossed before my
> proxies can see it, thanks anyway:-).

It's been stated (by others) that IDS's can't be expected to interpret
some types of attempted attacks.  The gateway machine is in
a good position to recognize some of them.  I was thinking more
along the lines of log entries like the ones I get now when
someone fails to connect to something rather than a full-blown
IDS that attempts to identify particular attacks.  I would like to
see something like "malformed packets with xxx statistics
from this IP address" in the logs.   I'm sure you didn't mean to
imply that you aren't insterested in logging failed attempts
against your AG.

                         Ryan