Monthly Archives: July 2011

Enabling ModSecurity protection in Apache2 on Ubuntu

 

This post documents how to add ModSecurity protection in Ubuntu's Apache. It has been tested on Ubuntu 11.04 but might work on earlier or latter issues with few modifications.

Installation of base packages

ModSecurity is a open source Web Application Firewall (WAF). It offers an array of request filtering and other security features to the Apache HTTP Server.

Fortunately, ModSecurity is already part of the Ubuntu package repositories. Therefore, installing the necessary stuff is rather straightforward:

apt-get install libapache2-mod-security mod-security-common
a2enmod mod-security
/etc/init.d/apache2 force-reload

Activation of the core rule set

The mod-security-common-package contains the core rule set (crs) which will not be configured automatically. In order to activate the crs, /etc/apache2/conf.d/mod-security.conf has to be created with the following content:


    Include /usr/share/doc/mod-security-common/examples/rules/*conf
    Include /usr/share/doc/mod-security-common/examples/rules/base_rules/*conf

Now the web server has to be restarted by the following line:

service apache2 restart

Testing the setup

In order to prove the setup is working, a test file called test.php with the following content can be used:

It's supposed to be placed in the root of your web server, so that it can be accessed by http://yourserver.tld/test.php. To run the actual test, the following address will do:

http://yourserver.tld/test.php?secret_file=/etc/passwd

If the content of /etc/passwd is displayed, ModSecurity is not working. A working installation will show a "403 Forbidden" error message.

Hardening PHP on Ubuntu with Suhosin patches

This post documents how to enable the Suhosin protection system for PHP on Ubuntu installations. It has been tested on Ubuntu 11.04 but might work on earlier or latter issues with few modifications.

Apparently, Ubuntu repositories already contain the patches as an additional package. They are installed by the following line:

aptitude install php5-suhosin

After that, the patches are available but not yet configured. The central config file for the protection system is located at /etc/php5/conf.d/suhosin.ini. For a basic configuration uncomment the following lines:

[suhosin]
suhosin.executor.include.max_traversal = 4
suhosin.executor.disable_emodifier = on
suhosin.mail.protect = 2

; Filtering Options   
suhosin.cookie.max_vars = 2048
suhosin.get.max_array_index_length = 256
suhosin.post.max_array_index_length = 256
suhosin.post.max_totalname_length = 8192
suhosin.post.max_vars = 2048
suhosin.request.max_totalname_length = 8192
suhosin.request.max_varname_length = 256

Defining the latter options keeps phpMyAdmin working. After editing the file, the changes are activated by restarting the Apache daemon:

service apache2 restart

Now you may play around with the other config options in order to harden your webserver even more.

Full restore from Time Capsule with account-authentication

 

This week the people at Apple released their new OS X-Version called "Lion" (10.7). Some interesting new highlights in terms of UI, backup and encryption were announced. I was curious and gave it a shot.

To be on the safe side I did a full backup with Apple's rsync-based Time Machine-software on my Time Capsule backup device. This way, I expected to be able to do a full system restore of a pre-upgrade-state in case something goes south.

Mission Control unfortunately is a pain

After trying Lion for a very short while, I discovered that quite many of my favorite tools wouldn't work as they did in Snow Leopard. Examples are Quicksilver, MacBiff, PathFinder and GeekTool. I suppose that most of these tools will get an update sooner than later so I would've been able to live with that.

Yet, one thing really is such a bummer that I'm not going to use Lion in the near future: Mission Control basically killed Spaces, Exposé and the handy "show all windows" functions. I rely on these in my daily work by using "hot corners" and I don't want to be forced or patronized to change my well working processes. I guess I'm not the only nerd to consider this a step backwards, so I'm counting on some witty developers to revive projects like Desktop Manager or Virtue in order to rebuild the Snow Leopard-ish window management behavior.

Starting the restore

Long story short I now wanted to do a full restore of my Snow Leopard setup. Considering myself security concerned, I gave separate accounts on my Time Capsule to all machines which do a backup there. Then I booted my Snow Leopard-DVD and chose the option to do a full restore from a Time Machine-backup.

The restore helper program displayed the according backup and even accepted my auth-data. Yet, I couldn't start the backup. I tried the same from a different Mac and another backup: same issue.

I figured it must have something to do with the user accounts on the Time Capsule as I was able to restore a Mac back in the days when I had only one machine. I changed the file sharing-setting in AirPort Utility so that the Backups were just secured "With Time Capsule password". Having a look at the directory structure on the Time Capsule, I saw that the backups are not stored in the actual root directory. Due to using user accounts, there was now a structure of /Users/machineName.

Bug found and worked around

I suspected there might be a bug in the restore software, expecting backups always in the root directory of the Time Capsule drive. I moved the according sparse image of my machine to the root of the Time Capsule and tried the restore again. It worked!

The result is that the "Restore System from Backup" functionality on the DVD can't handle separate user accounts on a Time Capsule. Apple, you should be embarrassed about that, especially for not documenting and not fixing this.

Anyway, after the successful restore I moved back the sparse file and reactivated the Time Capsule-accounts to keep my security conscience calm. After that, all backups are working as they did before.