SQL Server internal network traffic. Is it encrypted?

  • Something I really never thought about and I am in the process of researching this for my boss but thought I'd post in hopes of receiving a quicker response. From my desktop, connecting to a SQL 2000 instance on a server, can someone, internally, intercept and be able to read any of my interactions with the SQL server? Say I issue a simple select from QA and the server returns the recordset to my desktop, is this data encrypted or something similar to prevent "snooping" from occurring? TIA.

    -- You can't be late until you show up.

  • if someone is on your network, they could put in a packet sniffer, and copy packets back and forth from a server to any machine. with some work, they could change that info into something resembling what was sent back and forth.

    if they had the rights to the database, someone could connect with profiler, or create a new trace to track DML statements, and intercept any statements you make...

    but internally on the server itself, it's memory pointers being passed around internally, so only output being directed back to your machine after processing could be intecepted.

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • So with the sniffer, they could intercept packets and potentially see the data or is it more complex than that? This reason this has come up is we are about to go through an audit as our company has to be compliant due to our contracts with our clients and the confidentiality of our data. SSN is obviously a critical piece of this data. I've seen network configuration on the properties page for the SQL servers but when I click on the button, nothing happens. I'm guessing this is due to the install, where all defaults are usually accepted?? I appreciate your respons and apologize for posing additional questions, but as I stated, I really never thought about this from an internal perspective.

    -- You can't be late until you show up.

  • Keep in mind that 2005 introduced into the SQL Native client the ability to have encrypted communications between client and server (simply go into the connection OPtions screen before connecting to set it up). That would prevent any sniffer from being to pick anything up.

    I thought I heard Bryan mention that there was a way to force all connections to be encrypted. Let's hope he can stop on by and weigh in on the matter.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Beautiful as I have just begun the task (tday, actually!) of upgrading to 2005.

    -- You can't be late until you show up.

  • with regards to any code-based connections (i.e. in apps your devs have built), simply switching to the Native client and setting the .Encrypted property of the connection Object to TRUE will turn that on. That's one really easy and nice way to improve your app's security profile if you built it from scratch.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

Viewing 6 posts - 1 through 5 (of 5 total)

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