My webserver and database server are separate. All I've done to secure the webserver is used ufw and denied from all except ports 22, 80, and 443. What else really needs to be done there?

On my database server, I only allow from ports 22 and the port the database (mysql) listens on. This made me wonder. Usually I just allow all traffic. In the case of a database, I've usually made strict "users" and said things as far as the software goes like "only let user@internal_ip_address access the database". But should this be a firewall thing? Or both? It seems like if the firewall only allows traffic to port 22 and to 3306 from my webserver's internal ip address, that should be good enough? Do you do both just out of "good practice"?

What other general firewall rules should I be setting for these?

  • Don't forget egress (outbound) filtering too to mitigate against reverse proxy exploits. Separate hardware firewalls are a must for this as the host(s) can't always be trusted. – gravyface May 14 '11 at 2:41

That's much, much better than a lot of people!

Some things to focus on, at this point:

  1. Application security. SQL injection, cross-site scripting, directory traversal, etc. Depends what you're running, and if it's not your code it's not something you can be terribly proactive about, but it's probably your biggest surface area.
  2. That MySQL listener: does it really need to be open to the internet at all? Since you've got your users restricted to specific addresses, can you allow just those? What you have is good if you have no users allowed to log in from %, but blocking the listener would be better; some attacks only need to send a crafted packet to a listening socket without authenticating. Can you do the management you need to do via your SSH access? Bringing me to:
  3. SSH. Use public key authentication if at all possible. If not, then use the limit mode in ufw instead of a straight allow to help against brute-force attempts. Changing the listener address to a high port is standard practice for some, but the actual security value of that obscurity is negligible.

Short answer:

Yes. Utilizing all protections methods available is good, and the phrase, "Defense in Depth" describes having multiple layers of protection that overlap.

Less Short Answer:

In the general case, there are 3 things one needs to keep in mind when creating firewall rules:

  1. Audience
  2. Destination ports
  3. Protocol

What we mean by that is that, for a MySQL server, it's not enough to only limit incoming connections to port 3306/tcp, but we must also limit it from the MySQL clients. Ideally, that list of clients would be as small as possible for each port, however in reality sometimes it can be bigger. So think about each of those ports, SSH and web, and determine who actually needs to access those.

If your application includes it's own mechanism to limit scope then use them as well, see Short Answer above. This would include the access restrictions to MySQL of the form user@internal_ip_address mentioned in your question, as well as setting up htaccess (or similar) files in your web server. Of course take the time to weigh the security benefits of using those extra steps versus the management overhead of implementing and maintaining them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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