Linux web server best practices - recommendations, please?
 

Hi all,

I've got a couple of development web servers running Debian 5.0.8. They all work perfectly fine and run MySQL 5.0.51a-24+lenny5, PHP 5.2.6-1+lenny10 and Apache 2. I'm not a Linux expert by any stretch of the imagination so I hope these versions are OK.

Anyway, I'm considering running a couple of my production sites using Media Temple's (ve) servers - they're basically servers that you have to setup yourself, including configuring LAMP. I know I can do this but I'm not sure I can do it to a standard that's appropriate for a public web server.

I've looked for info about the best practices for this sort of thing and there's so much info I'm having some trouble making sense of it, plus a lot of it seems to be opinion-based and not a lot of fact.

Can anyone help a Linux n00b with any pointers on how to setup a LAMP server that's suitable for public website hosting? Assume for now that SQL injections aren't an issue - that's beyond the scope of this question.

I'm happy to consider changing from Debian to another distribution if that's a popular recommendation. Ubuntu maybe?

Thanks to anyone that can help. :)

Since you have already done research let's try it the other way around: show us a list of actions you propose to perform and we'll add to that. Deal?


Hmm. If you indicate you are not that knowledgeable wrt configuring a server then what knowledge allows you to determine something is out of scope, I wonder?..

Thanks for the response. It's a long answer so I'll just list everything. I've only only built a couple of Debian servers in the past and none of them have been intended for production use in any way. All I did in those cases was install Debian, make sure the source lists are up-to-date and make sure the appropriate shell access is available via SSH. I don't use root unless I'm installing a package and even then maybe I should be using sudo? The dev servers also run cacti although (mt) has reports on system resource usage so I don't imagine that would be required on the prod boxes.

Anyway, after that I installed Apache and PHP5 using this:

apt-get install apache2 php5 libapache2-mod-php5

That got the web server running to the point where <?php echo phpinfo(); ?> would work and show me that PHP is working. After that I installed MySQL using this:

apt-get install mysql-server mysql-client php5-mysql

After that, I installed phpMyAdmin using this:

apt-get install phpmyadmin

That got phpMyAdmin working but I don't really like it in the default location so I generally move it to /var/www/phpmyadmin and configure an appropriate Apache alias (right terminology?) for it so it's separate from all other websites. Since these are dev servers I also granted remote access to MySQL by changing the bind address in /etc/mysql/my.cnf (which I believe would be /etc/my.cnf on some other distributions). That wouldn't be required on the production ones.

I also installed ProFTPd so that I can upload, update and manage the websites via FTP. I'm used to managing sites by FTP but I've heard people say that it's better to do this via SSH file transfer?

The .htaccess files for phpMyAdmin etc are also configured so that username/password authentication is required before you even get to the phpMyAdmin login prompt.

My existing Debian instances came with Samba and NFS running - I assume that's because of the installation type I selected. They won't be needed on the production servers so I won't be installing them, although I will check that they're not running before anything public gets switched on.

"apt-get upgrade" and "apt-get autoclean" were also run to clean up package files that are no longer required.

I used this page to get some of those commands:

http://www.howtoforge.com/ubuntu_debian_lamp_server

Now, what I *don't* know anything about is iptables as all my Linux experience has been in development environments where firewall protection hasn't been required. I'm all but 100% certain that it'll be required for these servers. I'm yet to begin my research into configuring that.

Go easy on me dude - I'm still learning (aren't we all?). However, to answer your statement ... I'm saying it's out of scope as I'm also developing the applications that will run on these hosts and already make very sure that the appropriate parameters are passed to PDO when running SQL queries so that SQL injections are difficult. If there is something I missed by saying it's out of scope, please feel free to enlighten me.

Sorry for the long-winded reply but hey, you asked for everything I plan to do. ;-)

Debian + ispCP Omega

I'm not really proposing getting involved in the meat of this thread, but I will pick up on this one point:

• for a server, any server, you'll want to use a distro that has a reasonable period of time for which security fixes are made available. That is just a very pragmatic consideration of how often you want to take the pain involved in an upgrade/re-install.

That said, I would not suggest that you swap from any one distro to any other in a hunt after some magic floobydust that will give you security. There are differences (speed of security updates, for example) but the 'Distro 1 is secure, Distro 2 is insecure' approach is largely illusory. It is more about whether you understand the threats and the countermeasures, and whether you can implement what you need to implement on what is in front of you.

You want to learn it yourself (rather than hoping that your distro, which is put together with a very general set of users in mind, rather than your specific use case, does something that gets you off the hook), and then you will be able to cope with security on any distro; if you don't, you won't be able to cope with any distro. And, you are better off, at least initially, learning what you need to on one distro than nearly learning many...

This is something that you'll need to fix; as a 'manual', I always recommend the tutorial by Andreassson at frozentux http://iptables-tutorial.frozentux.net/ (download a viewable copy...you'll go back to it several times). The iptables man page is also good.

