Post reply

Register a Server Over the Internet

  • July 20, 2005 at 1:58 pm

    #165014

    I have a question about something I saw today that is strange to me.

    One of our developers is working with a consultant who is at another location.  This consultant gave him the name of his SQL Server and an login and password for connecting.

    Our developer went into Enterprise Manager and registered the SQL Server just by putting in the name, such as ABC123.SomeName.NET.  He used the SQL login he was given by the consultant.  Now he is able to access the SQL Server just like it is one of our servers inside our network.

    How is this done?  How did him putting in the name of the server allow the system to recognize the SQL Server?  Does this have something to do with a registered domain on the internet?

    Also, how did the consultant set this up to allow the remote registration and connection?

    Thanks,

    hawg

    ----------------------------------------------------------

    01010011010100010100110000100000010100110110010101110010011101100110010101110010
    001000000101001001101111011000110110101101110011

  • July 20, 2005 at 5:06 pm

    #575938

    This is me thinking out loud, but I have done this before with a web hosting company called webhost4life. They support creation of databases and with a sql login, I can connect thru QA using the Servers IP.

    Using Sql Login, the abc123.somename.net resolves to an ip address in the somename.net domain thru DNS.

    So using tcpip, you can connect to the sql server using a sql login, and password, I don't think there is any magic here. I think the Port sql is using is exposed to the internet, which is not a usual practice. and I;m sure its well protected with network hardware.

  • July 20, 2005 at 5:20 pm

    #575943

    To add to that, your consultant would probably have UDP port 1434 exposed to the Internet as well, so that EM on your developer's workstation could "discover" which TCP port your consultant's SQL instance was listening on (probably 1433).  If the consultant didn't have UDP port 1434 exposed then the developer would most probably have had to explicitly state the port when registering.  Eg:

        abc123.somename.net,1433

     

    The consultant's setup sounds a little dangerous, because there are people out there scanning for open ports and eager to launch an attack when they find one.  I hope he's got a strong sa password.

     


    Cheers,
    - Mark

  • July 21, 2005 at 7:07 am

    #576052

    Thanks for the insight.  I had just never seen this before and I was curious.  Everything makes sense.

    Thanks again,

    hawg

    ----------------------------------------------------------

    01010011010100010100110000100000010100110110010101110010011101100110010101110010
    001000000101001001101111011000110110101101110011

  • July 21, 2005 at 9:56 am

    #576136

    For remote Administration I'd rather grant RDP rights to a very limited account and use a non standard port for it

    Cheers!

     


    * Noel

  • July 21, 2005 at 10:10 am

    #576142

    If it's on the default port of 1433 (which it shouldn't be if it's on the Internet), you don't have to have udp/1434 exposed. In any case you don't want udp/1434 exposed if you can help it. Some ISPs even block traffic on udp/1434 because of Slammer.

    K. Brian Kelley
    @kbriankelley

  • July 21, 2005 at 11:34 am

    #576173

    The simplest way to protect SQL in a case such as this would be to use your firewall to limit access to a single IP address for those ports (1433, 1434).  That way, slammer scanners would be blocked, but the authorized people would be able to work normally.

     

    So long, and thanks for all the fish,

    Russell Shilling, MCDBA, MCSA 2K3, MCSE 2K3

  • July 21, 2005 at 11:57 am

    #576180

    If you can guarantee they're coming in on a certain IP or set of IPs. A lot of times that can't be done with consultants who are using standard ISPs.

    Also, then you are relying entirely on the firewall to keep you safe. You're relying on a single point of failure. Not good, especially when talking about exposure to the Internet. ACLs have been screwed up before and they'll get screwed up again. If you intentionally block udp/1434, say with an IPSEC policy and tell SQL Server to listen on a different port, you've done a defense in depth strategy... always a good thing.

    K. Brian Kelley
    @kbriankelley

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply