Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
1  
Maybe ask on security.stackexchange.com –  HTTP500 Sep 8 '11 at 17:01
2  
Perhaps consider using server and client-side SSL certificates with MySQL instead of VPN. See: dev.mysql.com/doc/refman/5.0/en/secure-create-certs.html –  HTTP500 Sep 8 '11 at 17:29
    
Thanks for the link, I hadn't thought of that and it just may be a good option. –  Steve K Sep 8 '11 at 23:58
    
number one attack vector will be injection attacks, so depending on your code you may be somewhat secure. btw in the past I've left a few db servers exposed on the internet as honeypots to see what would happen. The only thing that I did was created a strong pw and used code that was mostly imprevious to sql injection attacks, had lots of attempts but not successful hacks... –  tony roth Sep 9 '11 at 4:35
    
@tony - no web apps, just WinForm and WPF clients with authenticated access by my employees only. So even less of an injection threat. Still, it's possible... –  Steve K Sep 9 '11 at 4:38
show 3 more comments

1 Answer

If it has a port open to the net, it's a target. As simple as that. There is very hostile environment out there, and botnets provide plenty of resources to probe whatever lives on the net.

If you are in a hurry and the current solution is painful, but works, I wouldn't touch it. Give it more thought, research your options and don't act until you know what you are going to implement and why.

share|improve this answer
    
"If you are in a hurry and the current solution is painful, but works, I wouldn't touch it." <- That is sounds advice, thanks. –  Steve K Sep 9 '11 at 4:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.