Hello,

I have decided to create fixed bash packages for Debian Lenny. I have applied the upstream patchsets from from 052 until 057, so some other issues are also addressed in it. :-)
And here they are:

Source .dsc: http://misc.linux-dev.org/bash_shellshock/bash_3.2-4.1.dsc
amd64 package: http://misc.linux-dev.org/bash_shellshock/bash_3.2-4.1_amd64.deb
i386 package: http://misc.linux-dev.org/bash_shellshock/bash_3.2-4.1_i386.deb

Much fun with it!

We still have got some more or less webapplications which are not compatible with PHP higher than version 5.2.x, which is the only blocker for the last Lenny servers to upgrade them to Squeeze.. I do not think that I am alone with this ****** topic :)

So the new “masterplan” is to deploy those applications on seperated Wheezy servers, with PHP 5.2.x running as FastCGI, so that most parts of the system are “security supported”.

First; I didn’t documented my steps and I am not 100% done (something like 99%) but I have done the following to have it “as clean as possible”:

• Catch the original 5.2.17 sources and build them, urgs.. it fails at all with the new multiarch paths from Wheezy, after a few hours of patching I gave up..
• Using dotdeb Lenny sources as reference, they also have got 5.2.17 sources, but what the fuck? The orig sources of their mirror also could not build, because the patch series FAILS (not hunky, they fail!), how did they build them???
• After some sanitizing of the dotdeb packages I thought it is better to smoke some cigarette and to delete them, urgs..
• My next step was to catch the latest 5.2.12-x packaging from snapshot.debian.org, here the story continues… again…:

PHP 5.2.x is just not able to detect the new multiarch paths, it fails at most “dir” options. Since patching the whole build system would be *too* much work I decided to hack around this (ln -s /usr/lib/x86…./foo.so /usr/lib/), then some adjustions to the build dependencies, disablieng some modules, like SSL and libdb (incompatible versions), disabling merged patches and refresh the suhosin hardening patch; I get an working PHP 5.2.17 package on Wheezy.
But this is too easy!
I want packages which I could co-install with the PHP 5.4 packages from Wheezy, 5.2 should only used withing vHosts where I have enabled them..

So I rewrote the whole packaging (*burg* IMHO at all) to use “php52” instead of “php5” as packaging namespace and also everything is put into “/opt” as prefix. Much painfull work, but yeah it works.. :)
Some packages, like php52-dev or php-pear are broken, but those were not my goal of this action.

If someone is interested in those packages please send me an email.
Since PHP 5.2 is not supported any longer (and that this is at all a big hack) I will not publish the source and binaries at all.

If you want to add some rules to your Apache based on the clients country, mod_geoip is perfect for it.

Installation

On Squeeze following is enough: # apt-get install libapache2-mod-geoip geoip-database/squeeze-backports

Note that you should use the geoip-database version from squeeze-backports to have got the most up to date database version, I am updating it every month.

Configuration

You can add the rules to your VirtualHost, Directory, Location directives and also to your apache2.conf (“serverwide”). So you are flexible with where to use it.

Blocking countries

On some servers I have got more than 90 percent of spam requests only from three countries, so I blocked them with:

<DirectoryMatch “^/var/www/.*/html”>
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE UA BlockCountry
Deny from env=BlockCountry
</DirectoryMatch>

Allow only specific countries

In the other way you also can allow specific countries to have got access to your website, this also may be a good idea for extranets, where you know from where your customers are:

<Directory “/var/www/my.site.com/html/login”>
SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountry
SetEnvIf GEOIP_COUNTRY_CODE CH AllowCountry
Deny from all
Allow from env=AllowCountry
</Directory>

Very easy!

Rewrite Rules

You can also use it for mod_rewrite. Within a project, customers from CN and TW should be redirected to the chinese page:

RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^(CN|TW)$
RewriteRule ^(.*)$ http://some.example.cn/site.php [L]

mod_geoip with proxy frontends

Normaly mod_geoip works behinds load balancers and proxy servers, since it also take care of the HTTP_X_FORWARDED_FOR header.

But with haproxy it looks problematic, since it does not add the HTTP_X_FORWARDED_FOR header to KeepAlive’d requests :( Disabling KeepAlive is a bad idea on this cluster, so we decided to also use php5-geoip in our application, so everything is working nice now..

What mod_geoip is NOT is

mod_geoip helps you to block/allow specific countries, but it does not protect you from them.
Also keep in mind that the database is only ~ 99,8% accurate, so you may have got false positives/negatives. If you only allow german users, a german IP could be listed as russian.
This is much more problematic with mobile/satellite connections and surely you can also not access your page, if you are on vacation in another country. ;)