Re: How do I have my app connect to a remote SQL Server that has port 1433 closed?

From: Alan Silver (alan-silver_at_nospam.thanx)
Date: 03/22/05 

Date: Tue, 22 Mar 2005 14:28:00 +0000

>I may be missing some details somewhere but here are a few
>thoughts/questions:

Thanks, I have commented below...

>1. If you are running a web based application, why not make it a real thin
>web client and have the relevant connection info/code reside on the web
>server that's protected behind your ISP's firewall? That way, clients point
>to the web server and interact only with the web server. SQL Server access
>is controlled by the web server and is invisible to your clients.

I have web sites that run from databases. In order to allow the web site
owners access to modify the databases, I have admin applications that
install on their PCs. At the moment, those applications use a straight
connection to port 1433 on the server.

If I understand you correctly, you are suggesting moving to a web-based
admin. Apart from the amount of work required to rewrite the
applications, this also gives the added problem of extra pages on the
site that I don't want anyone (other than the site owners) to see.

>2. Having SQL Server's connection info hidden/encoded in the client
>application hoping that nobody will ever know it exists is pretty naive. It
>may deter the average user but even script kiddies can figure out ways to
>capture the URL information. Just looking at the outgoing stream at the
>proxy server or turning on the sniffer will probably do the trick.

Yup, that was my thought, which is why I posted the question here
looking for a better answer.

It's worth pointing out that the client app is not freely available, it
is only supplied to customers, so it's not as much of a problem as it
would be in other cases. Not that this removes the worry about people
hacking the app, but it is a slight mitigating factor.

Also, having the info encoded in the client app is no worse than having
port 1433 open. They still have to find a uid and password. At least
with the URL approach I mentioned, they need to figure out the URL, then
figure out the parameters to send, then figure out the values to use,
then find the Windows uid and password for the page. That's a lot more
effort than simply bashing port 1433 with combinations of uid and
password.

>Btw, you can configure the default port to talk to from the Client Network
>Utility. Just highlight TCP/IP and click on the Properties button.

Surely that wouldn't really help. I imagine people looking for ways in
to a server will just probe all ports and see if they get a response.
Changing port wouldn't stop them for many picoseconds ;-)

Thanks for the reply, any further thoughts appreciated.

>"Alan Silver" <alan-silver@nospam.thanx> wrote in message
>news:gRxjBXJ5YuPCFwup@nospamthankyou.spam...
>> Hello,
>>
>> I have a few applications that connect directly to a remote SQL Server,
>> mainly (but not only) so that web site owners can update the databases
>> that run their web sites.
>>
>> The people that maintain the web/SQL server have now said (quite sensibly)
>> that they want to close port 1433 as it is a security risk. I would like
>> to know how my client applications are supposed to interact with the SQL
>> Server if they don't use port 1433. The ISP told me that this server is
>> the only one they have that has the port open, but they wouldn't tell me
>> how to do the data access - well, they would, but they want consultancy
>> rates for it!!
>>
>> So, anyone any suggestions? The ISP's only suggestion was to have a
>> private ASP on one of the web sites, that you send the connection details
>> and SQL, and it returns a recordset as XML. The client applications could
>> open the recordset from the URL. They did say that they would put Windows
>> security on the page, so anyone trying to get at it would need a UID and
>> password, and that the actual URL should be encoded in the client
>> application so no-one would ever know it exists, but it still sounds like
>> a major security hole to me. I'm sure there are better ways of doing this.
>>
>> I'm sure plenty of people have found a secure way around this, but my
>> searches haven't turned up anything helpful.
>>
>> Anyone any suggestions? TIA.
>>
>> --
>> Alan Silver
>> (anything added below this line is nothing to do with me)
>
> 

-- 
Alan Silver
(anything added below this line is nothing to do with me)

Relevant Pages

  • Re: Unable to print to networked printer - get access denied messa
    ... Check the permissions on the server assuming the client has a true RPC ... How is the Standard TCP/IP port configured for the device? ...
    (microsoft.public.windowsxp.print_fax)
  • Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)
    ... That's the problem tunneling (port forwarding) solves. ... >>can't get past the client firewall. ... > I don't understand why the server would be making the ... server initiates another connection to the client -- in this ...
    (Debian-User)
  • Re: Remote Connection Issue
    ... through port number 3389 and a workstation on the LAN through port number ... I understand that you want to allow a LAN client ... and you have configured server publishing rule ... > By default Terminal Server and Windows 2000 Terminal Services uses TCP ...
    (microsoft.public.windows.server.sbs)
  • Re: RealVNC
    ... Default listening port for RealVNC server that runs on the machine on which ... Then there is default Java listening port on port 5800 on the client machine ...
    (microsoft.public.windows.server.sbs)
  • Re: Redirecting data sent to a local printer to another host and port on the network
    ... All client workstations have access to the ... simply redirecting netcat traffic on port 9100 to port 515 on ... Only LPR clients talk to LPD print server daemons. ... >workstation at the branch site where the print job originated. ...
    (comp.unix.sco.misc)