Episode 11, L.A.M.P.

PodCast Feed


Links:

LAMP
Coppermine
PHPNuke
MAMP (OSX AMP)
Apache virtual hosts
Apache htaccess
Chrooting Apache
MySQL securtiy script
PHP register_globals
PHP error_reporting
PHP allow_url_fopen
Nikto
Nessus

RYOS, Episode 11 - L.A.M.P.

Thud: Run your own server podcast for November the 25th, 2006.

Thud: In this episode, L.A.M.P, what is L.A.M.P., tips for setting up L.A.M.P., and a moment of SEC.



This episode's reverse sponsor is the Mac Geek Gab podcast. Two geeks gabbing about Macs, what more could you want? Check them out at macgeekgab.com.

Thud: Ok, let's get started. Gek, tell me about L.A.M.P.

Gek: L.A.M.P. stands for Linux Apache, MySQL and PHP, Python, or Pearl. It's basically just a way to describe what your web application is using for the varios platforms: Linux for the operating system, Apache for the web server, MySQL for the database, and PHP, Python, or Pearl for the language that you use to write your application.

Thud: Ok, so L.A.M.P. is really just a package of applications to build a backend.

Gek: Correct. Your actual application is going to be a diary or blog software or a database of people's personal information, it can be anything. This is just a way to describe the technology that that's built on.

Thud: Why would you want to use this combination as a platform? What have you seen people using this for typically?

Seg: Well, I guess this is the basic platform for PHP and there's tons of PHP applications out there. PHP is a very common language for writing applications in and applications like content management or blogs or galleries have to have a database backend and MySQL's very common for that. That runs on every Linux distribution that I know of, so that brings up Apache and Linux, and it's just a combination that seems to work well together and it's easily available on every distribution I know of. I think that's one of the reasons why I think it's referred to as L.A.M.P. because that combination just seems to kind of meld together and work so perfectly together. You don't necessarily have to have Linux as the OS, there are a lot of amp packages for Windows or even OS10 for the Mac users. Of course they also run on BSD or any of the other Unix's so Linux is just kind of a holder for Unix in general.

Thud: A long time ago, when I was trying to organize photos on my own website, I do a lot of frackles, and I was using Copper Mine, which is an open source photo gallery that you can put on your web page. That uses Apache MySQL and PHP and I happened to be running it on Linux so that was a L.A.M.P. solution. It's a really cool program and well written, I haven't used it in a long time but I can't imagine that they haven't improved it quite a bit since I've used it. It really is a very basic introduction to what's common with the L.A.M.P. package. You have to go and make sure that Apache is configured properly, that your MySQL database is set up, and that PHP is properly installed and has the tendencies that Copper Mine needs to run. It was really easy and I can understand why people would use that as a base because not just from the developer perspective but from the end user perspective setting up those four technologies is pretty easy.

Gek: Yeah, I've used it in a number of applications. I've used L.A.M.P. for doing PHP Nuke, there's a couple of other galleries, I don't remember their names offhand, like Copper Mine, that I've used in the past. I've also used specifically an amp package for OS10 because that's what I use on my laptop and I decided to install it. I forget the name of it but I'll include the link in the show notes. It's a package specifically for OS10 that makes it very easy to get PHP, Apache, and MySQL all up and running on there. It was really nice to be able to use that on my laptop to be able to try out writing a few scripts of my own and to try out some other additional L.A.M.P. packages, like PHP Nuke or Copper Mine, or any of the others. There's thousands out there at this point.

Thud: One of the things we wanted to do with this particular episode is cover the Apache, MySQL, and PHP in general because each of those applications we can of course do multiple shows on. They're very complicated pieces of software, especially when you dig into the little corners to tweak all the knobs to get everything working as well as you possibly can. So we're just going to cover those on kind of a high level at this point. With that, let's go ahead and start on Apache. Gek, do you have any general notes on setting up an Apache server?

Gek: Basically where I begin is I always set up a virtual host or a virtual host directive for whatever it is I'm trying to do. So, on my own website, if I'm running, I'll use Copper Mine as my example just because I've done it before. If I wanted to do a photo gallery, I would set up like gallery dot whatever my domain name is dot com just so that when I'm playing with something I can separate it in the directory structure to its own site, and I don't have to worry about opening up my main site to any vulnerabilities. I can play with it on a separate name.

