February 22, 2005 at 3:29 pm
My ISP refuses to open port 1433. they claim it is for security reasons, that they would be liable if a client got the slammer virus. In my opinion they aren't liable for their clients lack ablility to install sp3.
Anyway, I cannot use management tools like query analyzer and enterprise manager to do dts's and such...since MS SQL port listener service on the servers i use are configured to use 1433 (they won't change the port # for me).
Is there anything i can do to manage these databases? I am in an area where i cannot switch ISP's. Even if I did, they could decide to block my ports anyway.
Any thoughts appreciated.
.
February 23, 2005 at 12:36 am
Have You tried to get an RDP connection to the server instead, and using the necessesary tools remote?
Regads Ib
February 23, 2005 at 12:57 am
unfortunately, it is a shared server. So, only thing i can use is the web-based enterprise manager and query analyzer. Which is harder to use and doesn't allow me to do DTS's.
.
February 23, 2005 at 3:01 am
There is a tool by Microsoft called SQLWEBADMIN. Look for it in the downloads section de http://www.microsoft.com/sql
You have to install it on the server and allows you to ru scripts and manage objects over http via your browser.
dts is more complicated. What I would suggest is that you save your dts packages as structured storage files in a folder that you share on ftp with proper access security. Anytime you need to maintain a package, you have to download it via ftp and upload it when finished.
HABIB.
February 23, 2005 at 3:21 am
At least threaten to change ISP citing that your organisation cannot function without the relevent port. Might scare them.....I hate it when ISP's think they can control ports, especially when they don't disclose them at the time of signing you up.
Also, have a look at these registry keys on both your machine and the server:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL<instance number>\MSSQLServer\SuperSocketNetLib\Via
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI9.0\LastConnect
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib\Tcp
Each of the keys contain entries for sending and listening ports. The way to do it would be to change the listening port, to say: 3333. And then change the sending ports to match that. Then configure your router/port forwarding to forward port 3333 to the relevent server.
It's a longshot, but I have done something like this before (though not for SQL).
February 23, 2005 at 8:14 am
Um, they are wrong.
SQL Slammer went after the SQL Server listener service which is on udp/1434. This has nothing to do with tcp/1433. Granted, there were a couple of worms that went after the sa account (blank password) on tcp/1433, but none are very prevalent today. So in essence, they CAN open tcp/1433 so long as they block udp/1434. In fact, if they are blocking tcp/1433 but are not blocking udp/1434, they ARE susceptible to slammer and have done little to protect their own infrastructure.
K. Brian Kelley
@kbriankelley
February 23, 2005 at 9:52 am
Consider a VPN
Opening up your SQL over the web without a VPN is a very dangerous thing to do anyhow.
...
-- FORTRAN manual for Xerox Computers --
February 23, 2005 at 2:37 pm
"So in essence, they CAN open tcp/1433 so long as they block udp/1434.
So you're saying if they do this, i can still use server tools like query analyzer and enterprise manager and they would still be protected from slammer? This may be a point i can argue with them.
Grasshopper: The SQL servers i'm connecting to are on shared servers...rented by people who don't have th e money, or it is not cost effective for them to get VPN setup...or get a dedicated server. Some of the databases don't even contain sensitive data.
Thanks
.
February 23, 2005 at 2:42 pm
Correct. Slammer used udp/1434. If there whole basis for blocking tcp/1433 is Slammer then they need to go back and learn about how Slammer works. If they didn't block udp/1434 then they are susceptible and they didn't know it. Merely opening tcp/1433 doesn't do anything for Slammer.
K. Brian Kelley
@kbriankelley
February 24, 2005 at 10:57 am
i currently work remotely and have found it much easier to use a VPN with Remote Desktop Connection to the server. Once you are in, you have full access to the server and whatever client tools are installed. It is much faster and much safer.
March 4, 2005 at 8:52 am
If Terminal services/RDP is not feasible, another possible VPN like approach would be to get an SSH server installed on the "shared" SQL Server (like Vshell, or Cygwin with SSH, or even Services for UNIX). After that you can "port forward" port 1433 via an SSH tunnel that you establish between your client and the server (there are numerous SSH clients; like SecureCRT, Cygwin, Putty, Services for UNIX, etc.).
By tunneling your traffic you do not have to "force" the ISP to change its' policies and you do not have to change the default SQL Server port (even though it is a good idea to do so for a SQL Server that can be accessed directly from the Internet).
March 4, 2005 at 5:18 pm
try port scanning the server and see if any other ports in the vicinity are open. use Nmap for this. use the -P0 (zero) command to not ping scan the ports, but actually try to connect.
here is my thought process. I find it hard to believe that their DBAs would not relocate the ports that SQL listens on. Yeah, they could VPN in, but having another open port affords them the ability to connect to their SQL server remotely, should VPN access be unavailable, in the event that there is an issue that needs attention.
If there are other open ports, say 1496 for example, then use the Client Network Utility and set up an alias to the server that connects on the target port.
Worth a try.
BTW - What ISP ? I bet we would all like to know who they are so we can avoid them, or laugh at them as the case may well be.
March 4, 2005 at 8:29 pm
Whoa. Before port scanning, make sure you're ISP is okay with this (hint, they probably won't be). Port scanning is considered impolite at best and criminal intrusion at worst. BTW, an NMAP port scan, even UDP or SYN Stealth, is detected by most commercial-grade IDS sensors unless you have the scan set to take a very long time.
K. Brian Kelley
@kbriankelley
March 10, 2005 at 11:21 am
Thanks for all the adivce. I am currently travelling in the arctic...but when i get back i will try and hammer all of this out as i really don't have any other ISP options in my area.
The ISP is MTAonline.net out of Wasilla, AK.
hard to avoid when the competition just resells mta's service at $100/mo higher.
thanks again for the info, i will post a follow up.
.
March 16, 2005 at 10:57 pm
So, i informed my ISP that they have blocked 1433 tcp when they really need to block 1434 udp, and they claim that they still won't do anything about it...unless i can show some kinda official documentation from microsoft that shows this information. Or something that is convinicing enough to change their business rule.
Thanks for all the advice
.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply