blog.arithm

Build mod_security against the wrong set of headers, and Apache 2 will mysteriously begin to segfault in a persistent manner. Check which version you’re running with dpkg --get-selections | grep apache2.

Seems my shiny new Debian distro running the prefork version of Apache had the threaded (worker) headers installed against it. Duh. apt-get install apache2-prefork-dev reinstalled the correct prefork headers and Apache is happy again.

Mathiew Dessus has a great article about installing mod_securty on Debian for those interested.

Quick note on how to make alternative authentication modules work with Apache 2.2.

mod_auth_imap kept complaining about a missing password file:

(9)Bad file descriptor: Could not open password file: (null)


Turns out with Apache 2.2 you have to explicitly turn off Basic authentication even when you are using an alternative module. So a proper Apache 2.2 mod_auth_imap configuration would look something like this:

Auth_IMAP_Enabled On
AuthBasicAuthoritative Off
AuthType Basic
Require valid-user
Auth_IMAP_Authoritative On
Auth_IMAP_Server mail.server.com
Auth_IMAP_Port 143
Auth_IMAP_Log On


Turning off AuthBasicAuthoritative forces Apache to ignore the standard password file authentication.

There seems to be a “virus bot” out there just now starting to attack servers in Japan. It spoofs the distributed open source search engine Majestic 12 with a user agent string of MJ12bot/v1.0.8 (http://majestic12.co.uk/bot.php?+. (The real Majestic 12 is up to version 1.2.x.)

Use mod_rewrite in Apache to block it:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^MJ12bot/v1\.0\.8.*$
RewriteRule .* - [F]


Add the above to either httpd.conf or a local .htaccess config file. See the Majestic 12 FAQ for more information.

Note that the way the virus has been hitting some of our sites appears as though it actually attempts to coordinate DOS attacks from multiple servers. Scary if true. And it seems to be smart enough to stop attacking as soon as it realizes that access has been denied.

Update: If you run mod_security, consider appending evil MJ12’s user agent string to the rogue web crawler portion of the bad robots conf file modsecurity_crs_35_bad_robots.conf:

SecRule REQUEST_HEADERS:User-Agent "(?:e(?:mail(?:(?:collec|harves|magne)t|(?: extracto|reape)r|siphon|wolf)|(?:collecto|irgrabbe)r|xtractorpro\
|o browse)|m(?:ozilla\/4\.0 \(compatible; advanced email extractor|ailto:craftbot\@yahoo\.com)|a(?:t(?:tache|hens)|utoemailspider|dsarobot)|w(?\
:eb(?:emailextrac| by mail)|3mir)|f(?:astlwspider|loodgate)|p(?:cbrowser|ackrat|surf)|(?:digout4uagen|takeou)t|\bdatacha0s\b|hhjhj@yahoo|chinac\
law|rsync|shai|zeus|mj12bot/v1\.0\.8)” \
“deny,log,auditlog,status:404,msg:’Rogue web site crawler’,id:’990012′,severity:’2′”

mod_security returns a 404 Not Found error instead of Access Denied which should further help to confound the virus.

For whatever reason this was virtually impossible to find. Even the Great Google knew not.

Hoyasoft’s Windows Media Server plugin, VideoGuard, enables a wide range of simple content protection mechanisms for video streams: From basic HTTP authentication to referer URL checking to MD5 ticket validation. VideoGuard’s snap-in admin interface is intuitive and makes setting up URL-level authorization and/or authentication strightforward.

Though the documentation could do with a serious overhaul, Hoyasoft’s email-based technical support is quite good. (Thanks Steve!)

And most importantly, VideoGaurd seems to be the only product on the market offering this kind of simple security functionality. (Which should probably have been built into Windows Media Server in the first place…)

Ugh. Nobody seems to know what this thing is, though it seems to be some kind of PHP worm roving the internet looking for phpMyAdmin exploits. It appears to have been around since 2005 and searches for an exploit in the phpMyAuth class of older phpMyAdmin distributions.

I’ve seen it knock one of my servers on three seperate occasions; this from the first:

[05/Jul/2007:20:26:42 -0500] “GET /mysql-admin/main.php HTTP/1.0″ 404 280 “-” “pmafind”
[05/Jul/2007:20:26:42 -0500] “GET /phpMyAdmin-2.5.6/main.php HTTP/1.0″ 404 285 “-” “pmafind”
[05/Jul/2007:20:26:42 -0500] “GET /main.php HTTP/1.0″ 404 268 “-” “pmafind”
[05/Jul/2007:20:26:42 -0500] “GET /phpMyAdmin-2.5.1/main.php HTTP/1.0″ 404 285 “-” “pmafind”
[05/Jul/2007:20:26:42 -0500] “GET /phpMyAdmin-2.5.4/main.php HTTP/1.0″ 404 285 “-” “pmafind”
[05/Jul/2007:20:26:42 -0500] “GET /phpMyAdmin-2.2.3/main.php HTTP/1.0″ 404 285 “-” “pmafind”
[05/Jul/2007:20:26:42 -0500] “GET /phpMyAdmin-2.2.6/main.php HTTP/1.0″ 404 285 “-” “pmafind”


Interesting that it looks for specific versions of PHP. And odd that it announces itself by specifying a user-agent. (”Hi, worm here. Please let me in. Got a bit of infesting to do.”)

Deadmoo has a good, recent-ish post about it, though mostly Google just returns random posts and stats pages listing the pmafind referer. Where do these things come from?

How to have to punch in your password only once per day (or less):

This has been bugging me for years and I finally got around to looking up a solution.

Everyone knows that Emacs is the greatest editor on the planet, superior in all ways to vi. Unfortunately, Emacs has this nasty habit of tossing tilde-terminated backup files around whatever directory in which you happen to be editing. Not only does this clutter up the file system, it can also be something of a security risk; especially if you’re working on web servers. And really, snapshots of your most recent save is not so useful if, like me, you pathologically ctrl-x ctrl-s your code every few characters or so.

After a bit of hunting I discovered that Emacs’ built-in versioning could solve both of these problems. Cons the following two commands into your local .emacs:

;; Enable versioning with default values.
(setq version-control t)

;; Save all backup file into the designated directory.
(setq backup-directory-alist (quote ((".*" . "~/.emacs.d/backups/"))))

and not only will Emacs remember all saves:

$ ls .emacs.d/backups/
!home!gates!GPLv3.txt.~1~ !home!gates!GPLv3.txt.~2~


but, as you see, it also tucks your backups safely out of harm’s way.