I guess everything is possible but I am wondering how easy is it for someone to hijack a connection string with a network packet analyzer or equivalent tool.
A winforms application fetches data directly from an MSSQL server.
(Supposing there are no webservices in the middle for extra protection)
1) Is it possible for someone with an analyzer to read the connection string as clear text?
2) The connection string could be protected with an SSL certificate?
3) The SSL certificate should be installed on the SQL server?
4) I already own an SSL certificate https Could I install it also for the SQL server?
5) The speed of the the return data, will be reduced due to SSL?
Thanks in advance
Yes. If they're on the same network as the packet sniffer (henceforth "the sniffer") and the connection string is in plain text it's easy. Using a switch instead of a hub will not make it any harder to do this.
still possible using a man-in-the-middle attack. Channel binding is designed to detect and prevent this, along with careful examination of the certificate received by the client. Client certificates would help strengthen this as well
yes it should
as long as the host name matches the sql server exactly it should work, otherwise you'll need a new cert.
it probably will reduce the speed but not by much. Benchmark it and see if the slowdown still gives acceptable performance; there's no other way to predict the impact with any degree of reliability.
One other thing: if the connection string is encrypted I can still analyze the packet to find your server's location and if the data being passed back and forth isn't encrypted I can still read it even if I can't connect to the sql server. I can also potentially modify it. This is why it's unusual for a SQL connection to exist over the internet and why it's usually either connecting to a DB on the same server, connecting via a local network, connecting via a VPN, or encrypting the whole data stream.
If it isn't encrypted, it can be read, yes. Note that the SQL Native Client may often perform a non-SSL based encryption (depending on lots of factors), but yes, it can also be encrypted with SSL; see technet. And yes, it slows things down slightly. The requirements for the certificate are all in the technet article. But please don't expose your db server to the internet...
Related
I'm currently learning the basics of cloud computing, and have been trying to set up and access a small database using AWS RDS. I followed this video, and have followed it word for word. But when trying to connect to the db, I get a connection error.
I initially tried this with a PostgreSQL db, but have since remade and trying with another DB provider to see if that was the issue.
The DB is set to be publicly accessible.
I've checked/rechecked master user/password, and have even reset the password just in case
I've edited inbound rules to allow ALL inbound TCP Ipv4 and Ipv6 (not good practice but just trying to get access from anything)
I've written the endpoint by hand just in case there was trailing whitespace or a sneaky \n somewhere in it
I'm honestly at a complete loss of what to check next. I'm assuming there is a setting somewhere I'm missing, being new to this topic, so any help would be greatly appreciated.
I'd like to log all SQL that a client app is sending to a remote SQL server I have no access to. I'm thinking of some kind of client side proxy that can log and pass through data. It has to run on the same machine as the client app.
Any ideas appreciated.
SQL Server's protocol, TDS ("Tabular Data Stream") is not encrypted by default, so a trivial packet-forwarder could be used to proxy SQL Server connections and intercept commands (and their responses).
The TDS protocol specification is available from Microsoft's website, you could write your own proxy which can intercept commands that way: https://msdn.microsoft.com/en-us/library/dd304523.aspx?f=255&MSPPError=-2147217396
However, this is a large undertaking. You have other simpler options if you don't need to capture every connection:
If you control your application's source-code, then simply modify all database operations to intercept every SqlCommand's CommandText and Parameter values.
You could skip writing a proxy and instead use native packet-capture, you'll need to use WinPCap: https://www.winpcap.org/
You could also use SQL Server's Profiling features to get a log of every command executed: What are the APIs used by SQL Profiler?
What you are looking is called an SQL Profiler.
In specific - you are looking for an API for one.
I have never used an API of a profiler myself - but this one looks promising.
Also - take a look at this question for another sample.
If you want to have an impression of a working profiler client you can take a look at this answer.
I need a way to identify whether a given port at a given address is running an instance of Microsoft SQL Server, IBM DB2 Server, or neither, from Python.
My first thought is that I can use Python's telnet library, telnetlib, like this:
import telnetlib
import socket
def checkDBServerType(address, port):
try:
tn = telnetlib.Telnet(address, port)
except socket.error:
return None
tn.write(<something>)
if <something-else> in tn.read_eager():
return "MSSQL"
else:
return "IBMDB2"
The issue is, I have no idea what to send. The user will also be providing my program with a username, password, and database name, so those are also available if that helps.
Also, this is my first post on ServerFault although I've used StackOverflow regularly and SuperUser sometimes. Is this the proper venue for my question, or would it be more appropriate on StackOverflow? (I can't decide if server admin type people or programmer type people would be more likely to be able to help.)
Since you're just looking for a heuristic, I'd say that merely being able to connect to the default port would be a good first cut. So, for instance, if you can connect to TCP 1433, you can reasonably say that that machine is running a default instance of SQL Server. It's not perfect of course (i.e. you could get false positives or false negatives), but it's pretty good. Only you can answer whether it's good enough for you.
You can't simply "talk" to a database server and expect it to tell you what kind of software it's running; there is no standard common protocol to connect to database servers, and although the query language (SQL) is quite standardized, the underlying connection is based on a protocol which is specific to each database system; these protocols are also generally not text-based, thus you can't simply open a socket to a database server and write something on it; also, they are usually never used directly by client applications: every DBMS provides a set of connection libraries which neatly encapsulate them, so that you don't have to understand how to talk to the database server and can focus on actually querying its data.
Your best bet would be to grab the client connection libraries for SQL Server and DB2 and ask each of them to connect to the remote server; whetever one succeeds first will tell you what kind of server is sitting on the remote end.
I recently made a small app for a friend and then made it a public app, in doing so I forgot that it connects to my MS SQL DB and checks for values. Someone used Red Gate .Net Reflector to get my password and destroy it all. I've contacted their ISP and they are looking into it, apparently this person has a static ip with them.
So this is a lesson learned at a heavy price for me. How can I prevent this from happening again? How can I get away from the unsafe connection string they were able to use?
Never hard code connection strings. Use the configuration section provided for it (connectionStrings), and if really paranoid, encrypt it.
If you are using a shared database, you should not even have a connection string on the client, but create a service point (for example a webservice) that will connect to the database on their behalf. The client can connect to this and your connection string is safe behind your service, which is in your control and on your server.
Don't expose a database connection, but have your app communicate through a webservice, or similar, that only has methods and privileges, to do what the app needs.
If you absolutely need the database connection, make sure the user only has read permissions on the database.
Encrypting the connection string is a start, but your program will have to know how to decrypt it for it to be useful. If your program can decrypt it, an attacker will also be able to - you can only affect the amount of work he needs to put in it.
Therefore, in my opinion, you should expose a read-only service.
If it's a public app, you need to provide individual logins for each user or have a proxy sitting between the database and the application which authenticates the users and talks to the database.
Encrypting the connection string wouldn't help much, I think it can be easily decrypted with built-in tools or with Crack.net.
If you're suuuper paranoid, prompt the sysadmin for the password each time the application starts (maybe an admin interface.) That way it's only memory resident.
I love this question. Like driis said, even with encrypted connection strings you need to store a password (or key, or whatever) to decrypt your encrypted connection string. Just more layers of the same problem.
Using connection strings and encrypted sections in you config will won't stop this type of attack, it's only designed to make the config file unreadable on a machine other than which it is installed.
The only safe way is to create a web service that connects to your database to retrieve the data, and then make sure that the web service logon only has the minimum permissons required, or force the user of the web service to logon and them impersonate that user for the database connection.
It appears you don't have firewall protection to stop external connections directly to your database so I wonder what other even more dangerous ports you may have exposed to the internet???
Using a firewall to limit access to your server to http, and https protocols would reduce the chances of a successful attack.
I've got a SQL Server 2000 box that I'd like to put on "the Internet" so that developers could connect remotely without VPN access.
What's the safest way to do so? It might be temporary, e.g. every once in a while, but it's definitely necessary.
Thanks,
Rob
Short answer - don't do this.
Long answer:
Install good firewall on the box.
Install and run ssh server on it.
Open only the ssh port.
Your devs can use PuTTY or any other ssh client to "tunnel" the sql port over the ssh connection.
The SAFE thing to do is put it behind a VPN.
Seriously, why would you even consider such a risk?
Read DannySmurf's answer. If security threat is not your highest concern, then try LogMeIn at least.
First option, I agree, "don't".
Second option, create a web front end on the exposed box and leave sql non-exposed.
Third option, if you must expose the sql box then mandate asymetric key encryption with all clients, deny all other connections, log clients and review connectivity logs with alerts for clients not matching allowed connection specs (stored in an encrypted table on an internally non-exposed server). Be prepared for some enlightening hacker techniques sure to surprise.
-Alek
I accidentally left an SQl Server (port 1433) open on the net for a while, and once I realized it, I was getting something like 100,000 hits per hour with some sort of automated programs (coming from an army of IP's I believe), trying to break into the server.
Luckily I used very long and complicated passwords...and don't believe I was ever compromised.