Re: Protocol inspection

["Marcus J. Ranum" <mjr () ranum com>]

Darden, Patrick S. wrote:
> 4.  application proxy (SQL proxy that filters out all queries by default except those that match specific criteria, 
> i.e. a SQL whitelist ruleset)
>
> I think if someone did make such a  beastie, it would make waves.

There are a couple products aiming at that space. Basically, it's an SQL
parser with a pass-through. Not suprisingly, most customers wanted to
place it out-of-line first (as a sniffer) to make sure it works - thereby
missing the point completely. I haven't kept a close eye on those
products in the last couple years but I saw one at a trade show years
ago and it was basically a SQL IDS at that point - the poor engineers
at the vendor had spent a year dealing with fast promiscuous packet
capture and TCP reassembly, all of which were useless features for
an in-line device. But fear of "single point of failure" or "performance
degradation" make an in-line SQL screener a tough sell.

An option that few people explore is to devise a simple middleware
layer with a limited set of transaction options. Don't expose full
SQL to the outside world - force the front-end system to render
requests down to an abstraction, then build a transaction system
that can exist behind that which turns abstract transactions into
SQL and returns a result. Doing this is, of course, insanely
hard if you're being overrun with webbie developers who all bought
the latest "how to write a mission critical app using PHP and
MYSQL" book.  It does have the advantage, though, of placing a
control-and-think point in the design cycle. And, of course, you
know what I'm going to say next: forcing there to be an actual
"design cycle" is a big piece of the value of such a system. If
you've just got webbies coding whatever they want against the
database backend, you're going to wind up with an inefficient
site - never mind an insecure one - where every single piece of
state is stuffed into the database and a single page-view results
in a hundred database queries.  Building a database translator
box allows you to do fun things like decide "there is NO option
for 'tell me who all my customers are.'"  Systems like this are
valuable, from a security perspective, because they act as a
natural interlock - "you can do anything you like as long as
it's from this short list of approved options."  And the fact that
someone has to actually write code in order to effectuate a
bad idea makes it less likely the bad idea will happen fast.

Of course if you're asking about this in the context of web
applications, we all know you're in hell. Because web
applications are all about "bad ideas happening fast."

mjr. 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards