mod_security, apache httpd, glassfish - Part 4

Part 4, mod_sec install.

One dependency that I missed downloading earlier was libXML2.  This is a dependency for mod_security.  If you wish, you can also install lua and curl.  Lua is needed if you plan to write your own rules and want to use the new lua engine.  I'm not really planning on writing rules, the base rules are pretty good.  As for curl, it is only needed if you want to send logs to a central repo like loglogics.  Since I don't have that kind of infrastructure setup, I won't worry about that in these posts.  If you wish to install those, simple follow the install instructions and then edit the configure to point to the locations in which you have installed the dependencies.

For now, navigate over to http://xmlsoft.org/downloads.html and download libXML2.

./configure --prefix=/path/to/deps/ --enable-shared 

Now we can install mod_security

CC="gcc -m64" ./configure --prefix=/path/to/deps/ --with apxs=/path/to/httpd/bin/apxs --with-pcre=/path/to/deps/bin/pcre-config --with-apr=/path/to/deps/bin/apr-1-config --with-apu=/path/to/deps/bin/apu-1-config --with-libxml=/path/to/deps/bin/xml2-config

When you untared the mod_security files, there was a rules directory.  We are going to copy that directory to /path/to/httpd/conf/rules.  Next, you are going to copy the modsecurity_crs_10_config.conf.example to the same file name minus the example part.  The purpose of this series of articles is not to go through an indepth setup of mod_security.  Just enough to get it working.  You are going to go into the file you just copied and make the following change.

#
# Review your SecRuleEngine settings.  If you want to
# allow blocking, then set it to On however check your SecDefaultAction setting
# to ensure that it is set appropriately.
#
#SecRuleEngine DetectionOnly 
SecRuleEngine On

This is basically going to turn the rules engine on.  You may want to put it on detection only if you are testing a legacy app.  We are going to create another file by the name of modsecurity_crs_10_global_config.conf.  In this file, we are going to basically setup some more mod_security rules.

SecServerSignature "Microsoft-IIS/6.0"
SecDebugLog /cardlock/httpd/logs/modsec_debug.log 
SecDebugLogLevel 3 

Basically this just sets the server to identify itself as IIS 6.  This is a little "security through obscurity".  Hopefully a few script kiddies will get deterred by this.

We need to add the following to our httpd.conf

<ifmodule security2_module>
 Include conf/rules/modsecurity_crs_10_global_config.conf
</ifmodule>

We need to now actually apply these rules to our site that we have just created.  In our site.conf, we should add the following.

