0

We have a VPS that contains a SQL Server Express instance. Using SQL Server Configuration we have enabled TCP/IP to listen on a random port, say 5741. We have disabled sa and created another user with a very complicated username pattern, say HlsvslEWlajxcqpe and also a complicated password.

Is this enough security to access this SQL Server instance from anywhere on the Internet using SQL Server Management Studio?

What security risks do we need to take into consideration to make this instance more secure?

These questions helped a little, but they are different problems:

Compromised server name and port number of a SQL Server DB Server
Online SQL Server database for a Business app. Security considerations
Is sending plaintext passwords to a SQL Server database a security risk?

Saeed Neamati
  • 145
  • 6

2 Answers2

1

"and created another user with a very complicated username pattern, say HlsvslEWlajxcqpe and also a complicated password."

This will mitigate brute force efforts, but won't help you if someone manages to inject code in your application that exposes where these credentials are stored. They will be able to log right in, presumably from anywhere.

For starters, you need to block all access to this port from all hosts except those related to your application.

Ivan
  • 6,288
  • 3
  • 18
  • 22
  • So, what you're saying is that our SQL Server's Machine security **is dependent upon** other servers' security. Well, can't we argue that if an attacker has access to the application server, still has access to DB server? I mean it's simple: attacker => app server, app server => db server, thus attacker => db server. – Saeed Neamati Jun 12 '17 at 16:04
  • Yes, and no. How they access the DB through your app is dependent on the type of attack. If they simply do a directory traversal and get the creds, if there's no public access to that DB then they can't do much with it. But if you allow access from anywhere then they're in. Or, if your app allows privilege escalation then yes they'll have full access to your DB and anything else on that filesystem. You just try windows and doors until you find one that opens... – Ivan Jun 12 '17 at 19:03
1

First a database server is not intended to be directly connected to the wild internet. They are complex applications where optimization is often seen as more important that robustness - after all, they should only be accessed from cooperating systems and not hostile ones.

Second, using a random port sound a bit like obfuscation. The answers of a database application normally allows to identify it pretty soon, so a simple nmap could be enough to disclose the port number.

Finally, it is common to let the security of an account rely only on its password. All unix and unix-like systems have a administrative account named root with id 0. So I do not think that a complex administrative login adds any security.

Best practices simply recommend that network rules (firewalls) only allow access to the database server from the application servers and the production network. It is common to ask admins to use a strongly protected VPN when they need to do administrative tasks from the outside of the computer center.

So my advice it to keep the good old sa account and the well known port, but setup firewalls to only allow access from friendly machines.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • Creating a username that can't be guessed, doubles security through obscurity. Because dictionary and brute-force attacks need to find username first. That's how it adds security. If you know where my house is, then you only need to work on how to open the safe. But if you don't know where I live, then your job gets way harder. Right? – Saeed Neamati Jun 13 '17 at 04:01
  • I truly appreciate your answer, but apart from `nmap` that helped us, other explanations were mostly like `it's better to do so`. Why? We're talking science here, not religion. Why it's better? While we care about best practices we don't want to be limited by them and follow them blindly. – Saeed Neamati Jun 13 '17 at 04:03
  • `a database server is not intended to be directly connected to the wild internet`, who says that and for what possible reasons? Maybe it belongs to older days and now it can be connected just as securely as a web server connects. Maybe we can create something like DF (database firewall) just like WAF. – Saeed Neamati Jun 13 '17 at 04:04
  • @SaeedNeamati: *Maybe it belongs to older days*... I am a rather old man now :-). More seriously, the more complex an application is, the more risks it can contains vulnerability in code. That's the reason why complex web application servers are protected behind simpler proxies in corporate datacenters, and that's the reason why I would never let a database containing sensitive data directly accessible from internet. And still as an old greyed hair man, when I come to security I no longer roll my own but only rely on best practices: *devil hides in the details*. I had been burnt when I tried – Serge Ballesta Jun 13 '17 at 06:06
  • OMG, I never intended to offend and I'm so sorry for the phrases that made this misunderstanding. What I meant by old days was not that you're old of course, I only meant that just like social norms that would be followed without reasoning and doubt and after a while become counter-productive, security measurements might also need to be revised. and the only way to review something and improve it, is by knowin **why**. – Saeed Neamati Jun 13 '17 at 06:18
  • @SaeedNeamati: Obscurity is not bad by itself, *provided you do not rely on it alone to protect your data*. I do not like it because it can give a false security feeling to people not enough used to security. So I always assume that apart from secrets that can easily be changed all other details can have been disclosed. And only rely on 2FA (have + know) when security requirements are high. – Serge Ballesta Jun 13 '17 at 06:20
  • @SaeedNeamati: Ideally, all pieces of code with a large exposition should be carefully reviewed for possible vulnerabilities. I know I cannot do that myself, so I rely on well known open source security softwares having good reputation, because I assume that people better than I at security have reviewed them. It may look like paranoia, but it is said that only truly paranoiac admins have a hope to not be hacked. BTW I have not felt offended :-) – Serge Ballesta Jun 13 '17 at 06:33
  • Even OpenSSL contained a vulnerability caused by an implementation flaw. How could we be sure that SQL server does not suffer from one? – Serge Ballesta Jun 13 '17 at 06:36