Bradley Coudriet > howto

I needed to install logwatch a OS X machine for work, and i figured i would just document the process.

Thats is… logwatch is installed as you can see by running

sudo logwatch

(cias staff at this point look to our internal wiki)

Now you just need to tweak your /etc/logwatch/conf/logwatch.conf file to suit your needs

Also if you want it to run everynight at midnight put a script in /etc/periodic/daily

Rob wrote a great article on how to Netboot your macs across multiple subnets, like we do here at RIT

cias.rit.edu/~rrhpph/wordpress/

When place before all other output on your PHP script this little snipped will force you PHP page to be presented over SSLThis is very useful on things like Login forms.

if($_SERVER['SERVER_PORT'] != '443') {

    //Force SSL upon this page

    header("Location: https://".$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']);

}

Here at CIAS we have a bunch of linux servers, and we run logwatch on them to give us a daily look at our servers.

There are few options with logwatch and how you want to get the information, you can have it email you, which for one or two servers that is pretty standard, but we are managing 10+ servers, and i don’t want to clog up my email and i don’t want to use my inbox as a way to archive all of our logwatch reports.

So what did I come up with?

On The Server

Everything that happens here is using a simple upload script i created to facilitate the aggregation of the scripts. Machine’s logwatch runs as a cron scripts and outputs its report to a directory on the machine. Right after that script runs another scripts run and copies the logwatch report to a central web server.

On the Web Server

The ‘logwatch’ app is just a nice simple front end to a bunch of directories from this structure

archive
    server1
        12-3-07
            logwatch.txt
        12-2-07
            logwatch.txt
     server2
            12-3-07
                logwatch.txt

I created a nifty little PHP class that takes care of this structure, and allows easy access to the files through code.

RSS and <insert favorite news reader here>

Cool, so now i have a nifty little web app that organizes our logwatch reports… so whats the next step?

I already run NetNewsWire on my Mac and RSS would be a perfect solution for seeing updated logwatch reports as they come in from the servers. So create the RSS is was pretty easy…

1. use the PHP class
2. output in RSS format the last 5 logwatch reports for the specified server
3. RSS MONEY!!

I’m pretty happy with this elegant solution. I always have a hard time remembering to ‘go’ to a web app… I always keep NetNewsWire open. So this solution makes me a better System Administrator

Earlier today we installed a wildcard certificate on cias.rit.edu.

What does this mean?

A: Before today, if you went to https://bjcpgd.cias.rit.edu (over SSL) you would be using the certifcate for cias.rit.edu, and in the eyes of your browser bjcpgd.cias.rit.edu and cias.rit.edu are two totally seperate domains. The installation of this wildcard certifcate now means that the certificate will cover and be valid for all sub-domains of cias.rit.edu. This means you can now easily use SSL to protect your web applications on cias.rit.edu.

Do I have to change anything to use this certificate?

A: Not at all! The certificate is active and valid for all accounts under cias.rit.edu. You may need to tweak your application to make sure its point to https:// in the areas that you want protected, but that is a very application specific issue.

What else has the cias tech team been doing to help secure our applications and data on cias.rit.edu?

A: In the past we have allowed all users to be able to browse other users directories. We’ve been slightly uncomfortable with this scenario for a while. Yesterday we made a change to everyone’s home directory that will keep prying eyes out, yet still allow your web applications to ‘roam free’. We specificly did the follow on each users home directory:

    chgrp www-data /home/<username>    chmod 750 /home/<username>

What exactly did that just do? First off we made the group owner for you home directory the web server’s user. So you are the owner of your directory, and www-data is the group. The chmod of 750 means, The owner can read,write and execute. The group can read and write, everyone else has NO ACCESS.

Tonight i encountered a new error in Apache i’ve never seen before:

[Thu Feb 28 17:54:32 2008] [notice] child pid 2602 exit signal File size limit exceeded (25)

I saw MANY of these errors, and Apache wouldn’t return any pages to the browser.

Here to find out, in 32bit Linux, there is a 2GB file size limit.. when this file size limit is reached on an Apache Log file….. these errors start to crazy.. and breaks Apache.

Lesson learned

So… with that said, once we get all 64bit ESX Nodes, i will start to slowly upgrade my web nodes up to 64bit.

Update:

I have since read on the ‘Tubes’ that this issue has been resolved in Apache 2.2.x… the server that was having this problem was Apache 2.0.x

Security should always be on the mind of any developer of web technologies, but sadly in todays rush toward rapid application development and fast approaching deadlines, security takes a backseat sometimes. Here at CIAS we need to walk the thin line between a locked down and secure web environment, and an open and available environment which allows Students, Faculty and Staff the ability to freely explore all aspects of web programming.

We have had a few incidents involving unsecured uploads scripts on the cias.rit.edu student web server, so we need to start taking a harder look at security. These incidents have involved both spam, and hacking attempts.

There are two ways I can look at the security of the cias.rit.edu web applications.

1. I can lock down apache and php and make it nearly impossible for hacking attempts, at the expense of your ability to create flexible web applications.
2. I allow the responsibility to come down to the individual account owners to secure their applications and keep security of the server as their primary priority.

I would much rather latter option, the first option creates an environment that is very much limiting and locked down.

With that said, what can you as a developer do to help secure our environment in your file upload scripts??

Here are some simple steps you can take in your scripts:

• Check the referrer of the form submission: make sure the information being sent from your script actually come from your script, not being faked from an outside source
• Restrict file types: This is the most important step you can do to secure your file upload scripts. if you are only expecting jpg images, make sure the file being uploaded has the .jpg and/or .jpeg extension. Note to watch out for double extensions (i.e. image.jpg.php )
• Rename the file being uploaded: If the image comes in as MyCutePuppy.jpg, rename it to something like timestamp_MyCutePuppy.jpg, or even better yet, if you are keeping your images in a database, you can easily track the names of your files if you rename them to something completely random, such as a timestamp or md5 checksum
• Permissions: 777 is not a good idea for your unless you REALLY need it. The best idea is at least 644 ( Owner can read/write/, everyone else can only read) This is a perfect for image uploads, if you are doing things in your web app such as deleting images, you may need to loosen up your permissions, but make sure you don't just blanket 777 everything, as this 'is a bad idea'
• You will need your upload directory to be 777, but all the files in it should be 644
• Make your users login, or at least give some information that you can use to track them down. Actions like this will deter users (or bots) from doing 'bad' things

Ok, so with these nice little tips, how can we create a nice easy php upload script that won't allow the server to be owned?

Well, to understand that, I think we need to understand how an unsecured upload script can be exploited, here is a great example, and exactly how we've been attacked before.

1. Hacker finds an unsecured upload script
2. Hacker uploads a .php file
3. Hacker then finds his .php that was uploaded to the server, not renamed and with 777 permissions. By just visiting this PHP script in his web browser the attack has started
4. That PHP scripts then proceeds to download from the internet binaries and other php scripts that can be used to gain a command line on the machine
5. The hacker now has the run of the server as the user www-data who runs the apache server. This is a bad situation, this has now put every account on the web server at risk, because the www-data user has permissions to everyone's directory.
6. The hacker at this point can either launch attacks on other servers, using our good name as a proxy, or can continue to exploit our server and install software that gives the hacker a backdoor.

As you can see, this 'is a bad thing'

So how do we stop this from happening?!

The following script gives you everything you need! (Read the comments to understand what everything does)
The sample script implements many of the points i talked about earlier in this post, ejoy

You can try out the script, and see the source at: http://bjcpgd.cias.rit.edu/upload.php

I was searching the internet looking for a way to install the ImageMagick gem on Leopard, and lone behold i found it!

YAY

http://nullstyle.com/2007/10/27/how-to-build-imagemagick-and-install-rmagick-with-macports-on-mac-os-x-leopard/

**disclaimer**
I would like to thank Adam Miller very much for working with me to create an environment that can run ruby on rails, and for providing this great how-to for creating rails application on cias.rit.edu I personally cannot take any responsibility for the great work he's done documenting these steps. Bravo Adam.

Prerequisite:

You should be comfortable typing in commands to a command line interface. You should also be sure to have rails, mysql, and a server running on your local machine for development. Your rails app will run in production mode on the CIAS server, so you will not be able to access many of the debugging tools that development mode offers you.

That sound good? Alright, here we go!

Step 1: Creating the Apps Directory

For reasons of security and flexibillity, I'm going to recommend creating a directory for your applications to live in. We don't want to have your apps live in a public facing directory so lets create it as low as we can go (your home folder).

Step 2: Setting up your app

We're already to go now just call the rails command to build your new application:

This will create a brand new rails app for you. If you already have been developing your application locally, you can also deploy your application here. Hopefully your using subversion to manage your files and you can just checkout a version of your app:

If not you could use ftp to get your local files up on the server, although I would not recommend this method at all.

Step 3: Set permissions

By default, the permissions will be set incorrectly, and we can't have that.

I've also found that if your generating a new rails app, your tmp directory and its contents will have incorrect permissions as well.

Step 4: Create the symbolic link

Create a symbolic link to your apps public directory. For this tutorial, I'm assuming you will want to run your application from the apps directory we set up in step 1.

If you want your application to run at your root level, then replace your public_html folder with your symbolic link.

Step 5: Edit your .htaccess file.

In your apps public directory, edit the .htaccess file using your favorite editor. Because your app is not going to be running at the root level (if it is, you may be able to just skip this step), you'll need to tell the server how it should map your urls. Above the very first RewriteRule add this line.

Again, if your running your app in your public root, just leave off the symbolic-link-name.

We also need to make sure apache knows we want to use fastcgi to run our application. Add this line to the top of your .htaccess file:

Then we also need to rewrite this line:

to be:

So that we make sure we're using fastcgi insead of just cgi. Your app will be painfully slow (and consume a lot of resources) if your not running with fastcgi.

Now you should be able to visit
http://cias.rit.edu/~your-account/symbolic-link-name/
And you should see the rails welcome message. If your deploying an application that you have already started, you may see an error instead of the rails welcome message. Don't worry about this as we have not finished setting up the database yet. Onward ho!

Step 6: Database hookups

You'll need to edit the production database values in database.yml. Each cias account (as far as I know) comes with a mysql database in the name of your account. So we can edit it to look something like this:

Step 7: Production mode

As of this writing, cias.rit.edu is not set up to force your app into production mode by default. It's important to run production mode because it is more secure and consumes less resources. In the app of your rails directory, open up config/enviornment.rb and add this line somewhere towards the top:

Step 8: Enjoy!

And that should do it! Your app should be up and running. If you have problems feel free to shoot me an email: acm6603[at]gmail.com. Google is also very helpful even though it won't be specific to this server.