Hacker News Reader

Comment by EGreg | Hacker News Reader

How does this work?

Will it affect MySQL databases accessible from the Internet but secured with a long random password?

Don't expose MySQL databases to the internet. Just don't. Stick an API layer in at the very least with key based auth, and only the bare minimum capabilities allowed for the user.

That said, if you'd read the article you'd see that so far only unsecured MongoDB, Elasticsearch and Redis installations are being attacked so far.

Most SAAS db providers provide their database over the internet, but secured with a login/pass. Eg all DB's on Heroku elements marketplace work like this.

You can also usually lock it down by IP address.

Yes, or they provide an internal subnet only accessible to servers from the same tenant. Usually it's double useful because usually this traffic is not charged.

I'm doing my first web project (self-taught), which is the prototype for an offering me and a partner are developing to become a startup. I was about to start deployment (for the first time in my life) this week, but now I'm afraid. It's a flask app. We serve users forms (POST), then I use this input to run calculations on the server through a python script which makes queries to a MySQL db, then I return results to browser my listing a result-array dynamically using a Jinja template. Is this unsecure? Any tip or accessible reading material to help me understand this matter? We don't store credit card info or other sensitive information for now, because we didn't reach any clients yet, but final version should have at least login functionality. Any light/knowledge/consideration will be much appreciated!

PS: I don't know exactly what you mean by "Stick an API layer in at the very least with key based auth" because I never used an API before and didn't know I would need something like this.

It sounds like you are probably fine. Your python flask script is the API layer. Just make sure it can only run sql that you want it to run (ideally, read only until you get it authenticated), and that it escapes user input, and that no one except admins have access to the actual db underneath, and you are totally fine.

Also, for that matter, its a good idea to run backups too, just in case something goes wrong and you need to restore.

This is literally people allowing users to run arbitrary commands on their fully exposed db, and then being surprised when someone runs a delete.

>PS: I don't know exactly what you mean by "Stick an API layer in at the very least with key based auth" because I never used an API before and didn't know I would need something like this

Don't allow access to `mysql -h hostname` from WWW. Instead, keep your MySQL server accessible only by machines you control in the same security group/network/etc. To get access to the database from the public, create an API that allows predefined queries only to users you've authorized. This API would also be hosted within the same security group/network/etc. The public never gets direct access to the database, yet gets the predefined access they need.

Your API, in this case, is basically your Flask application so you're pretty much done.

If you want to run a database securely, you configure a decent password (should be asked during installation), create new users for each application/database (easy with tools like MySQL workbench) and make all applications running on the server (Flask, in this instance) connect to localhost/127.0.0.1. Don't expose services like databases to the outside world if you cannot in any way help it.

Then enable a firewall on your server (Ubuntu server comes with UFW by default) and lastly use a port scanning tool like nmap/zenmap to check if you have left any services other than HTTP(S) exposed.

I don't know much myself about Flask deployments specifically, but you'll probably use something like nginx or Apache to handle the actual web requests. There's an article here [0] on how to do that. After you've done that, you can secure your connections for free through Let's Encrypt clients like certbot [1] which handle most of the configuration for you.

TL;DR:

1. Configure your application to connect to localhost with a secure password

2. Enable a firewall, run "nmap <your domain>" to check if it works (should only expose HTTP(S) and probably SSH if you did it right).

3. Install nginx or Apache to handle requests for you and follow the guide at [1]

[0] https://www.digitalocean.com/community/tutorials/how-to-depl...

[1] https://certbot.eff.org/instructions

"Don't expose MySQL databases to the internet."

Trouble is modern web-development is so dumb they just treat databases as dumb-blackboxes. So hence they end up in situations like this where security is thrown out the window in the name of minimising any obstacles to get data from the database (and no doubt dump it all into a stupid array in the frontend).

This creates a self-perpetuating lore amongst devs that databases are "slow".

But this is largely because they can't be bothered to use the database in the correct manner (correct schema design, sprocs etc. etc.)

And don't get me started on the "portable query" junk ! Sure you can write dumb queries that run on everything from SQLite to Oracle, but its far from being a remotely sensible thing to do.

Rant over. ;)

It's fine to expose MySQL to the internet, but it better before set up securely.. and you better be using the database-level user security.

It's not strictly necessary, as long as there are no known vulnerabilities, and you use sufficiently hard password.

However, it's highly recommended you never expose such services to the public, or at least limit allowed IP ranges.

> as long as there are no known vulnerabilities

That's really not something you should be gambling on. Assume the worst, and architect based on it.

Limit what can be exposed where / how (e.g. as you say, "at least limit allowed IP ranges", but to me that's absolute bare minimum)

That makes any number of assumptions about the API layer, what "key based auth" is used and what data the database has.

For example I'd probably trust MySQL or PostgreSQL key validation more than what some random dev has coded in a private repo (more eyes on the code and probably better developers looking at it).

Auth is something that a lot of devs still do not implement properly and even popular libs for it like passport for node and others (including default configs for most JWT libs) have had very bad security issues.

If your minimum permissions map well onto the databases permission model then it's better to not have a layer in between. Proper db permissions and a using TLS/SSH as a transport is probably better.

No. The bot targets only unsecured Elastic databases, i.e. ones where no credentials are necessary to execute queries.

I don't mean to sound harsh, but if you are asking yourself this question you need security auditing ASAP.

Not at all. There could be some new vulnerabilities in MySQL that make even password-protected databases vulnerable.

As for us, we give access via an SSH tunnel, which requires public keys from certain IPs.

Reply on news.ycombinator.com