I'm connecting to a SQL Server instance in a shared environment using SQL Server Management Studio. I don't want to take the hosting service's word so I'd like to find a way to discover whether all communications are encrypted. Especially the password, since it seems from this answer that sometimes it's sent in plaintext and sometimes not (I've been trying to use Microsoft Network Monitor to find out if it's encrypted but haven't been successful yet.)
Even if the password is encrypted, what if someone uses the connection (as a man-in-the-middle) to enter his own data into the database? (I'm more worried about that, though reading from the database is also a problem, of course.)
So, to sum up, how can I force a secure connection or at least discover whether one is present, when I don't have administrator's privileges on the database?
SQL Server client drivers offer the ability to require encryption and also verify that the certificate on the SQL Server comes from a trusted provider. Most drivers for SQL Server (JDBC, ODBC, .NET client, etc) have these settings.
More information can be found here: https://technet.microsoft.com/en-us/library/ms189067(v=sql.105).aspx
Related
I am looking to create a database server that can be used to store data using a VB.net application. When I initially installed SQL Server 2005 Express edition, I believe I installed this using the LocalDB option.
As it stands my application is a simple tool which utilises the Process.Start command under certain situations, depending on user input, to launch Game Servers for use at a gaming LAN I assist in running.
I wish to progress the application by being able to update, delete and query a database created in SQL Server 2005 Express. I understand the use of connection strings etc, however I am wondering if the installation using LocalDB will mean that I cannot connect to the server to process the data I require.
Can I continue to use the LocalDB option and create a Database Server for specific use using my application or is a different installation option required?
Secondly, can someone point me in the right direction of how to create a new Server for this purpose? All of my searches so far have provided results for creating a database only, and not the server.
I have a couple questions about what you are trying to do.
First, why are you installing SQL Server 2005? It was released almost a decade ago.
I would go with 2012 express edition.
http://www.microsoft.com/en-us/download/details.aspx?id=29062
Second, install the management tools. SSMS is a nice GUI to do work in.
Third, If you are spinning up anything other than express, there are licensing costs which are quite high. 9K for standard and 25K for enterprise per socket or such.
Here are the versions and features list from microsoft.
http://technet.microsoft.com/en-us/library/ms144275.aspx
Last but not least, having the express edition on another computer is fine. However, you will have to use a network protocol such as TCP/IP instead of shared memory.
It will take longer to send Tabular Data Stream (TDS) to the other computer versus talking to memory on the same computer.
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/c4f06669-41fd-42e6-b4a9-564cf04ca9f7/how-to-choose-between-shared-memory-named-pipes-tcpip-via?forum=sqlgetstarted
Good luck with your project.
You can use a local instance of SQL Server just fine, if you want to set up a separate server for some reason then you'll need either a 2nd machine on which to install SQL Server, or to spin up a virtual machine. If running Windows 8 (and barring hardware limitations) you have Hyper-V at your fingertips.
This is not a complete answer for you but may give you some things to think about.
First you might want to think about your choice of database. If you don't have a compelling reason for using 2005 you will probably at least want to move to SQL Express 2008.
Second, to answer the part about creating a server... A server is something that serves data. In a general sense a computer configured to be contacted by external machines and respond with data is a server. A web server runs a program like IIS or Apache to respond with web pages. A database server contains a database and allows connections to that database. So as long as you install the database on a computer and configure it to allow external connections, you have your database server.
In MS SQL there are several things that need to be set up to allow a database to accept external connections. One is that the SQL Server Browser service will need to be active. Another is that the database itself will need to be configured to allow external connections (SQL Authentication type probably).
Hope this helps.
Addition:
SQL Remote Connection Configuration
Disclaimer, I don't have SQL Express 2005 installed but I think the settings are found in the same place in 2008. If the info here is not exact to SQL Express 2005, the general terminology used here should be enough to get you headed in the right direction to find the specifics.
While viewing the database in Server Management Studio or Enterprise Manager, right click the database server instance name (the root of the tree) and select properties. There should be a section title Connections and within this section there should be an option "Allow remote connections to this server". Make sure it is checked. The other setting you need in this properties menu is under the security area. There is a radio button for "Windows Authentication Mode" and "SQL Server and Windows Authentication Mode", you want the second that allows both.
The next step you have may be to create a new user, add a password, and connect the user to the database. That will give you the credentials you will use in your database connection string while programming. I usually add new users through the security section of the database then set the User Roles for each database that I need to connect to. It is good practice to limit the permissions to those needed by the application. Typically this is read and write, but sometimes you can get away with just read. The less the better.
I'm currently working on a project that requires connection to a SQL Server 2008 database over a LAN network. I intend using one computer as a server where the database will be on, while the others will connect to the server. I've done a thorough search but couldn't find any material on this. All the examples and materials I've seen seem to skip the topic of database connection over a LAN. Does anyone know how I can do this? I would like to see a simple code showing how this is done (in VB.net since that's the language that I'm using).
Connecting to SQL Server over the network is no different to connecting to SQL Server on your local machine. Simply...
Using Conn As New SqlConnection(connstring)
//Do something here
End Using
For information about your connection string have a look at connectionstrings.com
There are a few gotchas though that have more to do with networking and firewalls than any code you will have to write so before you start make sure you can connect to your server with SQL Server Management Studio or similar. Make sure you SQL Server is configured to allow incoming connections.
Depending on the nature of your application and the number of users this may not be the best archictecture. Make sure you are using windows authentication as you really don't want to be storing SQL Connection Strings with username and passwords in config files on the client machines.
what is the recommendations should i do to prevent anyone from hacking or getting the sql server data base file (MDF File) ?
Note : i use sql server 2005
Some simple recommendations:
Do not expose access to your database server to the internet. It should be behind a firewall that only allows the web server to access it over a particular port (not the default).
Do not allow remote desktop or any other type of similar access from external connections. For internal connections, ensure that the passwords follow some type of policy. For example, require numbers, extended characters, etc.
Keep the database files in the normal data directory for sql server (file security is already set up for you).
Use transparent database encryption: http://msdn.microsoft.com/en-au/magazine/cc163771.aspx#S5 and How to protect the sql server 2005 MDF file
Make sure file sharing is turned off.
Make sure the only people who can access that server are the ones responsible for it.
Read up on sql injection to prevent other access mechanisms.
Use Active Directory security for database user accounts.
Use SSPI for the db connections so that you don't have a username/password stored in your web.config
Make sure that the network connection between your web and database server is encrypted via kerberos.
The same way you would protect any other file on your server.
I'd use a firewall and block every port than isn't needed.
Often in example code for software, I see a connection string eg. mysql://user#localhost
in the configuration file for the software to get access to the database. This seems fine for a test/development server but for production, this seems very insecure. What is the correct way to do this in a production environment?
Your production server should be secured, no random users/people should have access to sensitive files - such as app.config with a connection string in it.
That's pretty much the way it is on a production server as well. While it's a good idea to have the application access the database using an account that is as restricted as possible (e.g., it might not have permission to create or drop tables, schemas, databases, or might even be read-only depending on the application), if someone gains access to the application server they're pretty much going to gain at least that level of access to the database server - even if the authentication to the database is based on "trust" (i.e. some windows types of schemes), the attacker has access to the trusted host.
In past jobs, I've heard considerations of various obfuscation scenarios but ultimately they don't accomplish much.
I have built an application that uses SQL Express 2005 and I want to deploy it, but the problem is that anyone who has SQL Management Studio(or something like that) installed on his computer, can connect to my database and change it.
Is there anyway to prevent end-users from seeing or editing the content of my database, even those with the Administrator privileges?
I guess you're referring to the fact that by default SQL Server installs allow Windows and SQL Server Authentication. If you remove the Windows Authentication mode then users will have to connect via SQL Server authentication.
This from http://support.microsoft.com/kb/247931
SQL Server authentication SQL Server
authentication relies on the internal
user list maintained by the SQL Server
computer. This list does not include
Windows NT users, and is specific to
the SQL Server computer. Users are
created and configured using the SQL
Server Enterprise Manager. To use this
authentication method, perform with
the following steps:
• If you connect
through Open Database Connectivity
(ODBC), in the ODBC Administrator,
choose SQL Server authentication when
you configure the data source.
•In
the ActiveX Data Objects (ADO)
connection string, include the
parameters "UID" and "PWD" when you
use ODBC, and "User ID" and "Password"
when you use the SQLOLEDB provider.
I suppose this is not the answer you hoped for but it is unavoidable that anyone with administrative rights will be able to browse and edit information in the database.
You cannot change this.
Perhaps you could consider WHY you want to prevent this kind of access?
I expect you want to prevent tampering or accidental corruption of the data?
If that is the reason then you can go a long way to prevent corruption by adding constraints to your database. Add foreign key constraints, uniqueness constraints, everything that will help prevent data corruption.
Then an administrator would need to deliberately undo these constraints before they tamper, which would prevent most accidental corruption but of course not prevent malicious vandalism.
If you are concerned about protection of your intellectual property, you could encrypt the programmatic components (stored procedures and views and functions). This kind of encryption is not very strong but prevents casual inspection.
Encryption is added by using the
WITH ENCRYPTION
clause in your CREATE or ALTER statements.