Another thing I'll do is I'll try to set up HT access to require a user name and password even if I don't want the site to be password protected later. That makes it so that I can be sure that no one else is going to see the site until I am ready to make it public. And then all I have to do is leave it a separate name, a separate host name and remove the HT access file so that it doesn't require passwords anymore or I can just leave it as that and link to it from my main site.

I haven't really had much experience setting up Apache running in a fruit but I am a firm believer that you should segment things where you can. Do you have more experience in that, Thud?

Thud: Well I have a little bit more because my server OS of choice is OpenBSD and by default the Apache on there is in chroot jail. All it really means from a technical standpoint there is a lot more security, of course but from a day to day maintenance, one of the issues you are going to run into is if you are going to use PERL or PHP or something like that that the web server needs to have access to run whatever script you have those have to be within the jail so that it can access those files. So it's kind of an interesting setup because of the way that it works you end up installing PHP on your OS and then having to copy that install into the jail environment. So that all of that is there for Apache to access because in a jail, of course, Apache can't access anything that is not there.

Gek: I know on FreeBSD when you go to install something from ports you can tell it which route you want to install from. Can you do something like that on OpenBSD that would make it easier so that you could just go into port say port install PHP and then you know give it some route path that would actually be that chroot environment that you are running it in?

Thud: I have actually never looked into that because the way that I do the install, I do the standard install, so sitting in the OS out where Apache can't get to it and then I only copy over the specific pieces I need. Because there is a lot of things included in the default install everything PHP package that you just don't need. A good example is if I don't need MYSQL access at all I am just running straight PHP scripts I don't need the MYSQL bits so I don't bother copying those over. There are a couple of scripts out there that make it easy to do those installs do the regular install and then copy everything you need into the jail. Generally I just do it by hand though, because I can pick and choose exactly what I want.

Gek: I think the best advice we could probably offer is just that if you can run something isolated, then you have to. It just makes sense to do it that way because you are more likely to catch somebody trying to do something bad.

Thud: Yeah, separation is always good. And that actually kind of brings me back to what you originally said about setting up a virtual host, by having different types of websites on their own sub-domain like that galleries.whatever.com, not only does it make it easy for you to keep things separated while you are developing those sites but, in a production environment if you keep things separated.

That way even if they are all on the same physical machine if one of the sites ends up doing extra load and you need to move it off to another server you have already got everything in place. You've got DNS in place so that it's a different name all of your links are already going to the different name all you have to do is just move the site over to another server. And it make scaling up much, much easier if you just start off that way.

Gek: Yeah I have always been in favor of that over using a subdirectory of the first domain. I liked when Microsoft had it so that if you could think of a keyword like Office.Microsoft.com that would usually be the page that you wanted to look at.

Thud: All right, lets move on to MySQL.

Gek: MySQL really isn't one of my strengths but one of things that I always do and I made sure I learned how when I first started setting up anything that used my S-Q-L is if I am making a new database for an application I always set up a user that has total privileges just for that database and then I give that to the installation script.

I don't like the idea of ever setting up an application with your route account I know that some of the PHP based, not even just PHP but some of the applications that use MySQL want to have your route password so they can go create the user in the database and everything else I really think that that's a bad idea. So I do that extra step, I create a database, I create a user, I assign that user privileges to that database and only that database. And then that way when the program asks I can give it that information and not my route password.

Thud: All right, one of the things I do when doing a MySQL install is I try to do a lockdown. There is a script that comes as a part of MySQL install called MySQL_secure_ installation. And it walks you through a couple of things, one of them is setting the route password for MySQL, removing the temporary directory, and a couple of other steps. But it is very simple script to run. I don't know why it's not part of the default install but it is a script they include which makes it fairly easy to do a script lockdown.

Gek: So Thud, if you are going to set up PHP what do you usually use as best practice?

Thud: Well, one of the things that is often overlooked when installing PHP is the PHP dot INI file which is just the general PHP configuration. And there are a couple important things in there that you want to look at. The first one is depending on your application, if it has support for running without registered globals on then you should probably turn it off. All that really is, is just a variable in that PHP dot INI file that tells PHP to make all variables in the scripts global variables. That's generally a bad idea, it makes it a lot easier in the development phase but in production you should definitely turn it off if your application supports it.

