Configure Centrify Express with Apache’s mod_auth_kerb

I was lucky enough to spend the morning trying to get mod_auth_kerb working with our existing installation of Centrify without creating any additional SPNs.

It was actually very straight forward except for the missing component of the secret sauce, that’s not documented in many places.
Basically to get it to work perform the following on RedHat 6 (and CentOS 6):

yum install httpd
yum install mod_auth_kerb

vim /etc/httpd/conf.d/auth_kerb.conf

#
# The mod_auth_kerb module implements Kerberos authentication over
# HTTP, following the "Negotiate" protocol.
#

LoadModule auth_kerb_module modules/mod_auth_kerb.so

#
# Sample configuration: Kerberos authentication must only be
# used over SSL to prevent replay attacks.  The keytab file
# configured must be readable only by the "apache" user, and
# must contain service keys for "HTTP/www.example.com", where
# "www.example.com" is the FQDN of this server.
#

<Location /private>
  SSLRequireSSL
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  KrbAuthRealms YOURDOMAIN.COM
  Krb5KeyTab /etc/krb5.keytab
# KrbServiceName is the Centrify secret sauce
  KrbServiceName http
  require valid-user
</Location>

chown root:apache /etc/krb5.keytab
chmod 640 /etc/krb5.keytab

And that’s it. Hopefully “KrbServiceName http” was the secret sauce you needed!

Configure Apache logging to use source IP address behind load balancer

In this day and age load balancers are pretty common, whether it’s a service like Incapsula, Amazon ELB or anything else that proxies web traffic. One of the annoyances of proxies is that source address gets rewritten and if you want to know where your visitors are coming from then having the original source IP address helps.
Within Apache or most proxies for that matter they insert headers and the header we would like to take advantage of is “X-Forwarder-For”.

Now you could rewrite the Apache configuration to use the X-Forwarder-For header in place of the originating server’s (load balancer) IP address, the benefit of this is that Splunk will be happy with the builtin extractions. The downside is you should never trust headers as they can be manipulated client side and forged.

Here are two example from the vhost configuration file:

<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        ServerName www.cammckenzie.com
        ErrorLog logs/ssl_error_log
        LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i""

The above example is from a default configuration

Now if you wanted to replace the load balancer’s IP address with the X-Forwarder-For IP addresses you “could” use:

<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        ServerName www.cammckenzie.com
        ErrorLog logs/ssl_error_log
        LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i""

The above example dropped the load balancer’s IP address altogether and replaced it with the X-Forwarder-For address. This example is ultimately bad due to: dropping the true originating server altogether and now the Splunk inbuilt extractions will be broken if there is more that one address in the X-Forwarder-For list.

Perhaps what is a better idea is:

<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        ServerName www.cammckenzie.com
        ErrorLog logs/ssl_error_log
        LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" srcip="%{X-Forwarded-For}i""

This example is perhaps the best solution because you keep the original information available and intact, you haven’t broken the Splunk extractions and you have helped your Splunk install (a little bit) by creating a key value pair for “srcip”.

And just to show off and get really complicated you could perform a bit of filtering and if you know that all requests will be X-Forwarded-For and tired of your load balancer health checks spamming your logs you could perform something like the following:

<VirtualHost *:443>
        ServerAdmin webmaster@localhost
        ServerName www.cammckenzie.com
        ErrorLog logs/ssl_error_log
        LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" ELBCheck
        LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" srcip="%{X-Forwarded-For}i"" XForwarderFor
        SetEnvIf X-Forwarded-For "^.*..*..*..*" forwarded
        CustomLog logs/access_log XForwarderFor env=forwarded
        CustomLog logs/elb_health_check_access_log ELBCheck env=!forwarded

Now this example basically puts the Amazon’s elastic load balancer’s health check in one file and genuine requests in another!

SSH Forced commands from Web Page

Are you a paranoid nerd, who’s business requirements are very strict about IT security? No, well you may as well stop reading here.

Perhaps you have a business requirement to perform some random function on a server that only allows SSH access, but the rest of the business requires simple press button access to perform those functions?

Well with SSH force command wrappers, SSH keys and PHP you too can have simple click button access for the rest of the business!

Basically with a Linux apache server with PHP use the following code:
[Read More…]

Enable Apache’s inbuilt chroot functionality

This works on all versions of Apache webserver greater than 2.2.10.
I’ll presume you have a current working version of Apache serving files from /var/www/

mkdir -p /chroot/var/ 

Required for PHP5 compatibility:

mkdir -p /chroot/var/lib/php5
chown root:www-data /chroot/var/lib/php5
chmod 770 /chroot/var/lib/php5
cp /etc/localtime /chroot/etc/localtime
cp -R /usr/share/zoneinfo /chroot/usr/share/zoneinfo
cp -R /usr/share/apache2 /chroot/usr/share/apache2 
mv /var/www /chroot/var/ 

To help with compatibility and user / sysadmin expectations

ln -s /chroot/var/www /var/www 

Enable Apache’s in-built chroot (Debian)

echo "ChrootDir /chroot" > /etc/apache2/conf.d/chroot 

Enable Apache’s in-built chroot (Redhat/CentOS/Fedora)

echo "ChrootDir /chroot" >> /etc/httpd/conf/httpd.conf 
semanage fcontext -a -t httpd_sys_content_t “/chroot/var/www(/.*)?”
service apache2 restart 

Now test your damn website! Logfiles are your friend for troubleshooting any bugs :-)

How to fix: mktime(): It is not safe to rely on the system’s timezone settings

You might encounter a similar error message perhaps running wordpress or some other webapp.

[Tue Mar 12 09:41:14 2013] [error] [client 1.2.3.4] PHP Warning:  mktime(): It is not safe to rely on 
the system's timezone settings. 
You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case
 you used any of those methods and you are still getting this warning, you most likely misspelled the 
timezone identifier. We selected 'Australia/ACT' for 'EST/10.0/no DST' instead in 
/var/www/html/smarty/plugins/function.html_select_date.php on line 192

To resolve either fix the code or an easy fix is edit: /etc/php5/php.ini or /etc/php.ini depending on your operating system.
Look for the line:

;date.timezone = 

and make it:

date.timezone = 'Australia/Brisbane'

See a list of supported timezones from here: http://www.php.net/manual/en/timezones.php