Ians Ramblings

I came across an odd issue today, in that I had installed ImageMagick on a server as root, this was via Yum. When I ran the following command as root, I saw no errors and all was as expected:

perl -e ‘use Image::Magick;’

When I switched to the user account under which Apache runs for my Mod Perl application, the command above resulted in:

Can’t load ‘/usr/local/lib64/perl5/auto/Image/Magick/Magick.so’ for module Image::Magick: libMagickCore.so.5: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200.
at -e line 0
Compilation failed in require.
BEGIN failed–compilation aborted.
&Image::Magick::constant not defined. The required ImageMagick libraries are not installed or not installed properly.
END failed–call queue aborted.

I used the command ‘ldd’ to check the dependencies for the aforementioned Magick.so shared library and for root I saw the correct long list, for the apache user I saw the following:

ldd /usr/local/lib64/perl5/auto/Image/Magick/Magick.so

linux-vdso.so.1 =>  (0x00007fffeb1ff000)
libMagickCore.so.5 => not found
libm.so.6 => /lib64/libm.so.6 (0x00007f3e3fc27000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3e3f895000)
/lib64/ld-linux-x86-64.so.2 (0x0000003955a00000)

I looked at the location for libMagickCore.so.5 in the output for root and then copied the file into /lib64/ and re-ran the ldd command above and got:

libMagickCore.so.5 => /lib64/libMagickCore.so.5 (0x00007f4b22236000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4b21fb1000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4b21c1f000)
liblcms.so.1 => /usr/lib64/liblcms.so.1 (0x00007f4b219d7000)
libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00007f4b21772000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f4b214d5000)
libjasper.so.1 => /usr/lib64/libjasper.so.1 (0x00007f4b2127c000)
libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007f4b21057000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f4b20e45000)
libXt.so.6 => /usr/lib64/libXt.so.6 (0x00007f4b20be0000)
libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f4b209d7000)
libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f4b207bb000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f4b2047c000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f4b2026a000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f4b1ff19000)
libz.so.1 => /lib64/libz.so.1 (0x00007f4b1fd03000)
libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007f4b1faf5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4b1f8d8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4b1f6d4000)
/lib64/ld-linux-x86-64.so.2 (0x0000003955a00000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f4b1f4cf000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f4b1f2b4000)
librt.so.1 => /lib64/librt.so.1 (0x00007f4b1f0ab000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f4b1eea8000)

After this, Image Magick loaded correctly for the apache user. An alternative to this would be to use lddconfig to add the path to the missing file for the apache user, in my case it had been placed in an odd location so wasn’t appropriate.

If you, like me have fiddled with your MyBookLive to make it do alot more than it was designed to including updating the version of PHP, be aware if it throws a load of “cannot modify header” errors when launching the UI you just need to do the following: -

Edit your php.ini and ensure that error reporting goes to the apache error log not to the end user. The UI will now come up, the errors themselves are caused by the cake framework calling deprecated methods in the new version of PHP, clearly the better fix would be to upgrade the cake framework on the box but who knows what issues that could cause.

Just been looking into mod_security. It’s a fairly exhaustive security module for Apache. Hugely configurable and by the looks of it, extremely useful.

So far, I am just using it’s base rules but I also wanted to limit the number of allowed attempted login requests, I did this by creating a new config file in conf.d along with the existing initial config. You can call it what you want .conf then add contents such as:

[code]
SecDebugLog "/var/log/httpd/data/debug.log"
SecDebugLogLevel 2
SecDataDir "/var/log/httpd/data/data/"

SecServerSignature "AMIGA OS Apache/1.2"
#SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog"
SecRule RESPONSE_STATUS ^401$ "t:none,phase:5,nolog,setvar:ip.auth_attempt=+1,expirevar:ip.auth_attempt=60"
SecRule IP:AUTH_ATTEMPT "@gt 20" "log,drop,phase:1,msg:'Possible Brute Force Attack'
[/code]

Another cheeky thing just slipped in there is changing the server’s identification string, just to help stop potential attackers knowing which exact version of Apache you are running, and  on what platform

The config there, allows up to 20 logins before it starts dropping the connection to that IP. If the login attempts stop for more than a minute it will start allowing logins again from that IP.

Recently at work we have had some fairly nasty brute force attacks from over 200 unique IP addresses.

Been looking into a few options, but one fairly quick option to get set up is mod_evasive for Apache.

http://www.mydigitallife.info/2007/08/15/install-mod_evasive-for-apache-to-prevent-ddos-attacks/

I am currently trialling it, so will post an update. I am also looking at mod_security.

This is far from comprehensive, but if you are getting an awful lot of HEAD requests in your Apache logs from odd user agents, such as the “Morpheus F’ing Scanner” or such, then the following ReWrite rules might be useful for black holing them.
[code]
RewriteCond %{HTTP_USER_AGENT} ^Morfeus
RewriteRule ^.*$ - [F]
RewriteCond %{HTTP_USER_AGENT} ^.*DigiExt
RewriteRule ^.*$ - [F]
[/code]

Passing the spaces in a URL through to another URL using a proxy style re-write in Apache can be a slight pain because as standard it basically cuts off the URL at the first space.

The answer is rather easy once you know how: -

[sourcecode language="bash"]
RewriteEngine ON
RewriteMap escape int:escape
RewriteRule ^/search/([^/]+)/?$       http://%{HTTP_HOST}/index.php?action=search&search_txt=${escape:$1} [P]
[/sourcecode]

In this example index.php should then receive whatever is after /search/ on the url until the next optional /

This has been described many times and in many ways by so many sites, but usually the descriptions are long and tedious. If you simply want to know how to get your website’s pages to be compressed if the browser supports it, or not if the browser doesn’t add the following lines to your Apache configuration file: -

[sourcecode language="bash"]
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
[/sourcecode]

Basically compress anything that can be compressed using the gzip algorithm ignore images because they are already compressed.

I put these directives within my Virtualhost but they could be just used in an .htaccess file I believe.

To test it is working, install the firefox web developers plugin, open your page, click the information drop down and select the option to view the page headers you should see something like: -

[sourcecode language="bash"]
Date: Tue, 09 Mar 2010 10:42:56 GMT
Server: Apache/2.2.x (SGI)
X-Powered-By: PHP/5.1.xx
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Tue, 09 Mar 2010 10:42:57 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip —– This being the item of interest
Content-Length: 12115
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from conway
Connection: keep-alive
200 OK

[/sourcecode]