Include conf/rules/modsecurity_crs_10_config.conf
Include conf/rules/base_rules/*.conf
Include conf/rules/optional_rules/*.conf

When you startup your httpd now, you may get some "syntax" errors inside the mod_security configuration files. I just go in an delete/comment out the line in question. This is obviously okay if you are not using the technology the line pertains to. For example, you can probably safely comment out any php rules if you are not using php in your website. One in particular is about a data file missing for comment spam. You can go and get it (say google) or you can just deal with the line that is causing the issue.

After you startup apache, you will notice that the modsec_debug.log is getting populated. Feel free to test out mod_security. You can either use a tool like w3af, or just try putting sql injection as a parameter. You should see mod_security block it.

mod_security, apache httpd, glassfish - Part 3

Part three.

Just to recap, we have now installed Glassfish, Java, all the deps for apache httpd, and the httpd itself.  At this point you can startup apache httpd, and then try to navigate to the main page.  You should get a 403 Forbidden. This is because we have not configured apache yet.

The apache httpd configuration file (located in apache_httpd_root/conf/httpd.conf) is a very well documented file.  I'm not going to go through all of the details in the file, but I will touch on a few.  Ideally, you will make a copy of the httpd.conf and start with a fresh file.  From a security perspective, you want to have the configuration file to contain as little "junk" as possible.  This will assist when you are trying to figure out a problem with your server configuration.  It is just easier to read without all the explanations, plain and simple.

## Sample Apache httpd.conf configuration

ServerRoot "/path/to/apache/httpd"
ServerAdmin "your.address@you.com"
ServerTokens Full
ServerName myserver.myserveraddress.com
Listen 80

User apache
Group apache

LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule rewrite_module modules/mod_rewrite.so

DocumentRoot "/path/to/httpd/htdocs"

<Directory />
     Options FollowSymLinks
     AllowOverride None
     Order deny,allow
     Deny from all
</Directory>

ErrorLog "|/.../httpd/bin/rotatelogs -f /.../httpd/logs/error_log.%Y%m%d  86400"
TransferLog "|/.../httpd/bin/rotatelogs -f /.../httpd/logs/access_log.%Y%m%d 86400"

include conf/site.conf

So basically, the first section is just getting general information.  Don't worry about the ServerTokens Full just yet, we are going to use mod security to change our server signature in order to try and fool the script kiddies.  The next section sets up the user you want apache to run as.  If you want apache to run on port 80, we need to start apache as root.  The user/group defined in the file is what apache will switch to after it binds to port 80.  The load_modules section is simply loading all of our shared modules that we need.  The Directory tag is setting up the base permissions.  Basically, deny everyone for right now, until we get our site configured.  As mentioned before, apache has wicked documentation, so I suggest you read it.  Lets move on.

Our goal here is to get apache httpd talking to Glassfish.  Once we establish that, we can work on implementing the advanced features of mod_security.

There are two ways to get apache httpd to play nice with Glassfish.  One is to use mod_proxy.  The other is to use mod_jk.  Here is a very short list of pros and cons.

Mod_Proxy
pro:  Super simple to setup.
con:  Glassfish will see every request as originating from the apache httpd installation as opposed to someone out in the net.  This is bad if you want glassfish to handle some type of security based on ip addresses.

Mod_JK
pro:  More information provided to glassfish (ip address of originator etc.)  Works on a specific language to connect which is faster than mod_proxy.  Has built in support for workers to help support load.
cons:  Hard to setup

For the purpose of this article, we are just going to use mod_proxy.  I may come back later an make another post on using mod_jk.

We need to create a site.conf file with the following information.

<VirtualHost *:80>
  ProxyPass / http://localhost:8080
  ProxyPassReverse / http://localhost:8080
</VirtualHost>

Start up your Glassfish (and confirm that it is running).  Then start up your apache httpd.  You should be able to go to http://localhost and get served the glassfish page.

mod_security, apache httpd, glassfish - Part 2

Part deux!

Just a recap, part 1 took us through installing glassfish. We now have glassfish up and running on our system.

This part will focus on setting up the apache httpd.

1) Compile and install apr-1.4.2

tar xzf apr-1.4.2.tar.gz
cd apr-utils-1.3.10
CC="gcc -m64" ./configure --prefix=/path/to/deps --with-apr=/path/to/deps/bin/apr-1-config
make; make test
make install

The above code is going to be followed a lot (to a certain degree) so I'm only going to explain it this once.  Untar the archive.  Run the config script based on the parameters you want. The CC is compiler arguments and makes it compile for 64 bit (which is what my machine is).  Make the binary, test it, install it.

You will also want to update your bashrc again.

LD_LIBRARY_PATH=<path/to/deps/lib>

Don't forget to source.

2) Compile and install apr-utils

tar xzf apr-util-1.3.10.tar.gz
cd apr-utils-1.3.10
CC="gcc -m64" ./configure --prefix=/path/to/deps --with-apr=/paht/to/deps/bin/apr-1-config
make; make test
make install

3) Compile and install pcre

CC="gcc -m64" ./configure --prefix=/path/to/deps --enabled-shared

5) Compile and install apache httpd
Now that we have installed all the dependencies, we need to configure and install the httpd.  There are a couple of security issues that come up during the installation phase.  Most admins would say (and I'm sure there is a "principle" written about it somewhere) that you should only compile what you actually need.  Apache httpd comes with several built in modules that you would never ever use in a reverse proxy situation.  You could approach this two ways.
1)  Build all the modules with the --enable-shared=all options.  This will build all modules as shared.  Then you can simply edit your config as to which modules you want to load or not.
2)  Use the configure script to only compile the modules you need
There are pros and cons to both approaches.  With (1), all the modules are still there.  If an attacker somehow got access to the conf directory, they could enable modules that could cause futher holes. More realistically, however, someone could accidently turn on a module, and that module could have a vulnerability.  Option two allows you to have complete control on what is actually on the system.  If you ever needed an additional module, however, you would have to recompile to build it.  Because I'm game for pain, I'm going to go with option 2.

C="gcc -m64" ./configure --disable-autoindex --disable-auth-basic --disable-cgi --disable-cgid --disable-userdir --enable-expires=shared --enable-headers=shared --enable-proxy=shared --enable-proxy-http=shared --enable-rewrite=shared --enable-so --enable-ssl=shared --enable-unique-id=shared --with-apr=/path/to/deps/bin/apr-1-config --with-apr-util=/path/to/deps/bin/apu-1-config --with-pcre=/path/to/deps/bin/pcre-config --with-ssl=/path/to/deps --prefix=/path/to/root/httpd-2.2.17

You can go through the configure options on your own if you wish.  The only real requirements are ssl, rewrite, proxy, proxy-http, and unique-id.

After you have that all installed, you will want to run apache to ensure that it starts up.  Because apache is currently configured for port 80, you will have to run it as root.  Ideally you would get a startup script and sudo access to run it, but in this case, just su to root and run apachectl from the bin directory.  You should get a Forbidden error message when you type localhost into your browser.

In the next part, I will talk about configuring apache httpd and using mod_proxy to connect to glassfish.

mod_security, apache httpd, glassfish - Part 1

This post is going to be about building the above from scratch using as little system dependencies as possible.  You may ask yourself why you need to do this.  Well sometimes you work in an organization where your unix team doesn't do this stuff for you.  If they do, you would be subject to the yum rage that would happen every quarter, even if you didn't really need to upgrade your apache version.  Upgrading certain dependencies could mean having to recompile entire applications in order to meet patching schedules.  Of course, you should be upgrading your installations when new updates are found ..... but I digress.

The setup is going to be quite simple.  We are going to use apache httpd in a reverse proxy configuration with mod_security.  We are then going to use mod_proxy (I'll get to this later) to connect the apache httpd reverse proxy with the glassfish back end.  I am doing all of this on a CentOS 5.5 machine.

Before we start, there are a few dependencies that you are going to have to download:

1) libapr and libapr-util
If you were just compiling apache by itself, you could use the built in modules.  But it is very important that mod_security be compiled with the same versions as apache.  You can download them at http://apr.apache.org/ .  We are going to use version 1.4.2(apr) and 1.3.10(apr-utils)

2) libpcre
A perl regular expression library.  Same as above, it is very important that the same versions be used for mod_security and apache httpd.  http://www.pcre.org/ version 8.11

3) openssl
Any respectable website these days has SSL capabilities.  Even if you are not using it right away, we should configure your reverse proxy to be able to handle it.   http://www.openssl.org/source/ v1.0.0c

4) mod_security
http://www.modsecurity.org/download/ v2.5.13

5) Apache httpd
http://httpd.apache.org/download.cgi#apache22 v2.2.17

6) Glassfish
http://glassfish.java.net/downloads/3.0.1-final.html v3.0.1 (zip)

7) Java JDK
JDK 6u23 (From the oracle website)

That should be good for now.  Lets start getting our environment built.  I'm going to start with getting glassfish up and running since it is nice and easy.  If you are thinking about a folder structure, I usually make a separate folder that I'm going to do all my work in.  I make a files directory (it is ALWAYS handy to have the source with you later on... say when you want to rebuild).  I download all my files in there.  I make a dependencies folder and that is where I will install the dependencies that I need (for the most part).

Glassfish InstallGlassfish depends on a JAVA JDK being installed.  With the way most JAVA stuff is distributed, this is a fairly simple process.

1)  Unpack JAVA JDK
With the bin distribution, this is quite easy.

chmod 700 jdk-6u23-linux-x64.bin
./jdk-6u23-linux-x64.bin
mv jdk1.6.0_23 ../
ln -s jdk1.6.0_23 java

Quick explanation.  I had to make the bin executable (1).  I ran the bin which created the java jdk directory.  I moved that directory one directory back so it isn't under files.  I created a soft link called java.  The soft link comes in handy when you are upgrading versions.  You won't need to keep changing your bashrc to the new java folder, just change the soft link.

2) Update environment variables
Now that you have installed java, you are going to want to update your environment variables.  You can do that multiple ways.  If you are running everything from the command line and are using bash, you need to update your .bashrc in your home directory.
export JAVA_HOME=<path/to/java>
export PATH=<path/to/java/bin>:$PATH

Don't forget to source the bashrc (source ~/.bashrc) when you are done so the changes take effect.

3) Unpack glassfish
You should have downloaded the zip file for the glassfish distribution.  Most linux distros these days come with unzip.  If you don't have it, you'll have to get creative (or go build it...)

unzip glassfish-3.0.1.zip
mv glassfishv3 ../
ln -s glassfishv3 glassfish

Once again you'll want to edit your environment variables.  In this case, you will want to edit your path.

export PATH=</path/to/java/bin>:</path/to/glassfish/bin>:$PATH

Once you have sourced your bashrc, you can now try to run glassfish.

asadmin start-domain

You should see it successful start up.  Try it by trying to hit localhost:8080 and localhost:4848 in a web browser.

Glassfish will need to be secured.  I'm not going to go into this in this series of posts, but you would want to do basic things like (not an exhaustive list):
1)  Block 8080 from being accessible (except for local).  After all, that is why we are installing apache and mod_security
2)  Block 4848 from being accessible  (except for local)
3)  Enable the security manager inside of glassfish