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. ;)

Debian GNU/Linux Debian 7.0 (aka Wheezy) will be a “general hardened” distribution in my eyes. Not only that it now enabled hardened building of packages (see http://wiki.debian.org/Hardening), the Kernel team also backported with 3.2.20-1 the IMO very interesting hidepid option (already available in Wheezy since some weeks)!

What is the job of “hidepid”?

hidepid is an new mount option for the procfs (/proc), with that you can hide processes and its information to other users, like other shell users and to web scripts.

hidepid accepts three different values:

• hidepid=0 (default): This is the default setting and gives you the default behaviour.
• hidepid=1: With this option an normal user would not see other processes but their own about ps, top etc, but he is still able to see process IDs in /proc
• hidepid=2: Users are only able too see their own processes (like with hidepid=1), but also the other process IDs are hidden for them in /proc!

Additionaly you can specifiy an user/group ID which is still able to look up the processes with the gid option. So if you want to hide all processes to other users, except root (uid=0) and in this example gid=1001 (some semi administrative user in this example) your /etc/fstab has to look like this:

proc            /proc           proc    defaults,hidepid=2,gid=1001        0       0

It was a good descision to backport this feature IMO, but also be careful, it *may* break programs. I did not found any server related application which will break with hidepid=2, but we had to adjust our Nagios monitoring to execute some process checks with another UID, since the nagios user itself could not see anymore, if process A and B is still running.

UPDATE 1:
Since a few people asked (thanks for it) with hidepid=2 the process IDs are not invisible, they are unavailable:
$ ls /proc/1
ls: cannot access /proc/1: No such file or directory
$

Imagine you have got the following iptables rule set:

*filter
:INPUT ACCEPT [2:130]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [119:14185]
-A INPUT -s 127.0.0.0/8 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp –tcp-flags FIN,SYN,RST,ACK SYN -j DROP
COMMIT

This would allow all traffic from 127.0.0.0/8, on port 22 and 80. Other (TCP/IP) SYN packages (so on all the other connections) would be dropped.
Now you see, that your counter for the SYN DROP rule is increasing and you want to know what is rejected, but how?

The simple answer is ULOG – the netfilter userspace logging daemon.
In Debian you have got various implementations/variants of it, the local logging one (which I will use here, just called ulogd) and the -postgres, -mysql and -sqlite3 one (that are not the exact package names), with that you also can log everything to a (remote) database.
An special variant is the -pcap one, it will write the logs in the .pcap format, so you can analyze the full traffic.

So for our example it is enough to install the package:

apt-get install ulogd

And then add another rule BEFORE our SYN DROP:

-A INPUT -p tcp -m tcp –tcp-flags FIN,SYN,RST,ACK SYN -j ULOG
-A INPUT -p tcp -m tcp –tcp-flags FIN,SYN,RST,ACK SYN -j DROP

Now you will find in /var/log/ulog/syslogemu.log a log of all connections, which would be dropped, the log looks like this:

Aug 13 14:42:07 srv1 IN=eth0 OUT= MAC=00:0c:29:8c:2b:6c:00:d0:02:eb:e8:0a:08:00  SRC=75.125.70.194 DST=XXX.XXX.XXX.XXX LEN=40 TOS=00 PREC=0×00 TTL=54 ID=9566 PROTO=TCP SPT=57144 DPT=445 SEQ=2770468863 ACK=0 WINDOW=512 SYN URGP=0
Aug 13 14:45:29 srv1 IN=eth0 OUT= MAC=00:0c:29:8c:2b:6c:00:d0:02:eb:e8:0a:08:00  SRC=75.125.70.194 DST=XXX.XXX.XXX.XXX LEN=40 TOS=00 PREC=0×00 TTL=55 ID=13702 PROTO=TCP SPT=58528 DPT=445 SEQ=1217789951 ACK=0 WINDOW=512 SYN URGP=0

So you have got now the information about the full date, mac address (mostly it will be the one of your gateway), source and destination IP, source and destination port, length, protocol, etc.

You also could use it to log outgoing connections to port 80 and the IRC ports:

-A OUTPUT -p tcp -m tcp –dport 80 -j ULOG

-A OUTPUT -p tcp -m tcp –dport 6666:6669 -j ULOG

Whatever you want.