Meet the Gang   1   2   3   4   5   6   7   8   9

SQL on the internet

From Fabiano Bonin

Answered By Jim Dennis

I have a Linux box connected to internet, and a NT box in my intranet.

My NT box is running SQL server (port 1433) and i want that people outside can access this port through the Linux port.

Example: - In the SQL Server client, i put the address of my Linux box (real IP) and the connection is forwarded to my local NT box.

Is there some way?

First, please realize that this is a reckless way to expose your database server. If you accomplish this, you will be wholly dependent on the SQL server's own robustness for the integrity of your data.

At first it sounds like you want a port forwarder. With IP Masquerading it's possible for you to "hide" your NT box on an RFC1918 reserved IP address (such as any from the 192.168.0.0/16 block of class C nets) behind a Linux box (which, naturally has both an internal address and some sort of DRIP -- directly routable IP). You'd then configure any of several port forwarding utilities to simply forward packets that arrive on the DRIP TCP port 1433 to the internal NT port 1433.

Normally, the portforwarder would only change the destination IP address. The source (return) address would remain unmodified. Thus the NT box would attempt to route response packets as normal. The Linux box, NATurally would be configured as the default router for the NT box so it's return packets would then be routed appropriately after they arrive at the Linux system.

NATurally, the Linux box must be configured to do routing, usually with a command like:

'echo 1 > /proc/sys/net/ipv4/ip_forward'

... though many distributions may hide the ugly details by offering some friendlier interface.

This all sounds easy enough. However you have also said that you want to configure the MS SQL Server to simply accept addresses that appear to be from the Linux gateway. In the example I gave, the Linux gateway is transparent (more like a router). So the SQLServer connections "appear" to come from some public address on the Internet. Arguably this is what most people would prefer, since they can then configure the SQLServer to selectively allow or deny access to specific blocks of public IP addresses. (Also, it's easier that way).

You could write a proxy. This sort of proxy could be written in PERL, Python, C, Java or just about any language that offers lower-level access than awk and the shell. It would accept connections on the DRIP/interface TCP port 1433, initiate new connections on the internal IP address, and relay the application level data from one to the other and vice versa. It could be blocking (only one connection at a time) or non-blocking (handling multiple concurrent connections). If it was written to be called via inetd, and non-blocking, then one child/proxy process would be started for each connection (and the code would be much simpler, though the latency and overhead would be higher). If it was written to run "standalone" it could use any of several models of threading and/or forking (process spawning) to handle concurrent connections, lower latency and (possibly) lower it's memory footprint.

The disadvantage of writing a proxy is that you might have to know a bit about the application's protocol. In particular it might be that the MS SQL Server networking protocol uses additional "ephemeral" or "negotiated" TCP ports. In other words, there might be traffic on ports other than the TCP 1433 port. I don't know the details.

It's possible that a simple "plug-gw" proxy might work (plug-gw was part of the TIS, Trusted Information Systems, FWTK, firewall toolkit). TIS was eventually absorbed by McAfee Associates (later Network Assoc. Inc). Although the sources are freely available *for non-commercial and internal use*, TIS FWTK is not "free software" (no derivative works, limitations on re-distribution, consultants are not allowed to install it for customers, etc).

However, there are tools like plug-gw. The most notable is probably the Juniper FWTK from Obtuse Systems (http://www.obtuse.com ). That is currently distributed under a BSDish license.

I don't know much about the MS SQL Server or the net/wire protocol that it uses. However, there is a free (GPL) package by David Muse called SQLRelay (http://www.firstworks.com/sqlrelay.html ) which incoporates quite a bit of knowlege about it and various other SQL servers. SQL relay is probably overkill for what you want, but it might give you the information you need, and a small subset of its features might do the trick for you.

This page edited and maintained by the Editors of Linux Gazette Copyright © 2002
Published in issue 74 of Linux Gazette January 2002

HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

Meet the Gang   1   2   3   4   5   6   7   8   9