Securing a Simple Linux Server That Holds a MySQL Database

Securing a simple Linux server that holds a MySQL database?

A famous man once said "security is a process, not a product."

So you have a db server that should ONLY listen to one other server for db connections and you have the specific IP for that one other server. There are several layers of restriction you can put in place to accomplish this

1) Firewall

If your MySQL server is fortunate enough to be behind a firewall, you should be able to block out all connections by default and allow only certain connections on certain ports. I'm not sure how you've set up your db server, or whether the other server that wants to access it is on the same LAN or not or whether both machines are just virtual machines. It all depends on where your server is running and what kind of firewall you have, if any.

I often set up servers on Amazon Web Services. They offer security groups that allow you to block all ports by default and then allow access on specific ports from specific IP blocks using CIDR notation. I.e., you grant access in port/IP combination pairs. To let your one server get through, you might allow access on port 3000 to IP address 101.432.xx.xx.

The details will vary depending on your architecture and service provider.

2) IPTables

Linux machines can run a local firewall (i.e., a process that runs on each of your servers itself) called iptables. This is some powerful stuff and it's easy to lock yourself out. There's a brief post here on SO but you have to be careful. It's easy to lock yourself out of your server using IPtables.Keep in mind that you need to permit access on port 22 for all of your servers so that you can login to them. If you can't connect on port 22, you'll never be able to login using ssh again. I always try to take a snapshot of a machine before tinkering with iptables lest I permanently lock myself out.

There is a bit of info here about iptables and MySQL also.

3) MySQL cnf file

MySQL has some configuration options that can limit any db connections to localhost only - i.e., you can prevent any remote machines from connecting. I don't know offhand if any of these options can limit the remote machines by IP address, but it's worth a look.

4) MySQL access control via GRANT, etc.

MySQL allows you very fine-grained control over who can access what in your system. Ideally, you would grant access to information or functions only on a need-to-know basis. In practice, this can be a hassle, but if security is what you want, you'll go the extra mile.

To answer your questions:

1) YES, you should definitely try and limit access to your DB server's MySQL port 3000 -- and also port 22 which is what you use to connect via SSH.

2) Aside from ones mentioned above, your limiting of PHPMyAdmin to only your IP address sounds really smart -- but make sure you don't lock yourself out accidentally. I would also strongly suggest that you disable password access for ssh connections, forcing the use of key-pairs instead.You can find lots of examples on google.

Securing a web server with local MySQL database

If you're using Amazon EC2 then you should make use of their security groups to lock down your MySQL server and ensure that no external access to it is possible.

Application servers have an internal non-routing 10.x type IP that should be used for access control, and any external IPs, like your home network, should be specifically whitelisted if VPN access or SSH tunnelling is not practical, as those two are far easier to secure.

Be absolutely sure that no credentials, configuration files, or keys are stored anywhere in your web root. That is, should you accidentally misconfigure your application server in the worst possible way, with directory indexes turned on and everything, it's not possible to snag anything critical.

You might also want to specifically exclude the downloading of *.inc in case you make a mistake. The idea here is to set up a number of safeguards you'd have to break before things go horribly awry. A single-mistake failure situation is always the result of bad planning.

Above all else, be extremely vigilant about proper SQL escaping to avoid SQL injection bugs as no amount of firewall security on your MySQL server will help you when someone can drive a truck through a mistake in your code and have free reign on the server. It's recommended to thoroughly audit any SQL interfacing code you've written before going live with it.

Be sure to have a proper deployment procedure that uses a version control system. If you ever have an intrusion it's very easy to roll back to a known-good version of the code if you have one. The 1990s style "throw files at server with FTP" deployment approach is hazardous at the best of times and fatal to your business when it goes wrong. Use version control or you're living on borrowed time.

How do I secure a production server after inheriting it from the previous development vendor?

3 simple steps

  1. Backup configurations / source files from HTTP / SQL tables
  2. Reinstall operating system
  3. Follow standard hardening steps on fresh OS

Regardless of who it was, they could have installed any old crap on there (rootkits) that you can't configure away.

Sending secure data from .NET to Linux server using POST?

Some good reads:
There are some really good comments about security.

Is either GET or POST more secure than the other?

how to secure POST method without using SSL?

How secure is a HTTP POST?

Hope this helps.

Is this a secure way of connecting to an SQL server?

Browsers can see the PHP code only if your http server becomes misconfigured. I have seen this happen for example on Apache if the PHP handler directives are removed from the httpd.conf file. Then the code in .php files is delivered to browsers as-is.

A good way to protect your password against that (rare) possibility is to store the password in a config file that is read by your PHP code, and put the config file outside the Apache document root directory.



Related Topics



Leave a reply



Submit