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.
Related
I am in a unique situation where I need to test my server connectivity to Oracle databases however I do not have access to any account or password.
Reason why the connectivity needs to be tested is because many times there are multiple layers of firewalls between my servers and the database, and also particularly recently while trying to access RAC/Exadata databases we realized that doing a telnet on the "scan" IP range (which were the only range visible to me) was not enough and that there are underlying physical/virtual IPs that are actually used to connect which were blocked. If I can test connectivity I can at least confirm the database is accessible.
I thought about connecting using sqlplus test#DB, where "test" account doesn't actually exist. If I get a reply saying that incorrect username/password logon denied, then at least I know the database connectivity is working because at least it reached the database to perform authentication. But I have audit concerns (whether DBAs will think someone is trying to hack the system) and also whether there's an actual way or command to do this test.
like #OldProgrammer pointed out, this is pretty much an optimal case for tnsping from the command line
tnsping MY_SERVICE_NAME
Here's a good post showing the basic options. Oh, and I'm pretty sure the DBA's can still see the traffic if they want to.
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 have a mssql 2005 and software (that written by visual basic 6) and the software connects to the mssql.(local)
but the problem is that the "sa" user password changes every day!
And the company that write this software does not give us the password.
And the windows authentication does not work and I think that they delete the windows user too.
I searched on the msdn and ... that i found in the LAN, packets from clients were encrypted in SSL type and sent to the mssql and in a specific packet it includes the username and password of the db, and if that user&pass is same with db user&pass it can be full access to db.
I used backtrack & metasploit but it use dictionary for attack but it did not help me .
I used wireshark for finding that specific packet , then i think i found it (99% I sure) but that packet has a lot of unclear characters and i could not find those.
do you think that if i use SSLSTRIP to make a fake certificate then use it between client and server (as a gateway) can i get that? How?
can I use single user mode to add any user to mssql? How?
You are totally approaching this from the wrong angle. You have a software package that goes at extra lengths to prevent access to your data. You problem is the vendor, ditch him. Use a different software, one that has a rational vendor behind it.
Here are the MSDN official, approved, methodology to regain access on a SQL Server that had locked out administrators: Connect to SQL Server When System Administrators Are Locked Out
I'm trying to set up mirroring between two sql 2008 databases on different servers in my internal network, as a test run before doing the same thing with two live servers in different locations.
When I actually try and switch the mirroring on the target DB (with
ALTER DATABASE testdb SET PARTNER = N'TCP://myNetworkAddress:5022') I'm getting an error telling me that the server network address can not be reached or does not exist. A little research suggests this is a fairly unhelpful message that pops up due to a number of possible causes, some of which are not directly related to the server existing or otherwise.
So far I've checked and tried the following to solve this problem:
On the target server, I've verified that in SQL Configuration Manager that "Protocols for SQLEXPRESS" (my local installation is labelled SQLEXPRESS for some reason, even though querying SERVERPROPERTY('Edition') reveals that it's 64-bit Enterprise), and Client Protocols for SQL Native Client 10 all have TCP/IP enabled
I'm using a utility program called CurrPorts to verify that there is a TCP/IP port with the same number specified by the mirroring setup (5022) is open and listening on my machine. Netstat verifies that both machines are listening on this port.
I've run SELECT type_desc, port FROM sys.tcp_endpoints; and
SELECT state_desc, role FROM sys.database_mirroring_endpoints to ensure that everything is set up as it should be. The only thing that confused me was the "role" returns 1 .. not entirely sure what that means.
I've tried to prepare the DB correctly. I've taken backups of the database and the log file from the master DB and restored them on the target database with NORESTORE. I've tried turning mirroring on both while leaving them in the NORESTORE state and running an empty RESTORE ... neither seems to make much difference. Just as a test I also tried to mirror an inactive, nearly empty database that I created but that didn't work either.
I've verified that neither server is behind a firewall (they're both on the same network, although on different machines)
I've no idea where to turn next. I've seen these two troubleshooting help pages:
http://msdn.microsoft.com/en-us/library/ms189127.aspx
http://msdn.microsoft.com/en-us/library/aa337361.aspx
And as far as I can tell I've run through all the points to no avail.
One other thing I'm unsure of is the service accounts box in the wizard. For both databases I've been putting in our high-level access account name which should have full admin permissions on the database - I assumed this was the right thing to do.
I'm not sure where to turn next to try and troubleshoot this problem. Suggestions gratefully received.
Cheers,
Matt
I think that SQL Express can only act as a witness server with this SQL feature, you might get better mileage on ServerFault though.
Mike.
Your network settings might be OK. We got quite non-informative error messages in MS SQL - the problem might be an authorization issue and the server still will be saying "network address can not be reached".
By the way, how the authentication is performed? A MSSQL service (on server1) itself must be runned as a valid db user (on server2, and vice versa) in order to make the mirroring work.
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...