locked
Resolving SQL vulnerabilities : Block SQL Server from outside RRS feed

  • Question

  • Hi folks,

    Just very new to SQL Server, and have need help on below security violations. For these, is there anything we can configure on SQL side ?? Or some at network or OS side ?? Please help me.

    1. Microsoft's SQL TCP/IP Listener SQL servers
    Host(s) affected:
    10.xxx.xx.xx : ms-sql-s (1433/tcp)
    10.xxx.xx.xx : ms-sql-s (1433/tcp)
    10.xxx.xx.xx : unknown (49464/tcp)
    The remote host is running MSSQL, a database server from Microsoft. It is possible to extract the version number of the
    remote installation from the server pre-login response.

    Impact:
    Attackers can gain critical information about the host.
    Possible Solution:
    Block access to the SQL server from the outside.
    CVSS:
    AV:L/AC:L/Au:NR/C:P/I:P/A:P/B:N
    CVE:
    CVE-1999-0652

    Friday, May 10, 2013 3:21 PM

All replies

  • Hi folks,

    Just very new to SQL Server, and have need help on below security violations. For these, is there anything we can configure on SQL side ?? Or some at network or OS side ?? Please help me.

    1. Microsoft's SQL TCP/IP Listener SQL servers
    Host(s) affected:
    10.xxx.xx.xx : ms-sql-s (1433/tcp)
    10.xxx.xx.xx : ms-sql-s (1433/tcp)
    10.xxx.xx.xx : unknown (49464/tcp)
    The remote host is running MSSQL, a database server from Microsoft. It is possible to extract the version number of the
    remote installation from the server pre-login response.

    Impact:
    Attackers can gain critical information about the host.
    Possible Solution:
    Block access to the SQL server from the outside.
    CVSS:
    AV:L/AC:L/Au:NR/C:P/I:P/A:P/B:N
    CVE:
    CVE-1999-0652

    • Moved by Kalman Toth Friday, May 10, 2013 7:51 PM Not db design
    • Merged by Fanny Liu Tuesday, May 14, 2013 10:02 AM duplicate
    Friday, May 10, 2013 2:35 PM
  • You are posting to the database design forum, but your question is not relevent to the topic.  Try posting to the security forum - or perhaps asking your network administrator. 

    Friday, May 10, 2013 2:59 PM
  • Is this vulnerability still valid?

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0652


    Thanks & Regards RAJUKIRAN L Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers.

    Friday, May 10, 2013 4:33 PM
  • So, you mean it is no more a vulnerability ??
    Friday, May 10, 2013 4:38 PM
  • Well, you should certainly not expose SQL Server on the Internet, and if you do, you should put it outside your firewall in DMZ and take other precautions.

    Then again, this report lists addresses in 10.*.*.* and since these are private addresses, I would take this as the server is only exposed inside your organiation.


    Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
    Friday, May 10, 2013 6:11 PM
  • So, could please tell me, what configuration I must do from SQL Server as DBA, to prevent from this. Or any changes which needs to be done at any other level ?
    Friday, May 10, 2013 6:59 PM
  • There are a couple of ways

    • Disable the sa login (it is disabled by defauly but make sure it really is) and configure with complex password
    • Limit accounts with sysadmin privileges
    • Use very complex passphrase for SQL Server logins that have sysadmin privileges
    • Work with your network engineers to only allow traffic to SQL Server from the application servers and a handful of management servers
    • Avoid using SQL Server logins with sysadmin rights in your application connection string
    • Disable unnecessary services in Windows
    • Regularly run the SQL Server Best Practices Analyzer

    I'm sure others can still add on to this list. If you really want your SQL Server to be secured, Install SQL Server 2012 on Windows Server Core. 


    Edwin Sarmiento SQL Server MVP
    Blog | Twitter | LinkedIn

    • Proposed as answer by Uri DimantMVP Sunday, May 12, 2013 6:47 AM
    Friday, May 10, 2013 7:11 PM
  • To add some more.

    1) Hide your instance (disabled by default)

    2) Change your default ports

    3) Disable named pipes (enabled by default)

    4) Force encryption on traffic (traffic is by default not encrypted only login information)

    Saturday, May 11, 2013 2:35 AM
  • Do you have a firewall on the network blocking external access to the network?  Is SQL Server behind this firewall?  Where is the attacker in this scenario trying to access the SQL Server from?

    Jason Strate | http://jasonstrate.com | http://www.twitter.com/stratesql

    Saturday, May 11, 2013 5:15 PM
  • See all the links below about it!

    http://msdn.microsoft.com/en-us/library/ms144228.aspx

    http://msdn.microsoft.com/en-us/library/bb283235.aspx

    http://msdn.microsoft.com/en-us/library/ms174937.aspx


    André CR / Helped? If the answer is yes mark! If the answer is no, wait a little bit because i'll back! Visit my blog! sqlmagu.blogspot.com.br

    Monday, May 13, 2013 1:43 PM
  • So, I should freeze this are only options from SQL Server side ??

    Jay N Shah

    Monday, May 13, 2013 2:55 PM
  • yes, we do have firewall, but if attackers connect directly using sql server authentication then ??

    Could yu help me with Preventive actions other than hide instance, force encryption ??


    Jay N Shah

    Monday, May 13, 2013 7:52 PM
  • If the SQL Server is behind the firewall, then there isn't anything additional that needs to occur, when concerned with outside attackers.  As long as they are unable to break through the firewall, the SQL Server instance should be safe.  

    Now if the IP/ports have been opened on the firewall to allow external connections to the SQL Server, I would recommend reviewing the application architecture to understand why it is needed.  Then change the architecture and close the IP/ports from external access.

    If external access is required, look to see if instead VPN can be used.  And if not, can your network team limit the external IP addresses that are allowed to connect.

    HTH


    Jason Strate | http://jasonstrate.com | http://www.twitter.com/stratesql

    Monday, May 13, 2013 8:07 PM
  • Jay,

    I reread your post and I believe you are talking about the PRELOGIN message (http://msdn.microsoft.com/en-us/library/dd357559.aspx).

    Excerpt:

    PL_OPTION_TOKEN

    Value

    Description

    VERSION

    0x00

    PL_OPTION_DATA = UL_VERSION
                     US_SUBBUILD
    

    UL_VERSION is represented in network byte order (big-endian).

    The server SHOULD use the VERSION sent by the client to the server. The client SHOULD use the version returned from the server to determine which features are enabled or disabled. The client SHOULD do this only if it is known that this feature is supported by that version of the database.<9>

    ...

    PL_OPTION_TOKEN VERSION is a required token, and it MUST be the first token sent as part of PRELOGIN. If this is not the case, the connection is closed by the server.

    So it appears that the protocol requires the version information to be posted. Going back to Erland's post, where was this threat assessment done? I know certain entities will use a zone system that might be composed up to 4-5 zones each with protected access from another.

    If you can give us more details about your zone setup and which zone the threat assessment was performed in and where the SQL Server instances are we might be able to help more.

    In terms of other options the only way you can mitigate this risk is by controlling which servers the SQL Server can establish connections to and from using the network layer.  

    • Edited by HITgrunt Tuesday, May 14, 2013 1:39 AM
    Tuesday, May 14, 2013 1:35 AM
  • If we force encrytion on server side, do we need to perform any more steps except turing on encryption

    Jay N Shah

    Tuesday, May 14, 2013 4:45 PM