12

Quick intro: Small company, VERY limited resources. I pretty much do everything including take out the trash.

We've been running an instance of MySQL internally for years and it's worked OK, but I think this is largely just good luck. We have several client computers that are deployed to vendor locations and at times trade shows. These client machines need access to the database. Currently we are facilitating the secured access through a VPN to our network. Our firewall does not have a hole open for MySQL.

The VPN solution is a pain and has it's own security implications. I'm also increasingly nervous about keeping my own MySQL instance online and available. I came across Amazon AWS's RDS service and it sounded PERFECT! However, I ran up against the security group issue right away and realized that I would need to grant full, unlimited access to all IPs due to the fact that I have no control over the IP ranges of the client machines. Trust me on this one, I have no idea what their IPS will be.

I've read that it is a very bad practice to expose a DB to the public and that when you absolutely must do this it's better to deploy a web services API to the DB. It would be nice to do this, but there is no way that I have the time (at this time) to write a web services endpoint for all out applications.

So finally.... my question: What are the threats that we would face by exposing our DB instance to all IPs? We aren't a bank, we aren't a public company - no one even really knows about us so it seems that a targeted attack is unlikely. However I'm completely ignorant of security threats and "what's out there" - are there threats that scan all IP ranges looking for a server to respond, then when it does they attack "just for fun"?

To be clear, I KNOW this is against best practices and I don't need a lecture, I'm looking for real-world advice on the likeliness of attack - if that's possible to determine.

BTW, I found this question and it is related but not exactly what I need. I just wanted to include it so that others don't respond by linking to it. Public Amazon RDS database?

Community
  • 1
Steve K
  • 221
  • 2
  • 5
  • 4
    As Nam noted you will be discovered and then targeted. Computers with nothing better to do make quick work of finding and fingerprinting systems connected to the internet. Don't assume that because you are small and have no advertised assets that you will not be targeted. Expect to be compromised and plan how to recover. Design in loss mitigation so that when you are hacked the atacker only gets part of the database instead of the full database. – this.josh Sep 09 '11 at 08:08
  • The real question is, what is more pain: maintaining a VPN solution (complex), or having an exposed DB server (insecure)? Don't forget to add in the probabilities and risks of a breach in each case. – Piskvor left the building Sep 09 '11 at 12:37
  • @this.josh - your point is noted: I must assume I will be compromised with open ports. VPN isn't sounding so bad any longer... – Steve K Sep 09 '11 at 16:33
  • @SteveK I hate to make your pain worse, but using a VPN doesn't mean you won't be compromised. See: RSA Data Security compromise. Using a VPN makes the probability of being compromised lower. You should have a plan in place to detect and recover from a compromise even if you do use a VPN. That said attackers tend to go for easy targets or targets with known valuable (to the attacker) resources. A hardened system with no incentive for an attacker is about the best state you can be in. – this.josh Sep 09 '11 at 22:50

5 Answers5

9

It sounds like you've got a decent grasp on threats, know that what you're doing now is preferable from a security standpoint, and are facing a cost / benefit analysis. With that in mind, here are some alternate thoughts:

  • Configure MySQL with an SSL frontend. There are some features in MySQL for that, but stunnel may make you less crazy. While client certificates are somewhat ideal, I imagine from your VPN struggles that may not be in the cards.

  • Run MySQL on your machine and configure it to listen to the world and use the iptables (firewall) capability of the system to deny any connections. Create a very simple web service that upon successful authentication will add the source IP to the list of permitted hosts. Every so often you can clear the iptables statistics and remove hosts that don't generate traffic for a few days. Think of it as port knocking with an audit trail.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • Did you mean to say "NOT preferable" because your opening sentence has me scratching me head ;) – Steve K Sep 09 '11 at 03:38
  • I agree that the SSL option seems to be a sure thing I should do. I did some initial research (google) and my head already hurts. I'll keep looking for a high-level guide that explains the strategy and requirements before I dive into the tranches. You port knocking idea is clever, however I'm running consumer black box firewall (Linksys RV802) so I don't have programmatic control. – Steve K Sep 09 '11 at 03:41
  • I was under the impression that your current setup used a VPN, but you were moving to something more open. That's why I said that what you were doing now is preferable -- moving away from ideal. – Jeff Ferland Sep 09 '11 at 05:00
7

Trust me when I say there are scanners running days and nights on the net. When you open your DB up to the public, you'll see all sort of scanning attempts in the server log.

Some examples of blind attacks are SQL Slammer worm specifically targetting MS SQL, LizaMoon a mass SQL injection and SpoolCLL targetting weak passwords in MySQL.

So, if you must expose MySQL, please at least use a different port.

Nam Nguyen
  • 1,450
  • 12
  • 14
  • I will be sure to check the server log regularly. My passwords for the mySQL accounts are all very strong (128bit random generated from KeePass). I left the port to the default because I honestly thought "Oh, it's so obvious to change the port, I'm sure the hackers check all ports" - ha... so I will change the port! Thanks for your answer :) – Steve K Sep 09 '11 at 02:51
  • If you absolutely must go down this route, consider adding port-knocking for access and/or fail2ban – symcbean Sep 09 '11 at 12:09
7

For trade shows, do you HAVE to connect to your live database ? Could you make do with a (recent) copy on a local machine.