You'll probably also want to look at some examples, eg
http://www.linuxhomenetworking.com/w...Using_iptables
http://www.yolinux.com/TUTORIALS/Lin...rkGateway.html
(I'm not suggesting that there is anything here that you can necessarily use 'as is', but that, once you have understood how iptables works, going through someone else's ruleset then helps in making that learning concrete.)
You might choose to use an 'easy' front end to iptables, but I'd suggest that it is unsafe if you do not understand the underlying iptables so that you can (at a minimum) audit what the easy front end has, or has not, done for you.

Just to save a few clicks, the tutorial seems to have been moved, online HTML here, "chunky" html here, and index of downloadable formats plus translations can be found here

Even more info on iptables http://www.netfilter.org/

Thanks for the extremely concise and useful response. I appreciate the time you've taken to put that together - it's very helpful.

iptables is ... complex lol.

Thanks again! :)

---------- Post added 04-12-11 at 08:18 PM ----------

Cool, thanks for that. :)

Yup, that's the site I'll be trying to use most, if I can. Hopefully the home website of the iptables stuff is the best resource! :)

Not really all that complex. Well, not for quite a lot of the time, anyway. Mostly, you'll have traffic on a really small number of ports and that will have to end up in the right place.

Then there is ssh, which will need some special treatment. You'll have to inform yourself about the options:
http://la-samhna.de/library/brutessh.html
Decide what you are going to do (and you might decide to combine two appraoches...say, something that looks to improve your chances and a non-standard port for ssh, a sshd log based approach and a non-standard port or port knocking and a non-standard port or rsa and a non-standard port (you'll see I quite like a non-standard port, but in combination with something that looks as if it might work, all on its own)). You'll get an amount of traffic from script kiddies trying to get in, but that, of itself, isn't a great problem if you have the right measures in place.

And you need to look through the log files; you'll see some noise there, but is this only on the standard port, or has anyone caught on to your non-standard port? Are you getting a few attempts from any one ip and then they are going away, or does someone seem to be trying many, many times? If you are using a log-based banning approach does that seem to be working? (You may be able to script some of this, but that isn't the fundamental point.)

There is probably other stuff that you'll want to do with iptables (some logging, for example, but not so much that it ties up the machine totally), but the really complex stuff (apart from if you want to use iptables as part of blocking excess ssh connections, or limiting DoS attacks), you don't want to think about in your initial thinking about iptables.

In common with almost every 'set up a webserver' tutorial, everywhere (in printed materials, as well as on the net), that says nothing about security. I think that is really dangerous, but then the people who put the tutorials out there want to tell you how simple it all is...

Salasi mentioned some good points, especially the "understand the threats and the countermeasures" part, but the rest of the thread pays a bit too much attention to intricacies too soon: I'd say get an overview of things before you dive into details. Here's some unordered thoughts:
- Harden the machines before assigning them tasks in your setup. This will expose flaws and other things to correct earlier on. Best start by reading the Securing Debian Manual as it's one of the oldest and most comprehensive ones.
- Ensure machines, especially the publicly exposed ones, run file system integrity checkers and appropriate logging because you can't know (and respond to) what you don't log.
- Since you mentioned dev boxes I hope you have good procedures in place for testing and deploying changes from development to production.
- Always test changes for their impact locally: GNU/Tiger and remotely: say OpenVAS or Nessus.
- SW choices affect performance (different resource requirements), redundancy (one DNS and fallback MTA in a different network), exposure (FTP, HTTP) et cetera. Check if you require Apache or if different a web server that is as functionally complete, well-maintained but lighter on resources would work.
- See if exposing your web stack services through a (reverse?) proxy, deploying mod_security, GreenSQL makes sense in terms of redundancy, security and possible expansion.
- Don't expose admin parts like Phpmyadmin or any other web-based management panels publicly: ACL them properly and use IP range restrictions where possible.
- Consider fail2ban for blocking unauthorized service attempts and set up a communications with your ISP so you know how (D)DoS situations will be handled.
- Part 6 of the LQ FAQ: Security references, or the cleaned up version at http://rkhunter.wiki.sourceforge.net/SECREF?f=print, may help direct you to some other sources of information to look at.

HTH

salasi & unSpawn,

Thanks for taking the time to hash this stuff out for me. The conceptual parts are more helpful than the technical parts in some ways as I can figure out the tech bits for myself. As an ex-Windows admin, though, my approach to security is a bit different to Linux ... i.e. take a deep breath and hope there are no vulnerabilities that I haven't patched. ;-)

I've read what you've both written and as I said, it really has helped heaps.

Thanks again for your help - I really appreciate it.

All I need to do now is find a new host ... the one I was going to go with has turned out to be complete rubbish from a review standpoint. Back to the drawing board on that one. :-)

Cheers

A very fair point, but I would also like to add:

• That tutorial that you have been following is wholly inadequate for this purpose. It is probably an excellent how-to for getting a development server up and running in the walled garden of your private network, but exposed to the internet....no.
• You mentioned iptables, and that was something security related that I could grab onto. The intention was to give you something specific to look at before broadening out the view a bit.

... except that it wasn't me that said you paid too much attention to intricacies too soon ... ;-)

I know that, but you have a deal with unSpawn and I shouldn't do anything to stand in the way of you getting the most value out of that deal. (It is an excellent deal, btw.)

That said, you asked something specific about iptables, so I though that I could jump in with a bit of detail about that without treading on unSpawn's toes.