Apache

A new version of mod_security has just been released - 2.0 - complete with a total rewrite that includes a number of new features. El reg is running an article on the new release which includes an interview with ModSecurity's author Ivan Ristic.

mod_security is an apache module for monitoring requests made to a web server and acting on those requests according to rules - useful for blocking malicious bots, stopping web spammers and so on. I've been using it for a few years now and it handles blocking of weblog spammers and trojan worms/bots very well, though it has to be said the configuration isn't the simplest of all time.

Hopefully this configuration issue might be made easier with the also newly released modsecurity console, although reading through that page it doesn't seem to mention anything about using it to configure mod_security... Will have a look at it later and see what's what.

A list of the new features or improved features in ModSecurity 2.0 - taken from the article above:

• Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.


• Per-rule transformation options (previously normalisation was implicit and hard-coded). Many new transformation functions were added.


• Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.


• Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).


• Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).


• Support for web applications and session IDs.


• Regular Expression back-references (allows one to create custom variables using transaction content).


• There are now many functions that can be applied to the variables (where previously one could only use regular expressions).


• XML support (parsing, validation, XPath).

The article is well worth reading if you already use ModSecurity - particularly if you're interested in moving from just simple blocking and logging of requests as in mod_security 1.0 to a more sophisticated web application firewalling system - mod_security 2.0. 2.0 includes a pseudo web app firewalling programming language making it easy to manipulate and process HTTP in a stateful manner - tracking HTTP sessions per IP in real time for example or perhaps watching for anomalous web activity and then flagging any IP that transgresses behaviour deemed as acceptable and watching for that IP in the future.

parsepath.pl is a brilliant perl script for fixing permissions problems on Unix based platforms by Jeremy Mates. Probably the most common type of permission problem from a sysadmin/webmaster's viewpoint is uploading a file to a directory in a website's document root folder and then trying to access the file or script in a web browser only to get the dreaded 403 error message:

Forbidden
You don't have permission to access /foo/bar/test.php on this server.

Most time the solution is very simple, just change the permissions on 'test.php' to make sure the user the webserver runs as can read the file correctly - the simplest and most common method being to change the mode of the file to '755':



Unfortunately sometimes it's not that easy and many times you see users asking 'I'm getting 'access denied' errors even though I've changed the perms to 755'. The problem is that one of the subdirectories that the 'test.php' file lives in has permissions set so that the webserver can't read the file properly. Now that's where the headache comes in :)

However, parsepath.pl can take the headache out of fixing permissions problems.

Say you have a website document root directory tree /usr/local/www/web/www.munk.me.uk/foo/bar and you upload a web script 'test.php' into that directory. You try and access the file in a webbrowser but get the 403 permission denied error above. First off you check the permissions on the file itself:



That looks ok, with permissions 755 and the owner/group set to 'www' the webserver user 'www' should be able to read the file ok. So in this case the problem must be with the permissions on one of the parent subdirectories. The old method of working out the perms would be either to trawl one by one through each directory checking the perms on each subdirectory or to change the permissions recursively on the document root folder so all subfolders have the read bit set for the webserver user/group.

With parsepath.pl things are a lot simpler though - just run the following command:



With this command parsepath.pl recurses through each subdirectory below the file/path you feed it on the commandline and tells you the permissions problems - if any - for the user 'www' (the user=www argument) to read (the +r argument) the file 'test.php'.

In the output, we're told that permissions to read the test.php by the user www fails on two counts:



With this information it's easy enough to go in and make the changes necessary to fix the problem using 'chmod g+rx foo foo/bar'.

There are other ways of invoking parsepath.pl though. Running it just with a file/path as an argument it'll tell you the permissions on each subdirectory under it:



which can is better to see a whole tree in one go.

No permissions were harmed in the making of this article!


I'll include the parsepath.pl script in the extended article just in case the original ever gets lost - big credit of course goes to the author of the script, Jeremy Mates. His site is actually very interesting from a sysadmin's point of view containing lots of interesting admin scripts and thoughts on system administration in general - spent quite a while grazing through his stuff there - cheers Jeremy.

Well, today is the first day after my old domain munk.me.uk expired - I'm now using the domain munk.me.uk, rest in peace munk.me.uk!

This article discusses a strategy for migrating a domain name in the case when the new domain will host exactly the same content of the old but you want to ensure that search engines will register the move and users who search for content you host will still find you after the move.

Quite a while ago I posted a question to the freebsd-isp mailing list about a minor modification that could be added to the apachectl apache startup shell script to stop it from displaying a lot of sensitive information when PHP and other CGI applications display apache's environment information to users. A bit mouthful - the gist of it is that when you use apachectl to start/stop apache from a shell, the environment variables of the shell user that invokes the apachectl script become available to CGI applications by default.

For example in my case the following types of sensitive environmental information is available by default when someone runs phpinfo.php on my server:



and so on along with all the other environment variables I have set in my default root shell - not really what I want displayed to all and sundry :P To see this yourself on your own server, try running phpinfo() from a php script:



Anyway the solution I found is to 'sanitize' the environment when the apachectl script starts up the apache httpd process by using the following simple line in apachectl:



A problem report I was considering sending to the FreeBSD ports team is included in the extended article below - I didn't bother sending it in the end because it's not really a FreeBSD issue. Not sure why I didn't send it to the Apache mailing list though, I thought I did but I can't find it now. Ho hum.

AWStats was recently updated from version 6.1 to 6.2. Of itself this was no problem, checking the changelog there is nothing significant that breaks anything. However unfortunately the AWStats FreeBSD port was modified by the port maintainer to correct a problem that already existed - namely that some of the tools that ship with AWStats don't work because they can't find the files that they need - icon files for example.

The port maintainer modified the port so that the icon files for AWStats are now placed in /usr/local/www/awstats/icons/ - the original default location was /usr/local/www/icons/. This took me a little while to figure out, perhaps it's the New Years hangover but a more detailed note in the /usr/ports/UPDATING file for current users of awstats would have been good. Ho hum I suppose it's at least something that anything was added at all to UPDATING. I'm all for tidying up directory structures but in this case it seems that a 'fix' for something that was trivially broken has actually resulted in breaking something that was working fine - as the saying goes if it ain't borked don't fix it.

The short and tall of it is that to fix the problem that this 'fix' created, a 'DirIcons' directive needs to be added to each awstats config file:



and then an alias line needs to be added to the httpd.conf file:



otherwise the awstats pages look odd because the icon files can't be found.

For posterity there's a GNATS message I drafted to be sent in reply to this FreeBSD Problem Report regarding the recent awstats update in the extended article below.