The additional risks at a trade show are that you are surrounded by competing companies who would have a commercial interest either in your data or in making your application unavailable (crashing the server). There's also more potential for listening in on the provided network.

Gary
  • 884
  • 7
  • 12
  • This is a good question to ask and we can consider designing in offline support but the current version, the version we are taking to a show in ~4 weeks needs to have internet access. – Steve K Sep 09 '11 at 16:34
2

Could you use an amazon DB but only access it through an ec2 box via a carefully constructed frontend app or possibly even just an ipsec tunnel straight to the ec2 instance?

Steve Dispensa
  • 3,441
  • 16
  • 20
  • I'd love to, that sounds really fun actually but I don't have the time (or budget to hire someone). As I mentioned in my original post I can't afford to deploy an abstraction API to access the DB. – Steve K Sep 09 '11 at 02:52
-1

Databases should never be allowed access by everyone due to some of the following security issues:

  • Direct access to exploit the database server and any vulnerabilities it may have.
  • DDOS/DOS vector (skip the website and go directly to the database).
  • Ability to bypass any application security setup.
  • Little to no audit trail available and out of the box there is little to no auditing in MySQL. So if someone did a dump of your database or did other malicious activities you would only have firewall logs to go by and nothing else.
  • If the data is not being sent encrypted over the internet then your database can be easily compromised for anyone sniffing the network. Then they can use valid credentials to do as they please.
  • Since little to nothing is audited out of the box, everything is bypassed and allowed they could have access for an unknown time and you may never know it.
  • Other sites or applications could use your database to serve the content publicly to the world and allow user's to download the database, run quires, etc.
  • The set maximum resources for the database could be consumed by 3rd parties using your database.
  • No protection against SQL Injection.
  • The MySQL server could be used to get a shell to the server to setup system accounts, delete files, change settings and other malicious activities.
  • The security part of being a System Administrator and Database Administrator has just been removed.
  • Loss of job
ITOps
  • 101
  • 2
  • 2
    -1: A lot of conjecture there (Loss of job, security part removed), and some misrepresentations such as: No protection against SQL Injection, idea that lack of audit out-of-the-box prevents audit, or several threats that could be equally performed via VPN. – Jeff Ferland Sep 09 '11 at 02:52
  • As being the DBA/System administrator you job is to insure security of the Systems. Allowing any ip access is removing a critical part of securing access to the database. From the comment from Steve it sounds like he wants to remove the use of a VPN which reduces the security another layer. If the database was exploited a 3rd party could gain access and make an app to use the database which could be vulnerable to SQL injection. You can be fired for not securing the systems/data you are hired to protect. – ITOps Sep 09 '11 at 02:55
  • A good (and scary) list. A few questions: 1) if they can't determine a set of credentials, then they can't squat on my db, right? 2) If I change to using SSL between my clients and my server that would prevent the (effective) sniffing, correct? 3) Can you execution a SQL injection attack without having a valid connection to the server? I mean... if I gave you the IP and you were so inclined... you couldn't launch an injection attack, could you? – Steve K Sep 09 '11 at 02:55
  • 1
    Using SSL will help prevent ease dropping on the SQL user credentials which by default are transmitted in plain text. If not encrypted all they would need to do is listen to database traffic to see the credentials. With the credentials protected it lowers the possibility of others using credentials of the database in their own application that might have SQL injection flaws. If they do not have those credentials they cannot do anything in terms of SQL, but there is still the possibility of the server being exploited if they used a 0-day exploit. – ITOps Sep 09 '11 at 03:03
  • Remember that my original question was trying to determine the likeliness of an attack. If I address the basic vectors to thwart the lazy attacker, what are the chances that I would be the recipient of a more substantial effort? Risk analysis. – Steve K Sep 09 '11 at 03:05
  • If still using the VPN very low. If you are the target of a SQL Bot medium as many bots are programmed to not stop trying unless they are blocked, but keeping MySQL updated should help reduce this. – ITOps Sep 09 '11 at 03:07
  • @Steve: 1) Normally no. There are historical cases of authentication flaws in MySQL, and unknown bugs may be present. 2) It would prevent passive sniffing, and if you pay attention to the key hash, it would also prevent active sniffing. 3) Correct. An SQL injection attack takes advantage of flaws in an application that is already authorized to connect to the db. Discussions about that have very limited bearing for this topic. – Jeff Ferland Sep 09 '11 at 03:08
  • @ITOps: Security is almost always a trade-off. If he's making an informed decision, sometimes the cost savings is worth the risk. Sometimes you just accept that. – Jeff Ferland Sep 09 '11 at 03:08
  • With the security risks involved, I would advise speaking with your management on this so they are fully informed about what you are wanting to do and how you will be securing it. As normally it is Senior Management that makes the decision on the cost vs risk decisions and the engineers/administrators implement it. – ITOps Sep 09 '11 at 03:23
  • @ITOps - I'm the owner, the IT guy, the lead software engineer, marketing manager, Janitor, etc. - you get the idea ;0) However your point is taken. – Steve K Sep 09 '11 at 03:45
  • @Jeff - appreciate the additional info and responses. If you moonlight or do contract work shoot me a msg. – Steve K Sep 09 '11 at 03:46
  • @Steve twitter is `jbferland`, or you can ping me in this site's chat room: http://chat.stackexchange.com/rooms/151/the-dmz – Jeff Ferland Sep 09 '11 at 05:10