Another thing to turn off in production id to set air recording to zero that way if your script has any kind of error it won't give out the error information to the user that hits the website. Because a lot of times there are variables in there that you don't necessarily want everyone to see directories where files are located or things like that. So turning off error reporting is another security thing you can do in production. You wouldn't want to do it in development obviously, but definitely do it in production.

And the last one I want to cover on this is there's another variable called allow_url_fopen. Again, it might work fine if in development but in production if your application supports it you want to turn it off. That simply tells PHP to not allow if it's off to not allow your application to hit a URL out on the web somewhere. There are a lot of inclusion security issues you can have if you leave that on. So again, in production you should probably just turn it off. And it's the same for most variables. If you don't use it, disable it. So Gek, do you have any notes on Pearl or Python in a L.A.M.P. environment?

Gek: Most of the stuff that you would do for Pearl or Python is done in development. With Pearl you can turn on the taint module to make sure that tainted data doesn't get past which will help stop things like SQL injection or cross-sight scripting. It's not perfect but it is very good and it is certainly recommended that you turn that on for any Pearl applications that you are writing. For Python, I'm not really familiar with any issues with Python. I think mainly because these days most of the Python web development is happening with TurboGears or something similar and I don't think people are using Python as much in a CGI kind of way interface like Pearl or PHP.

Thud: Yes, I actually haven't seen any stand alone Python applications for a L.A.M.P. environment. There is usually some kind of framework like TurboGears or something else that kind of handles most of it for you. And also, PHP is significantly different from Pearl and Python just in the methodology of how they're used in a web server environment. So like you said, most of the security side of it is just within the scripts as you're writing them.

[Music]

Thud: For this episode's moment of SEC, we're going to cover Nikto. Gek, tell me about Nikto.

Gek: I've only used it maybe a handful of times but it is extremely useful. It is a Pearl application that is written just to do web vulnerability testing. It runs through - I think it's something like 2000 or over 2000 basic checks against your web server - just to see how the application is working or just your web pages and to find out if it's vulnerable for any of the things it can scan for. It's my understanding that it plugs into NESSUS but I've used it only as a standalone application. I just run it against my websites every now and then to see how I stand and if I find any problems it's usually pretty easy to research what it is and then go fix it. Do you have any experience with tying it into NESSUS or anything else you've done with it?

Thud: I've only ever used Nikto as a plugin from within NESSUS. NESSUS is a much bigger scanning application that scans for a lot more than just web servers. But Nikto is very, very good at doing those scans for web applications. I always use it from within NESSUS because I need to be scanning a lot of other things at the same time and I've always found that it's very handy for identifying security issues within a web application. OK Gek, what are your closing thoughts for this episode?

Gek: L.A.M.P. is a great development in the Open Source community. I mean it is just a combination of packages that are commonly used but I think it gives somebody who's new and thinking "Hmm.... I really want to start my own web application" a place to start. You don't have to go out and write your own database program, write your own web server. You've got this great package you can already pull together and use and if you want to do one of the custom made applications you can. You can still do that and plug-in it in. You can replace the Apache part with your own web server if you think that you can write a better web server than the Apache group. What about you Thud? What are your closing remarks?

Thud: I think L.A.M.P. is a great framework for starting development of new projects. It has all the pieces that you need. Since PHP is such an easy language to learn, it's become very common for many people to write applications not only open source stuff but just little personal scripts or full, big multi-million dollar production applications. So L.A.M.P. is just a quick way to get started down that road and get everything you need in one place just set up and running. And I just wanted to say again that because this episode is on L.A.M.P. and it's a fairly short episode we're just skimming over the top of all the individual pieces. We are going to have future episodes on Apache, MySQL, PHP, Pearl, Python, and all of the other related things. We just wanted to quickly to skim over to give you an idea of how it all fits together.

[Music]

Thud: For show notes or other details, please visit our website at runyourownserver.org.

[Music]

Thud: If you'd like to send us feedback or have a question you'd like us to answer on the show, please send an email to podcast att runyourownserver.org.


Thud: The intro music, "I like Caffeine", is by Tom Cody. This song, "Down the road", is by Rob Costlow. Please visit our website for links to their websites.


Thud: This podcast is covered under a Creative Commons license. Please visit our website for more details.

[Music]


Transcription by CastingWords