SQL Server 2000 Remote Login

[user_request]

Does anyone have any clue why remote login via IP would fail after working correctly for SQL Server 2000?

:confused:

[laxbobber]

We are having problems too with our SQL 7 server. It can't connect to other servers on the net and I can't connect to it from my house. This used to work. Does anyone know if ServerBeach has started blocking MSSQL ports or something?

[skoniecki]

Yes... they blocked 1433 and 1434 (Default SQL ports) because of the SQL Slammer again. They said that it will be blocked for a while. You can right-click on the server in Enterprise Manager, though, and then click on Properties. Then, there's a Network Configuration tab. Click on TCP/IP and click on Properties. Specify another port (i.e. 1200). Then hit ok a few times and restart the service.


At home (or on your PC), use the client network library and tell it to connect to the same port over TCP/IP and you'll be all set. Change your foreign connection strings to include the port: i.e.
source=sql.server.com, 1200.

Hope that helps!:rolleyes:

[laxbobber]

I think it is great that SB is taking the proactive measures to protect us all from slammer but why didn't they tell anyone? I wasted SOOO much time on this when, had I been told the ports would be blocked, I could have changed ports and got on with my life.

SB, was this announced and I just missed it somehow? If there is a particular forum and/or mailing list I should be on please let me know!

Thanks...
Bob

[user_request]

Well said Bob. :o

[laxbobber]

Update: after posting that last message I found this in the Network Status forum. It was posted yesterday - 08-01-2003 06:27 PM

RCP Patch for Windows (http://www.serverbeach.com/forums/showthread.php?s=&threadid=156)

So, I guess it was announced...but after the ports were blocked.

:confused:

Anyway, again .... thanks to SB for protecting us but we really need to know about it so we can plan for/around it!

[bagfull]

Getting a mail on these issues will make our life easy... :o

[bagfull]

Change the port of your MS SQL to 1435-37 permanently. This has made life much easier. Who knows when the port needs to be blocked again?

[r1ck]

how do i change port if the enterprise manager is missing. it seems EM didn't come with MSDE installation. i really appreciate your help.

[VxJasonxV]

It sounds like you're having the same problem as myself r1ck.

[Andy Blum]

I understand blocking ports. But what if we had a production application? You need to think about the customers who use your system for production. Can you imagine an in house admin blocking ports that are used by the db and not emailing the dba?

Come on guys, how am I to feel secure that in a month you dont block port 1200 as well.

[knightfoo]

Originally posted by Andy Blum
I understand blocking ports. But what if we had a production application? You need to think about the customers who use your system for production. Can you imagine an in house admin blocking ports that are used by the db and not emailing the dba?

Come on guys, how am I to feel secure that in a month you dont block port 1200 as well.

If you plan on using SQL in a production environment, your first concern should be security, which means you've already implemented a VPN and/or IPSEC to make sure your database connections are secure. Since you are using VPN/IPSEC, the filtering of port 1433 has no affect on your secure, production database connections.

-knightfoo

[Andy Blum]

We have a connection between two SQL Servers I dont care abaout the data being sent wheter that thats secure. Its not sensitive! So your analysis is dead wrong. Why would I want to connect through a VPN from one application to another?

Basically you are saying,

That its ok not to inform customers through an email because you know that if they really cared they would be using a particular solution. Sounds to mee lie you are just defensive because you are wrong.


Your Last Response:
If you plan on using SQL in a production environment, your first concern should be security, which means you've already implemented a VPN and/or IPSEC to make sure your database connections are secure. Since you are using VPN/IPSEC, the filtering of port 1433 has no affect on your secure, production database connections.


quote:
--------------------------------------------------------------------------------
Originally posted by Andy Blum
I understand blocking ports. But what if we had a production application? You need to think about the customers who use your system for production. Can you imagine an in house admin blocking ports that are used by the db and not emailing the dba?

Come on guys, how am I to feel secure that in a month you dont block port 1200 as well.
--------------------------------------------------------------------------------

[knightfoo]

The ports are blocked because of security vulnerabilities related to SQL. We also block the RPC ports related to NetBIOS and Windows messaging services due to the amount of abuse related to these services. All of this has been documented in our forums and if you ask support, they will tell you that the ports are blocked. Nothing is being hidden, we just don't put a banner on the front of the web site that says "WE BLOCK MS SQL PORTS".

Why do we block the ports? To make sure we can provide a fast, reliable network. When the SQL Slammer worm came through, very few of our customer servers were affected. If we could depend on all the administrators on the Internet and our network to practice good security policy, we would not have to filter ports to keep our network free from attacks and worms.

-knightfoo

[Andy Blum]

Its fine that you block ports. In fact, I am impressed with your committment to security. What I have real problems with, is the way you could of cost your customers uncountable dollars by breaking a key component of their site. THereby, depriving them of income.

I only came on to this post because I was curous about port 1433 cause I could not connect. In my case, when we DO go live inabout 3 monts. I have two databases at two differnt locations with replication imn between.

In three months, if you did something on that our site key portions of our might not be usable.

I feel that if a change is made to the configuration of my box, or ports to the network is made. You need to alert me before hand.

You cannot be excpected to understand the ramifications of your decisions. You can't know what your customers are doing. IU am serously suggesting you abandon the "Doing before Informing" attitude when it comes to blocking traffic or changing configuration on our pc's.




In my

[knightfoo]

This really isn't as big of an issue as you are making it out to be. For SQL, all you need to do is change the port that your server uses or implement VPN access between the servers. Changing the port is trivial, both for the client and server.

We do not randomly block ports. The SQL port filter came about immediately after the Slammer worm, so it was no surprise. The other ports we block are related to our AUP .. if someone is trying to use those ports, they are doing something wrong and have no right to complain. If we ever decide to randomly block ports for no apparent reason, we will be sure to let our customers know.

-knightfoo

[QT]

This subject of port blocking has been discussed many times in the past. ServerBeach has responded and explained their policy to each thread created. I see no point in furthering this discussion as it's leading to nowhere, fast.
Thread closed.