Skip to Content.
Sympa Menu

freetds - Re: hints for writing a proxy?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Greg Beeley <gbeeley AT ix.netcom.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: hints for writing a proxy?
  • Date: Tue, 23 Feb 1999 19:59:48 +0000


Hi all,

Brian Bruns wrote:
>
> On Tue, 23 Feb 1999 ark AT eltex.ru wrote:
> > c) What else is worth filtering?
> >
> Have you considered a very basic encapsulation? Reading the first four
> bytes will give you the packet size, so everything inside the packet
> could be considered opaque. You could have the gateway listen on one port
> for each server you are tunneling to, relay that via HTTP (using POST
> let's say) to the reverse gateway on the other side on the firewall, which
> would untunnel and ship in to and fro from the SQL server. It really
> wouldn't need to be all that smart. Of course HTTP 1.1 with persistant
> connections would help greatly (otherwise tracking state is a PITA).
>
> Actually you could even make an apache module to do the HTTP->TDS part,
> though that would probably be overkill.

One very useful thing to do is to monitor the SQL statements sent via the
proxy so that such statements can be limited to, for example, small result-
set select statements and no inserts/updates/deletes/select-into/etc. That
can _help_ prevent, for example, someone from SELECTing your entire database
who shouldn't be able to do that (for example, online address book; you want
people to be able to look up someone based on certain criteria that they
already know, but want to make it very hard for someone to grab the whole
database by entering no or too few criteria into the query form). And, if
you've got a firewall, that's a very good place to put some extra security
assurance for this issue.

I could see the possibility of using the existing FreeTDS code in a modified
form to keep track of the 'state' of the TDS connection. I've looked mostly
at the JDBC driver; anyone have ideas about how easy it would be to pull the
protocol analysis parts of the FreeTDS code out without having to use the
parts of the code which must be 'instructed' on what to do? (i.e., you
can keep track of the status of a proxied result set, but you don't want to
have to tell the TDS code what the query was before it will listen for that
result set).


--------
Greg.Beeley AT LightSys.org




Archive powered by MHonArc 2.6.24.

Top of Page