the

Little Projects

of Shawn M. Jones

I know many of you out there are saying “mod_security’s been around forever and you’re just reading about it now?”

The truth is that I’ve heard of it, but hadn’t had both the time and the reminder to implement it until now.

The module provides Apache with application-level firewalling, protecting it from all manner of web attacks.

It’s relatively easy to use these days.

Download it from: http://www.modsecurity.org/download/index.html
Install it as per the README

Then you have to do some stuff that’s not in the docs I found, hence I’m writing this blog post.

Edit /etc/httpd/conf/httpd.conf

Put the following directives in:

LoadFile /usr/lib/libxml2.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so

That mod_unique_id isn’t mentioned in the directions. Ergh!

Also, make sure you download the rules too.

You unzip/tar them into your /etc/httpd/conf.d directory (or make your own modsecurity directory and tell Apache to Include it).

Restart Apache.

Now you’ve got an application-level firewall on your web server. It took less than half an hour. Most of that was reading docs.

If you don’t know what SELinux is, start here.

I just spent the last hour or two trying to figure out why syslog would not log anything on one of my machines. It turns out I must’ve copied an updated /etc/services file from /tmp to /etc. This would normally be fine, but the file did not contain the correct context. Instead, copying it gave it the context of the /tmp directory.

Hence, syslog would not start. Because syslog is where SELinux logs its errors, I couldn’t see any errors to lead me to figure out what the problem was.

Once I changed SELinux from enforcing to permissive with:

/usr/sbin/setenforcing Permissive

I could see that syslog started fine and was telling me that the context on /etc/services was out of wack.

Ergh…

I wonder if there is some way I can make sure this doesn’t happen again?

I guess I could use the setfiles command frequently to ensure that all of the file contexts are set correctly.

Sheesh.

How was your day?

Yip, I’m still alive.

I am a computer geek.

I do computer geek things.

After all of the work on the house for the past few months, I needed to engage in a geeky project, something that would benefit my network. Something that has plagued me since my server rebuild has been the lack of a centralized authentication scheme for my network. LDAP, of course, is the choice I had made, but setting it up and understanding what was going on would take longer than setting it up.

Tonight, I have published a brief article entitled “SSL LDAP Server on CentOS 5″ which details how to set up the LDAP server portion of the authentication system. Soon I will include an article on the client end. One will be for CentOS and the final one will be for Windows, which can use pGina to load an LDAP module and authenticate (I found that to be very cool).

It wasn’t enough for me to just have centralized authentication. If that were all I needed, I would have used NIS. I wanted encryption so that any rogue program or user on my small home network would not be able to sniff my passwords off the wire. Paranoid? Yes, yes I am, but not enough to use Kerberos yet. I also wanted something that pGina would work with. Many factors had to be considered for my authentication scheme, including brief experiments with Samba and Microsoft Active Directory.

I also wanted to know how this all worked for work. What good is a security person who doesn’t understand how the technology works? I don’t know. There are too many of those. Maybe I can make things better by trying to be one that does, in some way, know how the tech works. It’s a goal.

A day long been it has…

I was expecting to leave the area around our Nation’s Capital before noon today.

The vulnerability scanning tool that we are mandated to use (Retina) failed to properly complete a scan of our customer’s network yesterday.

I spent this afternoon trying to figure out what was wrong with it.

Eventually, utilizing other tools at my disposal I was able to rule out connection issues and fix Retina itself.

I don’t know what went wrong with the initial scan. I do know that removing all of the xml files in the directory where Retina stores its job information fixed it. The new scan of their network took 3 hours to complete. In the interim I helped our customer set up their own vulnerability scanner so that they can scan their own network in the future.

Yay me. The customer is happy. I’m exhausted. All is ok with the world.

Tomorrow is bowling day at work. I must remember to wear my T-shirt.

No time for photos.